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/.markdownlint.json b/.markdownlint.json new file mode 100644 index 0000000000..66e4c0d02a --- /dev/null +++ b/.markdownlint.json @@ -0,0 +1,26 @@ +{ + "default": false, + "resultVersion": 1, + "MD001": true, + "MD002": true, + "MD003": true, + "MD005": true, + "MD006": true, + "MD011": true, + "MD012": true, + "MD018": true, + "MD019": true, + "MD023": true, + "MD024": true, + "MD025": true, + "MD027": true, + "MD031": true, + "MD034": true, + "MD035": true, + "MD037": true, + "MD038": true, + "MD039": true, + "MD041": true, + "MD042": true, + "MD045": true +} 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 a1749b8dbc..0000000000 --- a/.vscode/settings.json +++ /dev/null @@ -1,4 +0,0 @@ -// Place your settings in this file to overwrite default and user settings. -{ - "editor.wrappingColumn": 0 -} \ No newline at end of file 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 238deccd6d..0418e709cf 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -4,53 +4,45 @@ The following is a set of guidelines for contributing to the Auth0 documentation. These are just guidelines, not rules, use your best judgment and feel free to propose changes to this document in a pull request. -#### Table Of Contents +## Table of Contents -[General Guidelines](#general-guidelines) - -[Reusing Content](#reusing-content) - -[Markdown](#markdown) +* [General Guidelines](#general-guidelines) +* [Reusing Content](#reusing-content) +* [Markdown](#markdown) * [Headings](#headings) - * [Warning banner](#warning-banner) - * [Panels](#panels) - * [Alerts](#alerts) + * [UI Components](#ui-components) * [HTTP Request Snippets](#http-request-snippets) * [Escaping Strings](#escaping-strings) + * [Image zooming](#image-zooming) * [Screenshots](#screenshots) * [Front Matter](#front-matter) - -[Finishing](#finishing) - -[Editing Text](#editing-with-wordy) - -[Test Procedures](#text-procedures) - -[Review Apps](#review-apps) - -[Quickstarts](#quickstarts) + * [Linting](#linting) +* [Sidebar](#sidebar) +* [Beta Content](#beta-content) +* [Finishing](#finishing) +* [Editing with Wordy](#editing-with-wordy) +* [Test Procedures](#test-procedures) +* [Review Apps](#review-apps) +* [Quickstarts](#quickstarts) * [Creating Quickstarts](#creating-quickstarts) + * [Versioning Quickstarts](#versioning-quickstarts) * [Quickstart Guidelines](#quickstart-guidelines) * [Seed Projects](#seed-projects) - -[Updates Feed](#updates-feed) - -[API](#api) - -[Document Front-matter](#document-front-matter) - -[Document Variables](#document-variables) +* [Updates Feed](#updates-feed) +* [API](#api) +* [Code snippets](#code-snippets) +* [Document Front-matter](#document-front-matter) +* [Document Variables](#document-variables) * [Common Variables](#common-variables) * [User Specific Variables](#user-specific-variables) - - - +* [Versioning](#versioning) ## General Guidelines + * 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. @@ -58,87 +50,151 @@ The following is a set of guidelines for contributing to the Auth0 documentation * Run all images through [TinyPNG](https://tinypng.com/). ## Reusing content + To avoid duplication of content, you can create document fragments to be referenced from other documents. The process of including another document is shown below. First, create your fragment document. The convention is to name fragments with an underscore, like: `_mydocument.md`. After you create your markdown document, you can reference it in another document with a relative path: -``` +```markdown <%= include('../_mydocument.md') %> ``` Additionally, you can send variables to the included document: -``` +```markdown <%= include('../_mydocument.md', { key: 'value', something: true }) %> ``` ## 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` VALID: `# My Heading` -### Warning banner -You can add a warning banner to the top of a page to notify that a page is deprecated or other similar messages. +### UI Components -``` -::: warning-banner -You message here +General advice: +- 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. + +#### Note + +Use this component if you want to display some extra information, links to related content or clarifications. + +Only use this if the content is brief (one to four lines), if not use the `panel` component. + +```markdown +::: note +If you need a refresher on the OAuth 2.0 protocol, you can go through our OAuth 2.0 article. ::: ``` -### Panels -Panels can be useful to separate information from the main body of a document. If you want to add versioning information use [alerts](#alerts) instead. +![Note container](https://cloud.githubusercontent.com/assets/6318057/26081072/91318302-399f-11e7-8cf2-57cb55c6ce1d.png) -``` -::: panel-primary This is a panel -Panel content +#### Warning + +Use this component if you want to notify that the content is deprecated, there is a security issue or to highlight some **very important** information. + +Only use this if the content is brief (one to four lines), if not use the `panel-warning` component. It's recommended to keep the copy of the warnings short and clear. + +```markdown +::: warning +Long-lived tokens compromise your security. Following this process is NOT recommended. ::: +``` + +![Warning container](https://cloud.githubusercontent.com/assets/6318057/26081268/6a894af4-39a0-11e7-96bc-6ef69a3be941.png) + +#### Panels + +Use panels when you want to separate long information from the main body of the document. + +Try to add a meaningful title to the panel. Avoid using "NOTE" or "WARNING". -::: panel-warning This is a warning -Panel content +We support two types of panels: **panel** and **panel-warning**. + +##### Panel (default) + +```markdown +::: panel Title +Description ::: -::: panel-info This is info -Panel content +::: panel Enable APIs Section +If you can't see the [API section](${manage_url}/#/apis) in the left hand menu of the dashboard then you will have to enable it. Navigate to your [Account Advanced Settings](${manage_url}/#/account/advanced), scroll down to the *Settings* section and toggle the **Enable APIs Section** switch. ::: +``` + +![Panel default container](https://cloud.githubusercontent.com/assets/6318057/26082080/4a465756-39a4-11e7-99a1-79846c7cdfa6.png) + +##### Panel (warning) -::: panel-danger This is a dangerous -Panel content +```markdown +::: panel-warning Title +Description ::: -::: panel-success This is good -Panel content +::: 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 Flow](/flows/concepts/implicit) is more appropriate in that case. ::: ``` -### Alerts +![Panel warning container](https://cloud.githubusercontent.com/assets/6318057/26082243/588586b0-39a5-11e7-88ef-3290be88e96a.png) -Alerts should be used to display brief versioning information. For example: +##### Next steps list -```html -
- Heads up! This document uses an outdated version of Lock (version 9). Learn how to migrate to version 10, or, if you're new to Lock, start out with the Lock 10 Documentation. -
-``` +Use this container to mark a Next to read/Continue reading list of links. -looks like this: +Try to keep the list length to a minimum (up to 5 links). -![Alert displaying version info](/media/readme/alert-version.png) +``` +::: next-steps +* [Access Token](/tokens/access-token) +* [ID Token](/tokens/id-token) +* [OpenID Connect Overview](/protocols/oidc) +::: +``` -[Styleguide: Alerts](http://styleguide.auth0.com/#alert) +![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. -**NOTE:** You need to set the language type to `har` for this to work. View this raw markdown document for an example. +The library we use is [HTTP Snippet](https://github.com/Kong/httpsnippet). +**NOTE:** You need to set the language type to `har` for this to work. View this raw markdown document for an example. ```har { @@ -166,12 +222,13 @@ You can add a [HAR request format](http://www.softwareishard.com/blog/har-12-spe * cookies [array] - List of cookie objects. * headers [array] - List of header objects. * queryString [array] - List of query parameter objects. -* postData [object, optional] - Posted data info. See: http://www.softwareishard.com/blog/har-12-spec/#postData +* postData [object, optional] - Posted data info. See: * headersSize [number] - Total number of bytes from the start of the HTTP request message until (and including) the double CRLF before the body. Set to -1 if the info is not available. * bodySize [number] - Size of the request body (POST data payload) in bytes. Set to -1 if the info is not available. * comment [string, optional] (new in 1.2) - A comment provided by the user or the application. -#### Escaping Strings +### Escaping Strings + Occasionally you will need to use strings that contain the characters that are used for template replacement. The examples of this are `${example}`, `<% example %>` and `<%= example %>`. If you try to include these in your doc or a code snippet the document will fail to render because our template engine will try to replace your variable, i.e. `example`. However, you can include these by escaping them as shown below. Change `${example}` to `<%= "${example}" %>`. @@ -180,7 +237,19 @@ Change `<%= example %>` to `${ "<%= example %>" }`. Change `<% example %>` to `${ "<% example %>" }`. +### Image zooming + +You can enable zooming adding the `zoomable` data attribute to any image tag in html: + + +```html +Client Credentials Grant Flow +``` + +It's recommended to add this only for large images (like diagrams) and use it with .svg images. + ### Screenshots + On Mac OS X screenshots of the Auth0 interface need to be taken with Chrome, taking into account the following: 1. The browser cannot show any plugins, customizations, or bookmarks. @@ -193,7 +262,7 @@ On Mac OS X screenshots of the Auth0 interface need to be taken with Chrome, tak ``` 1. Auth0 screenshots should capture the complete browser window (**Command + Shift + 4**, then press **Space**). 1. Use color **#0099CC** for highlights. - 1. Resize image to a maximum 900px width. + 1. Resize image to a maximum 1500px width. Example: @@ -202,39 +271,100 @@ On Mac OS X screenshots of the Auth0 interface need to be taken with Chrome, tak **NOTE**: When you use the `Command + Shift + 4 + Space bar` shortcut Mac adds a drop shadow to your screenshot. This is normal and you don't have to remove it. #### Mobile Screenshots + For mobile screenshots you should use the [Phone Mockup](http://styleguide.auth0.com/#phone-mockup) component from styleguide. #### Close-ups + The exception to showing the full browser window is for highlighting a detail as part of a tutorial, for example, to show a field requiring input. It is often best to shrink the screenshot slightly to avoid having the image of the UI be mistaken for the actual UI. #### Borders + For close-ups and other screenshots that do not include the browser window, apply a 1px centered border (**select all > edit > stroke**) of color **#cccccc** to keep the image from blending with the background and appearing to float. ### Front Matter + 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 is disabled. Set it to `true` to display the dropdown. + Example front matter: -``` + +```yaml --- title: My Document description: This is a document +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`. URL Front Matter -``` + +```yaml --- url: /path/to/document --- ``` +### Linting + +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 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 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 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`: + +``` +- title: "Title text" + category: true +``` + +You can hide an article from the sidebar with the `hidden` key: + +``` +- title: "Title text" + hidden: true +``` + +You can nest articles with the `children` key: + +``` + - title: Getting Started + url: "/getting-started" + children: + - title: Auth0 Overview + url: /getting-started/overview + - title: The Basics + url: /getting-started/the-basics +``` + + +## Beta Content + +To mark a doc as Beta set this metadata: + +``` +beta: true +``` + +This will add a `Beta` button next to the header. + ## Finishing Prior to submitting your pull request, please check and edit your work. You should: @@ -256,32 +386,34 @@ To create and submit a job to Wordy: ![](media/readme/create-job.png) 4. Provide the requested information so that your editor is clear on what needs to be done. +![](media/readme/job-settings.png) - ![](media/readme/job-settings.png) - - 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) - * **Save my brief and language settings for future jobs**: Select this box to persist your chosen settings. +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 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 + Wordy charges based on total word count, which includes code snippets. If possible, remove code snippets prior to submitting your document to Wordy. ### Instructions for Editors + It is helpful to include some instructions for the Wordy editors to let them know that the articles may have words that seem out of place because the article is about technology. -> Please edit for spelling and grammar. Audience consists of programmers and technology readers. Grammar, casing, spelling etc will seem weird in some cases, especially with uses of the word "this", but chances are that those are cases of programming jargon or naming. The final article will include code snippets that have been removed from the text for brevity. Instead, a placeholder called CODE_SNIPPET has been used. +**NOTE**: Please edit for spelling and grammar. Audience consists of programmers and technology readers. Grammar, casing, spelling etc will seem weird in some cases, especially with uses of the word "this", but chances are that those are cases of programming jargon or naming. The final article will include code snippets that have been removed from the text for brevity. Instead, a placeholder called CODE_SNIPPET has been used. ### 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. ## Test Procedures + When testing a document or tutorial: 1. Ensure that the code in the tutorials is correct and functions as expected. @@ -292,6 +424,7 @@ When testing a document or tutorial: 1. Check for outdated dependencies, both Auth0 dependencies and third-party (i.e. node modules, nuget packages, gems, etc.). ## Review Apps + If you have access to the Auth0 Heroku account, you can create a preview release for your pull request: 1. Login to Heroku and open the `auth0-docs-content` pipeline. @@ -305,6 +438,7 @@ If you have access to the Auth0 Heroku account, you can create a preview release ## Quickstarts ### Creating Quickstarts + All quickstart data comes directly from the docs API at `/meta/quickstart`. This means that the quickstart on docs and manage will both consume the same datasource and will always be up-to-date. To add a new quickstart, create a folder with the name of the quickstart in the appropriate folder: [server-apis](/articles/server-apis), [server-platforms](/articles/server-platforms), [native-platforms](/articles/native-platforms), or [client-platforms](/articles/client-platforms). Inside that folder you will need to create an `index.yml` file that contains the following: ```yaml @@ -347,34 +481,49 @@ The `title` will generally be a single word like Introduction or Login as it wil After you publish the doc update, the new quickstart will automatically appear on both docs and manage. +#### Hiding Articles in Navigation + +Articles are included in navigation by default. To hide an article from navigation, +modify the `index.yml` and move the article from `articles` to `hidden_articles`. + +```yaml +articles: + - 00-Intro + - 01-Login +hidden_articles: + - Hidden-Article +``` + ### 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 -Each library that we publish should have appropriate reference documentation. There will be two kinds of reference documentation for each library. The first is automatically generated. Each library should generate reference docs using a tool like jsDocs on every build/release. This will ensure consistent and up to date documentation. +Each library that we publish should have appropriate reference documentation. There will be two kinds of reference documentation for each library. The first is automatically generated. Each library should generate reference docs using a tool like jsDocs on every build/release. This will ensure consistent and up to date documentation. Additionally, many libraries may also need manual documentation showing more sophisticated scenarios. Certainly, Auth0.js and Lock will need significant manual documentation. Other libraries will as needed. -#### Quickstarts -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. +#### 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 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. ##### Web + 0. Intro - Introduction and summary of what the quickstart is about and a Table of Contents 1. Login - Shows hot to create an auth0 application, add the login widget to your code, setup everything, and perform a login. 2. Login with Custom UI - Using auth0.js to build a custom login without Lock. @@ -383,11 +532,11 @@ 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 + 0. Intro - Introduction and summary of what the quickstart is about and a Table of Contents 1. Login - Shows hot to create an auth0 application, add the login widget to your code, setup everything, and perform a login. 2. Login with Custom UI - Using auth0.js to build a custom login without Lock. @@ -396,17 +545,18 @@ 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. - ##### API/Services + 1. Authentication - How to authenticate a user to call an API 2. Authorization - How to perform authorization in a API #### 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 @@ -416,6 +566,7 @@ As appropriate every framework/language should have libraries to help with commo We want to make authentication and authorization as easy as possible for our developers. These libraries are a critical part of that. However, libraries must not wrap functionality of the Lock widgets. We iterate on our Lock widgets too frequently to keep wrappers up to date. We can provide helpers that make Lock easier to include in an app for a particular framework, but these should only expose the core Lock functionality directly, never wrap or abstract it. #### Samples + Each seed project will have a corresponding sample (seed project). The idea of a seed project is that a user can download this and everything is setup and ready for them to run. Each sample for a quickstart should have its own repository in github in the github.com/auth0-samples organization. The structure of the repository is as follows: @@ -433,7 +584,8 @@ Each sample for a quickstart should have its own repository in github in the git In this way, each section of the quickstart has a sample showing the appropriate step. The sample in the numbered folder should exactly match the completed code of the tutorial. The 00 step is the blank empty project. The empty project would typically start with the standard “File->New” project for that particular framework. This means that anyone who is familiar with the framework will understand the starting point. ##### 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” @@ -441,35 +593,34 @@ The README for each sample folder should be written to reflect the objectives of This sample demonstrates how to retrieve an Auth0 user’s profile and how to update it via the Management API. After following the steps outlined here, you will be able to retrieve, set, and update a user profile.” - * Add link to quickstart in README +##### Important Snippets -##### Important Snippets: 1. Installation 2. Retrieving the user’s profile 3. Setting the user’s profile 4. Updating the user’s profile - #### Continuous Integration -Each sample repo should have appropriate CI setup. You should use the appropriate CI system for the sample. Typically this is Travis CI. The CI system does not need to have extensive tests, but should simply ensure that the project downloads dependencies and builds correctly. If possible we should test to make sure there are no build warnings either. +Each sample repo should have appropriate CI setup. You should use the appropriate CI system for the sample. Typically this is Travis CI. The CI system does not need to have extensive tests, but should simply ensure that the project downloads dependencies and builds correctly. If possible we should test to make sure there are no build warnings either. -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: https://travis-ci.org/auth0/Auth0.swift +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 | | :------| :-----------| :-----------| @@ -479,17 +630,17 @@ 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: + ``` AUTH0_CLIENT_ID={CLIENT_ID} AUTH0_DOMAIN={DOMAIN} AUTH0_CLIENT_SECRET={CLIENT_SECRET} ``` -##### Include Code +#### Include Code ``` <%= include('../../_includes/_package', { @@ -505,15 +656,16 @@ AUTH0_CLIENT_SECRET={CLIENT_SECRET} The follow are the values for the package configuration. - | Variable | Description | | :---------------------------- | :----------------------------------------- | | `org` | The organization of the github repo. Can be `auth0` or `auth0-samples`. | | `repo` | The name of the github repository. | | `path` | The path where the sample is contained. This will be the folder that gets downloaded. | | `requirements` | An array of strings representing the system requirements for the project and article. | +| `branch` | The branch of the github repository. If omitted this will default to `master` | ## Updates Feed + Publishing content updates is easy. Just create a yml file in the `/updates` folder in the format `YYYY-MM-DD.yml`. The document should be in the following format. There are three sections of content: added, changed, and fixed. If you are releasing a new thing (such as a new tutorial, document, or new version of an SDK) put it under `added`. Otherwise use `changed` or `fixed`. ``` @@ -552,7 +704,7 @@ fixed: ## API -> WARNING: This API is for Auth0 internal use only. You should not rely on the docs API for anything. There is *NO SLA or support* for the document API. +**WARNING:** This API is for Auth0 internal use only. You should not rely on the docs API for anything. There is *NO SLA or support* for the document API. All document content is accessible through the docs API as well as through regular HTML. @@ -565,12 +717,14 @@ To request content in JSON or JSONP format, pass the header `Accept: 'applicatio You can also request the document metadata be included in the JSON or JSONP responses by appending `?m=1` to the query. ## Code snippets + Code snippets are available both through the API and for use in markdown. Access via API: GET: `/docs/meta/snippets/{hash}` Response: + ```json { "title": "{title}", @@ -587,6 +741,7 @@ ${snippet('{hash}')} ``` ### Connections + Connections are available both through the API and for use in markdown. Access via API: @@ -595,6 +750,7 @@ GET: `/docs/meta/connections` GET: `/docs/meta/connections/{type}` GET: `/docs/meta/connections/{type}/{connection}` Response: + ```json { "title": "{title}", @@ -614,8 +770,8 @@ Response: - `public`: (Boolean) Indicates if the document will be rendered through a public url or in the sitemap. The document will still be available from the API. Defaults to `true`. - `description`: Every browsable document requires a description of up to 2 complete sentences. Please add a description to all new docs and any existing doc that you are working on. - ## Document Variables + When writing docs you can use the following variables instead of hard-coding these values. You can use `${variableName}` within any markdown document to reference the value. ### Common Variables @@ -624,9 +780,9 @@ When writing docs you can use the following variables instead of hard-coding the | :---------------------------- | :----------------------------------------- | :-------------------------------------- | | `manage_url` | The url to the management portal. | `https://manage.auth0.com` | | `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 @@ -638,3 +794,115 @@ When writing docs you can use the following variables instead of hard-coding the | `account.clientId` | The Client ID of the current Auth0 app. | `YOUR_CLIENT_ID` | | `account.clientSecret` | The Client Secret of the current Auth0 app. | `YOUR_CLIENT_SECRET` | | `account.callback` | The first callback URL of the current Auth0 app. | `http://YOUR_APP.auth0.com/callback` | + +## Versioning + +**NOTE:** For Versioning Quickstarts view [Versioning Quickstarts](#versioning-quickstarts) + +Building on the system we established for Quickstarts, topic versioning is controlled by adding metadata to `index.yml` files. The filesystem structure for a versioned topic looks like this: + +``` +lock/ + v9/ + article1.md + article2.md + v10/ + article1.md + article2.md + article3.md + index.yml +``` + +In this case `lock` is the name of the topic that has versions, and the two versions available are `v9` and `v10`. Note that different versions of the same topic may have different articles; more on this later. + +To create a versioned topic, the `lock/index.yml` file must contain a `versioning` property. Here's an example: + +```yaml +versioning: + baseUrl: libraries/lock + current: v10 + versions: + - v9 + - v10 + defaultArticles: + v1: article1 +``` + +The `versioning` object has the following properties: + +* `baseUrl` -- The URL for the topic. This is used to construct URLs for corresponding versions of a given article when a user navigates between. +* `current` -- The name of the current version. This must be present in the `versions` array. +* `versions` -- An array of all versions of the topic. Each of these must have a corresponding subdirectory beneath the topic directory. +* `defaultArticles` -- A map of default articles for each version. (Explained below) + +### User interface + +When a user views an article within a versioned topic, a select will be added after the main title: + +![Version select UI](https://cloud.githubusercontent.com/assets/6318057/26082431/3c74d560-39a6-11e7-836b-39c9ea6b50e4.png) + +The user can navigate between versions of the topic by selecting a new version from the drop-down box. If an article with the same filename is present in the newly-selected version, the user will navigate to that article. If no article with the same filename is present, they will instead receive a HTTP redirect (302) to the *default article* for that version. + +By default, the default article for a version is the first article in the subdirectory (sorted alphabetically, ascending). To change this, you can add an entry in the `defaultArticles` map of the `versioning` object in `index.yml`. + +If the version of the article is outdated or deprecated, add the `version-warning` component (after the main title) to show this. + +``` +::: version-warning +This document covers an outdated version of Lock. We recommend you to upgrade to v10. +::: + +``` + +![image](https://cloud.githubusercontent.com/assets/6318057/26082485/90f464fc-39a6-11e7-90ac-2a22773b02a5.png) + +### Limitations + +#### No sub-directories + +This versioning system has one major limitation: all articles for each version must exist in the same directory. For example, this is a valid hierarchy: + +``` +example/ + v1/ + foo.md + bar.md + v2/ + foo.md + bar.md + index.yml +``` + +But this hierarchy will not work: + +``` +example/ + v1/ + subtopic/ + foo.md + bar.md + v10/ + subtopic/ + foo.md + bar.md + 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 is a desired behavior we can always add it later. + +#### Case Sensitive + +The folder name must match exactly the names listed in the yaml file. This is case sensitive. + +For example, given the following yaml, naming the subdirectory `V9` instead of `v9` will result into a build error. + +```yaml +versioning: + baseUrl: libraries/lock + current: v10 + versions: + - v9 + - v10 + defaultArticles: + v1: article1 +``` 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 37b74cd4f0..1388ddcc84 100644 --- a/README.md +++ b/README.md @@ -1,18 +1,33 @@ # 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). +* 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 +## Author -[Auth0](auth0.com) +[Auth0](https://auth0.com) ## License diff --git a/STYLEGUIDE.md b/STYLEGUIDE.md index 5ccd676db3..12a59bbc8c 100644 --- a/STYLEGUIDE.md +++ b/STYLEGUIDE.md @@ -1,112 +1,204 @@ # Auth0 Style Guide -This style guide will cover the terminology and content specific to Auth0, along with some comments on common writing issues. +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 -Speak to the reader directly so that your document reads as if you were engaged in conversation. Address the reader as "you." Do not use indirect language such as "one" or other passive references. Avoid "we". +* Address the reader directly: "you". Use "we" only for Auth0's recommendations. +* Use the active voice. +* For instructions, use the imperative mood. -The active voice is most clear. The use of passive tense can confuse or mislead the reader. Avoid constructions such as "the function was called" or "the password was entered." Instead, state exactly who or what issued the call or entered the password. Never leave the reader with uncertainty about cause and effect. +| **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. | -### Imperative mood +* Use gender-neutral pronouns: "they", "their". -When directing the reader to perform a task, you can often omit the subject of the sentence: "Click **Save**." +| **Incorrect** | **Correct** | +| --- | --- | +| The user enters his password. | The user enters their password. | -### Gerunds -Gerunds make statements more passive. To discuss actions the reader must take, use the imperative form, not the gerund. For example, in a section about setting up SSH keys in which you are walking the user through the process, title the subhead "Set up your SSH keys" rather than "Setting up your SSH keys." +* Avoid gerunds in headings and the main body. -### Should, must, can, may - -The use of "should" and other ambivalent statements should be avoided. If something is required, tell the user it "must" be performed. - -Use "can" for most descriptions of available actions. Use "may" rarely and only for cases when the action is optional. Avoid "might". - -### Gender-neutral pronouns - -When a sentence cannot be constructed without a pronoun, the best solution for avoiding gender-specific pronouns or repetition of the subject is to use [singular they](https://en.wikipedia.org/wiki/Singular_they): "The user enters their password." +| **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. | ## Body text -### Paragraphs - -Keep paragraphs short for internet reading. - -### Subheads -Subheads are not intended to make independent statements. Therefore, reiterate in the paragraph text anything stated in the subhead. Do not use a subhead to introduce a separate idea and do not force the user to read the subhead to understand the text that follows. +* Keep paragraphs short for internet reading. +* Provide only the information necessary to understand and perform the steps. -## Abbreviations -Abbreviations should be avoided, including the use of e.g. Instead, use "for example." You want the content to flow smoothly, uninterrupted by questions the reader must ask himself regarding your intentions. +| **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`. | -### Contractions +* When mentioning several elements, use bulleted lists. +* Subheads are not independent statements. Repeat the information from the subhead in the paragraph. +* Avoid abbreviations. -Avoid contractions in most cases; they sound too casual. Complete words are more authoritative. +| **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. | -### Compound words +* Avoid contractions. Use complete words to be more authoritative. -Compound words may be used in three forms: one word, two words, or hyphenated. +| **Incorrect** | **Correct** | +| --- | --- | +| Can't | Cannot | -For example, when referring to something that happens at "run time", the proper format is two words. When referring to the "runtime engine", the proper format is a single word. And when using it as an adjective, such as "run-time execution", the proper format is the hyphenated form. - -Other commonly encountered compound words include "server side" and "client side". The same rules apply. When you write code for the "client side", you use two words. When you write "client-side code", the adjective form uses a hyphen. "Client side" and "server side" are never single words (clientside). +* Don't overuse adjectives. Never use more than two in a sentence. +* Don't overuse adverbs. +| **Incorrect** | **Correct** | +| --- | --- | +| The easiest way to enable authentication with Auth0 in your application is to use the OpenID Connect middleware. | To enable authentication in your application, use the OpenID Connect (OIDC) middleware. | +| Once a user has signed in, you can simply go to `/Account/Claims` to see these claims. | Once a user has logged in, you can go to `/Account/Claims` to see these claims. | ## Punctuation -### Colons -Colons are useful when you are directly referring to an example, such as "Here is the relevant code:" - -### Adjectives -Hyphens are used between adjectives and the verb they modify if and only if the adjective does not end in "ly." Therefore, "commonly used adjectives" is not hyphenated, while "oft-quoted phrase" is. +* 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". -### Punctuation and quotes -In American English, punctuation properly belongs inside quotation marks. Therefore, if you incorporate a quote into a sentence, either within or at the end, such as our editor said "You must end quotations with periods inside the quotation marks," you would construct the quotation as shown here, with the comma inside the quotation marks. +| **Incorrect** | **Correct** | +| --- | --- | +| "an easy to remember rule" | "an easy-to-remember rule" | +| "commonly-used adjectives" | "commonly used adjectives" | -The exception is when quoting code. If the code does not include the punctuation mark, do not place the punctuation mark inside the quotes. +* 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 -### Titles and subheads - -Only the first level title should be in "Title Case". All subheads should be in sentence case. - -### Notes - -**NOTE:** A note is at most two sentences that refer to the immediately preceding text to provide additional clarification. Do not use a block quote for notes; it makes them too prominent. - -### Panels - -::: panel-info Panels -Use a panel for information that applies to the overall document or to highlight information that must be taken into account, like version requirements. -::: - -### Menu items - -Use **Bold** when referring to menu items or fields in a webpage or UI. - -### Parameters - -Use `code_formatting` to refer to parameters and values. - -### Links - -The text of a link to additional information should be the title of the destination page, so the reader has some idea of the content being linked to. - -## Words to use - -### Access - -Depending on the situation, the reader can "gain access", "grant access", or "allow access". - -### The user - -Refer to the developer's customer as the "user". Be sure to keep the idea of the user separate from the "you" of the developer being addressed. +* 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. + +| **Incorrect** | **Correct** | +| --- | --- | +| Click "Save". | Click **Save**. | +| You **must** save these values securely. | You must save these values securely. | + +* Use `code_formatting` to refer to parameters and values. Avoid code formatting when mentioning types of objects. + +| **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. | + +* 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. + +| **Incorrect** | **Correct** | +| --- | --- | +| December 21 | Dec. 21| +| 21. December 2018 | Dec. 21, 2048 | +| Dec. 2048 | December 2048 | +| Mar. 15 | March 15 | +| 15 March 2048 | March 15, 2048 | + +* 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** | +| --- | --- | +| Save 3 items. | Save three items. | +| The password must contain at least twelve characters. | The password must contain at least 12 characters. | +| 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](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". + +| **Incorrect** | **Correct** | +| --- | --- | +| To limit access to your resources, you should use scopes. | To limit access to your resources, you must use scopes. | +| 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". + +| **Incorrect** | **Correct** | +| --- | --- | +| Log into the application. | Log in to the application. | +| Click the **Logout** button to activate the log-out action. | Click the **Log out** button to activate the logout action. | + +* Use "set up" as a verb or "setup" as a noun. +* Use "roll out" as a verb or "rollout" as a noun. Do not use "roll-out". + +| **Incorrect** | **Correct** | +| --- | --- | +| 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 "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. + +| **Incorrect** | **Correct** | +| --- | --- | +| Select **Save**.| Click **Save**. | +| 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". +* 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. + +| **Incorrect** | **Correct** | +| --- | --- | +| The method is executed at runtime. | The method is executed at run time. | +| 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. | ### The dashboard -The [Auth0 management console](${manage_url}) is referred to as the "dashboard". +* Dashboard: the [Auth0 management console](${manage_url}). +* The dashboard elements are called "section", "tab", "field". +* Dashboard-related terminology: +![](/media/readme/structure.png) -### More +### The application -For more information refer to [WORDS](WORDS.md). +* Account: a user, their credentials, a profile and other attributes +* 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 Cloud/Managed Private Cloud: single-tenant deployment diff --git a/WORDS.md b/WORDS.md index e5b05256f4..4764298894 100644 --- a/WORDS.md +++ b/WORDS.md @@ -4,8 +4,46 @@ 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**. - **Website**: Use "website", NOT "web site". +- **i.e.**: I.e. means `in other words`. Use `that is,` instead. +- **e.g.**: E.g. means `for example`. Use `for example,` instead. +- **etc.**: Use it when the space is too limited for the alternative. Otherwise use `and so on`. +- **a** vs **an**: Where the 'u' sounds like 'you' we use 'a' (for example, a university vs an umbrella) + +## Dashboard-Related Terminology + +![](/media/readme/structure.png) + +### Account + +Represents a user, their credentials, and (optionally) a profile and other attributes + + +### Subscription + +Defines custom terms; this is a contract or service plan e.g. trial, free, developer or developer-pro + +### Tenant + +A logical isolation unit of the products we offer. e.g. a tenant of Auth0 would be `foo.auth0.com` vs. another tenant `bar.auth0.com`. + +### Tokens + +When writing about tokens, capitalize specific token names as follows: + +* ID Token +* Access Token +* Refresh Token + +#### Within Private Cloud subscriptions + +* **Auth0 tenants** refers to regular cloud tenants +* **Private Cloud** or **Managed Private Cloud** refers to a single-tenant deployment + +### TL;DR + +Generally speaking, unless you're referring to MFA configuration, payment options, or user profiles (for the *owner* of the account), you'll use `tenant`, not `account`. diff --git a/app.json b/app.json index e7ef883247..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 @@ -12,13 +18,10 @@ "DISABLE_CDN": { "required": true }, - "GITHUB_ACCESS_TOKEN": { - "required": true - }, - "GITHUB_USER_NAME": { + "HEROKU_APP_NAME": { "required": true }, - "HEROKU_APP_NAME": { + "HEROKU_PARENT_APP_NAME": { "required": true }, "GIT_SSH_KEY": { diff --git a/articles/_includes/_api-auth-customize-tokens.md b/articles/_includes/_api-auth-customize-tokens.md new file mode 100644 index 0000000000..0c5ca2a2e3 --- /dev/null +++ b/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/articles/_includes/_api_auth_intro.md b/articles/_includes/_api_auth_intro.md index 29b5a48e4a..c7b3365570 100644 --- a/articles/_includes/_api_auth_intro.md +++ b/articles/_includes/_api_auth_intro.md @@ -1 +1,3 @@ -At some point, your APIs may need to allow limited access to users, servers, or servers on behalf of users. This tutorial demonstrates how to use the OAuth 2.0 authorization features of Auth0 to give your applications (or third-party applications) limited access to your APIs on behalf of users. For more information, check out [our documentation](https://auth0.com/docs/api-auth). \ 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 cb6f8fe006..3d4851c568 100644 --- a/articles/_includes/_callback_url.md +++ b/articles/_includes/_callback_url.md @@ -1,3 +1,5 @@ -## Configure Callback URLs + -A callback URL is a URL in your application where Auth0 redirects to after the user has authenticated. You can whitelist callback URLs for your app in the **Callback URL** field in your [Client Settings](${manage_url}/#/applications/${account.clientId}/settings). If no callback URLs are set, a mismatch error will be displayed when a user logs in. +### 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. 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 new file mode 100644 index 0000000000..af87d27465 --- /dev/null +++ b/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/articles/_includes/_configure_oauth2aas.md b/articles/_includes/_configure_oauth2aas.md deleted file mode 100644 index 4128e026e3..0000000000 --- a/articles/_includes/_configure_oauth2aas.md +++ /dev/null @@ -1,8 +0,0 @@ -To execute the steps in this tutorial, you will need to enable a flag under your [Account Settings](${manage_url}/#/account/advanced). This will allow you to opt-in and out of this feature at any point in time while it remains under preview. - -1. Open the Dashboard and browse to [Account Settings -> Advanced](${manage_url}/#/account/advanced). -1. Scroll down to the Settings section and turn on the flag "OAuth 2.0 API Authorization (Preview)" - - ![](/media/articles/api-auth/account-settings.png) - -You will see that the API section is now displayed on your sidebar. \ No newline at end of file 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 5e02e57a5d..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)](https://self-issued.info/docs/draft-ietf-jose-json-web-key.html) 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). +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 new file mode 100644 index 0000000000..4f58b1bb31 --- /dev/null +++ b/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/articles/_includes/_devcenter.html b/articles/_includes/_devcenter.html deleted file mode 100644 index 4b5f91ab95..0000000000 --- a/articles/_includes/_devcenter.html +++ /dev/null @@ -1,62 +0,0 @@ - -<% if (meta.tutorials && meta.tutorials.length > 0) { %> -

Tutorials

- - -<% if (meta.scenarios && meta.scenarios.length > 0) { %> -

Key Scenarios

- - -<% if (meta.resources && meta.resources.length > 0) { %> -

Other Resources

- diff --git a/articles/_includes/_devcenter_banner.html b/articles/_includes/_devcenter_banner.html deleted file mode 100644 index eefedf920d..0000000000 --- a/articles/_includes/_devcenter_banner.html +++ /dev/null @@ -1,7 +0,0 @@ -
- -

${meta.title}

-

${meta.subtitle}

-
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 32abcb8ed4..cacd38d8f0 100644 --- a/articles/_includes/_http-method.html +++ b/articles/_includes/_http-method.html @@ -1,4 +1,4 @@ -
- ${http_method} +

+ ${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/_java_new_app.html b/articles/_includes/_java_new_app.html index bccad054e9..ddfef608da 100644 --- a/articles/_includes/_java_new_app.html +++ b/articles/_includes/_java_new_app.html @@ -3,5 +3,5 @@ <% } 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 Client has one or more connections configured, for example, Google Social Connection, or username-password DB connection. +

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/articles/_includes/_libraries_support_frameworks.html b/articles/_includes/_libraries_support_frameworks.html new file mode 100644 index 0000000000..b14527fae5 --- /dev/null +++ b/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/articles/_includes/_libraries_support_lock.html b/articles/_includes/_libraries_support_lock.html new file mode 100644 index 0000000000..b23b2b155f --- /dev/null +++ b/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/articles/_includes/_libraries_support_sdks.html b/articles/_includes/_libraries_support_sdks.html new file mode 100644 index 0000000000..9fae1bad76 --- /dev/null +++ b/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/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-sdk.html b/articles/_includes/_lock-sdk.html index b7b7804432..d056c8d2da 100644 --- a/articles/_includes/_lock-sdk.html +++ b/articles/_includes/_lock-sdk.html @@ -1,5 +1,7 @@ -

For more information on using Lock see the documentation.

+<% if (meta.path !== "articles/libraries/lock/v11") { %> +

For more information on using Lock v11 see the documentation.

+<% } %>
    @@ -41,10 +43,10 @@ var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', { container: 'root', auth: { - redirectUrl: '${account.callback}', - responseType: 'code', + 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 + scope: 'openid email' // Learn about scopes: https://auth0.com/docs/scopes } } }); @@ -52,46 +54,64 @@ </script>
- 
<script src="https://cdn.auth0.com/js/lock-passwordless-2.2.min.js"></script>
+      
<script src="${lock_url}"></script>
 <script>
-  var lock = new Auth0LockPasswordless('${account.clientId}', '${account.namespace}');
-  function open() {
-    lock.sms({
-      callbackURL: '${account.callback}',
-      authParams: {
-        scope: 'openid email' // Learn about scopes: https://auth0.com/docs/scopes
+  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="https://cdn.auth0.com/js/lock-passwordless-2.2.min.js"></script>
+      
<script src="${lock_url}"></script>
 <script>
-  var lock = new Auth0LockPasswordless('${account.clientId}', '${account.namespace}');
+  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.emailcode({
-      callbackURL: '${account.callback}',
-      authParams: {
-        scope: 'openid email'  // Learn about scopes: https://auth0.com/docs/scopes
-      }
-    });
+    lock.show();
   }
 </script>
 <button onclick="window.open();">Email Code</button>

@@ -104,43 +124,45 @@
 <label>Password</label><input type="password" id="password"><br>
 <button class="signin-db">Sign in with Email/Password</button>
 
-<script src="https://cdn.auth0.com/w2/auth0-7.1.min.js"></script>
+<script src="${auth0js_url}"></script>
 <script src="http://code.jquery.com/jquery.js"></script>
 <script>
-  var auth0 = new Auth0({
+  var webAuth = new auth0.WebAuth({
     domain:         '${account.namespace}',
     clientID:       '${account.clientId}',
-    callbackURL:    '${account.callback}'
+    redirectUri:    '${account.callback}'
   });
   // sign-in with social provider with plain redirect
   $('.signin-google').on('click', function() {
-    auth0.signin({connection: 'google-oauth2'}); // use connection identifier
+    webAuth.authorize({
+      connection: 'google-oauth2' // use connection identifier
+    });
   });
   // sign-in with social provider using a popup (window.open)
   $('.signin-google-popup').on('click', function() {
-    auth0.signin({popup: true, connection: 'google-oauth2'},
-                function(err, profile, id_token, access_token, state) {
-                    /*
-                      store the profile and id_token in a cookie or local storage
-                        $.cookie('profile', profile);
-                        $.cookie('id_token', id_token);
-                    */
-                });
+    webAuth.popup.authorize({
+      connection: 'google-oauth2'
+    });
   });
+
   $('.signin-db').on('click', function() {
-    auth0.signin({
-      connection: 'foo',
-      username: 'bar',
-      password: 'foobar'
-    },
-    function (err, profile, id_token, access_token, state) {
-      /*
-          store the profile and id_token in a cookie or local storage
-            $.cookie('profile', profile);
-            $.cookie('id_token', id_token);
-        */
+    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>
- Download - Fork on Github + <% if (typeof branch !== 'undefined') { %> + Download + Fork on Github + <% } else { %> + Download + Fork on Github + <% } %>
<% if (typeof requirements !== 'undefined') { %> 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/_pipeline2.md b/articles/_includes/_pipeline2.md new file mode 100644 index 0000000000..0bd9cbb5c8 --- /dev/null +++ b/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/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 0b2e193b44..e2d873ea5d 100644 --- a/articles/_includes/_test-this-endpoint.md +++ b/articles/_includes/_test-this-endpoint.md @@ -1,5 +1,4 @@ -Your 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/_test-with-postman.md b/articles/_includes/_test-with-postman.md index 823c43e71f..559987c872 100644 --- a/articles/_includes/_test-with-postman.md +++ b/articles/_includes/_test-with-postman.md @@ -1,7 +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/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/_topic-links.md b/articles/_includes/_topic-links.md index 9cb0e7b5ab..e330d77284 100644 --- a/articles/_includes/_topic-links.md +++ b/articles/_includes/_topic-links.md @@ -6,6 +6,12 @@ ${article.title}

${article.description} + <% if (article.img) { %> + ${article.title} + <% } %> + <% if (article.mobileimg) { %> +

${article.title}
+ <% } %>

<% }) %> 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 new file mode 100644 index 0000000000..3c6104e535 --- /dev/null +++ b/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/articles/_includes/_version_warning_lock.md b/articles/_includes/_version_warning_lock.md new file mode 100644 index 0000000000..707490b682 --- /dev/null +++ b/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/articles/_includes/_video.md b/articles/_includes/_video.md new file mode 100644 index 0000000000..7eed662b37 --- /dev/null +++ b/articles/_includes/_video.md @@ -0,0 +1,3 @@ + + 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/_addons.html b/articles/addons/_addons.html deleted file mode 100644 index 07a34b9296..0000000000 --- a/articles/addons/_addons.html +++ /dev/null @@ -1,34 +0,0 @@ -<% var terminated = false; %> -<% var i=0; _.forEach(addons, function(article) { %> - <% if (article.addon) { %> - <% if (i === 0) { terminated = false; %> -
- <% } %> -
-
-
- <% if (article.public !== false) { %> -
- - - -
-

<%- article.addon %>

- <% } else { %> -
- -
-

<%- article.addon %>

- <% } %> -
-
-
- <% i++; if (i === 4) { i=0; terminated = true; %> -
- <% } %> - <% } %> -<% }); %> -<% if (terminated === false) { terminated = true; %> - -<% } %> -<% addons = []; %> \ No newline at end of file diff --git a/articles/addons/aws.md b/articles/addons/aws.md deleted file mode 100644 index 462b023af2..0000000000 --- a/articles/addons/aws.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -name: aws -title: Amazon Web Services (AWS) API -help: Enabling this add-on allows exchanging Auth0 tokens with AWS tokens that can be used to call their APIs (like S3, DynamoDB, etc.) flowing the user identity. -logo_class: AWS -public: false -image: /media/addons/aws.svg -seo_alias: aws ---- diff --git a/articles/addons/azure-blob-storage.md b/articles/addons/azure-blob-storage.md new file mode 100644 index 0000000000..fa945a5c8b --- /dev/null +++ b/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/articles/addons/azure-blob.md b/articles/addons/azure-blob.md deleted file mode 100644 index 43e99892be..0000000000 --- a/articles/addons/azure-blob.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -name: azure_blob -title: Windows Azure Blob Storage -help: Enabling this add-on allows exchanging Auth0 tokens with Azure Blob Storage Shared Access Signature tokens that can be used to call their APIs. -logo_class: Azure Blob Storage -public: false -image: /media/addons/azure_blob.svg -seo_alias: azure-blob ---- diff --git a/articles/addons/azure-mobile-services.md b/articles/addons/azure-mobile-services.md new file mode 100644 index 0000000000..2d88dd226a --- /dev/null +++ b/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/articles/addons/azure-sb.md b/articles/addons/azure-sb.md index 52a6abc5a3..da89208289 100644 --- a/articles/addons/azure-sb.md +++ b/articles/addons/azure-sb.md @@ -1,9 +1,51 @@ --- -name: azure_sb -title: Windows Azure Service Bus -help: Enabling this add-on allows exchanging Auth0 tokens with Azure Service Bus Shared Access Signature tokens that can be used to call their APIs. -logo_class: Windows Azure Service Bus -image: /media/addons/azure_sb.svg +addon: Azure Service Bus +title: Azure Service Bus Add-on +thirdParty: true public: false -seo_alias: azure-sb +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/articles/addons/box.md b/articles/addons/box.md deleted file mode 100644 index d202297a4e..0000000000 --- a/articles/addons/box.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -thirdParty: true -name: box -title: Box -logo_class: Box -configRoute: /add-ons/box -callback: https://sso.services.box.net/sp/ACS.saml2 -public: false -image: /media/addons/box.svg -seo_alias: box ---- diff --git a/articles/addons/client-addons/aws.md b/articles/addons/client-addons/aws.md deleted file mode 100644 index 536d37f39a..0000000000 --- a/articles/addons/client-addons/aws.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -addon: Amazon Web Services -image: /media/addons/aws.svg -url: /addons/aws -alias: - - aws - - amazon-web-services -seo_alias: amazon -description: How to configure the AWS Client Addon. ---- - -# Amazon Web Services Addon - -* You can find more details about how to obtain AWS Tokens to securely call AWS APIs and resources in [this how-to article](/aws-api-setup). -* Check out how to use delegation with the AWS API Gateway with delegation in the tutorial [AWS API Gateway Tutorial](/integrations/aws-api-gateway). -* Check out a complete sample for S3 on GitHub: diff --git a/articles/addons/client-addons/azure-blob-storage.md b/articles/addons/client-addons/azure-blob-storage.md deleted file mode 100644 index 7c07a4ddeb..0000000000 --- a/articles/addons/client-addons/azure-blob-storage.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -addon: Azure Blob Storage -thirdParty: true -url: /addons/azure-blob-storage -alias: - - azure blob storage - - azblob -image: /media/platforms/azure.png -tags: - - quickstart -articles: - - authenticate -description: This tutorial will show you how to use the Auth0 to authenticate and authorize Azure Blob Storage. ---- - -# Azure Blob Storage Addon - -Here's a sample call to the delegation endpoint to get the 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 (e.g. 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/articles/addons/client-addons/azure-mobile-services.md b/articles/addons/client-addons/azure-mobile-services.md deleted file mode 100644 index 44d4283527..0000000000 --- a/articles/addons/client-addons/azure-mobile-services.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -addon: Azure Mobile Services -thirdParty: true -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 -description: This tutorial will show you how to use the Auth0 to authenticate and authorize Azure Mobile Services. ---- - -# Azure Mobile Services Addon - -#### 1. Create a client for the 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](/client-platforms/vanillajs) or [Windows Phone](/native-platforms/windowsphone). You can use any of these tutorials for configuring an app that interacts with WAMS. - -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 client 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 client token (received in step #2) for another token to be used for 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 client app to interact with multiple WAMS APIs (or even other APIs). In Auth0, you can control which clients 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. Using 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/articles/addons/client-addons/azure-sb.md b/articles/addons/client-addons/azure-sb.md deleted file mode 100644 index d8bf584822..0000000000 --- a/articles/addons/client-addons/azure-sb.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -addon: Azure Service Bus -thirdParty: true -url: /addons/azure-sb -alias: - - Azure Service Bus -image: /media/platforms/azure.png -tags: - - quickstart -articles: - - authenticate -description: This tutorial will show you how to use the Auth0 to authenticate and authorize Azure Service Bus. ---- - -# Azure Service Bus Addon - -Here's a sample call to the delegation endpoint to get the 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 (e.g. 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/articles/addons/client-addons/salesforce-sandbox.md b/articles/addons/client-addons/salesforce-sandbox.md deleted file mode 100644 index 005382b7fd..0000000000 --- a/articles/addons/client-addons/salesforce-sandbox.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -addon: Salesforce (sandbox) -thirdParty: true -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. ---- - -# Salesforce (Sandbox) Addon - -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. - -> Under the hood, Auth0 uses [OAuth 2.0 JWT Bearer Token Flow](https://help.salesforce.com/HTViewHelpDoc?id=remoteaccess_oauth_jwt_flow.htm&language=en_US) 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/client-addons/salesforce.md b/articles/addons/client-addons/salesforce.md deleted file mode 100644 index ed4df4ad41..0000000000 --- a/articles/addons/client-addons/salesforce.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -addon: Salesforce -alias: - - salesforce -url: addons/salesforce -thirdParty: true -image: /media/addons/salesforce.svg -description: This tutorial will show you how to use the Auth0 to authenticate and authorize your Salesforce services. ---- - -# Salesforce Addon - -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' -... - -``` - -> Under the hood, Auth0 uses [OAuth 2.0 JWT Bearer Token Flow](https://help.salesforce.com/HTViewHelpDoc?id=remoteaccess_oauth_jwt_flow.htm&language=en_US) 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/client-addons/sap-odata.md b/articles/addons/client-addons/sap-odata.md deleted file mode 100644 index 2459cc8f7d..0000000000 --- a/articles/addons/client-addons/sap-odata.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -addon: SAP OData -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. ---- - -# SAP OData Addon - -> This integration is in __experimental mode__. Contact us if you have questions. - -> Under the hood, Auth0 uses [SAML 2.0 Bearer Assertion Flow for OAuth 2.0](http://help.sap.com/saphelp_nw74/helpdata/en/12/41087770d9441682e3e02958997846/content.htm) 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/addons/cloudbees.md b/articles/addons/cloudbees.md deleted file mode 100644 index 912bc732ef..0000000000 --- a/articles/addons/cloudbees.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -thirdParty: true -name: cloudbees -title: CloudBees -logo_class: CloudBees -configRoute: /add-ons/cloudbees -callback: https://grandcentral.cloudbees.com/authenticate/saml/consume -public: false -image: /media/addons/cloudbees.svg -seo_alias: cloudbees ---- diff --git a/articles/addons/concur.md b/articles/addons/concur.md deleted file mode 100644 index 8e25445818..0000000000 --- a/articles/addons/concur.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -thirdParty: true -name: concur -title: Concur (beta) -logo_class: Concur -configRoute: /add-ons/concur -callback: https://www.concursolutions.com/SAMLRedirector/ClientSAMLLogin.aspx -public: false -image: /media/addons/concur.svg -seo_alias: concur ---- diff --git a/articles/addons/dropbox.md b/articles/addons/dropbox.md deleted file mode 100644 index 7efcc6509c..0000000000 --- a/articles/addons/dropbox.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -thirdParty: true -name: dropbox -title: Dropbox -logo_class: Dropbox -configRoute: /add-ons/dropbox -callback: https://www.dropbox.com/saml_login -public: false -image: /media/addons/dropbox.svg -seo_alias: dropbox ---- diff --git a/articles/addons/echosign.md b/articles/addons/echosign.md deleted file mode 100644 index 9de9d33147..0000000000 --- a/articles/addons/echosign.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -thirdParty: true -name: echosign -title: EchoSign -logo_class: AdobeEchoSign -configRoute: /add-ons/echosign -public: false -image: /media/addons/echosign.svg -alias: - - echo-sign -seo_alias: echosign ---- diff --git a/articles/addons/egnyte.md b/articles/addons/egnyte.md deleted file mode 100644 index 600969f87c..0000000000 --- a/articles/addons/egnyte.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -thirdParty: true -name: egnyte -title: Egnyte -logo_class: Egnyte -configRoute: /add-ons/egnyte -public: false -image: /media/addons/egnyte.svg -seo_alias: egnyte ---- diff --git a/articles/addons/firebase.md b/articles/addons/firebase.md deleted file mode 100644 index b6625d4e3e..0000000000 --- a/articles/addons/firebase.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -name: firebase -title: Firebase API -help: Enabling this add-on allows exchanging Auth0 tokens with Firebase tokens that can be used to call their APIs flowing the user identity. -logo_class: Firebase -public: false -image: /media/addons/firebase.svg -seo_alias: firebase ---- diff --git a/articles/addons/index.md b/articles/addons/index.md index 0e05eb19d2..bd86928457 100644 --- a/articles/addons/index.md +++ b/articles/addons/index.md @@ -1,64 +1,48 @@ --- url: /addons -description: +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 -# Auth0 Client Addons +<%= include('../_includes/_uses-delegation') %> -Addons are plugins associated with a Client in Auth0. Usually, they are 3rd party APIs used by the client that Auth0 generates access tokens for (e.g. Salesforce, Azure Service Bus, Azure Mobile Services, SAP, etc). +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). -## Configure an Addon +Some typical scenarios for using add-ons include: -### Select the Addon +* **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. -<% if (account.clientId) { %> -Go to Application Addons page and select the add-on. -<% } else { %> -Go to Application Addons page and select the add-on. -<% } %> +* **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. -![](/media/addons/manage-addons.png) +![Addons Example Diagram](/media/articles/applications/applications-addon-types.png) -### Setup +## Available Add-ons -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. +- Amazon Web Services +- Firebase +- Layer +- Salesforce +- Salesforce (Sandbox) +- SAP +- Azure Mobile Services +- Azure Service Bus +- Azure Blob Storage +- SAML2 +- WS-Fed -The key to this integration is the [/delegation endpoint](/api/authentication#delegation) in Auth0. +## Keep reading -See the Delegation documentation to learn more about how to call this endpoint: - -[Delegation Tokens](/tokens/delegation) - -[Lock Android: Delegation API](/libraries/lock-android/delegation-api) - -[Lock iOS: Delegation API](/libraries/lock-ios/delegation-api) - -## Additional Information for Specific Addons: - -<% var clientAddons = cache.find('articles/addons/client-addons', {sort: 'index'}); %> -<%= include('./_addons', { addons: clientAddons }) %> +- [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/layer.md b/articles/addons/layer.md deleted file mode 100644 index 95945db359..0000000000 --- a/articles/addons/layer.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -name: layer -title: Layer API -help: Enabling this add-on allows exchanging Auth0 tokens with Layer tokens that can be used to call their APIs flowing the user identity. -logo_class: Layer -public: false -image: /media/addons/layer.svg -seo_alias: layer ---- diff --git a/articles/addons/mscrm.md b/articles/addons/mscrm.md deleted file mode 100644 index ca7d6bc9d9..0000000000 --- a/articles/addons/mscrm.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -thirdParty: true -name: mscrm -title: Dynamics CRM -logo_class: MicrosoftDynamicsCRM -configRoute: /add-ons/mscrm -public: false -image: /media/addons/mscrm.svg -alias: - - dynamics-crm -seo_alias: mscrm ---- diff --git a/articles/addons/newrelic.md b/articles/addons/newrelic.md deleted file mode 100644 index c1b88c7b15..0000000000 --- a/articles/addons/newrelic.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -thirdParty: true -name: newrelic -title: New Relic -logo_class: NewRelic -configRoute: /add-ons/newrelic -public: false -image: /media/addons/newrelic.svg -alias: - - new-relic -seo_alias: newrelic ---- diff --git a/articles/addons/office365.md b/articles/addons/office365.md deleted file mode 100644 index d8353c4833..0000000000 --- a/articles/addons/office365.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -thirdParty: true -name: office365 -title: Office 365 (beta) -logo_class: Office365 -configRoute: /add-ons/office365 -public: false -image: /media/addons/office365.svg -alias: - - office-365 -seo_alias: office365 ---- diff --git a/articles/addons/rms.md b/articles/addons/rms.md deleted file mode 100644 index 0379028a83..0000000000 --- a/articles/addons/rms.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -thirdParty: true -name: rms -title: AD RMS -logo_class: Windows Server Active Directory RMS -configRoute: /add-ons/rms -public: false -image: /media/addons/rms.svg -alias: - - active-directory-rms -seo_alias: rms ---- diff --git a/articles/addons/salesforce-api.md b/articles/addons/salesforce-api.md deleted file mode 100644 index 9251e1fd19..0000000000 --- a/articles/addons/salesforce-api.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -name: salesforce_api -title: Salesforce API -help: Enabling this add-on allows exchanging Auth0 tokens with Salesforce tokens that can be used to call their APIs flowing the user identity. -logo_class: SalesforceAPI -public: false -image: /media/addons/salesforce-api.svg -seo_alias: salesforce-api ---- diff --git a/articles/addons/salesforce-sandbox-api.md b/articles/addons/salesforce-sandbox-api.md deleted file mode 100644 index ca7e7f9dfd..0000000000 --- a/articles/addons/salesforce-sandbox-api.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -name: salesforce_sandbox_api -title: Salesforce (sandbox) API -help: Enabling this add-on allows exchanging Auth0 tokens with Salesforce (sandbox) tokens that can be used to call their APIs flowing the user identity. -logo_class: SalesforceSandbox -public: false -image: /media/addons/salesforce_sandbox_api.svg -seo_alias: salesforce-sandbox-api ---- diff --git a/articles/addons/salesforce-sandbox.md b/articles/addons/salesforce-sandbox.md new file mode 100644 index 0000000000..79bd815fe1 --- /dev/null +++ b/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/articles/addons/salesforce.md b/articles/addons/salesforce.md index 46c53b7b17..54aa6bb93e 100644 --- a/articles/addons/salesforce.md +++ b/articles/addons/salesforce.md @@ -1,11 +1,38 @@ --- +addon: Salesforce +title: Salesforce Add-on +alias: + - salesforce +url: addons/salesforce thirdParty: true -name: salesforce -title: Salesforce -logo_class: Salesforce -configRoute: /add-ons/salesforce -callback: https://login.salesforce.com public: false image: /media/addons/salesforce.svg -seo_alias: salesforce +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/articles/addons/samlp.md b/articles/addons/samlp.md deleted file mode 100644 index b0228a7e26..0000000000 --- a/articles/addons/samlp.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -name: samlp -data_logo: SAML2 Web App -title: SAML2 Web App -help: Enables the SAML protocol for this application. -public: false -image: /media/addons/samlp.svg -seo_alias: samlp ---- diff --git a/articles/addons/sap-api.md b/articles/addons/sap-api.md deleted file mode 100644 index 5e5784edcc..0000000000 --- a/articles/addons/sap-api.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -name: sap_api -title: SAP OData -help: Enabling this add-on allows exchanging Auth0 tokens with SAP OData compatible access tokens. -logo_class: SAP -public: false -image: /media/addons/sap_api.svg -seo_alias: sap-api ---- diff --git a/articles/addons/sap-odata.md b/articles/addons/sap-odata.md new file mode 100644 index 0000000000..4c5db1bcce --- /dev/null +++ b/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/articles/addons/sharepoint.md b/articles/addons/sharepoint.md deleted file mode 100644 index b153d7e5eb..0000000000 --- a/articles/addons/sharepoint.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -thirdParty: true -name: sharepoint -title: SharePoint -logo_class: Sharepoint -configRoute: /add-ons/sharepoint -public: false -image: /media/addons/sharepoint.svg -seo_alias: sharepoint ---- diff --git a/articles/addons/slack.md b/articles/addons/slack.md deleted file mode 100644 index 7f59dd77a3..0000000000 --- a/articles/addons/slack.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -thirdParty: true -name: slack -title: Slack -logo_class: Slack -configRoute: /add-ons/slack -public: false -image: /media/addons/slack.svg -seo_alias: slack ---- diff --git a/articles/addons/springcm.md b/articles/addons/springcm.md deleted file mode 100644 index 0a17e84e66..0000000000 --- a/articles/addons/springcm.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -thirdParty: true -name: springcm -title: SpringCM -logo_class: SpringCM -configRoute: /add-ons/springcm -public: false -image: /media/addons/springcm.svg -seo_alias: springcm ---- diff --git a/articles/addons/wams.md b/articles/addons/wams.md deleted file mode 100644 index 7ea62cd582..0000000000 --- a/articles/addons/wams.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -name: wams -title: Windows Azure Mobile Services (WAMS) API -help: Enabling this add-on allows exchanging Auth0 tokens with WAMS tokens that can be used to call their APIs flowing the user identity. -logo_class: Windows Azure Mobile Services -public: false -image: /media/addons/wams.svg -alias: - - windows-azure - - microsoft-azure - - windows-azure-websites - - windows-azure-vm - - azure-websites - - azure-vm - - azure - - azure-mobile - - azure-mobile-services -seo_alias: wams ---- diff --git a/articles/addons/wsfed.md b/articles/addons/wsfed.md deleted file mode 100644 index 4d1baf8e63..0000000000 --- a/articles/addons/wsfed.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -name: wsfed -data_logo: WS-Fed Web App -title: WS-Fed (WIF) Web App -help: Enables the WS-Fed protocol typically used by Microsoft applications (through Windows Identity Foundation). -public: false -image: /media/addons/wsfed.svg -seo_alias: wsfed ---- diff --git a/articles/addons/zendesk.md b/articles/addons/zendesk.md deleted file mode 100644 index 0464031ac7..0000000000 --- a/articles/addons/zendesk.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -thirdParty: true -name: zendesk -title: Zendesk -logo_class: Zendesk -configRoute: /add-ons/zendesk -public: false -image: /media/addons/zendesk.svg -seo_alias: zendesk ---- diff --git a/articles/addons/zoom.md b/articles/addons/zoom.md deleted file mode 100644 index a9a78430d7..0000000000 --- a/articles/addons/zoom.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -thirdParty: true -name: zoom -title: Zoom -logo_class: Zoom -configRoute: /add-ons/zoom -public: false -image: /media/addons/zoom.svg -seo_alias: zoom ---- 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/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 b9820a8890..9dc98e5ece 100644 --- a/articles/anomaly-detection/index.md +++ b/articles/anomaly-detection/index.md @@ -1,98 +1,73 @@ --- -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. - -## Shields +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. -### Brute-Force Protection -There are two different triggers for the brute-force protection shield, for two slightly different attack scenarios. +Auth0 has two types of **shields** to handle anomalies and attacks. -**Trigger:** *10* failed login attempts into a single account from the same IP address. +* [Brute-force protection](#brute-force-protection) +* [Breached password detection](#breached-password-detection) -**Actions**: -* Send an email to the affected user (The email can be [customized](#customize-the-blocked-account-email)) -* Block the suspicious 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. -::: panel-info 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. +Customize the actions in the **Anomaly Detection** section on the [Dashboard](${manage_url}/#/anomaly). -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 owners -* 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 owner 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. -2. Authenticating many users from the same IP address. For instance, 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 -* Block login attempts for suspected user accounts using that username and password combination +## Brute-force protection -This block remains in place until the user changes their password. +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. -## Setting Your Preferences +* 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 -To customize the **actions** that get taken from the **triggers**, go to the [Anomaly Detection](${manage_url}/#/anomaly) section on the dashboard. +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/anomaly-detection-overview.png) +## Breached password detection -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. +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). -![](/media/articles/anomaly-detection/changing-actions.png) +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). -Then you can use the toggle to enable/disable an action. +## Frequently asked questions -Here you can also add any IP addresses to the **Whitelist** field to avoid erroneously triggering the protection. +* **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 new file mode 100644 index 0000000000..da33b407f4 --- /dev/null +++ b/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/articles/api-auth/blacklists-vs-grants.md b/articles/api-auth/blacklists-vs-grants.md new file mode 100644 index 0000000000..8a8fbedf29 --- /dev/null +++ b/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/articles/api-auth/config/asking-for-access-tokens.md b/articles/api-auth/config/asking-for-access-tokens.md deleted file mode 100644 index 287c404b90..0000000000 --- a/articles/api-auth/config/asking-for-access-tokens.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -description: How to request tokens for your applications. ---- - -# Ask for Access Tokens for a Client Credentials Grant - -To ask Auth0 for tokens for any of your authorized client 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/json" } - ], - "postData": { - "mimeType": "application/json", - "text": "{\"grant_type\":\"client_credentials\",\"client_id\": \"${account.clientId}\",\"client_secret\": \"${account.clientSecret}\",\"audience\": \"YOUR_API_IDENTIFIER\"}" - } -} -``` - -The response will be a [signed JWT (JSON Web Token)](/jwt#2-body) containing at least the following claims in the body: - -``` -{ - "iss": "https://${account.namespace}/", - "sub": "${account.clientId}@clients", - "aud": "YOUR_API_IDENTIFIER", - "exp": // unix timestamp of the token's expiration date, - "iat": // unix timestamp of the token's creation date, - "scope": "" -} -``` - -### Verify an access token for a resource server - -Access tokens will be signed using the signature method configured for the resource server, and must be verified accordingly: - -* 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)](https://self-issued.info/docs/draft-ietf-jose-json-web-key.html) URL: [https://${account.namespace}/.well-known/jwks.json](https://${account.namespace}/.well-known/jwks.json) - -For claim verification, use any [recommended JWT library](https://jwt.io/) which validates all the standard claims returned in the token. - -### Authorized Client Applications - -Your client app must be authorized to access your API before you can request tokens. - -You can go to the **Non Interactive Clients** tab of your API in the [APIs section](${manage_url}/#/apis) of the dashboard to verify that the app you are using has been authorized to request access tokens from this API. - -To add an authorized app, follow the instructions as described in [Set up a Client Credentials Grant using the Dashboard](/api-auth/config/using-the-auth0-dashboard). - -### Where to Find the IDs - -To find the values for the parameters referred to in this sample, go to the [Clients](${manage_url}/#/clients) page in the Dashboard, and select the application you want to use. There you will find these values: - - * `CLIENT_ID`: This is the value of the **Client ID** field. - * `CLIENT_SECRET`: This is the value of the **Client Secret** field. - -Also, go to the [APIs section](${manage_url}/#/apis) of the dashboard and select the API you are working with. There you will find this value: - - * `YOUR_API_IDENTIFIER`: This is the value of the **Id** field on the Settings tab of the API. diff --git a/articles/api-auth/config/using-the-auth0-dashboard.md b/articles/api-auth/config/using-the-auth0-dashboard.md index 2d40c4d249..dde2b216f6 100644 --- a/articles/api-auth/config/using-the-auth0-dashboard.md +++ b/articles/api-auth/config/using-the-auth0-dashboard.md @@ -1,37 +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 -1. Open the Auth0 Management Dashboard and browse to the [Clients section](${manage_url}/#/clients). +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). -2. Create a new client of type **Non Interactive** for each of the applications that will consume the API you want to generate access tokens for. +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. -![Create a Client](/media/articles/api-auth/create-client.png) +To authorize the applications to call an API: -3. Navigate to the [API section](${manage_url}/#/apis) and create a new API. +1. Open the Auth0 Management Dashboard and browse to the [API section](${manage_url}/#/apis). -::: panel-info Enable APIs Section -If you can't see the [API section](${manage_url}/#/apis) in the left hand menu of the dashboard then you will have to enable it. Navigate to your [Account Advanced Settings](${manage_url}/#/account/advanced), scroll down to the *Settings* section and toggle the **Enable APIs Section** switch. -::: +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)](https://self-issued.info/docs/draft-ietf-jose-json-web-key.html) 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) +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. -**NOTE:** There will already be an **Auth0 Management API** that represents Auth0's APIv2. You can authorize client applications to request tokens from this API as well. +## Keep reading -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 client. Under the **Non Interactive Clients** tab, you can authorize your clients that will be the consumers of the API. This will create a `client grant` for each client and will allow you to generate access tokens for these clients to call your API. Optionally, you can select a subset of scopes to be granted to this client as part of the access token. Scopes allow the API to enforce fine-grained authorization. - - ![Authorize the Client](/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**. +* [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 b7dbbc5383..fc9e75f35a 100644 --- a/articles/api-auth/config/using-the-management-api.md +++ b/articles/api-auth/config/using-the-management-api.md @@ -1,93 +1,56 @@ --- -description: How to enable API Authorization using the Auth0 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 --- -# API Authorization: Using the Management API for setting up a Client Credentials Grant scenario +# Set Up Client Credentials Grants Using the Management API -If you do not want to use the Auth0 Dashboard to enable API Authorization, you can achieve the same results using the Auth0 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). -You will need the following: - -- Management APIv2 token with the following scopes: - - `create:resource_server` - - `create:client_grant` -- `Client_Id` and `Client_Secret` for the client application which must already be created and visible in your [Auth0 dashboard](${manage_url}). - -## Register your Resource Server - -The **Resource Server** entity represents the API that you want to issue access tokens for, identified by a friendly name and a URN identifier. - -The following restrictions that apply for the identifier: - -- It must be a valid URN. -- It cannot be modified after creation. -- It must be unique throughout your tenant. +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. -**NOTE:** Using your public API endpoint as an identifier is recommended. +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. -Let's start by creating the Resource Server that will represent your API. The following example uses _"My Sample API"_ as the name and _"https://my-api-uri"_ as the identifier. +You will need the following: -```har -{ - "method": "POST", - "url": "https://${account.namespace}.auth0.com/api/v2/resource-servers", - "headers": [ - { "name": "Content-Type", "value": "application/json" } - ], - "postData": { - "mimeType": "application/json", - "text": "{\"name\":\"My Sample API\",\"identifier\": \"https://my-api-urn\",\"signing_alg\": \"HS256\",\"scopes\": [{ \"value\": \"sample-scope\", \"description\": \"Description for Sample Scope\"}]}" - } -} -``` +- 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:** 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. +- The application information (`Client_Id` and `Client_Secret`) for the application you want to authorize [Auth0 dashboard](${manage_url}/#/applications). -Response: +- The API identifier for the API you want to invoke (${manage_url}/#/apis). -``` -{ - "id": "56f0131ffdf1c311694f4cc7", - "name": "My Sample API", - "identifier": "https://my-api-urn", - "scopes": [ - { - "value": "sample-scope", - "description": "Description for Sample Scope" - } - ], - "signing_alg": "HS256", - "signing_secret": "FF1prn9UxZotnFEfPVwEJhqqyRmwdSu5", - "token_lifetime": 86400 -} -``` +## Authorize the Application -## Authorize the consumer Client +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. -Now that the API and the Client are represented in Auth0, you can create a trust relationship between them. +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}.auth0.com/api/v2/client-grants", + "url": "https://${account.namespace}/api/v2/client-grants", "headers": [ - { "name": "Content-Type", "value": "application/json" } + { "name": "Content-Type", "value": "application/json" }, + { "name": "authorization", "value": "Bearer Auth0_MGMT_API_ACCESS_TOKEN" } ], "postData": { "mimeType": "application/json", - "text": "{\"client_id\": \"N99orgWBg8WDHOOfL4p6LXT7wEAliSik\",\"audience\": \"https://my-api-urn\",\"scope\":[\"sample-scope\"]}" + "text": "{\"client_id\": \"${account.clientId}\",\"audience\": \"https://my-api-urn\",\"scope\":[\"sample-scope\"]}" } } ``` -The `client_id` is the id of the consumer application, `audience` will be the identifier of the API, and `scope` is an array of strings, which must be a subset of those defined in the API. +Sample response: -Response: - -``` +```json { "id": "cgr_JGa6ZckLjnt60rWe", - "client_id": "N99orgWBg8WDHOOfL4p6LXT7wEAliSik", + "client_id": "${account.clientId}", "audience": "https://test-api", "scope": [ "sample-scope" @@ -95,10 +58,12 @@ Response: } ``` -Next, update your API to parse the token from the request and validate it. You will need to use the `signing_secret` of the API, which was used for signing the access tokens with the HS256 algorithm. - -## Request access tokens +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. -Now that all the elements are in place, you can request access tokens for your API from Auth0. +## Keep reading -For details on generating access tokens, see: [API Authorization: Asking for Access Tokens](/api-auth/config/asking-for-access-tokens) +:::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/articles/api-auth/dynamic-client-registration.md b/articles/api-auth/dynamic-client-registration.md index b6426b0d56..6bac759f08 100644 --- a/articles/api-auth/dynamic-client-registration.md +++ b/articles/api-auth/dynamic-client-registration.md @@ -1,54 +1,32 @@ --- -description: How to dynamically register Clients with Auth0, using the Management APIv2. +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 is a feature, based on the [OpenID Connect Dynamic Client Registration specification](https://openid.net/specs/openid-connect-registration-1_0.html), that enables you to register clients dynamically. These clients are called **third party clients** (since they are registered and used by third party developers). +Dynamic Client Registration enables you to register [third-party applications](/applications/guides/enable-third-party-apps) dynamically. -## Third Party Client characteristics - -Third party clients have the following characteristics: - -- The [ID tokens](/tokens/id-token) generated for these clients, 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 client and can be also enabled for selected first party (standard) clients. - -- To authenticate users using [Lock](/libraries/lock), you will have to use a version greater than `10.7`. - -- They cannot skip user consent when consuming APIs. This is for security purposes, as anyone can create a client, but each client relays on the final user to provide consent. - -- 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 client 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-info How to get a Management APIv2 Token -In order to access the [Management APIv2](/api/management/v2) endpoints from a third party client, 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` -::: +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 -In this section we will see how you can enable the dynamic registration feature for your tenant. - -By default, the feature is disabled for all tenants. To change this, you have to update some account 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). - -::: panel-warning Security 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. +::: 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. ::: -### Update tenant 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. -In order to enable the feature, you need to set to `true` the following flags at your tenant's settings: -- `enable_dynamic_client_registration`: Enables the feature. -- `enable_pipeline2`: Enables the underlying pipeline that is a required dependency. +This can be done by enabling the **OIDC Dynamic Application Registration** toggle on your tenant's [Advanced Settings page](${manage_url}/#/tenant/advanced). -You can update these flags using the [Update tenant settings endpoint](/api/management/v2#!/Tenants/patch_settings). +Alternatively, you can update this flag using the [Update tenant settings endpoint](/api/management/v2#!/Tenants/patch_settings). ```har { @@ -61,91 +39,22 @@ You can update these flags using the [Update tenant settings endpoint](/api/mana ], "postData": { "mimeType": "application/json", - "text" : "{ \"enable_pipeline2\": true, \"enable_dynamic_client_registration\": true }" - } -} -``` - -You need to update the `API2_ACCESS_TOKEN` with a valid Auth0 API2 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) are flagged as **Third Party Clients** and 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": "application/json" }, - { "name": "Authorization", "value": "Bearer API2_ACCESS_TOKEN" }, - { "name": "Cache-Control", "value": "no-cache" } - ], - "postData": { - "mimeType": "application/json", - "text" : "{ \"is_domain_connection\": true }" + "text" : "{ \"flags\": { \"enable_dynamic_client_registration\": 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 - -If you use or would like to use an Auth0 [Hosted Login Page](/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 a third party developer can register and configure a 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 a 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 [OAuth 2.0 Access Tokens](/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 a client with the name `My Example` and the callback URLs `https://client.example.com/callback` and `https://client.example.com/callback2`, you would use the following. +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 { @@ -156,48 +65,48 @@ To create a client with the name `My Example` and the callback URLs `https://cli ], "postData": { "mimeType": "application/json", - "text": "{\"client_name\":\"My Dynamic Client\",\"redirect_uris\": [\"https://client.example.com/callback\", \"https://client.example.com/callback2\"]}" + "text": "{\"client_name\":\"My Dynamic Application\",\"redirect_uris\": [\"https://application.example.com/callback\", \"https://application.example.com/callback2\"]}" } } ``` Where: -- `client_name` (required): The name of the Dynamic Client to be created. -- `redirect_uris` (required): An array of URLs that Auth0 will deem valid to call at the end of an Authentication flow. +- **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: 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 } ``` 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_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](/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 will 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 application to authenticate users with Auth0. +Now that you have a Client ID and Secret, you can configure your application to authenticate users with Auth0. -**NOTE**: We will go through a simple scenario, that showcases 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 application type, refer to [API Authorization](/api-auth). +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: @@ -208,23 +117,23 @@ 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 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. +- **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-info Custom claims namespaced format - In order to improve compatibility for client 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`. + ::: 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 Client Settings of your application. -- `state`: An opaque value the clients adds 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. -- `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`. +- **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: @@ -234,6 +143,6 @@ For example: ``` -This call will redirect the user to Auth0, and upon successful authentication, back to your application (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](#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 62b917a8a0..d5fea1d7e6 100644 --- a/articles/api-auth/faq.md +++ b/articles/api-auth/faq.md @@ -1,24 +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 -### Q: Can I execute a user consent flow? +## I have an Application that needs to talk to different Resource Servers -**A:** 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}). - -### Q: I have a Client that needs to talk to different Resource Servers. - -**A:** If a single Client 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). -### Q: Can I try the endpoints before I implement my application? +## Can I try the endpoints before I implement my application? -**A** Sure! You have two options: -- [Download our Postman collection](https://app.getpostman.com/run-collection/608670c820cda215594c). For more information on how to use our Postman collection refer to [Using the Auth0 API with our Postman Collections](/api/postman). +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 Client](/api/authentication#authorize-client) and read the _Test this endpoint_ paragraph for the grant you want to test. + - 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/articles/api-auth/grant/authorization-code-pkce.md b/articles/api-auth/grant/authorization-code-pkce.md index fe73431a56..fb575ab2c1 100644 --- a/articles/api-auth/grant/authorization-code-pkce.md +++ b/articles/api-auth/grant/authorization-code-pkce.md @@ -1,29 +1,61 @@ --- -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 --- +# Call APIs from Mobile Apps -# Calling 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. -The OAuth 2.0 grant that mobile apps utilize in order to access an API, is the **Authorization Code Grant using Proof Key for Code Exchange (PKCE)**. +::: note +If you need a refresher on the OAuth 2.0 protocol, you can go through our [OAuth 2.0](/protocols/oauth2) article. +::: -## Overview +## Overview of the flow -The **Proof Key for Code Exchange (PKCE)**, defined in [RFC 7636](https://tools.ietf.org/html/rfc7636), is a technique used to mitigate the authorization code interception attack when using the [Authorization Code Grant](/api-auth/grant/authorization-code) since the attacker can intercept the `authorization_code` returned by the Authorization Server and exchange it for an `access_token` (and possibly a `refresh_token`). -To mitigate this attack, the Client creates, for every authorization request, a cryptographically random key called `code_verifier` and it's transformed value called `code_challenge`, which is sent to the Authorization Server to obtain the `authorization_code`. When the Client receives the `authorization_code`, it will send the code and the `code_verifier` to the Authorization Server token endpoint to exchange them for the requested tokens. +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 Client initiates the flow and redirects the user to the Authorization Server sending the `code_challenge` and `code_challenge_method` parameters - 2. The Authorization Server redirects the user to the Client with an `authorization_code` in the querystring - 3. The Client sends the `authorization_code` and `code_verifier` together with the Redirect Uri and the Client Id to the Authorization Server - 4. The Authorization Server validates this information and returns an `access_token` (and optionally a `refresh_token`) + 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 -## Use Case +[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. - - Allow a Public Client to use the Authorization Code Grant without being susceptible to authorization code interception attack. - - The Client is typically an Android or iOS Application. +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). - ## Tutorials +## Keep reading - - [Configuring your tenant for API Authorization](/api-auth/tutorials/configuring-tenant-for-api-auth) - - [Executing an Authorization Code Grant with PKCE flow](/api-auth/tutorials/authorization-code-grant-pkce) +::: 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/articles/api-auth/grant/authorization-code.md b/articles/api-auth/grant/authorization-code.md index 9ff7a0643a..45412c6e0b 100644 --- a/articles/api-auth/grant/authorization-code.md +++ b/articles/api-auth/grant/authorization-code.md @@ -1,32 +1,59 @@ --- -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 --- +# Call APIs from Server-side Web Apps -# Calling 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. -The OAuth 2.0 grant that regular web apps utilize in order to access an API, is the **Authorization Code Grant**. +::: note +If you need a refresher on the OAuth 2.0 protocol, you can go through our [OAuth 2.0](/protocols/oauth2) article. +::: -## Overview +## 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 redirect-based flow where the User Agent receives an `authorization_code` from the Authorization Server and transfers this to the Client. The Client will then interact with the Authorization Server and exchange the `authorization_code` for an `access_token` (and optionally also a `refresh_token`). The Client can now use this `access_token` to call the Resource Server on behalf of the Resource Owner. +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 Client initiates the flow and redirects the user to the Authorization Server - 2. The user authenticates - 3. The Authorization Server redirects the user to the Client with an `authorization_code` in the querystring - 4. The Client 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 `access_token` (and optionally a `refresh_token`) - 6. The Client can use the `access_token` to call the Resource Server on behalf of the user +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. -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 Client*(eg: post messages, list contacts, ...). +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). -## Use Case +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`). - - Allow the Client to make calls to the Resource Server on behalf of the Resource Owner (Delegation) - - The Client is typically a traditional web application +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. - ## Tutorials +1. Auth0 authenticates the web app, validates the Authorization Code and responds back with the token. - - [Configuring your tenant for API Authorization](/api-auth/tutorials/configuring-tenant-for-api-auth) - - [Executing an Authorization Code Grant flow](/api-auth/tutorials/authorization-code-grant) +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/articles/api-auth/grant/client-credentials.md b/articles/api-auth/grant/client-credentials.md index 9491ec041e..8fa8cd26d3 100644 --- a/articles/api-auth/grant/client-credentials.md +++ b/articles/api-auth/grant/client-credentials.md @@ -1,31 +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 -# Calling APIs from a Service +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 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. -## Overview - -With **Client Credentials Grant** (defined in [RFC 6749, section 4.4](https://tools.ietf.org/html/rfc6749#section-4.4)) a Client can directly request an `access_token` to 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 Client itself. +## Client Credentials Grant Flow ![Client Credentials Grant Flow](/media/articles/api-auth/client-credentials-grant.png) - 1. The Client authenticates with the Authorization Server using its Client Id and Client Secret - 2. The Authorization Server validates this information and returns an `access_token` - 3. The Client can use the `access_token` to call the Resource Server on behalf of itself +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. -This flow is not redirect based but is an API call made by the Client to the Authorization Server. And finally the resulting access token can be used by the Client to call the Resource Server. +::: 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. +::: -## Use Case +## How to implement the flow - - Allow the Client to make calls to the Resource Server on its own behalf (machine to machine) - - APIs and services that are not user centric +For details on how to implement this using Auth0, refer to [Execute a Client Credentials Grant](/api-auth/tutorials/client-credentials). -## Tutorials +## Keep reading -- [Setting up a Client Credentials Grant using Auth0's Management Dashboard](/api-auth/config/using-the-auth0-dashboard) -- [Using Rules with Client Credential Grants](/api-auth/grant/using-rules). -- [How to ask Auth0 for an access token for a Resource Server in a Client Credentials Grant](/api-auth/config/asking-for-access-tokens) -- [Using Auth0's Management API for setting up Resource Servers and Client Grants](/api-auth/config/using-the-management-api) +::: 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/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 32a3ee7465..bf1a08f84c 100644 --- a/articles/api-auth/grant/implicit.md +++ b/articles/api-auth/grant/implicit.md @@ -1,33 +1,65 @@ --- -description: Describes how to call APIs from client-side web apps using the Implicit Grant. +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 -The OAuth 2.0 grant that Client-side web apps utilize in order to access an API, is the **Implicit Grant**. +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 also a redirect-based flow, similar to the Authorization Code Grant, but the main difference is that all of the interactions with the Authorization Server happen through the User Agent (this includes receiving the access token). After receiving the `access_token`, the User Agent will expose this to the Client, allowing it to call the Resource Server on behalf of the Resource Owner. +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 Client initiates the flow and redirects the user to the Authorization Server - 2. The user authenticates - 3. The Authorization Server redirects the user to the Client with an `access_token` (and optionally a `id_token`) in the hash fragment - 4. The Client can now extract the tokens from the hash fragment. In a Single Page Application this would be done using Javascript and in a Mobile Application this is typically handled by interacting with a Web View - 5. The Client can use the `access_token` to call the Resource Server on behalf of the user + 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). -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 Client (eg: post messages, list contacts, ...). +## Silent Authentication -## Use Case +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. -- Allow the Client to make calls to the Resource Server on behalf of the Resource Owner -- The Client is typically a Single Page Application or a Mobile Application +For details on how to implement this, refer to [Silent Authentication](/api-auth/tutorials/silent-authentication). -## Tutorials +## Keep reading - - [Configuring your tenant for API Authorization](/api-auth/tutorials/configuring-tenant-for-api-auth) - - [Executing an Implicit Grant flow](/api-auth/tutorials/implicit-grant) - - [Protecting against replay attacks](/api-auth/tutorials/nonce) - - [Silent authentication for SPAs](/api-auth/tutorials/silent-authentication) +::: 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/articles/api-auth/grant/password.md b/articles/api-auth/grant/password.md index e306351332..3da4c9a514 100644 --- a/articles/api-auth/grant/password.md +++ b/articles/api-auth/grant/password.md @@ -1,38 +1,67 @@ --- -description: Describes how to call APIs from highly trusted clients using the Resource Owner Password Grant. +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 -# Calling APIs from Highly Trusted Clients +<%= include('../_includes/_ropg-warning') %> -Highly trusted mobile apps and Client-side web apps can use the **Resource Owner Password Grant** to access an API. In this flow the end-user is asked to fill in credentials (username/password) typically using an interactive form. This information is later on sent to the Client and the Authorization Server. It is therefore imperative that the Client is absolutely trusted with this information. +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. -## Overview +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. -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 client and when other authorization flows are not available. +![Resource Owner Password Grant](/media/articles/api-auth/password-grant.png) -This grant type can eliminate the need for the client to store the user credentials for future use, by exchanging the credentials with a long-lived access token or refresh token. + 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. -![Resource Owner Password Grant](/media/articles/api-auth/password-grant.png) +::: 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 - 1. The Resource Owner enters the credentials into the client application - 2. The client forwards the Resource Owner's credentials to the Authorization Server - 3. The Authorization server validates the information and returns an `access_token`, and optionally a `refresh_token` - 4. The Client can use the `access_token` to call the Resource Server on behalf of the Resource Owner +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`. -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. +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). -## Use Case +## 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). -- Allow the Client to make calls to the Resource Server on behalf of the Resource Owner -- The Client is a highly trusted application and other authorization flows are not available +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). -## Tutorials +## Keep reading - - [Configuring your tenant for API Authorization](/api-auth/tutorials/configuring-tenant-for-api-auth) - - [Executing a Resource Owner Password Grant](/api-auth/tutorials/password-grant) +* [Implement the Resource Owner Password Grant](/api-auth/tutorials/password-grant) +* [Tokens](/tokens) diff --git a/articles/api-auth/grant/using-rules.md b/articles/api-auth/grant/using-rules.md deleted file mode 100644 index e435845a05..0000000000 --- a/articles/api-auth/grant/using-rules.md +++ /dev/null @@ -1,140 +0,0 @@ ---- -description: Describes using rules with Client Credentials Grants. ---- - -# Using Rules with Client Credentials Grants - -You can now add [rules](/rules) into the [client credentials](/api-auth/grant/client-credentials) exchange pipeline where you exchange a `client_id` and `secret` for an `access_token`. - -## Prior to Beginning Your Configuration - -Please ensure that: - -* You have the [Webtask Command Line Interface (CLI) installed](${manage_url}/#/account/webtasks); -* You have created an [API defined with the appropriate scopes](${manage_url}/#/apis); -* You have created a [non-interactive client](${manage_url}/#/applications) that is authorized to use the API created in the previous step. - -## Creating the Rule - -**Note**: You can only create one rule, which will then be executed for **all** clients and APIs. - -### 1. Create the Rule For Use with Webtasks - -Create a file named `myrule.js`, and enter the following: - -```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 is a sample rule that 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). - -### 2. Create the Webtask to Use Your Rule - -Create the Webtask. You will need to set the following static metadata fields for the Webtask: - -* `wt-compiler = auth0-ext-compilers/client-credentials-exchange` -* `auth0-extension = runtime` -* `auth0-extension-name = credentials-exchange` -* `auth0-extension-secret = {random_secret}` - -The same `{random_secret}` value provided to the `auth0-extension-secret` metadata property must also be provided to the webtask code as an `auth0-extension-secret` secret parameter. This prevents unauthorized calls to this webtask. A secret may be conveniently created using `openssl` tool if your platform has it available: - -``` -SECRET=$(openssl rand 32 -base64) && \ -wt create myrule.js \ - --meta wt-compiler=auth0-ext-compilers/client-credentials-exchange \ - --meta auth0-extension=runtime \ - --meta auth0-extension-name=credentials-exchange \ - --meta auth0-extension-secret=$SECRET \ - --secret auth0-extension-secret=$SECRET -``` - -### 3. Test Your Setup - -To test your newly-created rule and webtask, make the following `POST` call: - -```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\",\"audience\": \"API_IDENTIFIER\",\"grant_type\": \"client_credentials\"}" - } -} -``` - -If all is well, you will receive a JWT `access_token` that looks like this: - -```json -{ - "iss": "https://YOURS.auth0.com/", - "sub": "YOUR_CLIENT_ID@clients", - "aud": "API_IDENTIFIER", - "exp": 1472832994, - "iat": 1472746594, - "scope": "test extra", - "https://foo.com/claim": "bar" -} -``` - -## Implementation Notes - -### Input Parameters - -The input parameters for the rule, including sample snippets: - -* **client** - `object` - the client asking for the token, including the `client` metadata (a key-value pair that can be set by client) - - ```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 - - ```json - { - "ip": "123.123.123.123", - "userAgent": "...", - "webtask": { - "secrets": { "FOO": "bar" } - } - } - ``` - -### Auth0 Runtime Expectation - -The Auth0 Runtime expects you to return an `access_token` that looks like the following: - -```json -{ - "https://anything.com/foo": "bar", - "scope": [ "scope1", "scope2" ] -} -``` - -If you decide not to issue the token, you can return `Error (cb(new Error('access denied')))`. - -### Logs - -You can use `wt logs` to see realtime logs. For additional information on reading the output, please consult [Webtask Streaming Logs](https://webtask.io/docs/api_logs). diff --git a/articles/api-auth/index.html b/articles/api-auth/index.html deleted file mode 100644 index 57cb373cfd..0000000000 --- a/articles/api-auth/index.html +++ /dev/null @@ -1,146 +0,0 @@ ---- -url: /api-auth -section: articles -classes: topic-page -title: API Authorization ---- - -
-
-

API Authorization

-

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

-
- -

- At some point, your APIs will need to allow limited access to users, servers, or servers on behalf of users. -

- -

- Auth0's API authorization features allow you to manage the authorization requirements for server-to-server and client-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. -

- - - diff --git a/articles/api-auth/index.md b/articles/api-auth/index.md new file mode 100644 index 0000000000..2c2bdf84b6 --- /dev/null +++ b/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/articles/api-auth/intro.md b/articles/api-auth/intro.md new file mode 100644 index 0000000000..77aa80441c --- /dev/null +++ b/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/articles/api-auth/passwordless.md b/articles/api-auth/passwordless.md new file mode 100644 index 0000000000..cc007bfeb4 --- /dev/null +++ b/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/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/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/_about.md b/articles/api-auth/tutorials/adoption/_about.md new file mode 100644 index 0000000000..e2f174b015 --- /dev/null +++ b/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/articles/api-auth/tutorials/adoption/_index.md b/articles/api-auth/tutorials/adoption/_index.md new file mode 100644 index 0000000000..40760b5d79 --- /dev/null +++ b/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/articles/api-auth/tutorials/adoption/api-tokens.md b/articles/api-auth/tutorials/adoption/api-tokens.md new file mode 100644 index 0000000000..8c310789ec --- /dev/null +++ b/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/articles/api-auth/tutorials/adoption/authorization-code.md b/articles/api-auth/tutorials/adoption/authorization-code.md new file mode 100644 index 0000000000..692a46e71f --- /dev/null +++ b/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/articles/api-auth/tutorials/adoption/client-credentials.md b/articles/api-auth/tutorials/adoption/client-credentials.md new file mode 100644 index 0000000000..bc6189bcf3 --- /dev/null +++ b/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/articles/api-auth/tutorials/adoption/delegation.md b/articles/api-auth/tutorials/adoption/delegation.md new file mode 100644 index 0000000000..8fea9b651a --- /dev/null +++ b/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/articles/api-auth/tutorials/adoption/implicit.md b/articles/api-auth/tutorials/adoption/implicit.md new file mode 100644 index 0000000000..451729f8b3 --- /dev/null +++ b/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/articles/api-auth/tutorials/adoption/index.md b/articles/api-auth/tutorials/adoption/index.md new file mode 100644 index 0000000000..eb7827dc97 --- /dev/null +++ b/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/articles/api-auth/tutorials/adoption/oidc-conformant.md b/articles/api-auth/tutorials/adoption/oidc-conformant.md new file mode 100644 index 0000000000..a8a601f4ad --- /dev/null +++ b/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/articles/api-auth/tutorials/adoption/password.md b/articles/api-auth/tutorials/adoption/password.md new file mode 100644 index 0000000000..15834e8bba --- /dev/null +++ b/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/articles/api-auth/tutorials/adoption/refresh-tokens.md b/articles/api-auth/tutorials/adoption/refresh-tokens.md new file mode 100644 index 0000000000..fa8d7447b6 --- /dev/null +++ b/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/articles/api-auth/tutorials/adoption/scope-custom-claims.md b/articles/api-auth/tutorials/adoption/scope-custom-claims.md new file mode 100644 index 0000000000..10b72653ed --- /dev/null +++ b/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/articles/api-auth/tutorials/adoption/single-sign-on.md b/articles/api-auth/tutorials/adoption/single-sign-on.md new file mode 100644 index 0000000000..f421306e27 --- /dev/null +++ b/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/articles/api-auth/tutorials/authorization-code-grant-pkce.md b/articles/api-auth/tutorials/authorization-code-grant-pkce.md index e8f966860e..e93cd3913b 100644 --- a/articles/api-auth/tutorials/authorization-code-grant-pkce.md +++ b/articles/api-auth/tutorials/authorization-code-grant-pkce.md @@ -1,21 +1,55 @@ --- 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];
@@ -28,7 +62,8 @@ String verifier = Base64.encodeToString(code, Base64.URL_SAFE | Base64.NO_WRAP |
 _ = SecRandomCopyBytes(kSecRandomDefault, buffer.count, &buffer)
 let verifier = Data(bytes: buffer).base64EncodedString()
     .replacingOccurrences(of: "+", with: "-")
-    .replacingOccurrences(of: "/", with: "_")
+    .replacingOccurrences(of: "/", with: "\_")
+    .replacingOccurrences(of: "=", with: "")
     .trimmingCharacters(in: .whitespaces)
@@ -43,25 +78,37 @@ NSString *verifier = [[[[data base64EncodedStringWithOptions:0]
+## 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(input, 0, input.length);
+md.update(bytes, 0, bytes.length);
 byte[] digest = md.digest();
-String challenge = Base64.encodeToString(digest, Base64.URL_SAFE | Base64.NO_WRAP | Base64.NO_PADDING);
+//Use Apache "Commons Codec" dependency. Import the Base64 class +//import org.apache.commons.codec.binary.Base64; +String challenge = Base64.encodeBase64URLSafeString(digest); 
@@ -74,7 +121,8 @@ data.withUnsafeBytes {
 let hash = Data(bytes: buffer)
 let challenge = hash.base64EncodedString()
     .replacingOccurrences(of: "+", with: "-")
-    .replacingOccurrences(of: "/", with: "_")
+    .replacingOccurrences(of: "/", with: "\_")
+    .replacingOccurrences(of: "=", with: "")
     .trimmingCharacters(in: .whitespaces)
@@ -93,7 +141,9 @@ NSString *challenge = [[[[hash base64EncodedStringWithOptions:0]
-To begin an Authorization Code Grant flow, your Client application should first send the user to the authorization URL including the `code_challenge` and the method used to generate it: +## 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? @@ -108,15 +158,21 @@ https://${account.namespace}/authorize? Where: -* `audience`: The target API for which the Client Application is requesting access on behalf of the user. -* `scope`: The scopes which you want to request authorization for. These must be separated by a space. -* `response_type`: The response type. For this flow, the value must be `code`. This indicates to the Authorization Server that you are performing an Authorization Code flow. -* `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 Authorization Code will be available in the hash fragment of this URL (via the `code` param). This URL must be specified as a valid callback URL under the Client Settings of your application. +* `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-warning A Note About code_challenge_method +::: 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. ::: @@ -128,20 +184,41 @@ For example: ``` -## Exchange the Authorization Code for an Access Token +## 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 OAuth Token URL 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}" + } + ] } } ``` @@ -154,7 +231,7 @@ Where: * `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 from `/oauth/token` contains `access_token`, `refresh_token`, `id_token`, and `token_type` values, for example: +The response contains `access_token`, `refresh_token`, `id_token`, and `token_type` values, for example: ```js { @@ -165,15 +242,15 @@ The response from `/oauth/token` contains `access_token`, `refresh_token`, `id_t } ``` -Note that the `refresh_token` will be present in the response, only 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 [Refresh Token](/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-danger Warning -It is important to understand that the Authorization Code flow with PKCE can only be used for Clients whose type is `Native` in the Dashboard. +::: warning +The Authorization Code flow with PKCE can only be used for Applications whose type is `Native` or `Single Page Application` in the Dashboard. ::: -## Use the Access Token +## 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 { @@ -185,3 +262,28 @@ 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. + +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/articles/api-auth/tutorials/authorization-code-grant.md b/articles/api-auth/tutorials/authorization-code-grant.md index a0f9e0d300..5ecd2127c1 100644 --- a/articles/api-auth/tutorials/authorization-code-grant.md +++ b/articles/api-auth/tutorials/authorization-code-grant.md @@ -1,29 +1,55 @@ --- 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 -To begin an Authorization Code Grant flow, your Client application should first send the user to the authorization URL: +::: 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={API_AUDIENCE}& - scope={SCOPE}& + audience=YOUR_API_AUDIENCE& + scope=YOUR_SCOPE& response_type=code& client_id=${account.clientId}& redirect_uri=${account.callback}& - state={OPAQUE_VALUE} + state=YOUR_OPAQUE_VALUE ``` Where: -* `audience`: The target API for which the Client Application is requesting access on behalf of the user. -* `scope`: The scopes which you want to request authorization for. These must be separated by a space. -* `response_type`: The response type. For this flow, the value must be `code`. This indicates to the Authorization Server that you are performing an Authorization Code flow. -* `client_id`: Your application's Client ID. -* `state`: An opaque value the clients adds 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, [click here to learn more](/protocols/oauth-state). -* `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 Authorization Code will be available in `code` URL parameter. This URL must be specified as a valid callback URL under the Client Settings of your application. +* `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: @@ -33,24 +59,45 @@ For example: ``` -The purpose of this call is to obtain consent from the user to invoke the Resource Server (specified in `audience`) to do certain things (specified in `scope`) on behalf of the user. The Authorization Server will authenticate the user and obtain consent, unless consent has been previously given. +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`, the Authorization Server will require consent to be given again. +Note that if you alter the value in `scope`, Auth0 will require consent to be given again. -## Exchange the Authorization Code for an Access Token +## 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 OAuth Token URL: +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\": \"${account.clientSecret}\",\"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}" + } + ] } } ``` @@ -63,7 +110,7 @@ Where: * `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 from `/oauth/token` contains `access_token`, `refresh_token`, `id_token`, and `token_type` values, for example: +The response contains the `access_token`, `refresh_token`, `id_token`, and `token_type` values, for example: ```js { @@ -74,16 +121,15 @@ The response from `/oauth/token` contains `access_token`, `refresh_token`, `id_t } ``` -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 Resource Server (API) in the Dashboard. For more information about Refresh Tokens and how to use them, see [our documentation]( - https://auth0.com/docs/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-danger 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 is more appropriate in that case. +::: 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. ::: -## Use the Access Token +## 3. Call the API -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 API by passing it as a Bearer Token in the `Authorization` header of the HTTP request: ```har { @@ -91,7 +137,26 @@ Once the `access_token` has been obtained it can be used to make calls to the Re "url": "https://someapi.com/api", "headers": [ { "name": "Content-Type", "value": "application/json" }, - { "name": "Authorization", "value": "Bearer {ACCESS_TOKEN}" } + { "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/articles/api-auth/tutorials/client-credentials.md b/articles/api-auth/tutorials/client-credentials.md new file mode 100644 index 0000000000..567e903447 --- /dev/null +++ b/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/articles/api-auth/tutorials/client-credentials/customize-with-hooks.md b/articles/api-auth/tutorials/client-credentials/customize-with-hooks.md new file mode 100644 index 0000000000..e8c5f642f2 --- /dev/null +++ b/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/articles/api-auth/tutorials/configuring-tenant-for-api-auth.md b/articles/api-auth/tutorials/configuring-tenant-for-api-auth.md deleted file mode 100644 index 0c534fa7f1..0000000000 --- a/articles/api-auth/tutorials/configuring-tenant-for-api-auth.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -description: How to configure you tenant to enable the new API Authorization Flows ---- - -# Configure your tenant for the new API Authorization flows - -If you want to unlock the new API Authorization scenario, you will need to enable a flag under your [Account Settings](${manage_url}/#/account/advanced). This will allow you to opt-in and out of this feature at any point in time while it remains under preview. - -1. Open the Management Dashboard and browse to your [Account Settings](${manage_url}/#/account/advanced). -1. Click on the _Advanced_ tab, scroll down to the _Settings_ section and turn on the flag __OAuth 2.0 API Authorization__. - - ![OAuth 2.0 API Authorization flag](/media/articles/api-auth/account-settings.png) - -You will now see that the API section is displayed on your sidebar. - -**NOTE**: For docs on the new API Authorization flows refer to [API Authorization](/api-auth). 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 2d777bc8e0..07c8ccc2c5 100644 --- a/articles/api-auth/tutorials/implicit-grant.md +++ b/articles/api-auth/tutorials/implicit-grant.md @@ -1,48 +1,83 @@ --- -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 --- +# Implement the Implicit Grant -# Execute the Implicit Grant Flow +::: 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). +::: -In order to execute an Implicit Grant flow you will need to configure your Client application to send the user to the authorization URL: +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={API_AUDIENCE}& - scope={SCOPE}& - response_type={RESPONSE_TYPE}& + audience=YOUR_API_AUDIENCE& + scope=YOUR_SCOPE& + response_type=YOUR_RESPONSE_TYPE& client_id=${account.clientId}& redirect_uri=${account.callback}& - nonce={CRYPTOGRAPHIC_NONCE} - state={OPAQUE_VALUE} + nonce=YOUR_CRYPTOGRAPHIC_NONCE& + state=YOUR_OPAQUE_VALUE ``` Where: -* `audience`: The target API for which the Client Application is requesting access on behalf of the user. -* `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`). +* `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. - ::: panel-info Custom claims namespaced format - In order to improve compatibility for client 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`. +* `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. ::: -* `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`, 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 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 the Client Settings of your application. -* `state`: 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. -* `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`. +* `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 ``` -## Extract the Access Token +## 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. -After Auth0 has redirected back to the Client, you can extract the `access_token` from the hash fragment of the URL: +You can extract the `access_token`, and other parameters, from the hash fragment of the URL: ```js function getParameterByName(name) { @@ -61,21 +96,21 @@ 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(); - // Use the access token to make API calls + // Use the Access Token to make API calls // ... }); ``` -## Use the Access Token +## 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 +// Use the Access Token to make API calls $('#get-appointments').click(function(e) { e.preventDefault(); @@ -87,10 +122,33 @@ $('#get-appointments').click(function(e) { }); ``` -## More information +## 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 -- [Implicit Grant overview](/api-auth/grant/implicit) -- [Authentication API Explorer](/api/authentication#implicit-grant) -- [How to configure your tenant for the new API Authorization flows](/api-auth/tutorials/configuring-tenant-for-api-auth) -- [Mitigate replay attacks](/api-auth/tutorials/nonce) -- [Silent Authentication for SPAs](/api-auth/tutorials/silent-authentication) +- [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/articles/api-auth/tutorials/nonce.md b/articles/api-auth/tutorials/nonce.md index b34074914a..c83e542ae8 100644 --- a/articles/api-auth/tutorials/nonce.md +++ b/articles/api-auth/tutorials/nonce.md @@ -1,27 +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 -When using the [Implicit Grant](/api-auth/grant/implicit), a 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 client, sent as a `nonce` query string parameter in the authentication request, and included in the ID token response from Auth0. -This allows clients to correlate the ID token response from Auth0 with the initial authentication request. +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 -[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; } ``` @@ -38,14 +63,14 @@ For example: window.localStorage.setItem('nonce', randomString(16)); ``` -## Validate the ID token +## Validate the ID Token -Once Auth0 responds with an ID token, this token must be validated and decoded as usual. +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 +var jwt = '...'; // validated and decoded ID Token body if (jwt.nonce === window.localStorage.getItem('nonce')) { // Nonce is OK } else { diff --git a/articles/api-auth/tutorials/password-grant.md b/articles/api-auth/tutorials/password-grant.md index eb5b0bf4ef..f8ef39ba44 100644 --- a/articles/api-auth/tutorials/password-grant.md +++ b/articles/api-auth/tutorials/password-grant.md @@ -1,37 +1,85 @@ --- -description: How to execute a 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 --- +# Implement the Resource Owner Password Grant -# Execute the Resource Owner Password Grant +<%= include('../_includes/_ropg-warning') %> -::: panel-danger Warning -Support for Rules and Refresh Tokens will be available in a future release. -::: +In this tutorial, we will go through the steps required to implement the Resource Owner Password Grant flow. + +## Before you start -## Configure your tenant for the Resource Owner Password Grant +* 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 Management Dashboard and browse to your [Account Settings](${manage_url}/#/account). -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 (i.e. database connections, AD, LDAP, Windows Azure AD, ADFS) +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) +![Update Default Directory](/media/articles/api-auth/default-directory-setting.png) -## Execute the flow +## Ask for a Token -In order to execute the flow the client needs to acquire the Resource Owner's credentials, usually this will be through the use of an interactive form. Once the client has the credentials it needs to forward them to Auth0 with a POST to the token endpoint. +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/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\": \"${account.clientSecret}\"}" + "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" + } + ] } } ``` @@ -39,14 +87,14 @@ In order to execute the flow the client needs to acquire the Resource Owner's cr Where: * `grant_type`: This must be `password`. -* `username`: Resource Owner's identifier. -* `password`: Resource Owner's secret. -* `audience`: API Identifier that the client is requesting access to. -* `client_id`: Client ID of the client making the request. -* `client_secret`: Client Secret of the client making the request. Required when the **Token Endpoint Authentication Method** field at your [Client Settings](${manage_url}/#/clients/${account.clientId}/settings) is `Post` or `Basic`. Do not set this parameter if your client is not highly trusted (for example, SPA). -* `scope`: String value of the different scopes the client is asking for. Multiple scopes are separated with whitespace. +* `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 from `/oauth/token` (if successful) contains an `access_token`, for example: +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 { @@ -56,21 +104,21 @@ The response from `/oauth/token` (if successful) contains an `access_token`, for } ``` -In case the scopes issued to the client differ from the scopes requested, a `scope` parameter will be included in the response JSON, listing the issued scopes. +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-info 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`, etc.) are included in the `access_token`. +::: 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-info 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. +::: 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 +### 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. @@ -83,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\": \"${account.clientSecret}\", \"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-info 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. +::: 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 Access Token +## 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 { @@ -110,3 +191,29 @@ 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. + +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/articles/api-auth/tutorials/represent-multiple-apis.md b/articles/api-auth/tutorials/represent-multiple-apis.md new file mode 100644 index 0000000000..5eaf10b709 --- /dev/null +++ b/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/articles/api-auth/tutorials/silent-authentication.md b/articles/api-auth/tutorials/silent-authentication.md index c51a09d071..cb23a93b46 100644 --- a/articles/api-auth/tutorials/silent-authentication.md +++ b/articles/api-auth/tutorials/silent-authentication.md @@ -1,45 +1,143 @@ --- -description: How to keep users logged in to your single-page 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 for Single Page Apps +# Configure Silent Authentication -Single Page web applications (SPAs) normally use the [Implicit Grant flow](/api-auth/grant/implicit) for authentication. -This flow returns an ID token and optionally an access token to authenticate and authorize the user. -These tokens, however, expire after some time and must be renewed to keep a user authenticated without them having to log in again. +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. -## Access token expiration +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. -Access tokens are opaque to clients. This means that clients are unable to inspect the contents of access tokens to determine their expiration date. +<%= include('../../_includes/_refresh_token_rotation_recommended.md') %> -There are two options to determine when an access token expires: +## Initiate Silent Authentication requests -1. Read the [`expires_in` response parameter](https://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthResponse) returned by Auth0. -2. Ignore expiration dates altogether. Instead, try to renew the access token if rejected by the API. +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. +) -The `expires_in` parameter is returned by Auth0 as a hash parameter following a successful authentication. -For example, Auth0 could call your callback URL with the following parameters: +For example: ```text -https://myapp.example.com/ - #access_token=...& - id_token=...& - token_type=Bearer& +GET https://${account.namespace}/authorize + ?response_type=id_token token& + client_id=...& + redirect_uri=...& state=...& - expires_in=3600 + scope=openid...& + nonce=...& + audience=...& + response_mode=...& + prompt=none ``` -This parameter indicates how many seconds the access token will be valid for. -With this information we can call `setTimeout` or some other scheduling mechanism to renew the access token when needed. +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. -## Use `prompt=none` to retrieve a new token +::: note +Any applicable [rules](/rules) will be executed as part of the silent authentication process. +::: -When you authenticate a user to your application, you would normally redirect them to the [`/authorize` endpoint of Auth0's authentication API](/api/authentication#social). +### Successful authentication responses -This endpoint supports a `prompt` query parameter; if it is set to `none`, the following will happen: +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. -* If the user is still authenticated, Auth0 will call back to your application immediately with renewed ID and access tokens. -* If the user is no longer authenticated or had never authenticated, Auth0 will call back to your application with an error. +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) -You can use the [`renewAuth` method from auth0.js](https://github.com/auth0/auth0.js#api) to authenticate users with `prompt=none` in an iframe. -This lets you keep users logged in without needing to refresh or redirect away from your application. 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 new file mode 100644 index 0000000000..e6a60b46de --- /dev/null +++ b/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/articles/api-auth/user-consent.md b/articles/api-auth/user-consent.md new file mode 100644 index 0000000000..75c4329390 --- /dev/null +++ b/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/articles/api-auth/which-oauth-flow-to-use.md b/articles/api-auth/which-oauth-flow-to-use.md index de8e696050..3c2fe7f418 100644 --- a/articles/api-auth/which-oauth-flow-to-use.md +++ b/articles/api-auth/which-oauth-flow-to-use.md @@ -1,48 +1,69 @@ --- -title: Which OAuth 2.0 flow should I use? -description: Helps the user identify the proper OAuth 2.0 grant for each use case. +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? +# Which OAuth 2.0 Flow Should I Use? -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 Client's type, but other parameters weight in as well, like the level of trust for the Client, or the experience you want your users to have. +[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. -Follow this flow to identify the grant that best matches your case. +## OAuth 2.0 terminology -![Flowchart for OAuth 2.0 Grants](/media/articles/api-auth/oauth2-grants-flow.png) - -::: panel-info Quick refresher - 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. +- **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 this case of machine to machine authorization, the Client 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 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. +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 Grant](/api-auth/grant/client-credentials). +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 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 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 Grant](/api-auth/grant/authorization-code). +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 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 later on sent to the Client and the Authorization Server. It is therefore imperative that the Client is absolutely trusted with this information. +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). -## Is the Client a native app or a SPA? +### Implicit Grant -If the Client is a Single Page Application (meaning an application running in a browser using a scripting language such as Javascript) then the [Implicit Grant](/api-auth/grant/implicit) should be used. In this case, instead of getting an authorization code that needs to be exchanged for an access token, the Client 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. You need to get a new access token, using the `/authorize` endpoint of the [Auth0 Authentication API](/api/authentication), each time the old expires. +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. -If the Client is an SPA, then for more information on how this flow works and how to implement it refer to: [Implicit Grant](/api-auth/grant/implicit). +For more information on how this flow works and how to implement it, refer to [Implicit Flow](/flows/concepts/implicit). -**NOTE:** While SPAs cannot use refresh tokens, 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. This will not display the login dialog or the consent dialog. In addition to that if you call `/authorize` from a hidden iframe and extract the new access token from the parent frame, then the user will not see the redirects happening. +## Is the Client a Native/Mobile App? -If the Client is a native app then the [Authorization Code Grant using Proof Key for Code Exchange](/api-auth/grant/authorization-code-pkce) is used. What this grant adds to Authorization Code Grant, is the concept of `code_verifier`. When at first the client 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 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. +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. -If the Client is a native app, then for more information on how this flow works and how to implement it refer to: [Authorization Code Grant (PKCE)](/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/authentication/_application-reg.md b/articles/api/authentication/_application-reg.md new file mode 100644 index 0000000000..21471c3821 --- /dev/null +++ b/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/articles/api/authentication/_change-password.md b/articles/api/authentication/_change-password.md index 2478a5186d..00e44b2854 100644 --- a/articles/api/authentication/_change-password.md +++ b/articles/api/authentication/_change-password.md @@ -1,15 +1,13 @@ # Change Password - -
Examples
- + ```http POST https://${account.namespace}/dbconnections/change_password -Content-Type: 'application/json' +Content-Type: application/json { "client_id": "${account.clientId}", "email": "EMAIL", - "password": "", "connection": "CONNECTION", + "organization": "ORGANIZATION_ID" } ``` @@ -17,36 +15,34 @@ 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 +// Script uses auth0.js. See Remarks for details. - -$('.change_password').click(function () { - auth0.changePassword({ + + webAuth.changePassword({ connection: 'CONNECTION', - email: 'EMAIL' + email: 'EMAIL', + organization: 'ORGANIZATION_ID' }, function (err, resp) { if(err){ console.log(err.message); }else{ console.log(resp); } - }); -}); + ``` <%= include('../../_includes/_http-method', { + "http_badge": "badge-success", "http_method": "POST", "path": "/dbconnections/change_password", "link": "#change-password" @@ -58,34 +54,34 @@ $('.change_password').click(function () { "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. +- 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](/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-configurations) diff --git a/articles/api/authentication/_delegation.md b/articles/api/authentication/_delegation.md deleted file mode 100644 index e089a73fb3..0000000000 --- a/articles/api/authentication/_delegation.md +++ /dev/null @@ -1,113 +0,0 @@ -# Delegation - -
Examples
- -```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 - - - -//get a delegation token -var options = { - id_token: "TOKEN", // The id_token you have now - api: 'API_TYPE', // 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 -}); - -//get the token for another API or App -var options = { - id_token: "TOKEN", // The id_token you have now - api: 'auth0' // This is default when calling another app that doesn't have an addon - targetClientId: 'TARGET_CLIENT_ID' -}; - -auth0.getDelegationToken(options, function (err, delegationResult) { - // Call your API using delegationResult.id_token -}); -``` - -> RESPONSE SAMPLE: - -```json -{ - "token_type": "Bearer", - "expires_in": 36000, - "id_token": "eyJ0eXAi..." -} -``` - -<%= include('../../_includes/_http-method', { - "http_method": "POST", - "path": "/delegation", - "link": "#delegation" -}) %> - -Delegated authentication is used when an entity wants to call another entity on behalf of the user. For example, a user logs into an application and then calls an API. The application exchanges the token of the logged in user with a token that is signed with the API secret to call the API. - -Given an existing token, this endpoint will generate a new token signed with the `target` client's secret. This is used to flow the identity of the user from the application to an API or across different APIs that are secured with different secrets. - -### Request Parameters - -| Parameter | Description | -|:-----------------|:------------| -| `client_id`
Required | Τhe `client_id` of your client | -| `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. | - - -### 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 **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 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`. -- The `email` scope value requests access to the `email` and `email_verified` Claims. - -### More Information -- [Delegation Tokens](/tokens/delegation) diff --git a/articles/api/authentication/_impersonation.md b/articles/api/authentication/_impersonation.md deleted file mode 100644 index a68579ac11..0000000000 --- a/articles/api/authentication/_impersonation.md +++ /dev/null @@ -1,90 +0,0 @@ -# Impersonation - -
Examples
- -```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_method": "POST", - "path": path, - "link": "#impersonation" -}) %> - -::: panel-warning Advanced Feature -Impersonation functionality may be disabled by default for your tenant, but can be enabled by [contacting support](${env.DOMAIN_URL_SUPPORT}). -::: - -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 ac4d965432..0df041af98 100644 --- a/articles/api/authentication/_introduction.md +++ b/articles/api/authentication/_introduction.md @@ -1,10 +1,145 @@ # Introduction -The Authentication API exposes the identity functionality of Auth0, as well as the supported identity protocols like [OpenID Connect](/protocols/oidc), [OAuth 2.0](/protocols/oauth2), and [SAML](/protocols/saml). +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. -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. +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). -For each endpoint in this document you will find sample snippets you can use, in three available formats: +:::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/articles/api/authentication/_linking.md b/articles/api/authentication/_linking.md deleted file mode 100644 index 4a87086872..0000000000 --- a/articles/api/authentication/_linking.md +++ /dev/null @@ -1,121 +0,0 @@ -# Account Linking - -## Link - -
Examples
- -```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_method": "GET", - "path": "/authorize", - "link": "#link" -}) %> - -::: panel-danger Deprecation Notice -This endpoint is deprecated for account linking. The [POST /api/v2/users/{id}/identities](/api/management/v2#!/Users/post_identities) should be used instead. -::: - -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 client | -| `connection` | The name of the connection configured to your client. 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 [Client's Settings](${manage_url}/#/clients/${account.clientId}/settings). - - -### More Information - -- [Linking Accounts](/link-accounts) -- [User Initiated Account Linking](/link-accounts/user-initiated-linking) -- [Account Linking from Server Side Code](/link-accounts/suggested-linking) - - -## Unlink - -
Examples
- -```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_method": "POST", - "path": "/login/unlink", - "link": "#unlink" -}) %> - -::: panel-danger Deprecation Notice -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. -::: - -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` | - - -### Test with Postman - -<%= include('../../_includes/_test-with-postman') %> - - -### More Information - -- [Unlinking Accounts](/link-accounts#unlinking-accounts) diff --git a/articles/api/authentication/_login.md b/articles/api/authentication/_login.md index 73a8a36048..ede24026ba 100644 --- a/articles/api/authentication/_login.md +++ b/articles/api/authentication/_login.md @@ -1,8 +1,14 @@ + # Login -## Social +<%= include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "GET", + "path": "/authorize", + "link": "#social" +}) %> -
Examples
+## Social ```http GET https://${account.namespace}/authorize? @@ -11,212 +17,132 @@ GET https://${account.namespace}/authorize? connection=CONNECTION& redirect_uri=${account.callback}& state=STATE& - additional-parameter=ADDITIONAL_PARAMETERS + ADDITIONAL_PARAMETERS ``` ```javascript +// Script uses auth0.js. See Remarks for details. -//trigger login with google -$('.login-google').click(function () { - auth0.login({ + // Trigger login with google + webAuth.authorize({ connection: 'google-oauth2' }); -}); -//trigger login with github -$('.login-github').click(function () { - auth0.login({ + // Trigger login with github + webAuth.authorize({ connection: 'github' }); -}); - -//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!'); - }); -}); - -//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 login popup with twitter + webAuth.popup.authorize({ + connection: 'twitter' }); -}); + ``` -<%= include('../../_includes/_http-method', { - "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`. - -**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. +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 | Use `code` for server side flows and `token` for client side flows | -| `client_id`
Required | The `client_id` of your client | -| `connection` | The name of a social identity provider configured to your client, for example `google-oauth2` or `facebook`. If null, it will redirect to [Auth0 Login Page](https://auth0.com/#/login_page) 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. | -| `state`
Recommended | An opaque value the clients adds 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. | -| `additional-parameter` | Use this to send additional parameters 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 **Client** (select the client 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 [Client Settings](${manage_url}/#/clients/${account.clientId}/settings). - -1. At the *OAuth2 / OIDC* tab, click **OAuth2 / OIDC Login**. +| `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 -- The `redirect_uri` value must be specified as a valid callback URL under your [Client's Settings](${manage_url}/#/clients/${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). -### More Information +### Learn More -- [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-) -## Social with Provider's Access Token - -
Examples
+## Database/AD/LDAP (Passive) ```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"}' +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 -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); -``` +// Script uses auth0.js. See Remarks for details. + + ``` -<%= include('../../_includes/_http-method', { - "http_method": "POST", - "path": "/oauth/access_token", - "link": "#social-with-provider-s-access-token" -}) %> - -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. - +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 | |:-----------------|:------------| -| `client_id`
Required | The `client_id` of your client. | -| `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. | - - -### Test with Postman - -<%= include('../../_includes/_test-with-postman') %> - +| `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 -- 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 +- 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). -For the complete error code reference for this endpoint refer to [Errors > POST /oauth/access_token](#post-oauth-access_token). +### 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-) -### More Information -- [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) - - -## Database/AD/LDAP (Passive) - -
Examples
+## Enterprise (SAML and Others) ```http GET https://${account.namespace}/authorize? @@ -224,304 +150,224 @@ GET https://${account.namespace}/authorize? client_id=${account.clientId}& connection=CONNECTION& redirect_uri=${account.callback}& - state=STATE& - additional-parameter=ADDITIONAL_PARAMETERS + state=STATE ``` ```javascript +// Script uses auth0.js. See Remarks for details. -//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 with offline mode support to get the refresh_token -$('.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 + // 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' }); -}); -``` - -> RESPONSE SAMPLE -```text -HTTP/1.1 302 Found -Location: https://auth0.com/#/login_page&state=STATE + // Redirect to url + // ... + ``` -<%= include('../../_includes/_http-method', { - "http_method": "GET", - "path": "/authorize", - "link": "#database-ad-ldap-passive-" -}) %> +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). -Use this endpoint for browser based (passive) authentication. It returns a `302` redirect to [Auth0 Login Page](https://auth0.com/#/login_page) that will show the Login Widget where the user can login with email and password. +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 and `token` for client side flows. | -| `client_id`
Required | The `client_id` of your client. | -| `connection` | The name of the connection configured to your client. 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. | -| `state`
Recommended | An opaque value the clients adds 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. | - - -### Test with Authentication API Debugger - -<%= include('../../_includes/_test-this-endpoint') %> - -1. At the *Configuration* tab, set the fields **Client** (select the client 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 [Client Settings](${manage_url}/#/clients/${account.clientId}/settings). - -1. At the *OAuth2 / OIDC* tab, click **OAuth2 / OIDC Login**. - +| `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 -- The `redirect_uri` value must be specified as a valid callback URL under your [Client's Settings](${manage_url}/#/clients/${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. -- The main difference between passive and active authentication is that the former happens in the browser through the [Login Page](https://auth0.com/#/login_page) and the latter can be invoked from anywhere (a script, server to server, and so forth). - - -### More Information -- [Database Identity Providers](/connections/database) -- [Rate Limits on User/Password Authentication](/connections/database/rate-limits) -- [Active Directory/LDAP Connector](/connector) -- [Using the State Parameter](/protocols/oauth2/oauth-state) - - -## Database/AD/LDAP (Active) - -
Examples
+- 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). -```http -POST https://${account.namespace}/oauth/ro -Content-Type: 'application/json' -{ - "client_id": "${account.clientId}", - "username": "USERNAME", - "password": "PASSWORD", - "connection": "CONNECTION", - "scope": "openid", -} -``` +### Learn More -```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"}' +- [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 -```javascript - - +:::note +This feature is currently in Early Access. To request access, contact your Technical Account Manager. +::: -//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 - }); -}); -``` +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). -> RESPONSE SAMPLE: +Use the Back-Channel Login endpoint to authenticate users for the following use cases: -```json -{ - "id_token": "eyJ0eXAiOiJKV1Qi...", - "access_token": "sMjTAT...", - "token_type": "bearer" -} -``` +- 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": "/oauth/ro", - "link": "#database-ad-ldap-active-" + "path": "/bc-authorize", + "link": "#back-channel-login" }) %> -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`. +```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 | The `client_id` of your client | -| `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)) | -| `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 [TouchID](/libraries/lock-ios/touchid-authentication) scenarios. Required when `grant_type` is `urn:ietf:params:oauth:grant-type:jwt-bearer` | - +| `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. | -### Test with Postman +### Response Body -<%= include('../../_includes/_test-with-postman') %> +If the request is successful, you should receive a response like the following: -### Test with Authentication API Debugger - -<%= include('../../_includes/_test-this-endpoint') %> +```http +{ + "auth_req_id": "eyJh...", + "expires_in": 300, + "interval": 5 +} +``` -1. At the *Configuration* tab, set the fields **Client** (select the client you want to use for the test) and **Connection** (the name of the social connection to use). +The `auth_req_id` value should be kept as it is used later in the flow to identify the authentication request. -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). +The `expires_in` value tells you how many seconds you have until the authentication request expires. -1. At the *OAuth2 / OIDC* tab, set **Username** and **Password**. Click **Resource Owner Endpoint**. +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 -- 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 [Login Page](https://auth0.com/#/login_page) and the latter can be invoked from anywhere (a script, server to server, and so forth). +The following code sample is an example login hint: + ```http + { + "format": "iss_sub", + "iss": "https://[TENANT_DOMAIN]/", + "sub": "auth0|[USER ID]" + } + ``` -### Error Codes - -For the complete error code reference for this endpoint refer to [Errors > POST /oauth/ro](#post-oauth-ro). - - -### More Information -- [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) - +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: -## Enterprise (SAML and Others) +- 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. -
Examples
+<%= include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "POST", + "path": "/oauth/token", + "link": "#post-token" +}) %> ```http -GET https://${account.namespace}/authorize? - response_type=code|token& - client_id=${account.clientId}& - connection=CONNECTION& - redirect_uri=${account.callback}& - state=STATE& - additional-parameter=ADDITIONAL_PARAMETERS -``` - -```javascript - - - -//trigger login with an enterprise connection -$('.login-microsoft').click(function () { - auth0.login({ - connection: 'contoso.com' - }); -}); +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' ``` -<%= include('../../_includes/_http-method', { - "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. +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 | |:-----------------|:------------| -| `response_type`
Required | Use `code` for server side flows, `token` for client side flows. | -| `client_id`
Required | The `client_id` of your client. | -| `connection` | The name of the connection configured to your client. 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. | -| `state`
Recommended | An opaque value the clients adds 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. | +| `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 -### Test with Authentication API Debugger +If the authorizing user has not yet approved or rejected the request, you should receive a response like the following: -<%= include('../../_includes/_test-this-endpoint') %> +```http +{ + "error": "authorization_pending", + "error_description": "The end-user authorization is pending" +} +``` -1. At the *Configuration* tab, set the fields **Client** (select the client you want to use for the test) and **Connection** (the name of the social connection to use). +If the authorizing user rejects the request, you should receive a response like the following: -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). +```http +{ + "error": "access_denied", + "error_description": "The end-user denied the authorization request or it +has been expired" +} +``` -1. At the *OAuth2 / OIDC* tab, click **OAuth2 / OIDC Login**. +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." +} +``` -### Remarks +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 no `connection` is specified, it will redirect to [Auth0 Login Page](https://auth0.com/#/login_page) and show the Login Widget. -- The `redirect_uri` value must be specified as a valid callback URL under your [Client's Settings](${manage_url}/#/clients/${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. +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" +} +``` -### More Information +Once you have exchanged an `auth_req_id` for an ID or access token, it is no longer usable. -- [SAML](/protocols/saml) -- [Obtain a ClientId and Client Secret for Microsoft Azure Active Directory](/connections/enterprise/azure-active-directory) -- [Using the State Parameter](/protocols/oauth2/oauth-state) +### 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 f44c9b7ae8..930bf1a337 100644 --- a/articles/api/authentication/_logout.md +++ b/articles/api/authentication/_logout.md @@ -1,10 +1,17 @@ + # Logout +## Auth0 Logout -
Examples
+<%= 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}& + client_id=${account.clientId}& returnTo=LOGOUT_URL ``` @@ -16,66 +23,174 @@ curl --request GET \ ``` ```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 -$('.logout-dbconn').click(function() { - //log the user out from their current browser session in your app - localStorage.removeItem('id_token'); +| 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`. | - //log the user out from Auth0 - auth0.logout(); +### Remarks - //log the user out from Auth0 and redirect to tenant-level whitelisted URL LOGOUT_URL - auth0.logout({ returnTo: 'LOGOUT_URL' }, { version: 'v2' }); +- 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). - //log the user out from Auth0 and redirect to client-level whitelisted URL LOGOUT_URL - auth0.logout({ returnTo: 'LOGOUT_URL', client_id: ${account.clientId} }, { version: 'v2' }); -}); -``` +### 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 client level (see [Setting Allowed Logout URLs at the App Level](/logout#setting-allowed-logout-urls-at-the-app-level)). -- If the `client_id` parameter is NOT included, the `returnTo` URL must be listed in the `Allowed Logout URLs` set at the account level (see [Setting Allowed Logout URLs at the Account Level](/logout#setting-allowed-logout-urls-at-the-account-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 client. | -| `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 + +- 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 -### Test with Authentication API Debugger +```http +POST https://${account.namespace}/samlp/CLIENT_ID/logout +``` -<%= include('../../_includes/_test-this-endpoint') %> +```shell +curl --request POST \ + --url 'https://${account.namespace}/samlp/CLIENT_ID/logout' \ + --header 'content-type: application/x-www-form-urlencoded' \ + --data '{SAML_LOGOUT_REQUEST}' +``` -1. At the *Configuration* tab, set the fields **Client** (select the client you want to use for the test) and **Connection** (the name of the social connection to use). +Use this endpoint to log out a user from an Auth0 tenant configured as a SAML identity provider (IdP). -1. Copy the **Callback URL** and set it as part of the **Allowed Logout URLs** of your [Client Settings](${manage_url}/#/clients/${account.clientId}/settings). +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). -1. At the *Other Flows* tab, click **Logout**, or **Logout (Federated)** to log the user out of the identity provider as well. +### 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). -- 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. +### Learn More +- [Logout](/logout) +- [Log Users Out of SAML Identity Providers](https://auth0.com/docs/authenticate/login/logout/log-users-out-of-saml-idps) -### More Information +## Global Token Revocation +<%= include('../../_includes/_http-method', { + "http_badge": "badge-primary", + "http_method": "POST", + "path": "/oauth/global-token-revocation/connection/YourConnectionName", + "link": "#logout" +}) %> -- [Logout](/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 new file mode 100644 index 0000000000..32c6a59802 --- /dev/null +++ b/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/articles/api/authentication/_passwordless.md b/articles/api/authentication/_passwordless.md index ab1980c0a4..4cb6994684 100644 --- a/articles/api/authentication/_passwordless.md +++ b/articles/api/authentication/_passwordless.md @@ -1,19 +1,20 @@ + + # 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 -
Examples
- ```http POST https://${account.namespace}/passwordless/start -Content-Type: 'application/json' +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,96 +27,72 @@ 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 +// Script uses auth0.js. See Remarks for details. -//EMAIL: request a link to be sent via email -$('.request-email-link').click(function (ev) { - ev.preventDefault(); - auth0.requestMagicLink({ - email: $('.email-input').val() - }, function (err) { - if (err) { - alert(err.error_description); - return; + // Send a verification code using email + webAuth.passwordlessStart({ + connection: 'email', + send: 'code', + email: 'USER_EMAIL' + }, function (err,res) { + // handle errors or continue } - // the request was successful and you should receive - // an email with the link at the specified address - }); -}); - -//EMAIL: request a code to be sent via email -$('.request-email-code').click(function (ev) { - ev.preventDefault(); - - auth0.requestEmailCode({ - email: $('.email-input').val() - }, function (err) { - if (err) { - alert(err.error_description); - return; + ); + + // Send a link using email + webAuth.passwordlessStart({ + connection: 'email', + send: 'link', + email: 'USER_EMAIL' + }, function (err,res) { + // handle errors or continue } - // the request was successful and you should receive - // an email with the code at the specified address - }); -}); - -//SMS: request a code to be sent via SMS -$('.request-sms-code').click(function (ev) { - ev.preventDefault(); - - auth0.requestSMSCode({ - phoneNumber: $('.phone-input').val() - }, function (err) { - if (err) { - alert(err.error_description); - return; + ); + + // Send a verification code using SMS + webAuth.passwordlessStart({ + connection: 'sms', + send: 'code', + phoneNumber: 'USER_PHONE_NUMBER' + }, function (err,res) { + // handle errors or continue } - // the request was successful and you should receive - // a SMS with the code at the specified phone number - }); -}); -``` - -> RESPONSE SAMPLE: - -```JSON -//for connection=email -{ - "_id": "5845818fe...", - "email": "test.account@passwordless.com", - "email_verified": false -} + ); + ``` <%= 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 client. | +| `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`. | @@ -123,151 +100,157 @@ You have three options for [passwordless authentication](/connections/passwordle | `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`. - +- 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 -
Examples
- ```http -POST https://${account.namespace}/oauth/ro -Content-Type: 'application/json' +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 +// Script uses auth0.js. See Remarks for details. - -//EMAIL: authenticate the user when you get the code, using email and code -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'); -}); - -//SMS: authenticate the user when you get the code, using phoneNumber and code -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"); -}); -``` - -> RESPONSE SAMPLE: -```json -{ - "id_token": "eyJ0eXA...", - "access_token": "5CB7...", - "token_type": "bearer" -} + // Verify code sent via email + webAuth.passwordlessLogin({ + connection: 'email', + email: 'USER_EMAIL', + verificationCode: 'VERIFICATION_CODE_SENT' + }, function (err,res) { + // handle errors or continue + } + ); + + // Verify code sent within link using email + webAuth.passwordlessLogin({ + connection: 'email', + email: 'USER_EMAIL', + verificationCode: 'VERIFICATION_CODE_SENT_WITHIN_LINK' + }, function (err,res) { + // handle errors or continue + } + ); + + // Verify code sent via SMS + webAuth.passwordlessLogin({ + connection: 'sms', + phoneNumber: 'USER_PHONE_NUMBER', + verificationCode: 'VERIFICATION_CODE_SENT' + }, function (err,res) { + // handle errors or continue + } + ); + ``` <%= include('../../_includes/_http-method', { + "http_badge": "badge-success", "http_method": "POST", - "path": "/oauth/ro", + "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. 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 | |:-----------------|:------------| -| `client_id`
Required | The `client_id` of your client. | -| `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`. | +| `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 -### Test with Postman - -<%= include('../../_includes/_test-with-postman') %> +For the complete error code reference for this endpoint refer to [Standard Error Responses](#standard-error-responses). +### Learn More -### Test with Authentication API Debugger +- [Passwordless Authentication](/connections/passwordless) -<%= include('../../_includes/_test-this-endpoint') %> +<%= include('../../_includes/_http-method', { + "http_badge": "badge-success", + "http_method": "POST", + "path": "/passwordless/verify", + "link": "#authenticate-user-legacy" +}) %> -1. At the *Configuration* tab, set the fields **Client** (select the client you want to use for the test) and **Connection** (use `sms` or `email`). +::: 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. Copy the **Callback URL** and set it as part of the **Allowed Callback URLs** of your [Client Settings](${manage_url}/#/clients/${account.clientId}/settings). +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. 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**. +### 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 `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). +### Learn More + +- [Passwordless Best Practices](/connections/passwordless/best-practices) -### More Information -- [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 2aceedce68..0769a51318 100644 --- a/articles/api/authentication/_saml-sso.md +++ b/articles/api/authentication/_saml-sso.md @@ -1,11 +1,9 @@ # 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 -
Examples
- ```http GET https://${account.namespace}/samlp/${account.clientId}? connection=CONNECTION @@ -21,41 +19,38 @@ curl --request GET \ <% 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. +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, 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, 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 client. | -| `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 -
Examples
- ```http GET https://${account.namespace}/samlp/metadata/${account.clientId} ``` @@ -68,32 +63,26 @@ curl --request GET \ <% 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. +This endpoint returns the SAML 2.0 metadata. ### Request Parameters | Parameter | Description | |:-----------------|:------------| -| `client_id`
Required | The `client_id` of your client. | - - -### Test with Postman - -<%= include('../../_includes/_test-with-postman') %> +| `client_id`
Required | The `client_id` of your application. | -### More Information +### Learn More - [SAML](/protocols/saml) -## IdP-Initiated SSO Flow - -
Examples
+## IdP-Initiated Single Sign-On (SSO) Flow ```http POST https://${account.namespace}/login/callback?connection=CONNECTION @@ -111,32 +100,21 @@ curl --request POST \ <% 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 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 | Parameter | Description | |:-----------------|:------------| -| `connection`
Required | The name of an identity provider configured to your client. | +| `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 **Client** (select the client 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 [Client Settings](${manage_url}/#/clients/${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 0f3b6007a9..46e637c7bd 100644 --- a/articles/api/authentication/_sign-up.md +++ b/articles/api/authentication/_sign-up.md @@ -1,15 +1,21 @@ # Signup - -
Examples
+ ```http POST https://${account.namespace}/dbconnections/signup -Content-Type: 'application/json' +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' } } ``` @@ -17,39 +23,34 @@ Content-Type: 'application/json' curl --request POST \ --url 'https://${account.namespace}/dbconnections/signup' \ --header 'content-type: application/json' \ - --data '{"client_id":"${account.clientId}", "email":"EMAIL", "password":"PASSWORD", "connection":"CONNECTION"}' + --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. - -

Signup Database Connection

- - - - ``` @@ -59,38 +60,52 @@ curl --request POST \ { "_id": "58457fe6b27...", "email_verified": false, - "email": "test.account@signup.com" + "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 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. +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`
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. | -### Test with Postman - -<%= 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). -### 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) +- [Metadata Overview](/users/concepts/overview-user-metadata) diff --git a/articles/api/authentication/_userinfo.md b/articles/api/authentication/_userinfo.md index 83b7abcfa6..f21daa73ff 100644 --- a/articles/api/authentication/_userinfo.md +++ b/articles/api/authentication/_userinfo.md @@ -1,9 +1,6 @@ # User Profile - ## Get User Info -
Examples
- ```http GET https://${account.namespace}/userinfo Authorization: 'Bearer {ACCESS_TOKEN}' @@ -12,165 +9,98 @@ Authorization: 'Bearer {ACCESS_TOKEN}' ```shell curl --request GET \ --url 'https://${account.namespace}/userinfo' \ - --header 'authorization: Bearer {ACCESS_TOKEN}' \ - --header 'content-type: application/json' + --header 'Authorization: Bearer {ACCESS_TOKEN}' \ + --header 'Content-Type: application/json' ``` ```javascript +// Script uses auth0.js. See Remarks for details. - -auth0.getUserInfo(access_token, function (err, profile) { - if(err) { - // handle error - return; - } - alert('hello ' + profile.name); -}); -``` - -> RESPONSE SAMPLE: - -```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", - "identities": [ - { - "user_id": "58454...", - "provider": "auth0", - "connection": "Username-Password-Authentication", - "isSocial": false + // Parse the URL and extract the Access Token + webAuth.parseHash(window.location.hash, function(err, authResult) { + if (err) { + return console.log(err); } - ], - "created_at": "2016-12-05T11:16:59.640Z", - "sub": "auth0|58454..." -} -``` - -<%= include('../../_includes/_http-method', { - "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`. - - -### Request Parameters - -| Parameter | Description | -|:-----------------|:------------| -| `access_token`
Required | The Auth0 `access_token` obtained during login. | - - -### Test with Postman - -<%= include('../../_includes/_test-with-postman') %> - - -## Get Token Info - -
Examples
- -```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 - - - -auth0.getProfile(idToken, function (err, profile) { - if(err) { - // handle error - return; - } - - alert('hello ' + profile.name); -}); ``` > 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..." + "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_method": "POST", - "path": "/tokeninfo", - "link": "#get-token-info" + "http_badge": "badge-primary", + "http_method": "GET", + "path": "/userinfo", + "link": "#get-user-info" }) %> -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. +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 | |:-----------------|:------------| -| `id_token`
Required | The `id_token` to use. | +| `access_token`
Required | The Auth0 Access Token obtained during login. | -### Test with Postman +### Remarks -<%= include('../../_includes/_test-with-postman') %> +- 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 -### More Information +- [Auth0.js v8 Reference: Extract the authResult and get user info](/libraries/auth0js#extract-the-authresult-and-get-user-info) -- [User Profile: In-Depth Details - API](/user-profile/user-profile-details#api) +- [Auth0 API Rate Limit Policy](/policies/rate-limits) diff --git a/articles/api/authentication/_wsfed-req.md b/articles/api/authentication/_wsfed-req.md index e6eabc8c26..c8e94025b2 100644 --- a/articles/api/authentication/_wsfed-req.md +++ b/articles/api/authentication/_wsfed-req.md @@ -1,9 +1,6 @@ # WS-Federation - ## Accept Request -
Examples
- ```http GET https://${account.namespace}/wsfed/${account.clientId} ``` @@ -15,6 +12,7 @@ curl --request GET \ <% var acceptWSReqPath = '/wsfed/YOUR_CLIENT_ID'; %> <%= include('../../_includes/_http-method', { + "http_badge": "badge-primary", "http_method": "GET", "path": acceptWSReqPath, "link": "#accept-request20" @@ -27,57 +25,37 @@ This endpoint accepts a WS-Federation request to initiate a login. | Parameter | Description | |:-----------------|:------------| -| `client-id` | The `client-id` of your client. | +| `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. | - - -### 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 **Client** (select the client 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 [Client Settings](${manage_url}/#/clients/${account.clientId}/settings). - -1. At the *Other Flows* tab, click **WS-Federation**. - +| `wreply` | The callback URL. | ### Remarks - The `wtrealm` parameter must be in one of these formats: - - `urn:clientID` (e.g. urn:${account.clientId}) + - `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). - -### More Information +### Learn More - [WS-Federation](/protocols/ws-fed) - ## Get Metadata -
Examples
- ```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", "http_method": "GET", "path": getMetadataPath, "link": "#get-metadata21" @@ -85,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 ed8eb8bd03..4979eff892 100644 --- a/articles/api/authentication/api-authz/_authz-client.md +++ b/articles/api/authentication/api-authz/_authz-client.md @@ -1,230 +1,25 @@ -# Authorize Client +# Authorize Application -To begin an OAuth 2.0 Authorization flow, your Client application should first send the user to the authorization URL. +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 -- Authorization Code Grant using Proof Key for Code Exchange (PKCE) -- Implicit Grant +- [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. -Note also the following: -* Additional parameters can be sent that will be passed through to the provider, e.g. `access_type=offline` (for Google refresh tokens) , `display=popup` (for Windows Live popup mode). -* The `state` parameter will be returned and can be used for XSRF and contextual information (like a return url). +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). +## 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). -## Authorization Code Grant - -
Examples
- -```http -GET https://${account.namespace}/authorize? - audience=API_IDENTIFIER& - scope=SCOPE& - response_type=code& - client_id=${account.clientId}& - connection=CONNECTION& - redirect_uri=${account.callback}& - state=STATE& - additional-parameter=ADDITIONAL_PARAMETERS -``` - -> RESPONSE SAMPLE - -```text -HTTP/1.1 302 Found -Location: ${account.callback}?code=AUTHORIZATION_CODE&state=STATE -``` - -<%= include('../../../_includes/_http-method', { - "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, 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 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. | - -### Test with Authentication API Debugger - -<%= 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 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 client 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 [Client's Settings](${manage_url}/#/clients/${account.clientId}/settings). - -### 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) - - - -## Authorization Code Grant (PKCE) - -
Examples
- -```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_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`. | - - -### Test with Authentication API Debugger - -<%= 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 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 client 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}/#/clients/${account.clientId}/settings). - - -### 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) - - -## Implicit Grant - -
Examples
- -```http -GET https://${account.namespace}/authorize? - audience=API_IDENTIFIER& - scope=SCOPE& - response_type=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_method": "GET", - "path": "/authorize", - "link": "#implicit-grant" -}) %> - -This is the OAuth 2.0 grant that Client-side 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`, or `id_token token` to get both an `id_token` and an `access_token`. | -| `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. | -| `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`. | - - -### Test with Authentication API Debugger - -<%= 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 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 [Client's Settings](${manage_url}/#/clients/${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 client 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`. - - -### 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 for Single Page Apps](/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 ebb250dfc4..0000000000 --- a/articles/api/authentication/api-authz/_get-token.md +++ /dev/null @@ -1,400 +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 - -
Examples
- -```http -POST https://${account.namespace}/oauth/token -Content-Type: 'application/json' -{ - "grant_type": "authorization_code", - "client_id": "${account.clientId}", - "client_secret": "${account.clientSecret}", - "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": "${account.clientSecret}","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: '${account.clientSecret}', - 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_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 **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 **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) - -
Examples
- -```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_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 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 **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 - -
Examples
- -```http -POST https://${account.namespace}/oauth/token -Content-Type: 'application/json' -{ - audience: "API_IDENTIFIER", - grant_type: "client_credentials", - client_id: "${account.clientId}", - client_secret: "${account.clientSecret}" -} -``` - -```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":"${account.clientSecret}"}' -``` - -```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: '${account.clientSecret}', - 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_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 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, 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 - -
Examples
- -```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": "${account.clientSecret}" -} -``` - -```shell -curl --request POST \ - --url '${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": "${account.clientSecret}" - }' -``` - -```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: '${account.clientSecret}' }, - 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_method": "POST", - "path": "/oauth/token", - "link": "#resource-owner-password" -}) %> - -This is the OAuth 2.0 grant that highly trusted apps utilize 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 later on sent to the client and Auth0. It is therefore imperative that the client is absolutely trusted with this information. - - -### 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`. Do not set this parameter if your client is not highly trusted (for example, SPA). | -| `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 client 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). | - - -### Test with Authentication API Debugger - -<%= 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 **Username** and **Password**, and click **Password Grant**. - - -### Remarks - -- The scopes issued to the client may differ from the scopes requested. In this case, a `scope` parameter will be included in the response JSON. -- 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). - - -### More Information - -- [Calling APIs from Highly Trusted Clients](/api-auth/grant/password) -- [Executing the Resource Owner Password Grant](/api-auth/tutorials/password-grant) 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 index 376d467917..c8ce53f4ab 100644 --- a/articles/api/authentication/api-authz/_resource-owner.md +++ b/articles/api/authentication/api-authz/_resource-owner.md @@ -1,46 +1,35 @@ -# Resource Owner - -
Examples
+# Resource Owner Password Flow +## Get Token ```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" -} +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/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" }' + --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/ro', - headers: { 'content-type': 'application/json', 'accept': 'application/json' }, - body: - { connection: 'CONNECTION', - grant_type: 'PASSWORD', + url: 'https://${account.namespace}/oauth/token', + headers: { 'content-type': 'application/x-www-form-urlencoded' }, + form: + { grant_type: 'password', username: 'USERNAME', - client_id: '${account.clientId}', password: 'PASSWORD', + audience: 'API_IDENTIFIER', scope: 'SCOPE', - id_token: 'ID_TOKEN', - device: 'DEVICE'}, - json: true }; + client_id: '${account.clientId}', + client_secret: 'YOUR_CLIENT_SECRET' } + }; request(options, function (error, response, body) { if (error) throw new Error(error); @@ -52,59 +41,56 @@ request(options, function (error, response, body) { > RESPONSE SAMPLE: ```JSON +HTTP/1.1 200 OK +Content-Type: application/json { - "access_token": "eyJz93a...", - "id_token": "eyJ0XAi...", - "token_type": "Bearer" + "access_token":"eyJz93a...k4laUWw", + "token_type":"Bearer", + "expires_in":86400 } ``` <%= include('../../../_includes/_http-method', { + "http_badge": "badge-success", "http_method": "POST", - "path": "/oauth/ro", - "link": "#resource-owner" + "path": "/oauth/token", + "link": "#resource-owner-password" }) %> -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`. +:::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. | -| `connection`
Required | The name of the connection configured to your client | -| `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 [TouchID](/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') %> +| `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). | -1. At the *Configuration* tab, set the **Client** field to the client 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 [Client Settings](${manage_url}/#/clients/${account.clientId}/settings). - -1. At the *OAuth2 / OIDC* tab, set the **Username** and **Password**, and click **Resource Owner Endpoint**. +### 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 -- 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). - - -### More Information +- 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). -- [Calling APIs from Highly Trusted Clients](/api-auth/grant/password) +### 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-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 21167b7243..3b9163d8ae 100644 --- a/articles/api/authentication/errors/_errors.md +++ b/articles/api/authentication/errors/_errors.md @@ -1,14 +1,21 @@ # Standard Error Responses The Authentication API may return the following HTTP Status Codes: - -Error Code | Description ----------- | ------- -400 | Bad Request -401 | Unauthorized -403 | Forbidden -404 | Not Found -405 | Method Not Allowed -429 | Too Many Requests -500 | Internal Server Error -503 | Service 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 d59915bc47..44b0f7541e 100644 --- a/articles/api/authentication/errors/_oauth-access_token.md +++ b/articles/api/authentication/errors/_oauth-access_token.md @@ -1,22 +1,10 @@ # POST /oauth/access_token -### HTTP 400 - -JSON | Description ----- | ------- -`{"error": "invalid_request", "error_description": "the connection was disabled"}` | The `connection` is not active or not enabled for your `client_id`. -`{"error": "invalid_request", "error_description": "the connection was not found"}` | Invalid `connection` name. -`{"error": "invalid_request", "error_description": "missing client_id parameter"}` | The `client_id` value is null. -`{"error": "invalid_request", "error_description": "missing access_token parameter"}` | The `access_token` value is null. -`{"error": "invalid_request", "error_description": "missing connection parameter"}` | The `connection` value is null. - -### HTTP 401 - -JSON | Description ---- | --- -`{"error": "invalid_request", "error_description": "invalid access_token: invalid_token"}` | The `access_token` is invalid or does not contain the `scope` you set. - -### HTTP 403 -JSON | Description ----- | ------- -`{"error": "unauthorized_client", "error_description": "invalid client"}` | The `client_id` is invalid. +| 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 new file mode 100644 index 0000000000..cbca1e2779 --- /dev/null +++ b/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/articles/api/authentication/errors/_oauth-ro.md b/articles/api/authentication/errors/_oauth-ro.md index 16f4dd6680..e552af873a 100644 --- a/articles/api/authentication/errors/_oauth-ro.md +++ b/articles/api/authentication/errors/_oauth-ro.md @@ -2,57 +2,33 @@ ## Grant type: jwt-bearer -### HTTP 400 - -JSON | Description ----- | ------- -`{"error": "invalid_request", "error_description": "missing device parameter"}` | Missing Device. You need to provide a device name for the caller device (like a browser, app, etc). -`{"error": "invalid_request", "error_description": "missing id_token parameter"}` | Missing id_token. For this grant type you need to provide a JWT id token. -`{"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 -### HTTP 400 - -JSON | Description ----- | ------- -`{"error": "invalid_request", "error_description": "missing username parameter"}` | Missing username parameter in the request. -`{"error": "invalid_request", "error_description": "missing password parameter"}` | Missing password parameter in the request. -`{"error": "invalid_request", "error_description": "missing connection parameter"}` | Missing connection parameter in the request. -`{"error": "invalid_request", "error_description": "scope parameter must be a string"}` | Incorrect scope formatting. Each scope must be separated by whitespace. -`{"error": "invalid_request", "error_description": "specified strategy does not support requested operation"}` | The connection/provider does not implement username/password authentication. - -### HTTP 401 - -JSON | Description ----- | ------- -`{"error": "invalid_user_password", "error_description": "Wrong email or password."}` | Wrong username or password (this can vary depending on the identity provider). -`{"error": "unauthorized", "error_description": "user is blocked"}` | The user is blocked. -`{ "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."}` | Another site had a security breach and your password has been leaked. - -### HTTP 429 - -JSON | Description ----- | ----------- -`{"error": "too_many_attempts", "error_description": "..."}` | Some anomaly detections will return this error. -`{"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 -### HTTP 400 - -JSON | Description ----- | ----------- -`{"error": "invalid_request", "error_description": "missing client_id parameter"}` | Missing `client_id` parameter in the request. -`{"error": "invalid_request", "error_description": "the connection was not found"}` | Provided connection was not found. -`{"error": "invalid_request", "error_description": "the connection was disabled"}` | Provided connection is disabled. Check the connection in the dashboard, you may have turned it off for the provided `client_id`. -`{"error": "invalid_request", "error_description": "The connection is not yet configured..."}` | The connection is not properly configured with custom scripts. -`{"error": "invalid_request", "error_description": "the connection was not found for tenant..."}` | The connection does not belong to the tenant. Check your base url. -`{"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. - -### HTTP 403 - -JSON | Description ----- | ----------- -`{"error": "unauthorized_client", "error_description": "invalid client"}` | Provided `client_id` is not valid. -`{"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 62b2a3d812..348b707a16 100644 --- a/articles/api/authentication/errors/_passwordless-start.md +++ b/articles/api/authentication/errors/_passwordless-start.md @@ -1,17 +1,25 @@ + # POST /passwordless/start -### HTTP 400 - -JSON | Description ------|------------ -`{"error": "bad.tenant", "error\_description": "error in tenant - tenant validation failed: invalid\_tenant"}` | Invalid tenant -`{"error": "bad.client\_id", "error\_description": "Missing required property: client_id"}` | Missing client_id -`{"error": "bad.connection", "error_description": "Missing required property: connection"}` | Missing connection -`{"error": "bad.connection", "error_description": "Connection does not exist"}` | Connection does not exist -`{"error": "bad.connection", "error_description": "Connection is disabled"}` | Disabled connection -`{"error": "bad.connection", "error_description": "Invalid connection strategy. It must either be a passwordless connection"}` | Invalid connection -`{"error": "bad.authParams", "error_description": "error in authParams - invalid type: string (expected object)"}` | Invalid authParams -`{"error": "bad.request", "error\_description": "the following properties are not allowed: "}` | Invalid paramaters -`{"error": "bad.phone\_number", "error\_description": "Missing required property: phone_number"}` | Missing phone_number -`{"error": "bad.phone\_number", "error_description": "String does not match pattern: ^\\+[0-9]{1,15}$"}` | Invalid phone_number format -`{"error": "sms\_provider\_error", "error\_description": " (Code: )"}` | SMS Provider errors +| 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 18b8348081..3edd4a539a 100644 --- a/articles/api/authentication/index.md +++ b/articles/api/authentication/index.md @@ -1,6 +1,9 @@ --- -title: Authorization API Explorer +title: Authentication API Explorer fullWidth: true +contentType: + - index + - reference ---
@@ -32,23 +35,19 @@ fullWidth: true
- <%= include('./_saml-sso') %> -
- -
- <%= include('./_wsfed-req') %> + <%= include('./_multifactor-authentication') %>
- <%= include('./_impersonation') %> + <%= include('./_saml-sso') %>
- <%= include('./_linking') %> + <%= include('./_wsfed-req') %>
- <%= include('./_delegation') %> + <%= include('./_application-reg') %>
API Authorization @@ -56,22 +55,74 @@ 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/_resource-owner') %> + <%= 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/_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 new file mode 100644 index 0000000000..a173755d24 --- /dev/null +++ b/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/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 new file mode 100644 index 0000000000..0e4b6657ce --- /dev/null +++ b/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/articles/api/authentication/legacy/_login.md b/articles/api/authentication/legacy/_login.md new file mode 100644 index 0000000000..4c197080e9 --- /dev/null +++ b/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/articles/api/authentication/legacy/_resource-owner.md b/articles/api/authentication/legacy/_resource-owner.md new file mode 100644 index 0000000000..d191536587 --- /dev/null +++ b/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/articles/api/authentication/legacy/_userinfo.md b/articles/api/authentication/legacy/_userinfo.md new file mode 100644 index 0000000000..d35e12a99e --- /dev/null +++ b/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/articles/api/authorization-extension/_groups.md b/articles/api/authorization-extension/_groups.md new file mode 100644 index 0000000000..17bc41355c --- /dev/null +++ b/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/articles/api/authorization-extension/_introduction.md b/articles/api/authorization-extension/_introduction.md new file mode 100644 index 0000000000..973481dac2 --- /dev/null +++ b/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/articles/api/authorization-extension/_permissions.md b/articles/api/authorization-extension/_permissions.md new file mode 100644 index 0000000000..8c1c151fcf --- /dev/null +++ b/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/articles/api/authorization-extension/_roles.md b/articles/api/authorization-extension/_roles.md new file mode 100644 index 0000000000..45ca6b2d8c --- /dev/null +++ b/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/articles/api/authorization-extension/_users.md b/articles/api/authorization-extension/_users.md new file mode 100644 index 0000000000..a2337dd9f2 --- /dev/null +++ b/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/articles/api/authorization-extension/index.md b/articles/api/authorization-extension/index.md new file mode 100644 index 0000000000..cc27f2407b --- /dev/null +++ b/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/articles/api/info.md b/articles/api/info.md index 079480a8e9..44920523b6 100644 --- a/articles/api/info.md +++ b/articles/api/info.md @@ -1,13 +1,31 @@ --- -description: This page explains the basics of Auth0's APIs, the Management and Authentication API. +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. The first API is the Authentication API and handles all the primary identity related functions. The second API is the Management API which enables you to automate various tasks in Auth0 such as creating users. Below you will find more information about each of these APIs. + +Auth0 exposes the following APIs for developers to consume in their applications. ## Authentication API -The Authentication API exposes all of the identity functionality of Auth0 as well as all of the supported identity protocols such as OpenID Connect, OAuth, and SAML. Generally speaking you will consume this API through one of our SDKs like [Auth0.js](/libraries/auth0js) or libraries such as the [Lock](/libraries/lock) widget. However, if you are building all of your authentication UI manually you will likely interact with this API directly. + +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)
@@ -17,7 +35,7 @@ The Authentication API exposes all of the identity functionality of Auth0 as wel

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

@@ -26,7 +44,7 @@ The Authentication API exposes all of the identity functionality of Auth0 as wel

Postman

Try the Auth0 Authentication API in Postman.

-

Run in Postman

+

Run in Postman

How to use our Postman Collections

@@ -35,8 +53,16 @@ The Authentication API exposes all of the identity functionality of Auth0 as wel
-## Management API v2 -The Auth0 Management API can be used to manage all aspects of your Auth0 account. You can use the API to automate the configuration of your environments and use this API for runtime tasks such as creating users. +## 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)
@@ -55,7 +81,7 @@ The Auth0 Management API can be used to manage all aspects of your Auth0 account

Postman

Try the Auth0 Management API in Postman.

-

Run in Postman

+

Run in Postman

How to use our Postman Collections

@@ -64,5 +90,10 @@ The Auth0 Management API can be used to manage all aspects of your Auth0 account -## Management API v1 (deprecated) -The Auth0 Management API v1 contains various management functions for your Auth0 account. This API is **deprecated** and should not be used for new projects. If you have an existing app that uses the v1 Management API you can browse the [API explorer](/api/v1). +### 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/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 9c233d902d..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-banner -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" section under "Account Settings" in the Auth0 [dashboard](https://manage.auth0.com/#/account/advanced). +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. @@ -145,13 +134,13 @@ Authorization: Bearer {token}
GET /api/clients/{client-id}/users
-
Gets all users from a specific client
+
Gets all users from a specific application
-Gets all users who have logged in with a specific client +Gets all users who have logged in with a specific application ```text -GET /api/clients//users +GET /api/clients/users Authorization: Bearer {token} ``` @@ -338,10 +327,10 @@ Authorization: Bearer {token}
DELETE /api/users/{user_id}/refresh_tokens/{refresh_token}
-
Revokes a refresh 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|etc", + "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} @@ -462,7 +451,7 @@ Content-Type: application/json } ``` -## Clients +## Applications (Clients)
GET /api/clients
@@ -481,7 +470,7 @@ Authorization: Bearer {token}
Creates a new applications/APIs
-Create a client. 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 @@ -498,13 +487,13 @@ Content-Type: application/json
Updates an applications/APIs
-Update a client. The body of the request must include the `name` and `callbacks` parameters. Does not overwrite the entire client, only the provided values. +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 clients. +WARNING! Changing the `signingKey` for the globalClient will change it for all applications. ```text PATCH /api/clients/{client-id} @@ -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 client related to the event. - * `client_name`: The name of the client 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 client related to the event. -* `user_name`: The user name releated 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} @@ -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 client related to the event. - * `client_name`: The name of the client 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 client related to the event. - * `client_name`: The name of the client 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 client related to the event. - * `client_name`: The name of the client 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 4fc7bf03de..3d0af562df 100644 --- a/articles/api/management/v1/reference.md +++ b/articles/api/management/v1/reference.md @@ -1,45 +1,67 @@ --- 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 - https://${account.namespace}/api +```text +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: - https://${account.namespace}/api/connections/?access_token={ACCESS-TOKEN} +```text +https://${account.namespace}/api/connections/?access_token={ACCESS-TOKEN} +``` or in an ```Authorization``` header: - GET https://${account.namespace}/api/connections - Authorization: bearer {ACCESS-TOKEN} +```text +GET https://${account.namespace}/api/connections +Authorization: bearer {ACCESS-TOKEN} +``` A token is obtained using the POST method: - POST https://${account.namespace}/oauth/token - Content-type: application/x-www-form-urlencoded - client_id=${account.clientId}&client_secret=${account.clientSecret}&type=web_server&grant_type=client_credentials +```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: - { - 'access_token': TOKEN - 'token_type':'bearer' - } +```text +{ + 'access_token': TOKEN + 'token_type':'bearer' +} +``` -Here is a simple example using `curl`: +Here is a simple example using cURL: - curl https://${account.namespace}/oauth/token --data "client_id=${account.clientId}&client_secret=${account.clientSecret}&type=web_server&grant_type=client_credentials" +```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. +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. - Authorization: bearer {ACCESS-TOKEN} +```text +Authorization: bearer {ACCESS-TOKEN} +``` ## Connections @@ -56,20 +78,24 @@ The `Authorization` header is the only accepted header and is used in place of t To return a list of all defined connections in Auth0, use this syntax: - GET https://${account.namespace}/api/connections/?access_token={ACCESS-TOKEN} +```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": { - "client_id": "${account.clientId}", - "name": YOUR-CONNECTION-NAME, - "options": - { - ... - }, - "status": 0, - "strategy": STRATEGY - } + ... + }, + "status": 0, + "strategy": STRATEGY +} +``` #### Parameters | Parameter | Description | @@ -86,29 +112,35 @@ 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: - - `provisioning_ticket`: TICKET +When implementing the `office365`, `g-suite` or `adfs` strategies, the following properties are added to the connection object: - `provisioning_ticket_url`: PROVISIONING-URL +```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. +A GET on `connections` with a specified `{connectionName}` in the path will return the matching connection object only. + +###### The cURL sample scripts -###### Here are two `curl` sample scripts: This script returns a specific connection: - curl https://${account.namespace}/api/connections/?access_token={YOUR ACCESS TOKEN} +```text +curl https://${account.namespace}/api/connections/?access_token={YOUR ACCESS TOKEN} +``` This script returns all connections: - curl https://${account.namespace}/api/connections/{YOUR-CONNECTION-NAME}?access_token={YOUR ACCESS TOKEN} +```text +curl https://${account.namespace}/api/connections/{YOUR-CONNECTION-NAME}?access_token={YOUR ACCESS TOKEN} +``` ##### Options @@ -116,175 +148,195 @@ The `options` object returned in the `connection` will be different for each str ###### ADFS Strategy - { - tenant_domain: A-DOMAIN, - adfs_server: YOUR-FEDERATION-METADATA-ENDPOINT, - thumbprints: [ '9b250aad7e4950604072ffaa60cde7795f23b52a', - 'f97702a42c893a0fb1bc6dad21c79fb720473a85', - '9b250aad7e4955604072faca60cde7795f23b52a', - 'f97702a42c893a0fb1bc6dad21c79fb720473a85', - '9b250aad7e4956704072ffaa60cde7795f23b52a', - 'f97702a42c893a0fb1b546dad21c79fb720473a85', - '9b250aad7e4959804072ffaa60cde7795f23b52a' ], - signInEndpoint: ADFS-LOGIN-PAGE - } +```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_). | - -###### Google Apps Strategy - - { - 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 `client_id` and `client_secret` for Google Apps connections, see [Google connections](/connections/social/google). +| `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 - { - 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: [] - } +```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 - { - 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: [] - } +```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 - { - 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: [] - } +```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 - GET https://${account.namespace}/api/connections/{A-CONNECTION-NAME}/?access_token=... - +```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. - DELETE https://${account.namespace}/api/connections/{A-CONNECTION-NAME}/?access_token=... +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} +} +``` - { - "removed": {id} - } - -__Note:__ Batch operations are not yet supported. +::: note +Batch operations are not yet supported. +::: #### Create a new Connection To create a new connection, POST a connection object to the `connections` resource: - POST https://${account.namespace}/connections - Content-Type: application/json +```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 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 +{ + "name": A-NAME-FOR-THIS-CONNECTION + "status": 0, + "options": { - "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": "google-apps" - }; + "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 (e.g. the entity `id`, etc.). +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 @@ -294,25 +346,31 @@ 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. *Note:* If the connection does not support querying for users (for instance: ADFS), this will return users who have logged in through that connection.| +|`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 - { - _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' - } +```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: @@ -321,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, etc.). | +|`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 4b76b16759..0000000000 --- a/articles/api/management/v1/use-cases.md +++ /dev/null @@ -1,64 +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) -* [Client Users](#client-users) -* [Email](#email) -* [Enterprise Users/Directory Searching](#enterprise-users/directory-searching) -* [Impersonation](#impersonation) -* [Searching via the Auth0 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` - -## Client 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 client 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) - -## Searching via the Auth0 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 Auth0 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 ca69738bb1..b81792b5c1 100644 --- a/articles/api/management/v2/changes.md +++ b/articles/api/management/v2/changes.md @@ -1,129 +1,135 @@ --- 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 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. * 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 client. To enable/disable a connection for a client, use the `enabled_clients` property. +* 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. | Implemented using Elastic Search. 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. | -| [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. | +| [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}/public\_key](/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` | +| [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` | +| [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}/public_key?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) +| [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) -### Client endpoints +### 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-) | Not available. | [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) | +| [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-) | Changed `connection-name` to `id`. | [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) | -| [GET /api/connections/{connection}/users?search={criteria}](/api/v1) | None. | * [GET /api/v2/users](/api/v2#!/Users/get_users) | - -*For appliance (search_engine:v1), use `connection` field; for cloud (search_engine:v2), use `q=identities.connection:"connection_name"` +| [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-) | 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) | +| [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 have not been implemented in Management API v2. Logs must first be indexed in Elastic Search. -## 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} -``` +Logs endpoints in Management API v2 are described at [Search Log Events](https://auth0.com/docs/api/management/v2#!/Logs/get_logs) -As explained in [Using JSON Web Tokens as API Keys](https://auth0.com/blog/2014/12/02/using-json-web-tokens-as-api-keys/), Auth0's API v2 allows you to issue an API JWT of specific scope, referred to below as `api_jwt_token`. To perform requests with API v2, use the `Authorization` header: -``` -Authorization: Bearer {api_jwt_token} -``` +| 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) | -### Scopes -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. +### Email Templates endpoints -### The `id_token` and special scopes -An `id_token` is a JWT containing information about a particular user. When a user logs into an application through Auth0, an `id_token` listing their claims is returned. Here is an example of an `id_token`, although more claims may be included: -``` -{ - "iss": "https://contoso.auth0.com/", - "sub": "google-oauth2|200076635456998357447", - "aud": "rs3sdOssVWaZlg0PzyPtIgWFCzcurlm5", - "exp": 1418452802, - "iat": 1418416802 -} -``` +| 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) | -When this token is sent to the API in the `Authorization` header: -``` -Authorization: Bearer {id_token} -``` +## 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`. -the following scopes will be granted automatically: +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. -* 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 +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: -Therefore, with an `id_token`, all the user's information can be read and written to `user_metadata`. +* `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 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 { metadata: { @@ -131,11 +137,14 @@ 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" 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: @@ -144,12 +153,14 @@ This automatic merging caused confusion for our customers. Also, having a single * 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. +* `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: { @@ -160,44 +171,53 @@ Neither of these two properties are merged into the root `user` object. If you s } } ``` + 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`. + +::: 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 clients. +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 clients is performed using the `enabled_clients` property. +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 clients `AaiyAPdpYddboKnqNS8HJqRn4T5ti3BQ` and `DaM8bokEXBWrTUFZiXjWn50jei6ardyV`: -``` +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. +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 @@ -212,13 +232,14 @@ In Management API v2, all endpoints use [JSON schemas](http://json-schema.org) t 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}}` +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 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/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/query-string-syntax.md b/articles/api/management/v2/query-string-syntax.md deleted file mode 100644 index 6317785b04..0000000000 --- a/articles/api/management/v2/query-string-syntax.md +++ /dev/null @@ -1,189 +0,0 @@ ---- -description: This page explains query string syntax, which you can use to construct custom queries when searching using Auth0's Management API. -section: apis ---- - -# Query String Syntax - -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. - -### Field Name Examples - -Some examples of query string syntax are: - -* Where the `date` field contains `2016`: - - `date: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 any of the fields of `app_metadata` contain `john` or `smith`. (Note that you need to escape the \* with a backslash.) - - `app_metadata.\*: (john smith)` - -* Where the field `description` has no value or is missing: - - `_missing_: description` - -* Where the field `description` has any non-null value: - - `_exists_: description` - -### 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*"`.) - -::: panel-warning Warning - -Including a wildcard at the beginning of a word (e.g. `"*ing"`) is particularly memory intensive since all terms in the index will be examined for a match. Leading wildcards can be disabled by setting the `allow_leading_wildcard` option to `false`. -::: - -### 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). - -::: panel-warning Warning -The `allow_leading_wildcard` parameter does not affect regular expressions. A query string, such as the following, would force Elasticsearch to visit every term in the index: - -`/.*n/` -Use with caution. -::: - -### 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 - -Ranges can be specified for date, numeric or string fields. Inclusive ranges are specified with square brackets: `[min TO max]` and exclusive ranges with curly brackets: `{min TO max}`. - -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). - -*The preceding information is adapted from Elastic's [Elasticsearch Reference](http://elastic.co).* diff --git a/articles/api/management/v2/tokens-flows.md b/articles/api/management/v2/tokens-flows.md new file mode 100644 index 0000000000..18ddec7612 --- /dev/null +++ b/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/articles/api/management/v2/tokens.md b/articles/api/management/v2/tokens.md index 1107c10e2c..4d99886e40 100644 --- a/articles/api/management/v2/tokens.md +++ b/articles/api/management/v2/tokens.md @@ -1,86 +1,38 @@ --- -description: Details generating and using an Auth0 Management APIv2 token. +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 --- -# The Auth0 Management APIv2 Token +# Access Tokens for the Management API -## Overview +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__). -The Auth0 Management APIv2 token is required to call v2 of the Auth0 Management API. This token is used by a specific tenant in Auth0 to call Auth0 Management APIv2 to access or update records for that tenant. This Management APIv2 token is a JWT, and contains various scopes, such as `read:users` or `update:clients`, and is signed with a client API key and secret for the entire tenant. +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. -## How to get a Management APIv2 Token +To call endpoints, you will need to do the following: -**Create a Non Interactive Client** +* [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) -A Non Interactive Client is a client that interacts with an API where there is no user involved. 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. +::: 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. +::: -To create a new Non Interactive Client, go to the [Clients section](${manage_url}/#/clients) of the dashboard then click the **CREATE CLIENT** button. +## Keep reading -Enter a name for your new client, select **Non Interactive Clients** and then click the **CREATE** button. +* [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) -![Create New Client](/media/articles/api/tokens/noninteractive-client.png) - -**Authorize the Client** - -After creating the new client, you will be brought to it's **Quick Start** section. Select **Auth0 Management API** from the dropdown. You will then see a message that the client is not authorized, click **NAVIGATE TO THE API AND AUTHORIZE**. - -![](/media/articles/api/tokens/navigate-button.png) - -This will bring you to the [APIs section](${manage_url}/#/apis) under **Auth0 Management API** in the **Non Interactive Clients** section. (To enable the APIs section of the sidebar, go to Account Settings > Advanced > Enable APIs Section) - -![Authorize Client](/media/articles/api/tokens/authorize-noninteractive.png) - -Toggle the slider to authorize your client. - -**Choose the scopes** - -You will see the available scopes that you can be granted for this client (which can be revoked at any time). Choose the desired scopes and then click the **UPDATE** button. - -![Choose authorized scopes](/media/articles/api/tokens/choose-scopes.png) - -**Getting the token** - -To test the client interaction with the API, go to the **Test** section under **Auth0 Management API**. - -![Test Client](/media/articles/api/tokens/test-client.png) - -This page will give you code snippets on how to form a request to get a token. - -You should be able to scroll down to see your `access_token` property from the token which can be used to make authorized requests to your API. - -### Special Scopes - -Notice that within the Users API some endpoints have scopes related to the current user (like `read:current_user` or `update:current_user_identities`). These are [special scopes](/api/v2/changes#the-id_token-and-special-scopes) in the id_token, which are granted automatically to the logged in user, so it makes no sense to click on them to generate a Management APIv2 token that will be used from server side code. - -## How to control contents of a Management APIv2 token - -The Management APIv2 token will be issued for a particular tenant. To have a token issued in the Management APIv2 explorer for a particular tenant, log into the Auth0 tenant, and then access the Management APIv2 explorer page. Similarly, to obtain the secret with which to sign a Management APIv2 token, log into the desired tenant first before accessing the Management APIv2 explorer page. - -## Validity - -There is no specific validity period for a Management APIv2 token. A Management APIv2 token can be built programmatically, as desired, by a client. - -## Renewing the token - -There is no mechanism for renewing a Management APIv2 token. A new token should be created whenever it is needed. - -## Termination of tokens - -You can terminate the Management APIv2 tokens calling the [blacklist endpoint](/api/v2#!/Blacklists/post_tokens). - -## Uses - -The Auth0 Management APIv2 access token is used to call the Auth0 Management APIv2. This token is required to update the app_metadata portions of the user profile. - -## API Secret - -Keep your API secret secure. In the event that your API secret has been compromised or you need to invalidate all of your tokens you can change the API secret. - -You can change the API secret in the dashboard by visiting this URL directly: - -```text -${manage_url}/#/applications/YOUR_API_ID/settings -``` - -You can then change the `Client Secret` in that page to change your Management APIv2 secret. diff --git a/articles/api/management/v2/user-search.md b/articles/api/management/v2/user-search.md deleted file mode 100644 index 12bb7b4439..0000000000 --- a/articles/api/management/v2/user-search.md +++ /dev/null @@ -1,182 +0,0 @@ ---- -description: This page lists several examples of users search queries using query string syntax. -section: apis ---- - -# Users Search - -As an Auth0 admin you can search different fields of your users using [query string syntax](/api/management/v2/query-string-syntax) with the Users section of the Management API. - -The `user_metadata`, `app_metadata` or the [normalized user profile](/user-profile/normalized) fields are searchable. Note that users have read/write access to the `user_metadata` field but only read-only access to the `app_metadata` field. - -Auth0 User Search uses [Lucene Query Syntax](http://www.lucenetutorial.com/lucene-query-syntax.html). - -## In the Dashboard - -To search user fields in the [dashboard](${manage_url}/#/users), use the **Search By** drop down to select the field for the search. To use [Lucene Query Syntax](/api/management/v2/query-string-syntax) as shown in the [queries below](#example-queries) select **Lucene Syntax (Advanced)**. - -![Select Lucene Syntax](/media/articles/api/user-search-lucene.png) - -## Using the Management API - -### API Explorer - -To search users using the [Management APIv2](/api/v2#!/users/get_users) explorer go to the **Users** section and then select **List or search users**. Click on the scopes for your search. Scroll down to the `q` parameter, this field uses [query string syntax](/api/management/v2/query-string-syntax). - -![q parameter](/media/articles/api/search-users-api.png) - -In this field enter your query string to search users. [See below](#example-queries) for examples of queries you can run from this field. - -### Postman - -To search users in [Postman](https://auth0.com/docs/api/postman). First make sure your [enviroment is configured](https://auth0.com/docs/api/postman#configuring-the-postman-environment). Then select the **Management API** as the enviroment you want to work in. For searching users, the API method is `GET ${account.namespace}/api/v2/users` which is under **Users** -> **List or search users**. - -![Select GET users](/media/articles/api/postman/get-users-postman.png) - -Then you can run your queries in the **Body** section and click **Send**. - -[Click here for more information on Postman requests](https://www.getpostman.com/docs/requests) - -## 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"` - -However, this will return results for both `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. - -### Structured JSON vs Delimited Strings - -Using structured JSON in your metadata is the ideal. Using delimited strings can result in security risks and exposure to problems. More information on metadata and how it should be structured can be found in the [metadata documentaton](/metadata). - -### 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 which support `raw` subfield queries are as follow: - -* `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 dashboard or the APIv2. - -### Cross-field search - -`john` - -### Search by specific field - -Search for all users whose name _contains_ exactly "john": - -`name:"john"` - -Search all users whose name _is_ exactly "john": - -`name.raw:"john"` - -### Wildcard Matching - -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 by email - -Search for all users whose email _is_ exactly "john@contoso\.com": - -`email.raw:"john@contoso.com"` - -### Search by multiple emails - -Search for all users whose email is exactly "john@contoso\.com" or "mary@contoso\.com" using `OR` or `AND` operators: - -`email.raw:("john@contoso.com" OR "mary@contoso.com")` - -### Search for users without verified email - -`email_verified:false OR _missing_:email_verified` - -### Filter a specific *user_metadata* field - -`user_metadata.blog_url:"www.johnsblog.com"` - -(`user_metadata` field names are customizable; "blog_url" is an example field.) - -### Filter a specific *app_metadata* field - -`app_metadata.firstName:"John"` - -(`app_metadata` field names are customizable; "firstName" is an example field.) - -### Search for users that have a certain *app_metadata* field - -`_exists_:app_metadata.plan` - -("plan" is an example field.) - -### Search for users without a certain *app_metadata* field - -`_missing_:app_metadata.plan` - -### List all users with a specific role - -`app_metadata.roles:"admin"` - -### List all users from a specific connection or provider - -`identities.provider:"google-oauth2"` - -### Search using 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}`. - -* 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}` - - -### List all users that have never logged in - -`(_missing_:logins_count OR logins_count:0)` - -### List all users who logged in before 2015 - -`last_login:[* TO 2014-12-31]` - -### Fuzziness - -You can search for terms that are similar to, but not exactly like, your search terms: - -`name:jhn~` diff --git a/articles/api/postman.md b/articles/api/postman.md index afb77dcad2..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, e.g. **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: +## Execute requests -![](/media/articles/api/postman/environment-configured.png) +Once the environment is configured, you can follow these steps to execute an Auth0 API method: -## Executing a request +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. -Once the environment is configured, you can follow theses steps to execute an Auth0 API method: +![Execute API Method](/media/articles/api/postman/execute-api-method.png) -1. Select the environment you want to work with -2. Select the relevant API method in the collection folder -3. Click the send button +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/). -![](/media/articles/api/postman/execute-api-method.png) +::: 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. -You man 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. +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). -## A word about storing tokens in Postman variables - -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. - -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). - -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 ab85daf477..a8a8111de9 100644 --- a/articles/appliance/admin/backing-up-the-appliance-instances.md +++ b/articles/appliance/admin/backing-up-the-appliance-instances.md @@ -1,13 +1,20 @@ --- section: appliance -description: Recommendations on when to back up Appliance instances +description: Recommendations on when to back up PSaaS Appliance instances +topics: + - appliance + - backups +contentType: concept +useCase: appliance +applianceId: appliance1 +sitemap: false --- -# Auth0 Appliance Administration: Appliance Backups +# PSaaS Appliance Administration: Appliance Backups -If the Auth0 Appliance is used in a stateless way (e.g. authentication, SSO), Auth0 recommends that you take **weekly** backups of all nodes using virtual machine snapshots. +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 Auth0 Appliance is only used to store data (e.g. database connections, user metadata), Auth0 recommends that you take **daily** 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 Appliance Instances Using the CLI](/appliance/cli/backing-up-the-appliance) +- [How to Back Up the PSaaS Appliance Using the CLI](/appliance/cli/backing-up-the-appliance) diff --git a/articles/appliance/admin/creating-tenants.md b/articles/appliance/admin/creating-tenants.md deleted file mode 100644 index 239c33af14..0000000000 --- a/articles/appliance/admin/creating-tenants.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -section: appliance -description: How to automatically create tenants in the Appliance ---- - -# Appliance Administration: Automatic Creation of Tenants - -If your business needs require you to create tenants regularly, you may automate this process in your Appliance instances. For example, you might need to create one tenant for each customer or project that goes live. - -## Creating a Management API Client 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' client, go to the Connections tab and disable **all** Connections for this client. -5. Navigate to `${manage_url}/#/apis`. Click the link to open the Auth0 Management API. -6. Go to the Non Interactive Clients tab, and enable Tenant Provisioning by moving the associated slide to the right. -7. Create the new client grant. - -### Creating the New Client 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 Client grant - -Once you have created your New Client 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\": \"${account.clientSecret}\"}" - }, - "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 f0183bbbe1..219fc4f573 100644 --- a/articles/appliance/admin/disabling-sign-ups.md +++ b/articles/appliance/admin/disabling-sign-ups.md @@ -1,34 +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 ---- - -# Auth0 Appliance Administration: Disabling Sign-Ups - -The 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 Client -The **Auth0** client in the Root Tenant Authority (RTA) controls access to the Management Dashboard, and the only Connections that you should enable for this client is the built-in Database Connection (the default Connection for this client 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** client. - -Additionally, please [disable signups](/appliance/admin/disabling-sign-ups) for the **Auth0** client. -::: - -Disabling signups will prevent users from signing up for an account in your 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 **Diable Sign Ups**. - -![Connections Settings Page](/media/articles/appliance/admin/disable-sign-ups.png) +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/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 e16a77179b..cdde2ec3c8 100644 --- a/articles/appliance/admin/index.md +++ b/articles/appliance/admin/index.md @@ -2,18 +2,25 @@ url: /appliance/admin section: appliance description: > - This document covers factors Auth0 Appliance administrators should be aware of when working with production Appliance instances. + 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 --- -# Auth0 Appliance: Administrator's Manual +# PSaaS Appliance: Administrator's Manual -This document covers factors Auth0 Appliance administrators should be aware of when working with production Appliance instances. +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 Appliance Instances](/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 Appliance](/appliance/admin/updating-the-appliance); -* [Configuring Custom Error 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 9cb7b0145b..a5f17a2222 100644 --- a/articles/appliance/admin/inviting-coadmins.md +++ b/articles/appliance/admin/inviting-coadmins.md @@ -1,20 +1,35 @@ --- section: appliance -description: How to invite additional administrators to your Appliance instances +description: How to invite additional administrators to your PSaaS Appliance +topics: + - appliance + - coadmins +contentType: how-to +useCase: appliance +applianceId: appliance5 +sitemap: false --- -# Appliance Administration: Inviting Co-Administrators +# PSaaS Appliance Administration: Inviting Co-Administrators -You may invite additional users to become co-administrators of your Appliance instances. This is done via the Appliance configuration area of the Management Dashboard. +::: 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). -> Administrators for the Appliance instances 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. +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 Appliance configuration options. +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. @@ -22,6 +37,6 @@ Since that connection has signups disabled, users will be have to be created bef 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 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. +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/articles/appliance/admin/limiting-ssh-access.md b/articles/appliance/admin/limiting-ssh-access.md index e16b028647..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 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 --- -# Auth0 Appliance Administration: Limiting SSH Access +# PSaaS Appliance Administration: Limiting SSH Access -Auth0 requires SSH access in order to connect to the 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. +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 Appliance instances. For Appliance deployments in the cloud, you would *not* enable the SSH endpoint for your virtual machines. For on-premise 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 4aedf29627..5ad7477bc3 100644 --- a/articles/appliance/admin/managing-the-dashboard.md +++ b/articles/appliance/admin/managing-the-dashboard.md @@ -1,26 +1,35 @@ --- section: appliance -description: How to access and restrict access to the Appliance Management Dashboard +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 --- -# Auth0 Appliance Administration: Managing the Dashboard +# PSaaS Appliance Administration: Manage the Dashboard -### Accessing the Dashboard +## Access the Dashboard -::: panel-warning Connections for the Auth0 Client -The **Auth0** client in the Root Tenant Authority (RTA) controls access to the Management Dashboard, and the only Connections that you should enable for this client is the built-in Database Connection (the default Connection for this client 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** client. +::: 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** client. +Additionally, please [disable signups](/appliance/admin/disabling-sign-ups) for the **Auth0** application. ::: -The [Auth0 Dashboard](/appliance/dashboard) uses the Auth0 Appliance to authenticate its users. +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. -> Changes to the Auth0 Client or `Initial-Connection` may result in unexpected Dashboard behavior. Please makes changes with caution. +::: 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 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: +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 @@ -36,13 +45,17 @@ function (user, context, callback) { ``` -> The default user `root@auth0.com` has access to the Appliance and its configuration area. Please remember to reset this user's default password or disable the user via the Auth0 Dashboard. +::: 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*. -### Restricting Access to the Dashboard +## Restrict Access to the Dashboard -Because the Dashboard uses the 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. +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 Appliance to authenticate using their Active Directory (via either ADFS or AD Connector). +* 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/articles/appliance/admin/monitoring.md b/articles/appliance/admin/monitoring.md index 1af263f214..751be898b9 100644 --- a/articles/appliance/admin/monitoring.md +++ b/articles/appliance/admin/monitoring.md @@ -1,11 +1,18 @@ --- section: appliance -description: How to monitor the Appliance +description: How to monitor the PSaaS Appliance +topics: + - appliance + - monitoring +contentType: how-to +useCase: appliance +applianceId: appliance8 +sitemap: false --- -# Auth0 Appliance Administration: Monitoring +# PSaaS Appliance Administration: Monitoring -While your existing monitoring platform may already collect data (such as metrics on CPU, disk size, etc.) at the virtual machine level, it may exclude information regarding the nodes in the cluster. +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). @@ -13,6 +20,6 @@ For information about general Auth0 Monitoring, please see [this page](monitorin ## Performing Health Checks on Load Balancers -When running the 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. +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/articles/appliance/admin/rate-limiting.md b/articles/appliance/admin/rate-limiting.md new file mode 100644 index 0000000000..5e276a2e64 --- /dev/null +++ b/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/articles/appliance/admin/updating-the-appliance.md b/articles/appliance/admin/updating-the-appliance.md index 0acca3e9c5..bfec4751aa 100644 --- a/articles/appliance/admin/updating-the-appliance.md +++ b/articles/appliance/admin/updating-the-appliance.md @@ -1,12 +1,119 @@ --- section: appliance -description: How to update the 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 -# Updating the 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. -Auth0 requires regular updates to your Appliance instances to ensure that you always have the latest features and improvements. The update interval is typically once per month. +Appliances must be updated using a **major release** at least once every **90 days**. -During the update, the Appliance instances will need limited connectivity to the Internet to download the application and operating system updates). The update will be [started via the Management Dashboard](/appliance/dashboard/updates) and typically takes between 10 to 30 minutes. +## Releases -The update will be scheduled so that an Auth0 Customer Success Engineer is on the call with your operations team during the entire process. +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/articles/appliance/appliance-overview.md b/articles/appliance/appliance-overview.md index 6705e30507..ed9bfb70b7 100644 --- a/articles/appliance/appliance-overview.md +++ b/articles/appliance/appliance-overview.md @@ -1,31 +1,66 @@ --- section: appliance -description: The Auth0 Appliance is an option for your organization when compliance or other policy requirements prevent you from using a multi-tenant cloud service. +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 --- -# Auth0 Appliance Overview +# PSaaS Appliance Overview -The Auth0 Appliance is an option for your organization when compliance or other policy requirements prevent you from using a multi-tenant cloud service. The Auth0 Appliance can be deployed in one of three places: +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**, **Microsoft Azure**, and/or **Google Cloud Platform**; -* 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 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, etc.), and other required dependencies (such as the SMTP, NTP, etc.). +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 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 Appliance deployment models. The following table shows the configuration options: - -![](/media/articles/appliance/ha-options.png) - -[Auth0 Deployment Models](/deployment) provides additional details and explains the differences between each of the Appliance deployment models and the standard multi-tenant cloud 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 @@ -34,17 +69,17 @@ 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 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 Appliance implementation project typically takes between 1-5 weeks. +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 Appliances, nor will any information be transferred off of the Appliances without your consent. +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 Appliance instances contact external Auth0 endpoints for updating under your consent and supervision. After maintenance completes, you can block Internet access to the 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 Appliance are necessary. If you expose API endpoints to be used for monitoring, Auth0 will collect this information to proactively monitor Appliance behavior for you. +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 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. +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 @@ -52,7 +87,7 @@ The typical update cycle is once per month. You can control and which version is The diagram below details a few of these dependencies: -![](/media/articles/appliance/overview.png) +Appliance Overview ## Monitoring and Support @@ -60,19 +95,19 @@ You are responsible for monitoring all the dependencies the Auth0 Service relies 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 Appliance for you, then Auth0 will monitor the related services. +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 Appliance has authenticated monitoring endpoints for metrics like CPU, memory, and disk space that you can query for more detailed information. +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 Auth0 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. +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 Auth0 Appliance depends on the expected traffic and the desired availability. In some scenarios, a single node is sufficient. For a highly-available configuration, the Production environment requires a minimum of three network load-balanced Appliance instances and one for the Dev/Test (non-Production) environment (which also does *not* required any special load balancing logic/sticky sessions). +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/articles/appliance/cli/adding-node-to-backup-role.md b/articles/appliance/cli/adding-node-to-backup-role.md index d211e5948a..fad2cdabe9 100644 --- a/articles/appliance/cli/adding-node-to-backup-role.md +++ b/articles/appliance/cli/adding-node-to-backup-role.md @@ -1,28 +1,35 @@ --- section: appliance -description: How to add an Appliance node in the backup node +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 --- -# Appliance: Adding a Node to the Backup Role - -> This document applies beginning with Appliance update **build 7247**. +# PSaaS Appliance: Adding a Node to the Backup Role ## Prerequisites -* A cluster with two or more nodes; - * At least one node must **not** be assigned a `backup` role. +* 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 Auth0 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. +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`. - +::: 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 -## Additional Reading: -* [Configuring and Using the Auth0 Appliance Command Line Interface](/appliance/cli/configure-cli) -* [How to Back Up Appliance Instances Using the CLI](/appliance/cli/backing-up-the-appliance) +* [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/articles/appliance/cli/backing-up-the-appliance.md b/articles/appliance/cli/backing-up-the-appliance.md index b5a3d1b848..f382361fb5 100644 --- a/articles/appliance/cli/backing-up-the-appliance.md +++ b/articles/appliance/cli/backing-up-the-appliance.md @@ -1,52 +1,87 @@ --- section: appliance -description: How to back up the Appliance using its CLI +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 Appliance Instances Using the CLI +# How to Back Up the PSaaS Appliance Using the CLI -You may use Appliance CLI to perform a backup on a specific node. +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 your workstation has been [configured to perform operations](/appliance/cli/configure-cli) on your Appliance instances; +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. -> Please perform backups only on Appliance instances running **build 7247** or later. Backups are only allowed on nodes added to the `backup` role. Please see [Adding a Node to the Backup Role](/appliance/cli/adding-node-to-backup-role) for additional information. +::: 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, throughout this document, the following sample values are used: +Please be aware that we use the following sample values throughout this document: -* IP address of the node to be backed up: `192.168.1.186`. Generically, the node may also be referred to as ``. +* 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`. -## Generating a New Backup +## Generate a New Backup To initiate a backup, run the following command in your local command-line interface: -`a0cli -t backup ` +```bash +a0cli -t backup +``` For example, if you were to run the above command using the provided sample values, you would run: -`a0cli -t 192.168.1.186 backup Passw0rd` +```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. -> Only one backup may performed and stored at any given time. Prior to generating a new backup of a node, the existing backup must be deleted. +::: 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). +::: -## Retrieving a Backup +## Back up Sensitive Configuration Info -Prior to downloading a backup, we recommend checking to ensure that one is available. +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. -### Checking the Status of the Backup +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`. -You can check on the status of a backup by running the following command in your local command-line instance: +The full instructions (along with the commands you'll need to run) are as follows: -`a0cli -t backup-status` +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: -```text +```json { "message": "Backup found", "arguments": { @@ -56,22 +91,36 @@ If a backup is available, you will see a message similar to the following: } ``` -### Retrieving an Existing Backup +![](/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: -`a0cli -t backup-retrieve` +```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. Please remember that the files are encrypted using the `aes-256-crt` algorithm. +Auth0 recommends checking the md5sum of the retrieved file against that received as part of the back-up status message. -### Deleting a Backup +```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: -`a0cli -t backup-delete` +```bash +a0cli -t backup-delete +``` -## Restoring a Backup +## Restore a Backup -Please contact Auth0 to work with a Customer Success Engineer to 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/articles/appliance/cli/configure-cli.md b/articles/appliance/cli/configure-cli.md index d884335b09..90b57df34f 100644 --- a/articles/appliance/cli/configure-cli.md +++ b/articles/appliance/cli/configure-cli.md @@ -1,15 +1,22 @@ --- section: appliance -description: How to configure the Appliance CLI +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 Auth0 Appliance Command Line Interface (CLI) allows you to perform operations on your Appliance instances via authorized workstations. +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, 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: @@ -42,36 +49,46 @@ However, if you have keys defined and you've run `update-commands`, you will see 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 availables commands from the specified node. - backup Creates a new backup. - backup-delete Deletes the current backup - backup-retrieve retrieves the current backup. - backup-status Retrieves the status of the node backup. - nslookup Performs an nslookup to a specified from the target node. - ping Sends a PING message to verify if the target node is up. - re-up 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 [device] [force] Add the backup role to the target node. - test-port Verifies if the target ip can listen on . + 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 - 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 ``` - -> Because the CLI sends commands to the server running on each Appliance's node, please ensure that the server is both available and can accept inbound and outbound connections to 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 Appliance. +Only workstations that you have authorized may perform operations on the PSaaS Appliance. To authorize a new workstation for use with the CLI: @@ -79,15 +96,17 @@ To authorize a new workstation for use with the CLI: ![](/media/articles/appliance/cli/cli-create-key.png) -2. Navigate to the CLI page of the Appliance configuration area, and add the key to your configuration. For additional information on how to do this, please see the [configuration instructions for Appliance CLIs](/appliance/dashboard/cli). +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) -> 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 Appliance. +::: 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 appliance's node, you will need to update the command list the node accepts by running the following command: +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` @@ -99,4 +118,6 @@ If the test was successful, you will see the following response: `{"message": "PONG"}` -> To get a list of available commands, run `a0cli` (omitting all parameters). +::: note + To get a list of available commands, run `a0cli` (omitting all parameters). +::: diff --git a/articles/appliance/cli/index.md b/articles/appliance/cli/index.md index b504692970..8f2d5a346f 100644 --- a/articles/appliance/cli/index.md +++ b/articles/appliance/cli/index.md @@ -1,14 +1,22 @@ --- url: /appliance/cli section: appliance -description: How to use the Appliance CLI +description: How to use the PSaaS Appliance CLI +topics: + - appliance + - cli + - backups +contentType: how-to +useCase: appliance +applianceId: appliance14 +sitemap: false --- -# Auth0 Appliance Command Line Interface +# Private SaaS (PSaaS) Appliance Command Line Interface -The Auth0 Appliance Command Line Interface (CLI) allows you to perform operations on your Appliance instances via authorized workstations. +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 Appliance Instances](/appliance/cli/configure-cli) -* [Backing up Appliance Instances with the CLI](/appliance/cli/backing-up-the-appliance) - * [Adding Appliance Nodes to the Backup Role](/appliance/cli/adding-node-to-backup-role) +* [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/articles/appliance/cli/reconfiguring-ip.md b/articles/appliance/cli/reconfiguring-ip.md index 35b3061b23..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 Appliance 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 Auth0 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 Appliance build **6576**, you may reconfigure the mapping of IP addresses to the names of nodes for each Appliance node using the 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 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 51126e0cba..5674a7c5b0 100644 --- a/articles/appliance/clock.md +++ b/articles/appliance/clock.md @@ -1,19 +1,25 @@ --- section: appliance -description: How to manage the time on Appliances +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 (e.g. AWS, Microsoft Azure, etc.), 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 Auth0 Appliance must have NTP configured correctly. In most cases, the NTP server is your Domain Controller. Contact your IT administrator for details. +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: -![ss-2014-12-15T11-34-37.png](/media/articles/appliance/clock/ss-2014-12-15T11-34-37.png) +![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. @@ -23,16 +29,20 @@ Auth0 uses __ntpd__ for internal time synchronization. As described in the [ntpd For example, the following settings will increase the frequency of updates: -![ss-2014-12-15T11-36-53.png](/media/articles/appliance/clock/ss-2014-12-15T11-36-53.png) +![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 +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. +::: 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 Auth0 appliance. +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/articles/appliance/critical-issue.md b/articles/appliance/critical-issue.md index f6a70c7c42..d7b7d47801 100644 --- a/articles/appliance/critical-issue.md +++ b/articles/appliance/critical-issue.md @@ -1,16 +1,25 @@ --- sitemap: false section: appliance -description: Outlines additional support procedure information for enterprise subscription customers with an Auth0 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 Auth0 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). -Appliance customers must have [Premium 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. +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 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. +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 @@ -20,27 +29,32 @@ 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 -## Special procedures for critical issues impacting production applications for Appliance customers +::: 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 -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. +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. -> **Important**: 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. +::: 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, 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.* +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 [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 Appliance installation.** -4. In **Environment** indicate the specific installation having the problem (i.e. Production, QA). -5. For **What can we help you with?** select `Auth0 Service Issue`. -6. 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. - -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.* +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 @@ -53,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, etc should be sent as updates to the ticket via support center.  Any conclusions or next steps should be added to the ticket as well. +* 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 cd0eddcca6..cb3728aba9 100644 --- a/articles/appliance/custom-domains/index.md +++ b/articles/appliance/custom-domains/index.md @@ -1,20 +1,47 @@ --- url: /appliance/custom-domains section: appliance -description: How to set up custom domains for your Appliances +description: How to set up custom domains for your PSaaS Appliance +topics: + - appliance + - custom-domains +contentType: + - index +useCase: appliance +applianceId: appliance16 +sitemap: false --- -# Custom Domains +# Private SaaS (PSaaS) Appliance: Custom Domains -Beginning with Appliance Build 5XXX, you may configure custom domains using the Management Dashboard. +::: 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. +::: -Custom domains allow you to expose one or more arbitrary DNS names for a tenant. Conventionally, Auth0 uses a three-part domain name for access, and it is the third portion of the domain name that varies depending on the tenant. +If you are using **PSaaS Appliance Build 5XXX** or later, you may configure custom domains using the Management Dashboard. -The root tenant authority (RTA) is a special domain that is configured when the cluster is 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. +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. -> All tenant domain names derive from the root tenant authority, and any changes to this will result in the deletion of all tenants. +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. -### Use Example +::: 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`: @@ -29,25 +56,28 @@ However, you might want to expose other domain names to your end users, such as: * `auth.site1.com` * `auth.site1.example.com` -You may do so by utilizing the Appliance's custom domains feature, which sets the domain used for authentication endpoints. +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 or more external DNS to a tenant that follows the standard naming convention. +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 domains to map to `auth.example.com`: +Suppose that we want the following domain to map to `auth.example.com`: ```text -auth.site1.example.com auth.site2.com ``` -Each of the custom domains (in this example, there are two) has its own certificate, which is stored separately. +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 Appliance configuration area](/appliance/dashboard/tenants). +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/articles/appliance/dashboard.md b/articles/appliance/dashboard.md deleted file mode 100644 index 985234cfbd..0000000000 --- a/articles/appliance/dashboard.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -section: appliance -description: > - Learn how to use the Management Dashboard to configure things like your Applications, Connections, Users, and Rules. ---- - -# Appliance Management Dashboard - -Regardless of whether you choose to use Auth0's cloud services or to run Auth0 through Appliance instances, the Management Dashboard is the interface through which you may configure things like your Applications, Connections, Users, and Rules. - -## 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 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 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 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/articles/appliance/dashboard/activity.md b/articles/appliance/dashboard/activity.md index 4f970f9475..d73389b069 100644 --- a/articles/appliance/dashboard/activity.md +++ b/articles/appliance/dashboard/activity.md @@ -1,14 +1,19 @@ --- section: appliance -description: Overview of the Appliance Dashboard Activity page +description: Overview of the PSaaS Appliance Dashboard Activity page +topics: + - appliance + - dashboard +contentType: concept +useCase: appliance +applianceId: appliance17 +sitemap: false --- -# Auth0 Appliance Dashboard: Activity - -::: panel-info Appliance Dashboard Navigation - -For additional information on navigating to and using the Appliance Dashboard, please see the section on [Appliance Controls](/appliance/dashboard#appliance-controls). +# 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. @@ -17,6 +22,6 @@ After you begin an update or make a change to the configuration, Auth0 displays 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 Appliance. +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/articles/appliance/dashboard/cli.md b/articles/appliance/dashboard/cli.md index 23654f9b3e..f817659fb8 100644 --- a/articles/appliance/dashboard/cli.md +++ b/articles/appliance/dashboard/cli.md @@ -1,21 +1,27 @@ --- section: appliance -description: Overview of the Appliance Dashboard CLI page +description: Overview of the PSaaS Appliance Dashboard CLI page +topics: + - appliance + - dashboard + - cli +contentType: concept +useCase: appliance +applianceId: appliance18 +sitemap: false --- -# Auth0 Appliance Dashboard: CLI - -::: panel-info Appliance Dashboard Navigation - -For additional information on navigating to and using the Appliance Dashboard, please see the section on [Appliance Controls](/appliance/dashboard#appliance-controls). +# 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 Auth0 Appliance instances requires integration with the Appliance Command Line Interface (CLI), you may add the required access keys to this page. +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 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 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 new file mode 100644 index 0000000000..e77472478b --- /dev/null +++ b/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/articles/appliance/dashboard/nodes.md b/articles/appliance/dashboard/nodes.md index c4cc82a154..f406e27741 100644 --- a/articles/appliance/dashboard/nodes.md +++ b/articles/appliance/dashboard/nodes.md @@ -1,17 +1,23 @@ --- section: appliance -description: Overview of the Appliance Dashboard Nodes page +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 -::: panel-info Appliance Dashboard Navigation - -For additional information on navigating to and using the Appliance Dashboard, please see the section on [Appliance Controls](/appliance/dashboard#appliance-controls). - +::: 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 Appliance configuration area provides a high-level overview of the nodes you have running as part of your Appliance setup. Each instance that you have with your web service provider is considered a node and is listed individually on this page. +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) diff --git a/articles/appliance/dashboard/oss-components.md b/articles/appliance/dashboard/oss-components.md index 013511a036..76c680a20e 100644 --- a/articles/appliance/dashboard/oss-components.md +++ b/articles/appliance/dashboard/oss-components.md @@ -1,15 +1,20 @@ --- section: appliance -description: Overview of the Appliance Dashboard OSS Components page - +description: Overview of the PSaaS Appliance Dashboard OSS Components page +topics: + - appliance + - dashboard + - oss +contentType: concept +useCase: appliance +applianceId: appliance22 +sitemap: false --- # OSS Components -::: panel-info Appliance Dashboard Navigation - -For additional information on navigating to and using the Appliance Dashboard, please see the section on [Appliance Controls](/appliance/dashboard#appliance-controls). - +::: 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. diff --git a/articles/appliance/dashboard/rate-limiting.md b/articles/appliance/dashboard/rate-limiting.md index 35c380b3b8..ac92f8c95c 100644 --- a/articles/appliance/dashboard/rate-limiting.md +++ b/articles/appliance/dashboard/rate-limiting.md @@ -1,17 +1,23 @@ --- section: appliance -description: Overview of the Appliance Dashboard Rate Limiting page +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 -::: panel-info Appliance Dashboard Navigation - -For additional information on navigating to and using the Appliance Dashboard, please see the section on [Appliance Controls](/appliance/dashboard#appliance-controls). - +::: 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 Appliance instances. +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) diff --git a/articles/appliance/dashboard/settings.md b/articles/appliance/dashboard/settings.md index 91728c4c36..842e959bdc 100644 --- a/articles/appliance/dashboard/settings.md +++ b/articles/appliance/dashboard/settings.md @@ -1,17 +1,23 @@ --- section: appliance -description: Overview of the Appliance Dashboard Settings page +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 -::: panel-info Appliance Dashboard Navigation - -For additional information on navigating to and using the Appliance Dashboard, please see the section on [Appliance Controls](/appliance/dashboard#appliance-controls). - +::: 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 Appliance configuration. +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) @@ -31,14 +37,14 @@ The Settings page is broken down into the following sections: ## 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 (e.g.: *10.4.2.39*) or a public NTP server (e.g.: *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; +* **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 Appliance; -* **Federated Logout**: if enabled, signing out of the Dashboard also signs you out from the ldP (e.g. when using enterprise connections with the 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 @@ -57,7 +63,7 @@ The Settings page is broken down into the following sections: ## SMTP Server -* **Send Mails From**: *Deprecated.* The email address used in the "From" field typically comes from that provided on your [custom email template](https://${manage_url}/#/emails); +* **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; @@ -72,17 +78,26 @@ 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 Appliance instances. +## 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 Appliance instances; +* **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) @@ -90,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 31f9b789d4..120e7b9073 100644 --- a/articles/appliance/dashboard/tenants.md +++ b/articles/appliance/dashboard/tenants.md @@ -1,24 +1,30 @@ --- section: appliance -description: Overview of the Appliance Dashboard Tenants page +description: Overview of the PSaaS Appliance Dashboard Tenants page +topics: + - appliance + - dashboard + - tenants +contentType: reference +useCase: appliance +applianceId: appliance25 +sitemap: false --- -# Auth0 Appliance Dashboard: Tenants - -::: panel-info Appliance Dashboard Navigation - -For additional information on navigating to and using the Appliance Dashboard, please see the section on [Appliance Controls](/appliance/dashboard#appliance-controls). +# 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 Appliance Dashboard lists all tenants associated with your Appliance instance. +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; -* **Clients**: the number of clients associated with 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. @@ -29,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: @@ -47,7 +57,9 @@ To add a custom domain, click on the "Add Domain" button. You will be prompted f * **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.** + ::: 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: @@ -57,6 +69,6 @@ Once the change has been implemented and you have refreshed the custom domains p * **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 (e.g. what is being secured); +* **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/articles/appliance/dashboard/troubleshoot.md b/articles/appliance/dashboard/troubleshoot.md index fb2e08360d..7af19b48fc 100644 --- a/articles/appliance/dashboard/troubleshoot.md +++ b/articles/appliance/dashboard/troubleshoot.md @@ -1,23 +1,29 @@ --- section: appliance -description: Overview of the Appliance Dashboard Troubleshoot page +description: Overview of the PSaaS Appliance Dashboard Troubleshoot page +topics: + - appliance + - dashboard + - troubleshooting +contentType: reference +useCase: appliance +applianceId: appliance26 +sitemap: false --- -# Auth0 Appliance Dashboard: Troubleshoot - -::: panel-info Appliance Dashboard Navigation - -For additional information on navigating to and using the Appliance Dashboard, please see the section on [Appliance Controls](/appliance/dashboard#appliance-controls). +# 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 Appliance Dashboard provides you with tools to help diagnose any issues that might occur. +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 Appliance instance(s) by clicking on the "Generate New Package" button. +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. @@ -33,7 +39,7 @@ Upon downloaded your package, you'll notice that the file name formatted as foll ## Health Check -The Health Check offers a quick overview of the status of your Appliance instances. Data is available for the past hour through the past twenty-nine (29) days. +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. diff --git a/articles/appliance/dashboard/updates.md b/articles/appliance/dashboard/updates.md index b81b855d9b..a78879ad02 100644 --- a/articles/appliance/dashboard/updates.md +++ b/articles/appliance/dashboard/updates.md @@ -1,19 +1,27 @@ --- section: appliance -description: Overview of the Appliance Dashboard Updates page +description: Overview of the PSaaS Appliance Dashboard Updates page +topics: + - appliance + - dashboard + - updates +contentType: reference +useCase: appliance +applianceId: appliance27 +sitemap: false --- -# Auth0 Appliance Dashboard: Updates - -::: panel-info Appliance Dashboard Navigation - -For additional information on navigating to and using the Appliance Dashboard, please see the section on [Appliance Controls](/appliance/dashboard#appliance-controls). +# 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 Appliance configuration area allows you to make the required/selected updates to your Appliance instance. +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). -> Updates cannot be rolled back/undone, so take VM snapshots and make backups as needed. +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) @@ -24,8 +32,8 @@ You will be asked to provide the *build number* you would like to apply in the * 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 Appliance updates cannot be undone. +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. -## Offline Update (Deprecated) - -If you possess an updater package from Auth0, use the "Update from Package" button to select the package and begin the updates. +::: 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/articles/appliance/disaster-recovery-raci.md b/articles/appliance/disaster-recovery-raci.md new file mode 100644 index 0000000000..4a9e440e7b --- /dev/null +++ b/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/articles/appliance/disaster-recovery.md b/articles/appliance/disaster-recovery.md index 0515aa051c..a2296865d2 100644 --- a/articles/appliance/disaster-recovery.md +++ b/articles/appliance/disaster-recovery.md @@ -1,68 +1,76 @@ --- -description: High-level overview of disaster recovery options for the Appliance +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 --- -# Appliance: Disaster Recovery +# PSaaS Appliance: Disaster Recovery -When preparing for the possibility of issues with your 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 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. +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 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). +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 Appliance Implementation +## Geographic High-Availability PSaaS Appliance Implementation -If your requirements demand very little to no downtime, we recommend a [Geographic High-Availability 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 Appliance implementation that provides: +Geo-HA is a PSaaS Appliance implementation that provides: * Data center redundancy; -* Automatic failure handling; -* The highest form of Appliance availability offered by Auth0. +* 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 Appliance Virtual Machines (VM) that need maintenance; +* 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 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 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 [Appliance Command Line Interface (CLI)](/appliance/cli) to [reconfigure the IP addresses](/appliance/cli/reconfiguring-ip) of the VM(s). - -::: panel-info VMWare's Site Recovery Manager -If you are hosting your 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. SRM will change the IP address(es) for your instance(s), and you can +3. Contact a Managed Services Engineer via support ticket to complete the recovery of your environment -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 [Appliance Command Line Interface (CLI)](/appliance/cli) ahead of time and uploaded the certificate. +::: 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 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 Appliance and bring it back online with your restored data. +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 [Appliance Command Line Interface (CLI)](/appliance/cli). You can then download them from the Appliance and store them at a secondary site for recovery in the event you need to implement a recovery scenario. +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**. @@ -70,18 +78,16 @@ 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 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: -* [Backing Up Appliance Instances](/appliance/admin/backing-up-the-appliance-instances) -* [Using the CLI to Backup Appliance Instances](/appliance/cli/backing-up-the-appliance) -* [Adding an Appliance Node to the Backup Role](/appliance/cli/adding-node-to-backup-role) - -**Note**: This option is available to Appliances on version **7247** or later. +* [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. +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 b95451b78a..b98480d9b1 100644 --- a/articles/appliance/extensions.md +++ b/articles/appliance/extensions.md @@ -1,32 +1,48 @@ --- url: /appliance/extensions section: appliance -description: Explains implementation details for Extensions specific to the Auth0 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 --- -# Auth0 Appliance: Extensions +# PSaaS Appliance: Extensions -While using [Extensions](/extensions) in the Appliance is very similar to using Extensions in the multi-tenant installation of Auth0, there are some differences. +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 -Extensions make use of Webtasks. When you activate a Webtask in the Appliance, you get a URL specific to that instance of the Webtask service. By default, this URL is structured as follows: +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.` -:::panel-info Enable Webtasks -To enable Webtasks, go to the [Webtasks Settings page of the Management Dashboard](${manage_url}/#/account/webtasks). -::: +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). -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 Client Settings page](${manage_url}/#/clients). - -![Allowed Origins Section of Client Settings](/media/articles/appliance/allowed-origins.png) +![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. -## Extensions Unavailable in the Appliance +## Delegated Administration Extension + +The [Delegated Administration](/extensions/delegated-admin) extension is available beginning with version 10755 when User search is enabled. + +## Dedicated Domains -The following Extensions are unavailable in the Appliance: +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). -* [Delegated Administration](/extensions/delegated-admin) -* [Auth0 Authorization](/extensions/authorization-extension) +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 60d6c4daa6..8750ac5517 100644 --- a/articles/appliance/geo-ha/disaster-recovery.md +++ b/articles/appliance/geo-ha/disaster-recovery.md @@ -1,100 +1,108 @@ --- section: appliance -description: Descriptions of Appliance Geo HA Failure Scenarios and Testing - +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 Appliance Failure Scenarios and Testing - -[Overview of the Geographic High-Availability Appliance](/appliance/geo-ha) + -## Geographic High-Availability Appliance Failure Scenarios and Impact +# Geographic High-Availability PSaaS Appliance Failure Scenarios and Testing -The following table details some of the ways in which the Geographic High-Availability Appliance may fail and what the implications of such a failure are. +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 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 siteSome 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.
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 Appliance Testing +## Geographic High-Availability PSaaS Appliance Testing -To test the Geographic High-Availability Appliance (GEO HA) failover/failback procedure, Auth0 will: +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. @@ -103,16 +111,16 @@ The Arbiter, located in a third site, determines which site stays active in the 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 Appliance +## Backing Up the Geographic High-Availability PSaaS Appliance -As a customer, it is your responsibility to perform regular backups on your Geographic High-Availability Appliance (GEO HA). Auth0 recommends a single backup, since the GEO HA is a single cluster stretched over a distance. +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 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 -* [How to Configure the Command Line Interface for Use with Appliance Instances](/appliance/cli/adding-node-to-backup-role) -* [Backing Up Appliance Instances with the Command Line Interface](/appliance/cli/backing-up-the-appliance) -* [Adding Appliance Nodes to the Backup Role](/appliance/cli/configure-cli) +* [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/articles/appliance/geo-ha/dr-overview.md b/articles/appliance/geo-ha/dr-overview.md index 582b7f012e..32051a5492 100644 --- a/articles/appliance/geo-ha/dr-overview.md +++ b/articles/appliance/geo-ha/dr-overview.md @@ -1,31 +1,44 @@ --- section: appliance -description: Descriptions of Appliance Geo HA Failure and Disaster Recovery +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 Appliance Failure & Disaster Recovery + -One key aspect of the Geographic High-Availability (GEO HA) Appliance is the data center redundancy and failure handling that ensures the highest form of Appliance uptime offered by Auth0. +# 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 Appliance is a stretched cluster that consists of the following pieces: +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 Appliance instances; -* one secondary data center with three Appliance instances; -* one arbiter, a seventh instance that is located in its own data center. +* 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. + + + @@ -61,4 +74,5 @@ The following table summarizes what might happen and its possible performance im -
Event Outcome Performance 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 primaryNo impact to the end user if both the primary and secondary data centers are still available None
+ +
diff --git a/articles/appliance/geo-ha/index.md b/articles/appliance/geo-ha/index.md index 6978a59b50..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 --- -# Auth0 Appliance: High Availability Geo Cluster (Geo HA) +# Private SaaS (PSaaS) Appliance: High Availability Geo Cluster (Geo HA) -The high availability geo cluster is an Appliance implementation that provides data center redundancy and automatic failure handling. This is the highest form of 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 @@ -18,22 +28,28 @@ Auth0 adds to the single data center high availability solution by extending the The standard configuration 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 Appliance instances; -* one standby data center with three Appliance instances; -* one arbiter, a seventh instance that is located in its own data center. +* 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 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 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). -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). - -> Ports 27017 and 7777 must be open between all instances in the cluster. +::: 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. Since it isn’t storing data and doesn’t run any services, it can be a small instance with two cores and 4GB of memory. +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. -### Geographically-Aware Global Load Balancer/DNS Failover Configuration +### 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. @@ -41,9 +57,9 @@ Two examples of products that support this configuration are the F5 Global Traff ### Application Tier -Auth0 requires the use of a geographically-aware load balancer or DNS failover solution that prefers to serve application requests using the primary data center, despite the fact that the Appliance instances in the hot standby data center are active and able to serve the requests. +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 geographically-aware load balancer or DNS failover solution mitigates this performance issue. +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 @@ -51,7 +67,7 @@ The data tier operates independently of the application tier as a single cluster 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 appliances in the standby data center), then a node in the secondary data center will be elected to become primary. +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. @@ -59,10 +75,12 @@ If the primary data center becomes available again and its instances are visible 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 Appliances 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 Appliance instances begin to fail. -4. **The geographically-aware global load balancer/DNS failover configuration detects 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 Appliances associated with the standby data center are now serving requests** and acting as the primary data node due to its election in step 2. +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. -### Further Reading +### Keep reading -* [Geographic High-Availability Appliance Failure Scenarios and Testing](/appliance/geo-ha/disaster-recovery) +::: next-steps +* [Geographic High-Availability PSaaS Appliance Failure Scenarios and Testing](/appliance/geo-ha/disaster-recovery) +::: diff --git a/articles/appliance/index.html b/articles/appliance/index.html index b72e153d84..56af4b1bc2 100644 --- a/articles/appliance/index.html +++ b/articles/appliance/index.html @@ -2,145 +2,144 @@ url: /appliance section: appliance classes: topic-page -title: Auth0 Appliance +title: PSaaS Appliance +topics: + - appliance +useCase: appliance +applianceId: appliance59 +sitemap: false ---
-

Auth0 Appliance

+

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.

-

What is Auth0 Appliance?

+

What is PSaaS Appliance?

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

-

Appliance Planning

+

PSaaS Appliance Planning

-

Appliance Administration

+

PSaaS Appliance Administration

  • - Appliance Release Notes + PSaaS Appliance Release Notes

    - This document shows the latest updates to the Auth0 Appliance. + This document shows the latest updates to the PSaaS Appliance.

  • - Appliance Administrator's Manual + PSaaS Appliance Administrator's Manual

    - This document covers factors Auth0 Appliance administrators should be aware of when working with production Appliance instances. + This document covers factors PSaaS Appliance administrators should be aware of when working with production PSaaS Appliance instances.

  • - Appliance Dashboard/Configuration Area + PSaaS Appliance Dashboard/Configuration Area

    - Regardless of whether you choose to use Auth0's cloud services or to run Auth0 through Appliance instances, the Management Dashboard is the interface through which you may configure things like your Applications, Connections, Users, and Rules. + Regardless of whether you choose to use Auth0's cloud services or to run Auth0 through PSaaS Appliance instances, the Management Dashboard is the interface through which you may configure things like your Applications, Connections, Users, and Rules.

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

    - In addition to providing tools for monitoring your 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.

  • - Appliance Command-Line Interface Tools + PSaaS Appliance Command-Line Interface Tools

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

  • - Automatic Creation of Tenants + Node.js Modules Available in Rules and Custom Database Connections for PSaaS Appliance

    - If your business needs require you to create tenants regularly, you may automate this process in your 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 Appliances -

    - For security reasons, rules and custom database connections for Auth0 appliances run in a JavaScript sandbox. You can use the full power of the ECMAScript 5 language and a few selected libraries. + 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.

  • Webtasks

    - Beginning with Build 7247, you may use the Appliance's version of WebTasks to execute your rules and custom database logic. + Beginning with Build 7247, you may use the PSaaS Appliance's version of WebTasks to execute your rules and custom database logic.

  • Extensions

    - Auth0 Extensions enable you to install applications (such as Webtasks) or run commands/scripts that extend the functionality of the Auth0 base product. This section explains implementation details specific for the Auth0 Appliance. + Auth0 Extensions enable you to install applications (such as Webtasks) or run commands/scripts that extend the functionality of the Auth0 base product. This section explains implementation details specific for the PSaaS Appliance.

  • Geographic High-Availability Appliance Failure Scenarios and Testing

    - The high-availability geo cluster is an Appliance implementation that provides data center redundancy and automatic failure handling. This is the highest form of Appliance availability offered by Auth0. + 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.

diff --git a/articles/appliance/infrastructure/dns.md b/articles/appliance/infrastructure/dns.md index 1db9492974..2466fa2ca1 100644 --- a/articles/appliance/infrastructure/dns.md +++ b/articles/appliance/infrastructure/dns.md @@ -1,24 +1,43 @@ --- section: appliance -description: Appliance infrastructure information about DNS +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 Appliance instances. +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). -> **Important**: DNS records must be finalized for all of the tenants prior to Appliance deployment. They cannot be changed afterwards. +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. -### Sample DNS Naming Scheme +Dedicated and non-dedicated host names must be unique. + +## Sample DNS Naming Scheme + - + - - + + @@ -26,61 +45,66 @@ The following document details the requirements of DNS records used for Applianc - + +
Management Dashboardmanage-project.yourdomain.commanage.yourdomain.com
Root Tenant Authorityrta-project.yourdomain.comConfigurationconfig.yourdomain.com
Webtask
App Tenant(s)app1-project.yourdomain.com;
app2-project.yourdomain.com
...etc.		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 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
Root Tenant Authority (Dev)rta-dev-project.yourdomain.comConfiguration (Dev)config.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
...etc.		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 +### Definitions of Terms Used in the DNS Naming Scheme -* **Root Tenant Authority (RTA)**: highly-privileged tenant used to do the Appliance baseline configuration and for managing the security of other tenants; +* **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) -### Multi-Tenancy - -The Auth0 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 Appliance for different projects. If a customer decides to create multiple app tenants, each app tenant must have its own DNS entry. +## Multi-Tenancy -### DNS Configuration Requirements +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. -#### IP Addresses and DNS Records +## 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). -For a single-node 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). +### 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). -> 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. +::: 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 +### Hostnames -The hostname (e.g. **manage-project**.yourdomain.com) must be at least three characters long and must **not** contain any underscores(_). +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. - +
+ @@ -127,22 +151,30 @@ The following are reserved tenant names and **may not** be used for the **app** - + +
login adminhelp support intauth
-The Management Dashboard, Configuration Tenant, and App Tenant(s) must all be a part of the same parent domain (e.g. yourdomain.com). +::: 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/). +::: -Three- or four-part domain names are supported (e.g. manage.project.yourdomain.com). +The Management Dashboard, Configuration Tenant, and App Tenant(s) must all be a part of the same parent domain (such as yourdomain.com). -#### Custom Domains +Three- or four-part domain names are supported (such as manage.project.yourdomain.com). -In the 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. +### 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: - +
+ @@ -153,6 +185,7 @@ Suppose these were your standard domains: +
Root Tenant Authority Sample Tenantauth.example.com new-name.not-example.com
-Please note that all tenant names are derived from the base RTA. 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 clients). +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 new file mode 100644 index 0000000000..f2a2e22e74 --- /dev/null +++ b/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/articles/appliance/infrastructure/faq.md b/articles/appliance/infrastructure/faq.md index 88c5b9dc11..e9dc9fc33e 100644 --- a/articles/appliance/infrastructure/faq.md +++ b/articles/appliance/infrastructure/faq.md @@ -1,32 +1,101 @@ --- -description: This page answers several common questions regarding the Auth0 Appliance infrastructure. +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 --- -# Auth0 Appliance Infrastructure Requirements: Frequently Asked Questions +# PSaaS Appliance Infrastructure Requirements: Frequently Asked Questions -### Are there any functional differences between the Auth0 Cloud and the Auth0 Appliance? +#### 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 Appliance? +#### 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 Appliance is a managed service that runs within your network. You are responsible for managing the infrastructure around the appliance. Auth0 will manage the Appliance’s internals. +#### 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 Appliance? -No, the Appliance is a managed service that runs within your network. You are responsible for managing the infrastructure around the appliance. Auth0 will manage the Appliance’s internals. The Appliance [exposes monitoring information](/appliance/monitoring) in the Dashboard for common metrics (CPU/memory/etc) or through the API, which can be used by your operations team and monitoring tools to determine how the Appliance is performing. The Appliance also includes a New Relic agent for monitoring purposes. +#### 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 Appliance? +#### 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? -If Auth0 hosts the Appliance, Auth0 will provide the required certificate(s). +#### 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. -### Why do both the DEV (non-prod) node and PROD cluster require unique certificates signed by a public Certificate Authority? +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 Appliance requires outbound access to? -For Auth0 Appliance updates, we can provide you with specific addresses that are required. For certain protocols, Internet connectivity is required during operation (such as social connections or emails). +#### 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/articles/appliance/infrastructure/index.md b/articles/appliance/infrastructure/index.md index fc5628f1a9..6f2919f464 100644 --- a/articles/appliance/infrastructure/index.md +++ b/articles/appliance/infrastructure/index.md @@ -1,13 +1,22 @@ --- -title: Auth0 Appliance Infrastructure Requirements +title: PSaaS Appliance Infrastructure Requirements url: /appliance/infrastructure section: appliance -description: This document contains information about the Appliance and its infrastructure requirements. +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 --- -# Auth0 Appliance Infrastructure Requirements +# Private SaaS (PSaaS) Appliance Infrastructure Requirements -This document contains the following information about the Appliance and its 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); @@ -16,5 +25,6 @@ This document contains the following information about the Appliance and its inf * [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 Appliance. +Please consult the [FAQ](/appliance/infrastructure/faq) for further information about the PSaaS Appliance. diff --git a/articles/appliance/infrastructure/infrastructure-overview.md b/articles/appliance/infrastructure/infrastructure-overview.md index 45d5172514..b9e92e633a 100644 --- a/articles/appliance/infrastructure/infrastructure-overview.md +++ b/articles/appliance/infrastructure/infrastructure-overview.md @@ -1,10 +1,16 @@ --- section: appliance -description: Appliance infrastructure overview +description: PSaaS Appliance infrastructure overview +topics: + - appliance + - infrastructure +contentType: concept +useCase: appliance +applianceId: appliance35 +sitemap: false --- +# PSaaS Appliance Deployment Architecture -# Auth0 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. -The typical Auth0 Appliance production deployment is a three-node clusters that allows for high availability. The following diagram outlines the typical architecture. - -![](/media/articles/appliance/appliance-infrastructure.png) + \ No newline at end of file diff --git a/articles/appliance/infrastructure/installation.md b/articles/appliance/infrastructure/installation.md index a0ca85e90a..4197c25fc8 100644 --- a/articles/appliance/infrastructure/installation.md +++ b/articles/appliance/infrastructure/installation.md @@ -1,13 +1,25 @@ --- section: appliance -description: Appliance infrastructure information about installation +description: PSaaS Appliance infrastructure information about installation +topics: + - appliance + - infrastructure + - installation +contentType: + - concept + - how-to +useCase: appliance +applianceId: appliance36 +sitemap: false --- -# Auth0 Appliance Infrastructure Overview + + +# PSaaS Appliance Infrastructure Overview ## Project Coordination and Execution -Auth0 provides a project plan methodology to help customers get up and running with the Auth0 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 Auth0 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. +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. @@ -31,23 +43,24 @@ Auth0 provides a project plan methodology to help customers get up and running w - +
IT OperationsBackup and monitor Appliance infrastructureBackup and monitor PSaaS Appliance infrastructure
## Overview of Required Steps -The following basic steps are required to get the infrastructure up and running and the Appliance deployed: +The following basic steps are required to get the infrastructure up and running and the PSaaS Appliance deployed: -1. Understand the Appliance infrastructure requirements as detailed in this document; -2. Complete and submit the Pre-Appliance Installation Checklist to ensure that you have everything you need ready and on hand for the Appliance deployment; -3. Access and install the Appliance; -4. Complete and submit the Post-Appliance Install Checklist to notify Auth0 that you have everything in place and that Auth0 can commence configuring the Appliance; -5. Complete the steps detailed in the 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 -> Production and non-Production (test/development) must be on completely isolated networks. +::: note +Production and non-Production (test/development) must be on completely isolated networks. +::: -All 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 Appliance is working as expected with your applications prior to deployment to Production. It also allows for a thorough 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. +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/articles/appliance/infrastructure/internet-restricted-deployment.md b/articles/appliance/infrastructure/internet-restricted-deployment.md new file mode 100644 index 0000000000..352e6b0e36 --- /dev/null +++ b/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/articles/appliance/infrastructure/ip-domain-port-list.md b/articles/appliance/infrastructure/ip-domain-port-list.md index 3821164f73..d81d3d2a2f 100644 --- a/articles/appliance/infrastructure/ip-domain-port-list.md +++ b/articles/appliance/infrastructure/ip-domain-port-list.md @@ -1,23 +1,38 @@ --- -description: Appliance infrastructure information about IP/Domain and Port Usage +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 --- + -# Appliance Infrastructure: IP/Domain and Port List +# PSaaS Appliance Infrastructure Requirements: IP/Domain and Port List -The Appliance requires certain ports within the cluster to be open and able to access each other, as well as selected external sites. +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 Appliance instances in the same cluster: +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: + + + @@ -48,6 +63,18 @@ When possible, instances within a cluster should have full connectivity to each + + + + + + + + + + + + @@ -60,13 +87,15 @@ When possible, instances within a cluster should have full connectivity to each +
Port Use Required? Notes
27017 DatabaseYes Required for logging and debugging
9200, 9300-9400Elastic SearchYesRequired for Elastic Search
3000Grafana instrumentationNoRequired if you are using Grafana instrumentation
22 MaintenanceNo Allows 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 Appliance instances to connect to these addresses. +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. + @@ -75,6 +104,8 @@ Auth0 strives to keep these IP addresses stable, though this is not a given. Fro + + @@ -94,17 +125,17 @@ Auth0 strives to keep these IP addresses stable, though this is not a given. Fro - + - + - - + + @@ -112,19 +143,19 @@ Auth0 strives to keep these IP addresses stable, though this is not a given. Fro - + - + - + - + @@ -144,7 +175,7 @@ Auth0 strives to keep these IP addresses stable, though this is not a given. Fro - + @@ -155,6 +186,23 @@ Auth0 strives to keep these IP addresses stable, though this is not a given. Fro + + + + + + + + + + + + + + + + +
Use DirectionNotes Required?
All Inbound
Command Line Interface Inbound and OutboundCLI Clients (often on the internal network)CLI Applications (often on the internal network) 10121Allows use of the Appliance Command Line InterfaceAllows use of the PSaaS Appliance Command Line Interface No
Updates Outbound apt-mirror.it.auth0.com (52.8.153.197)80/443Provides update packages for Appliance instances443Provides update packages for PSaaS Appliance instances Yes
Outbound docker.it.auth0.com (52.9.124.234) 443Provides updates for Appliance Docker PackagesProvides updates for PSaaS Appliance Docker Packages Yes
UpdatesWeb extensions, Hooks, and Management Dashboard Outbound cdn.auth0.com 443Required to run web extensions; Provides update packages for Appliance instances running versions `6868` or earlierRequired to run web extensions and Hooks; also required for admins to browse to the Management Dashboard Yes
GitHubExamples Outbound github.com 443Inbound Jump Host 22Allows access to Appliance instances for support purposesAllows access to PSaaS Appliance instances for support purposes No
Allows access to Healthcheck endpoints No
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 diff --git a/articles/appliance/infrastructure/network.md b/articles/appliance/infrastructure/network.md index db0bb019f6..d197ad2191 100644 --- a/articles/appliance/infrastructure/network.md +++ b/articles/appliance/infrastructure/network.md @@ -1,17 +1,31 @@ --- section: appliance -description: Appliance infrastructure information about Networks +description: PSaaS Appliance infrastructure information about Networks +topics: + - appliance + - infrastructure + - networks +contentType: reference +useCase: appliance +applianceId: appliance39 +sitemap: false --- -# Auth0 Appliance Infrastructure Requirements: Network +# PSaaS Appliance Infrastructure Requirements: Network -This document details the requirements for the network on which the Appliance runs. +This document details the requirements for the network on which the PSaaS Appliance runs. -> Auth0 Appliance can only be deployed in 1 NIC. +::: 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 Appliance virtual machine (VM) must have its own private static IP address and outbound access. This can be accomplished through: +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. @@ -21,55 +35,64 @@ For **multi-node** clusters, all virtual machines must be: * able to communicate between each other via ports `7777`, `27017`, `8721`, and `8701`. * able to reach the load balancer via port `443`. -> Production and non-Production (test/development) must be on completely isolated networks. +::: 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 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). +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 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. +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 Appliance is delivered as a subscription-based managed service, Auth0 will need access to specified endpoints to provide proactive monitoring. +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 Appliance instances (development/test *and* production). A standard single-node or cluster deployment requires four DNS entries for the following: +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 a client for the configuration and application tenants on the Appliance; -* **Root Tenant Authority**: the tenant on the Appliance that controls Appliance settings, configuration, and local Dashboard Admin users; +* **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 Appliance created for your apps. It manages settings for your apps, user profiles, rules, etc. This is the tenant you will interact with primarily through the Management Dashboard and the API. +* **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. -Please refer to the [DNS page](/appliance/infrastructure/dns) for additional requirements. +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 Appliance with high-availability. +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; +* 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. -> For AWS deployments, you must use TCP/IP. +::: 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 Auth0 Appliance. The reverse proxy must be configured with: +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 -* TCP mode with Proxy Protocol or HTTPS mode (SSL offloading); - * Note: The Auth0 AD/LDAP Connector does not work in HTTPS mode. -* the incoming hostname forwarded to the 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 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`. +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/articles/appliance/infrastructure/security.md b/articles/appliance/infrastructure/security.md index c58bb542f6..adc6c39577 100644 --- a/articles/appliance/infrastructure/security.md +++ b/articles/appliance/infrastructure/security.md @@ -1,27 +1,42 @@ --- section: appliance -description: Appliance infrastructure information about security +description: PSaaS Appliance infrastructure information about security +topics: + - appliance + - infrastructure + - security +contentType: reference +useCase: appliance +applianceId: appliance40 +sitemap: false --- -# Auth0 Appliance Infrastructure Requirements: Security and Access +# PSaaS Appliance Infrastructure Requirements: Security and Access - This document details the security and access requirements for your Appliance instances. + This document details the security and access requirements for your PSaaS Appliance instances. ## SSL Certificates - Each Auth0 Appliance (e.g. your production cluster Appliance instance(s) and your development/test node Appliance instance) requires a unique SSL certificate to be created and installed. +When using the PSaaS Appliance, you will need to provide several SSL certificates. You must create and install a unique SSL certificate for: - > 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. +* 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. -* 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; * webtask; - * App Tenant(s) (current *and* future) specific to that particular Appliance instance. + * App Tenant(s) (current *and* future) specific to that particular PSaaS Appliance instance. Auth0 accepts the following certificate format: @@ -29,7 +44,9 @@ Auth0 accepts the following certificate format: 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). +::: note + The PFX certificate must contain the full chain (all intermediate certificates must be included in the public key). +::: ```text -----BEGIN CERTIFICATE----- @@ -40,43 +57,43 @@ 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; -* add an exception so that the Appliance instance(s) may get through the proxy unauthenticated. +* 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 +## HTTPS or TLS -Please ensure that your network is configured such that the Auth0 Appliance exposes HTTPS to end users only. +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 Auth0 Appliance to send emails. The Auth0 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. -Optionally, you may use a Transactional Email Provider (e.g. SendGrid, Amazon SES, Mandrill). +Optionally, you may use a Transactional Email Provider (such as SendGrid, Amazon SES, Mandrill). -The Appliance supports STARTTLS, but it is not required. +The PSaaS Appliance supports STARTTLS, but it is not required. ## Auth0 Remote Access -Auth0 may require remote access to your Appliance instances to perform updates, maintenance, or troubleshooting. +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 (the preferred method) or via VPN. - -After the initial configuration, please feel free to disable this connection. If these requirements are not feasible given your infrastructure, please contact your Auth0 Customer Success Engineer or Pre-Sales Engineer to determine an alternate solution. +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 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. If these requirements are not feasible given your infrastructure, please contact your Auth0 Customer Success Engineer or Pre-Sales Engineer to determine an alternate solution. - -### Around-the-Clock Accessibility for Custom SLAs - -Auth0's remote access method requires SSH access via Jumphost (the preferred method) or via VPN. For those customers requesting a Custom SLA tied to the Appliance, remote access must be granted through this method 24 hours per day, 7 days per week. If these requirements are not feasible given your infrastructure, please contact your Auth0 Customer Success Engineer or Pre-Sales Engineer to determine an alternate solution. +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 a004c65ef1..45851327f6 100644 --- a/articles/appliance/infrastructure/virtual-machines.md +++ b/articles/appliance/infrastructure/virtual-machines.md @@ -1,42 +1,48 @@ --- section: appliance -description: Appliance infrastructure information about virtual machines +description: PSaaS Appliance infrastructure information about virtual machines +topics: + - appliance + - infrastructure + - virtual-machines +contentType: reference +useCase: appliance +applianceId: appliance41 +sitemap: false --- -# Auth0 Appliance Infrastructure Requirements: Virtual Machines +# PSaaS Appliance Infrastructure Requirements: Virtual Machines -You may deploy the Auth0 Appliance on your premises using your own infrastructure or the infrastructure of a cloud provider. Currently, Auth0 supports the following Appliance usage on the following cloud providers: - -* 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 -Auth0 provides the 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. +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 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. +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**: 16 GB RAM (8 GB RAM minimum); -* **CPU**: 4 vCPU (2 vCPU minimum); +* **Memory**: 32 GB RAM (minimum); +* **CPU**: 8 vCPU (minimum); * **Storage**: - * *For Non-Production Nodes*: 40 GB for system/operating system storage, 50 GB for data storage, and 50 GB for backup purposes (if you want to test the backup process). + * *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 each should be allocated 40 GB for system/operating system storage and 100 GB for data storage; - * One virtual machine should be allocated 40 GB for system/operating system storage, 100 GB for data storage, and 100 GB for backup purposes. + * 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. -> Large installations will require higher IO performance. Auth0 will work with you to determine the required storage performance levels. +::: 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 Appliance virtual machines across more than one physical host server/blade. +For multi-node clusters, Auth0 recommends deploying the PSaaS Appliance virtual machines across more than one physical host server/blade. ## For AWS Users -* The **M4.Large** instance is the minimum VM [instance size](https://aws.amazon.com/ec2/instance-types/) that will meet Auth0's requirements. +* 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. -* If your production and development/test environments are within separate AWS accounts/regions, Auth0 will require the credentials for both environments. + * 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/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/access-data.md b/articles/appliance/instrumentation/access-data.md deleted file mode 100644 index ea462d308e..0000000000 --- a/articles/appliance/instrumentation/access-data.md +++ /dev/null @@ -1,109 +0,0 @@ ---- -section: appliance -description: This document covers how to access the data gathered via Instrumentation. ---- - -# Auth0 Appliance: Access Your Data - -By connecting to your Appliance via SSH, you can access your data in one of two ways. - -## Run Quick Queries from the Command Line - -From the command line, you can run the `query-metrics` script, which provides you with one or more of the following metrics: - -* The number of MongoDB queries made every second -* The number of attempted logins per second -* The CPU usage per process -* The memory used per process - -### Get Detailed Usage Information - -By running the `query-metrics` script *without* arguments, you can view detailed usage information: - -`query metrics` - -### Get Specific Usage Information - -To see specific information about a given usage scenario, you can add the appropriate arguments when running the `query-metrics` script. To do this, modify your command as follows: - -`query-metrics [...]` - -The following table lists the query index and the metric to which it corresponds: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
IndexMetricResolution of MetricRetention Time
0Number of MongoDB Queries Per Second5 seconds1 day
1Number of MongoDB Queries Per Second1 minute7 days
2Number of Attempted Logins Per Second5 seconds1 day
3Number of Attempted Logins Per Second1 minute7 days
4CPU Usage By Process5 seconds7 days
5Memory Usage By Process5 seconds7 days
- -#### Example 1: View the Number of MongoDB Queries for the Past 2 Minutes - -`query-metrics 1 "time > now() - 2m" "time < now()"` - -#### Example 2: View the CPU Usage by NGINX Processes for the Past 10 Minutes - -`query-metrics 4 "time > now() - 10m" "time < now()" nginx` - -## Access Data Directly from InfluxDB via Command-Line Interface - -::: panel-warning Warning -You can delete data and drop measurements and databases using the InfluxDB Command-Line Interface. Proceed with caution. -::: - -You can access you data directly by querying your InfluxDB instance using its Command-Line Interface (CLI). To do this, run the `influx` command from the Appliance. The CLI allows you to run custom queries and explore your data. To see a full list of acceptable arguments for this command, please refer to the [InfluxDB documentation](https://docs.influxdata.com/influxdb/v1.0/tools/shell/). - -Within InfluxDB, the database containing Appliance-related data is named `auth0`. There are two data retention policies under `auth0`: - -1. `1day`: contains metrics that get downsampled and stored for 1 day -2. `1week`: contains metrics that get downsampled and stored for 1 week - -> The retention policy and measurement names should be surrounded by double quotes in queries. - -### Example Query - -The following query allows you to view the number of MongoDB queries per second for the last two minutes. - -```text -USE auth 0 - -SELECT queries_per_sec FROM auth0."1day"."mongodb" WHERE time > now() - 2m -``` - -For additional information on querying InfluxDB, please refer to the [InfluxDB documentation on data exploration](https://docs.influxdata.com/influxdb/v1.0/query_language/data_exploration/). diff --git a/articles/appliance/instrumentation/add-grafana-users.md b/articles/appliance/instrumentation/add-grafana-users.md deleted file mode 100644 index 91337af780..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. ---- - -# Auth0 Appliance: Adding Users to Grafana - - -By default, each Grafana instance (every Appliance node comes with its own instance of Grafana) includes the following users: - -* `admin` -* `root@auth0.com` - -To visualize the instrumentation page with an Appliance administrative user *other* than `root@auth0.com`, you will need to add that user to the Grafana instances for **each** Appliance node. - -1. Navigate to the 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-info 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 8ed97f9b66..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. ---- - -# Auth0 Appliance: Metrics Available via Instrumentation - -The following metrics are available to you when Instrumentation is enabled on your Appliance: - -## Metrics Regarding 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 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 b201fce903..0000000000 --- a/articles/appliance/instrumentation/components.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -section: appliance -description: This document covers the software used for Instrumentation. ---- - -# Auth0 Appliance: Instrumentation Components - -The following applications are used to implement Instrumentation within the 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 Appliance diff --git a/articles/appliance/instrumentation/index.md b/articles/appliance/instrumentation/index.md deleted file mode 100644 index f2c88c453f..0000000000 --- a/articles/appliance/instrumentation/index.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -url: /appliance/instrumentation -section: appliance -description: This document covers why and how to enable instrumentation in the Appliance. ---- - -# Auth0 Appliance: Instrumentation - -The Appliance ships with a feature called Instrumentation, which makes it easy for your Appliance administrators or Auth0 Customer Success Engineers to gather information about the current (or previous) state of the Appliance. With Instrumentation, you are collecting time series data about the overall Appliance, as well as individual processes. You can then query or visualize this data to draw conclusions about the state of your Appliance. - -> Please contact your Auth0 Customer Success Engineer if you would like to enable Instrumentation for your Appliance. - -* [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 a0af8cfc48..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. ---- - -# Auth0 Appliance: How to Visualize Your Data - -Once you have enabled Instrumentation, you can access your data in one of two places: - -* Appliance Dashboard -* Grafana - -## View Your Data in the 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 Appliance instances. - -![Appliance Instrumentation Dashboard](/media/articles/appliance/instrumentation/general-data.png) - -## Access Your Data Directly from Grafana - -Each 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 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 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 b5d26d5bb9..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 Auth0 appliances run in a JavaScript sandbox. You can use the full power of the ECMAScript 5 language and a few selected libraries. +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 Auth0 appliances 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 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 b4759dbe9c..50fa8bc069 100644 --- a/articles/appliance/monitoring/authenticated-endpoints.md +++ b/articles/appliance/monitoring/authenticated-endpoints.md @@ -1,60 +1,171 @@ --- section: appliance -description: Overview of using the authenticated endpoint with the 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 --- -# Using Authenticated Testing Endpoints +# PSaaS Appliance: Authenticated Testing Endpoints -For tests that provide detailed information, Auth0 requires that these requests be authenticated using a key generated in your Appliance configuration area. 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 Appliance configuration area. 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) - > 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. +Scroll to the bottom of the page, and click Save to apply the new API Key value. -### Available Endpoints +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. -The following authenticated endpoints are available for you to use: +:::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. +::: -* /status/cpu -* /status/memory -* /status/disk -* /status/services -* /status/network -* /status/internet -* /status/email -* /status/db -* /status/replicaset +## Authenticated API Endpoints -Your call might look something like the following: +The API exposes a number of endpoints that you can use to test the status of the service. -``` -curl --user -api_keys_health:S9ranHlz0qQmIs0NgcYb8hU3MLKcBB4Khth2pom5VzLryYeW -v http://10.1.0.248:9110/status/cpu -``` +**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 -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. +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 ``` -curl -k --user -api_keys_health:S9ranHlz0qQmIs0NgcYb8hU3MLKcBB4Khth2pom5VzLryYeW -v https://10.1.0.248/health/status/cpu + +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 ``` -### Endpoint Responses +### 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 -Calls to authenticated endpoints may result 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. -* 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. +| 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/articles/appliance/monitoring/index.md b/articles/appliance/monitoring/index.md index 04b246f51c..a7f8f588d9 100644 --- a/articles/appliance/monitoring/index.md +++ b/articles/appliance/monitoring/index.md @@ -1,18 +1,77 @@ --- url: /appliance/monitoring section: appliance -description: Ways to monitor the Appliance +description: Ways to monitor the PSaaS Appliance +topics: + - appliance + - monitoring +contentType: +- index +- concept +useCase: appliance +applianceId: appliance48 +sitemap: false --- -# Monitoring the Appliance +# Monitoring the Private SaaS (PSaaS) Appliance -In addition to providing tools for monitoring your Appliance instances, 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 Appliance instances, you can gather and visualize data about your infrastructure and processes -* **Health Checks**: [Health Checks](/appliance/dashboard/troubleshoot#health-check) provide minute-by-minute summaries of your 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 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 New Relic**: Auth0 supports integration with New Relic as a means of monitoring your Appliance instances. You will need to [provide your New Relic license key](/appliance/dashboard/settings#monitoring) in the Appliance configuration area; -* **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). +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 4658762666..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 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,12 +33,16 @@ 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 -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 client applications. All configuration information is continuously replicated across 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. -> 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. +::: 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/articles/appliance/private-cloud-requirements.md b/articles/appliance/private-cloud-requirements.md index b3df3f4ba9..58a4f080df 100644 --- a/articles/appliance/private-cloud-requirements.md +++ b/articles/appliance/private-cloud-requirements.md @@ -1,20 +1,130 @@ --- section: appliance -description: > - If you have decided to purchase an Appliance that is hosted in a dedicated area of Auth0's cloud, Auth0 will set up the Appliance on your behalf. This document describes the necessary information. +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 -# Information Requirements for Setting Up the Appliance in Auth0's Private Cloud +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. -If you have decided to purchase an Appliance that is hosted in a dedicated area of Auth0's cloud, Auth0 will set up the Appliance on your behalf. To do so, Auth0 asks that you provide the following information: +## Support -* **Preferred AWS region** such as AWS US-West-2, AWS US-East-1, AWS EU-Central-1, etc; -* **Six (6) DNS names**: - * Three (3) will be used for the non-Production node, and three (3) will be used for the Production cluster; - * **Important**: Please finalize DNS names prior to Appliance deployment. -* **SMTP Settings** (including the hostname, port number, username, and password). Auth0 will work with you to enter your settings. For additional details, please see the [SMTP section of the Appliance infrastructure manual](/appliance/infrastructure/security#smtp). +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. -## Further Reading +In general, the tenant name you'll use for support is formatted as follows: **customer_name**-support -* [DNS](/appliance/infrastructure/dns) -* [DNS Records](/appliance/infrastructure/network#dns-records) +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/articles/appliance/raci.md b/articles/appliance/raci.md index a748555f72..4d86c2fe93 100644 --- a/articles/appliance/raci.md +++ b/articles/appliance/raci.md @@ -1,11 +1,18 @@ --- section: appliance -description: This document details who is responsible for what aspects of a given Appliance installation. +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 --- -# Auth0 Appliance: Roles and Responsibilities +# PSaaS Appliance: Roles and Responsibilities -The Auth0 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 Appliance provides the packaging and services required to run the Auth0 code base in a third-party environment. +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 @@ -15,7 +22,7 @@ The Auth0 Appliance is a managed service that is used if your organization's com * General maintenance; * Installation of patches/updates. -The **subscriber** is responsible for supplying and monitoring the infrastructure on which the Appliance runs. This includes, but is not limited to: +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; @@ -33,30 +40,25 @@ The following RACI Matrix provides a more in-depth summary of the roles and resp * **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 -|Appliance-Related Tasks or Deliverables|Auth0|Subscriber|Notes| +|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 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 Appliance monitoring, backup, and updates, as well as answer questions.| -|Monitoring|I|R, A|The subscriber is responsible for [monitoring the Appliance](/appliance/monitoring).| -|Backing Up|I (in the event that there are issues)|R, A|The subscriber is responsible for [backing up the Appliance](/appliance/disaster-recovery) using the [Command-Line Tools](/appliance/cli).| +|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 Customer Success Engineers will partner with the subscriber's infrastructure engineers to update the Appliance on an agreed-upon basis. The subscriber is responsible for: taking VM snapshot(s) prior to the update, providing access to the Appliance, being present as the 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 Appliance after the Development node has been updated and inform Auth0 about any issues.| +|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 Appliance. Auth0 will *consult* on issues pertaining to integration between Auth0 APIs and Dashboards.| +|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.| -## Further Reading - -For more information about the Appliance, see: +### Keep Reading * [Overview](/appliance/appliance-overview ) * [Infrastructure](/appliance/infrastructure) -* [Dashboard](/appliance/dashboard) -* [Monitoring](/appliance/monitoring) * [Disaster Recovery](/appliance/disaster-recovery) -* [Command-Line Interface (CLI)](/appliance/cli) * [Enterprise Support](/onboarding/enterprise-support) * [Critical Support Issues Guidance](/appliance/critical-issue) diff --git a/articles/appliance/remote-access-options.md b/articles/appliance/remote-access-options.md new file mode 100644 index 0000000000..586fd59a1f --- /dev/null +++ b/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/articles/appliance/webtasks.md b/articles/appliance/webtasks.md deleted file mode 100644 index b0bbeaa864..0000000000 --- a/articles/appliance/webtasks.md +++ /dev/null @@ -1,124 +0,0 @@ ---- -url: /appliance/webtasks -section: appliance -description: How to use Webtasks on the Appliance ---- - -# Auth0 Appliance: Webtasks - -Beginning with Build 7247, you may use the Appliance's version of [Webtasks](http://webtask.io/) to execute your rules and custom database logic. - -::: panel-info Prerequisites -Prior to working with Webtasks, please ensure that you have configured the: - -* [Appliance Command Line Interface (CLI)](/appliance/cli/configure-cli); -* [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. - -## 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 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://tehsis.github.io/webtaskio-canirequire/) are available for the Appliance. - -To see which modules are available for Webtasks running on 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 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: - -```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) - }); -}; -``` - -Afterwards, 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. - -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"}, - ... - ] -} -``` - -## Further Reading - -* [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) diff --git a/articles/appliance/webtasks/dedicated-domains.md b/articles/appliance/webtasks/dedicated-domains.md new file mode 100644 index 0000000000..11bbe60ff3 --- /dev/null +++ b/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/articles/appliance/webtasks/index.md b/articles/appliance/webtasks/index.md new file mode 100644 index 0000000000..c390c9c027 --- /dev/null +++ b/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/articles/application-auth/current/client-side-web.md b/articles/application-auth/current/client-side-web.md new file mode 100644 index 0000000000..8d504faa5c --- /dev/null +++ b/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/articles/application-auth/current/index.md b/articles/application-auth/current/index.md new file mode 100644 index 0000000000..685c9b3586 --- /dev/null +++ b/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/articles/application-auth/current/mobile-desktop.md b/articles/application-auth/current/mobile-desktop.md new file mode 100644 index 0000000000..183b936bb5 --- /dev/null +++ b/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/articles/application-auth/current/server-side-web.md b/articles/application-auth/current/server-side-web.md new file mode 100644 index 0000000000..026aa3dab9 --- /dev/null +++ b/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/articles/application-auth/index.yml b/articles/application-auth/index.yml new file mode 100644 index 0000000000..2132d215a0 --- /dev/null +++ b/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/articles/application-auth/legacy/client-side-web.md b/articles/application-auth/legacy/client-side-web.md new file mode 100644 index 0000000000..da677b5d3a --- /dev/null +++ b/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/articles/application-auth/legacy/index.md b/articles/application-auth/legacy/index.md new file mode 100644 index 0000000000..56a74c0a5b --- /dev/null +++ b/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/articles/application-auth/legacy/mobile-desktop.md b/articles/application-auth/legacy/mobile-desktop.md new file mode 100644 index 0000000000..04b9497aee --- /dev/null +++ b/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/articles/application-auth/legacy/server-side-web.md b/articles/application-auth/legacy/server-side-web.md new file mode 100644 index 0000000000..5cb0b0ac58 --- /dev/null +++ b/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/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 new file mode 100644 index 0000000000..f86aa43c4a --- /dev/null +++ b/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/articles/applications/application-settings/_settings-pt2.md b/articles/applications/application-settings/_settings-pt2.md new file mode 100644 index 0000000000..cbd497d7b3 --- /dev/null +++ b/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/articles/applications/application-settings/_settings.md b/articles/applications/application-settings/_settings.md new file mode 100644 index 0000000000..7a276d13d1 --- /dev/null +++ b/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/articles/applications/application-settings/_token-endpoint-auth-method.md b/articles/applications/application-settings/_token-endpoint-auth-method.md new file mode 100644 index 0000000000..be1b5f2d98 --- /dev/null +++ b/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/articles/applications/application-settings/_trust-token-endpoint-ip-header.md b/articles/applications/application-settings/_trust-token-endpoint-ip-header.md new file mode 100644 index 0000000000..9f1da28c81 --- /dev/null +++ b/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/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/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/index.md b/articles/applications/index.md new file mode 100644 index 0000000000..2f3bf9a89a --- /dev/null +++ b/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/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 new file mode 100644 index 0000000000..7c95f9b91b --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_api-configure-scopes.md b/articles/architecture-scenarios/_includes/_api-configure-scopes.md new file mode 100644 index 0000000000..148a374c9a --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_api-implement.md b/articles/architecture-scenarios/_includes/_api-implement.md new file mode 100644 index 0000000000..3a217a0af4 --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_api-overview-of-solution.md b/articles/architecture-scenarios/_includes/_api-overview-of-solution.md new file mode 100644 index 0000000000..0ba99615fc --- /dev/null +++ b/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/articles/architecture-scenarios/_includes/_api-signing-algorithms.md b/articles/architecture-scenarios/_includes/_api-signing-algorithms.md new file mode 100644 index 0000000000..26c06a5eaf --- /dev/null +++ b/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/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.md b/articles/architecture-scenarios/application/mobile-api.md deleted file mode 100644 index b37b604a9c..0000000000 --- a/articles/architecture-scenarios/application/mobile-api.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -order: 02 -title: Mobile + API -image: /media/articles/architecture-scenarios/mobile-api.png -extract: Mobile Application ("Client") which talks to an API ("Resource Server"). 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 client communicating with an API. ---- - -# Mobile + API - -![Mobile + API Flow](/media/articles/architecture-scenarios/mobile-api.png) - -In this scenario you have a mobile application ("Client") which talks to an API ("Resource Server"). The application will use **OpenID Connect** with the **Authorization Code Grant using Proof Key for Code Exchange (PKCE)** to authenticate users. Note that this flow can only be used for Clients whose type is **Native** in the [Dashboard](${manage_url}). - -When a user logs in, Auth0 will return to the application an `access_token`, an `id_token`, and optionally a `refresh_token`: - -- The `access_token` is used to securely call the API on behalf of the user. - -- The `id_token` is consumed only by the client and contains user profile data. Alternatively the user profile can be obtained by calling the `/userinfo` endpoint in the Auth0 Authentication API with the `access_token`. - -- The `refresh_token` can be used in order to obtain a new `access_token` whenever a previous one expires. Note that a `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](${manage_url}). - -The application will usually store the information about the user's session (i.e. whether they are logged in, their tokens, user profile data, and so forth) inside some sort of Local Storage on the mobile device. - -## Read More - -The following is a list of articles on this website which will help you to implement this scenario: - -* [Configuring your tenant for API Authorization](/api-auth/tutorials/configuring-tenant-for-api-auth) -* [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) -* [Native Apps Quickstarts](/quickstart/native/) -* [Lock for iOS and OS X](/libraries/lock-ios) -* [Lock for Android](/libraries/lock-android) diff --git a/articles/architecture-scenarios/application/server-api.md b/articles/architecture-scenarios/application/server-api.md deleted file mode 100644 index 26fc22f022..0000000000 --- a/articles/architecture-scenarios/application/server-api.md +++ /dev/null @@ -1,295 +0,0 @@ ---- -order: 03 -title: Server Client + API -image: /media/articles/architecture-scenarios/server-api.png -extract: Server to server communication where a server “Client” needs to make secure calls to an API (“Resource Server”), but on behalf of the client 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 client vs. a user. -toc: true ---- - -# Server + API - -In this scenario we will build a Timesheet API for a fictitious company named ABC Inc. 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. - -## The Premise - -ABC Inc. 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 ABC's backend using an API. - -### Goals & Requirements - -ABC 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 clients, 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 clients as well. They want to put in place a security architecture that is flexible enough to accommodate this. ABC Inc. wants to ensure that a large part of the code and business logic for the application can be shared across the different client applications. - -It is required that only authorized users and applications are allowed access to the Timesheets API. - -## Overview of the Solution - - In order to ensure that only authorized users and applications are allowed access to the Timesheets API, ABC Inc. 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 application which need to communicate with the Timesheets API. - -### 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 make 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. - -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 query the `scope` claim to ensure that the required permissions were granted in order to call the particular API endpoint. - -::: panel-info What is an Access Token? -An access token (also referred to as `access_token`) is an opaque string representing an authorization issued to the client. It may denote an identifier used to retrieve the authorization information or may self-contain the authorization information (e.g. the user's identity, permissions, etc.) in a verifiable manner. - -It is quite common for access tokens to be implemented as [JSON Web Tokens](/jwt). -::: - -::: panel-info 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. -::: - -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. - -#### Participants - -Several participants in the OAuth 2.0 specification can be identified: - -- **Authorization Server**: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization. In this case the authorization server is Auth0. -- **Resource Servers**: The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens. In this case the resource server is the Timesheet API. -- **Clients**: An application making protected resource requests on behalf of the resource owner and with its authorization. -- **Resource Owner**: An entity capable of granting access to a protected resource when the resource owner is a person, it is referred to as an end-user. - -Using different grants types (or flows), these participants will interact to grant Clients limited access to the Resource Servers you are building. As a result, the Client will obtain an `access_token` that can be used to call the Resource Server on behalf of the user or of the Client itself. - -### 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 now 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 client (i.e. the cron job) makes calls to the Resource Server (i.e. 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)) a Client 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 Client itself. - -![Client Credentials Grant Flow](/media/articles/architecture-scenarios/server-api/client-credentials-grant.png) - -1. The Client 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 Client can use the `access_token` to call the Resource Server on behalf of itself. - - -## Auth0 Configuration - -In this section we will review all the configurations we need to apply using the [Auth0 Dashboard](${manage_url}). - -### Configure the API - -If this is the first time you create an API in Auth0, you will have to enable the API functionality first. Navigate to your [Account Advanced Settings](${manage_url}/#/account/advanced) and scroll down to the **Settings** section.Ensure that the **Enable APIs Section** is switched on. - -![Enable APIs Section](/media/articles/architecture-scenarios/server-api/enable-apis-section.png) - -Next, you can 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. - -> 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 client has been created you will need to configure the Scopes which clients 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 `read:timesheets`, `create:timesheets`, `delete:timesheets`, `approve:timesheets`. - -> For the purposes of this document we will only be ever concerned with the `create:timesheets` 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 clients as well. - -![Add Scopes](/media/articles/architecture-scenarios/server-api/add-scopes.png) - -### Create the Client - -When creating an API in the Auth0 Dashboard, a test client for the API will automatically be generated. In the Auth0 Dashboard, navigate to the [Client Section](${manage_url}/#/clients) and you will see the test client for the Timesheets API. - -![Non Interactive Client](/media/articles/architecture-scenarios/server-api/non-interactive-client.png) - -Go to the settings for the client by clicking on the gear icon, and rename the client to `Timesheets import Job`. - -For the cron job you will need a Non-Interactive client. This test client which was generated when the API was created was automatically configured as a Non-Interactive client as can be seen in the screenshot below. - -![Non Interactive Client Settings](/media/articles/architecture-scenarios/server-api/non-interactive-client-settings.png) - -### Configure Client's access to the API - -The final part of the Auth0 configuration is to allow the client access to the Timesheets API. Go back to the configuration of the API, and select the *Non-interactive Clients* tab. - -You will see the **Timesheets Import Job** client listed, and it should have access to API as can be seen from the switch to the right of the client name which indicates a value of `Authorized`. If it does not indicate that the client is authorized, simply toggle the value of the switch from `Unauthorized` to `Authorized`. - -![Authorize Client](/media/articles/architecture-scenarios/server-api/authorize-client.png) - -You will also need to specify which scopes will included in access tokens which are issued to the client when the client authorizes with Auth0. - -Expand the settings for the client 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 `create:timesheets` scope as it will simply create new timesheets based on the timesheet entries in the external system. - -Once you have selected the `create:timesheets` 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! - -## Inside the Implementation - -### Implement the API - -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-info 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 client 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. -::: - -We will configure one single endpoint that will be used for creating timesheet entries. The endpoint will be `/timesheets` 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_type': 'Employee', - 'user_id': '007', - 'year': 2016, - 'week': 24, - 'project': 'StoreZero', - 'hours': 40 -} -``` - -The API will print the JSON, so we can verify the contents and echo back a message like the following: `Timesheet created for Employee: 007`. - -**See the implementation in [Node.js](/architecture-scenarios/application/server-api/api-implementation-nodejs#define-the-api-endpoints)**. - -#### 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 a `Missing or invalid token` error message to the calling process. - -**See the implementation in [Node.js](/architecture-scenarios/application/server-api/api-implementation-nodejs#secure-the-api-endpoints)**. - -##### Get an Access Token - -To get an access token without using our Client 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}" -} -``` - -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 Client 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 `create:timesheets`. - -**See the implementation in [Node.js](/architecture-scenarios/application/server-api/api-implementation-nodejs#check-the-client-permissions)**. - -### Implement the Non Interactive Client - -In this section we will see how we can implement a Non Interactive Client for our scenario. - -**NOTE**: For simplicity reasons we will keep our implementations solely focused on the authentication and authorization part and configure our client 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 Client at the [Auth0 Dashboard](${manage_url}/#/clients). 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 Client's Id. You can retrieve it from the *Settings* of your Client at the [Auth0 Dashboard](${manage_url}/#/clients). - -- **Client Secret**: The value of your Auth0 Client's Secret. You can retrieve it from the *Settings* of your Client at the [Auth0 Dashboard](${manage_url}/#/clients). - -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). - -**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). - -**See the implementation in [Python](/architecture-scenarios/application/server-api/cron-implementation-python#invoke-the-api).** - -## Conclusion - -In this document we covered a simple scenario: an API, used to import timesheet entries in ABC'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 non interactive client 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. - -Don't forget to check back for new business cases and more complex architecture scenarios! diff --git a/articles/architecture-scenarios/application/spa-api.md b/articles/architecture-scenarios/application/spa-api.md deleted file mode 100644 index de028b8a15..0000000000 --- a/articles/architecture-scenarios/application/spa-api.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -order: 01 -title: SPA + API -image: /media/articles/architecture-scenarios/spa-api.png -extract: Single Page Web Application "Client" which talks to an API ("Resource Server"). The application will use OpenID Connect with the Implicit Grant Flow to authenticate users with Auth0. -description: Explains the architecture scenario with a Single Page Web Application to an API using OpenID Connect with the Implicit Grant Flow to authenticate users with Auth0. ---- - -# SPA + API - -![SPA + API Flow](/media/articles/architecture-scenarios/spa-api.png) - -In this scenario you have a Single Page Web Application ("Client") which talks to an API ("Resource Server"). The application will use **OpenID Connect** with the **Implicit Grant Flow** to authenticate users with Auth0. Note that this flow can only be used for Clients whose type is **Single Page Application** in the [Dashboard](${manage_url}). - -When a user logs in, Auth0 will return to the application an `access_token` and an `id_token`. In case the `response_type` value used is `id_token` then only an `id_token` will be returned. - -- The `access_token` is used to securely call the API on behalf of the user. - -- The `id_token` is consumed only by the client and contains user profile data. Alternatively the user profile can be obtained by calling the `/userinfo` endpoint in the Auth0 Authentication API with the `access_token`. In order for this to work `openid` should be granted as a scope. - -The application will usually store the information about the user's session (i.e. whether they are logged in, their tokens, user profile data, and so forth) inside some sort of storage such a Local Storage. - -## Read More - -The following is a list of articles on this website which will help you to implement this scenario: - -* [Configuring your tenant for API Authorization](/api-auth/tutorials/configuring-tenant-for-api-auth) -* [Calling APIs from Client-side Web Apps](/api-auth/grant/implicit) -* [Executing the Implicit Grant Flow](/api-auth/tutorials/implicit-grant) -* [Mitigating replay attacks when using the implicit grant](/api-auth/tutorials/nonce) -* [Single Page App Quickstarts](/quickstart/spa/) -* [Lock](/libraries/lock) diff --git a/articles/architecture-scenarios/application/web-app-sso.md b/articles/architecture-scenarios/application/web-app-sso.md deleted file mode 100644 index f92deaedd5..0000000000 --- a/articles/architecture-scenarios/application/web-app-sso.md +++ /dev/null @@ -1,399 +0,0 @@ ---- -order: 04 -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 ABC Inc. The app is meant to be used by ABC's employees and contractors. Employees will use their existing corporate directory (Active Directory), while contractors will be managed in a separate user store. - -::: panel-info 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 - -ABC Inc. 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 - -ABC Inc. 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-info Authentication vs Authorization -ABC 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. -::: - -ABC'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 client 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 client 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 ABC's corporate directory. - -ABC 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) - -## Overview of the solution - -### Identity Management - -ABC 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. - -::: panel-info Identity-as-Service -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. - -::: panel-info Supported identity protocols -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-info 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 client) 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, ABC 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 Client 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 __Client__, along with an _authorization code_ in the querystring. -1. The Client sends the _authorization code_ to Auth0, along with the client credentials (`client_id` and `client_secret`), and asks for a token. -1. Auth0 authenticates the __Client__ (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-info 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 client and used to get user information like the user's name, email, and so forth, typically used for UI display. - -::: panel-info 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 Client 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 Client's `client_id` value. The ID Token must be rejected if the ID Token does not list the Client as a valid audience, or if it contains additional audiences not trusted by the Client. -1. If the ID Token contains multiple audiences, the Client should verify that an `azp` claim is present. -1. If an `azp` (authorized party) claim is present, the Client should verify that its `client_id` is the claim value. -1. The Client must validate the signature of ID Tokens according to JWS using the algorithm specified in the JWT `alg` header parameter. The Client must use the keys provided by the Issuer. -1. The `alg` value should be the default of `RS256` or the algorithm sent by the Client 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 Client 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 Client should check the `nonce` value for replay attacks. The precise method for detecting replay attacks is Client specific. -1. If the `acr` claim was requested, the Client 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 Client 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 that if you store ID tokens on your server, you must store them securely. - -## Auth0 Configuration - -In this section we will review all the configurations we need to apply using the [Auth0 Dashboard](${manage_url}). - -### Client - -The Auth0 configuration part starts with registering the timesheets app at the Auth0 dashboard as a __client__. A client is an application making protected resource requests on behalf of the resource owner (end-user). - -::: panel-info NOTE -The term "client" does not imply any particular implementation characteristics. A client can be a web app, a mobile app or an SPA. In the case of ABC it is a ASP.NET Core web app. -::: - -The main characteristics of a Client in Auth0 are: -- __Name__: The canonical name of the client. This is used to identify the client at the portal, emails, logs, and more. -- __Client ID__ (read-only): The unique identifier for the client. 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 `abc.auth0.com`. -- __Callback URL__: The URL where the user is redirected after they authenticate. - -#### Create a Client - -ABC's scenario involves only one application: the timesheets web app. Hence we have to configure one Client at Auth0 side. - -To register a database connection, go to the [dashboard](${manage_url}) and in the side navigation select [Clients](${manage_url}/#/clients). - -Click on the button __+ Create Client__. You will be prompted for the name and the type of the client. We will name our client `Timesheet-App` and select `Regular Web Applications` as the client type. - -![Create Client 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}/#/clients/${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}/#/clients/${account.clientId}/settings): Here you can view and update the settings of your client. 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 client](#configure-callback-urls). -- [Addons](${manage_url}/#/clients/${account.clientId}/addons): Addons are plugins associated with a client in Auth0. Usually, they are third party APIs used by the client 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}/#/clients/${account.clientId}/connections): Connections are sources of users. We will use this view shortly to enable specific connections for our client. - -#### 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 client needs at least one connection, and each connection can be used for more than one client. - -ABC needs to configure two connections: one Active Directory connection for the internal employees, and one Database connection for external parties. - -::: panel-info 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 client to use this connection at the _Clients Using This Connection_ section. - -![Enable the client 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) - -::: panel-info AD/LDAP Connector -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 client to use this AD / LDAP connection: - -![Enable the client to use this AD connection](/media/articles/architecture-scenarios/web-app-sso/enable-client-ad.png) - -::: panel-info 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! - -## Inside the 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-info 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-info 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-info NOTE -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 (i.e. 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. - -**See the implementation in [ASP.NET Core](/architecture-scenarios/application/web-app-sso/implementation-aspnetcore#implement-admin-permissions)**. - -## Conclusion - -In this document 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 clients 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. - -Don't forget to check back for new business cases and more complex architecture scenarios! diff --git a/articles/architecture-scenarios/application/web-saml.md b/articles/architecture-scenarios/application/web-saml.md deleted file mode 100644 index 061bc44531..0000000000 --- a/articles/architecture-scenarios/application/web-saml.md +++ /dev/null @@ -1,22 +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. ---- - -# Regular Web App (using SAML) - -![](/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 Client. The Client 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 06804be4ea..0000000000 --- a/articles/architecture-scenarios/business/b2b-b2e.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -order: 04 -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. ---- - -# Business to Business + Enterprise Identity Scenarios - -![](/media/articles/architecture-scenarios/b2b-b2e.png) - -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. But you also have internal users (employees) who also log into the application, usually to 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) -* [Identity Protocols supported by Auth0](/protocols) -* [Integrating a Web App with Auth0](/oauth-web-protocol) -* [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 2072ba773b..0000000000 --- a/articles/architecture-scenarios/business/b2b.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -order: 02 -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. ---- - -# Business to Business Identity Scenarios - -![](/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) -* [Identity Protocols supported by Auth0](/protocols) -* [Integrating a Web App with Auth0](/oauth-web-protocol) -* [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 c4b4efed5f..0000000000 --- a/articles/architecture-scenarios/business/b2c.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -order: 01 -title: Business to Consumer Idenity 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. ---- - -# Business to Consumer Idenity Scenarios - -![](/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, etc 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) -* [Identity Protocols supported by Auth0](/protocols) -* [Integrating a Web App with Auth0](/oauth-web-protocol) -* [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 1e0c9d0152..0000000000 --- a/articles/architecture-scenarios/business/b2e.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -order: 03 -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. ---- - -# Business to Enterprise Identity Scenarios - -![](/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) -* [Identity Protocols supported by Auth0](/protocols) -* [Integrating a Web App with Auth0](/oauth-web-protocol) -* [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/server-api/api-implementation-nodejs.md b/articles/architecture-scenarios/implementations/server-api/api-implementation-nodejs.md deleted file mode 100644 index ecaafc6d46..0000000000 --- a/articles/architecture-scenarios/implementations/server-api/api-implementation-nodejs.md +++ /dev/null @@ -1,215 +0,0 @@ ---- -title: "Server Client + API: Node.js Implementation for the API" -description: The Node.js implementation of the API for the Server Client + API architecture scenario -url: /architecture-scenarios/application/server-api/api-implementation-nodejs ---- - -# Server Client + API: Node.js Implementation for the API - -::: panel-info Server + API Architecture Scenario -This document is part of the [Server + API Architecture Scenario](/architecture-scenarios/application/server-api) and it explains how to implement the API in Node.js. Please refer to the [Server + API Architecture Scenario](/architecture-scenarios/application/server-api) document for information on the implemented solution. -::: - -Full source code for the Node.js API implementation can be found in [this GitHub repository](https://github.com/auth0-samples/auth0-pnp-abc-timesheets/tree/master/timesheets-api/node). - -## 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" -} -``` - -### Set 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/). - -- **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 express-jwt jwks-rsa body-parser --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 -// set dependencies -const Express = require('express'); -const jwt = require('express-jwt'); -const jwksRsa = require('jwks-rsa'); -const bodyParser = require('body-parser'); - -// Initialize the app -const app = new Express(); - -// create timesheets API endpoint -app.post('/timesheet', function(req, res){ - res.status(201).send({message:”This is the POST /timesheet endpoint”}); -}) - -// launch the API Server at localhost:8080 -app.listen(8080); -``` - -Launch your API server using `node server` and navigate to `localhost:8080/timesheet`. You should see a JSON response with the `This is the POST /timesheet endpoint` message. - -So now we have our endpoint but anyone can call it. Continue to the next paragraph to see how we can fix this. - -## 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. -- If the validation fails return an appropriate error message. - -This is our sample implementation (some code is omitted for brevity): - -```js -// set dependencies - code omitted - -// Initialize the app - code omitted - -// validate the access token and enable the use of the jwtCheck middleware -app.use(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://{YOUR_AUTH0_DOMAIN}/.well-known/jwks.json` - }), - - - // Validate the audience and the issuer - audience: '{YOUR_API_IDENTIFIER}', - issuer: 'https://{YOUR_AUTH0_DOMAIN}/', - algorithms: [ 'RS256' ] -})); - -// return error message for unauthorized requests -app.use(function (err, req, res, next) { - if (err.name === 'UnauthorizedError') { - res.status(401).json({message:'Missing or invalid token'}); - } -}); - -// create timesheets API endpoint - code omitted - -// launch the API Server at localhost:8080 - code omitted -``` - -If we launch our server now and navigate to `localhost:8080/timesheet` 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). - -## Check the Client permissions - -In this step we will add to our implementation the ability to check if the client has permissions to use our endpoint in order to create a timesheet. We will look at the decoded JWT and see if the token has the correct scope, which is `create:timesheets`. If it doesn’t we will send an appropriate message, otherwise we will retrieve some of the request info and echo back the successful result. - - -This is our sample implementation (some code is omitted for brevity): - -```js -// set dependencies - code omitted - -// Initialize the app - code omitted - -// validate the access token and enable the use of the jwtCheck middleware - code omitted - -//middleware to check scopes -const checkPermissions = function(req, res, next){ - switch(req.path){ - case '/timesheet':{ - var permissions = ['create:timesheets']; - for(var i = 0; i < permissions.length; i++){ - if(req.user.scope.includes(permissions[i])){ - next(); - } else { - res.status(403).send({message:'Forbidden'}); - } - } - break; - } - } -} - -// enable the use of the jwtCheck middleware - code omitted - -//enable the use of the checkPermissions middleware -app.use(checkPermissions); - -// enable the use of request body parsing middleware -app.use(bodyParser.json()); -app.use(bodyParser.urlencoded({ - extended: true -})); - -// return error message for unauthorized requests - code omitted - -// create timesheets API endpoint -app.post('/timesheet', function(req, res){ - //print the posted data - console.log(JSON.stringify(req.body, null, 2)); - - //send the response - res.status(201).send({message:"Timesheet created for " + req.body.user_type + ": " + req.body.user_id}); -}) - -// 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. - -That's it! You are done! diff --git a/articles/architecture-scenarios/implementations/server-api/cron-implementation-python.md b/articles/architecture-scenarios/implementations/server-api/cron-implementation-python.md deleted file mode 100644 index 24d9765bab..0000000000 --- a/articles/architecture-scenarios/implementations/server-api/cron-implementation-python.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: "Server Client + API: Python Implementation for the Cron Job" -description: The Python implementation of the server cron job for the Server Client + API architecture scenario -url: /architecture-scenarios/application/server-api/cron-implementation-python ---- - -# Server Client + API: Python Implementation for the Cron Job - -::: panel-info Server + API Architecture Scenario -This document is part of the [Server + API Architecture Scenario](/architecture-scenarios/application/server-api) and it explains how to implement the server process in Python. Please refer to the [Server + API Architecture Scenario](/architecture-scenarios/application/server-api) document for information on the implemented solution. -::: - -Full source code for the Python implementation of the server process can be found in [this GitHub repository](https://github.com/auth0-samples/auth0-pnp-abc-timesheets/tree/master/timesheets-cron/python). - -## Get an Access Token - -In order to make the HTTP request to the Auth0 `/oauth/token` API endpoint we will use the libraries `json`, `urllib` and `urllib2`. - -This is our sample implementation: - -```python -def main(): - import json, urllib, urllib2 - - # Configuration Values - DOMAIN = "${account.namespace}" - AUDIENCE = "YOUR_API_IDENTIFIER" - CLIENT_ID = "${account.clientId}" - CLIENT_SECRET = "${account.clientSecret}" - API_URL = "http://localhost:8080/timesheet" - 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'] - -# Standard boilerplate to call the main() function. -if __name__ == '__main__': - main() -``` - -To test this modify your code to print the `access_token` variable and run the process using `python cron.py`. - -## Invoke the API - -The steps we follow in our implementation are: -- Build a JSON object containing timesheet data and assign it to a `timesheet` variable. -- Add the API URL and the `timesheet` variable contents to the request body using `urllib2.Request`. -- Add the `Authorization` header to the request. -- Set the `Content-Type` header to `application/json`. -- Invoke the API using `urllib2.urlopen` and add some error handling. -Retrieve the response using `json.loads` and print it in the console. - -This is our sample implementation (some code is omitted for brevity): - -```python -def main(): - # import libraries - code omitted - - # Configuration Values - code omitted - - # Get an access token from Auth0 - code omitted - - #Post new timesheet to API - timesheet = {'user_type': 'Employee', - 'user_id': '007', - 'year': 2016, - 'week': 24, - 'project': 'StoreZero', - 'hours': 40} - req = urllib2.Request(API_URL, data = json.dumps(timesheet)) - 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['message'] - 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 - code omitted -``` - -To test this make sure your API is running and run the process using `python cron.py`. - -That's it! You are done! diff --git a/articles/architecture-scenarios/implementations/web-app-sso/implementation-aspnetcore.md b/articles/architecture-scenarios/implementations/web-app-sso/implementation-aspnetcore.md deleted file mode 100644 index 795897393e..0000000000 --- a/articles/architecture-scenarios/implementations/web-app-sso/implementation-aspnetcore.md +++ /dev/null @@ -1,177 +0,0 @@ ---- -title: "SSO for Regular Web Apps: ASP.NET Core Implementation" -description: The ASP.NET Core implementation for the SSO for Regular Web Apps architecture scenario -url: /architecture-scenarios/application/web-app-sso/implementation-aspnetcore ---- - -# SSO for Regular Web Apps: ASP.NET Core implementation - -Full source code for the ASP.NET Core implementation can be found in [this GitHub repository](https://github.com/auth0-samples/auth0-pnp-webapp-oidc). - -## Configure the Cookie and OIDC Middleware - -For the purposes this guide we will be using a simple hosted login. You can use the standard cookie and OIDC middleware which is available with ASP.NET Core, so ensure that you install the NuGet packages. - -```text -Install-Package Microsoft.AspNetCore.Authentication.Cookies -Install-Package Microsoft.AspNetCore.Authentication.OpenIdConnect -``` - -Then configure the cookie and OIDC middleware inside your application's middleware pipeline. - -```csharp -public class Startup -{ - public void ConfigureServices(IServiceCollection services) - { - // Add authentication services - services.AddAuthentication( - options => options.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme); - - // Code omitted for brevity... - } - - public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory, IOptions auth0Settings) - { - // Code omitted for brevity... - - // Add the cookie middleware - app.UseCookieAuthentication(new CookieAuthenticationOptions - { - AutomaticAuthenticate = true, - AutomaticChallenge = true - }); - - // Add the OIDC middleware - app.UseOpenIdConnectAuthentication(new OpenIdConnectOptions("Auth0") - { - // Set the authority to your Auth0 domain - Authority = "https://${account.namespace}/", - - // Configure the Auth0 Client ID and Client Secret - ClientId = ${account.clientId}, - ClientSecret = ${account.clientSecret}, - - // Do not automatically authenticate and challenge - AutomaticAuthenticate = false, - AutomaticChallenge = false, - - // Set response type to code - ResponseType = "code", - - CallbackPath = new PathString("/signin-auth0"), - - // Configure the Claims Issuer to be Auth0 - ClaimsIssuer = "Auth0" - }); - - // Code omitted for brevity... - } -} -``` - -As you can see in the code above, we have configured two different types of authentication middleware. - -The first is the cookie middleware which was registered with the call to `UseCookieAuthentication`. -The second is the OIDC middleware which is done with the call to `UseOpenIdConnectAuthentication`. - -Once the user has signed in to Auth0 using the OIDC middleware, their information will automatically be stored inside a session cookie. All you need to do is to configure the middleware as above and it will take care of managing the user session. - -The OpenID Connect middleware will also extract all the claims from the `id_token`, which is sent from Auth0 once the user has authenticated, and add them as claims on the `ClaimsIdentity`. - -## Implement the Logout - -You can control both the application session and the Auth0 session using the `SignOutAsync` method of the `AuthenticationManager` class, and passing along the authentication scheme from which you want to sign out. - -As an example to sign out of the cookie middleware, and thereby clearing the authentication cookie for your application, you can make the following call: - -```csharp -await HttpContext.Authentication.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme); -``` - -Similarly you can log the user out from Auth0 by making a call to the `SignOutAsync` method and passing along `Auth0` as the authentication scheme to sign out of. - -```csharp -await HttpContext.Authentication.SignOutAsync("Auth0"); -``` - -For the above to work you will however also need to add extra configuration when registering the OIDC middleware by handling the `OnRedirectToIdentityProviderForSignOut` event. Inside the event you will need to redirect to the [Auth0 logout endpoint](/api/authentication/reference#logout) which will clear the Auth0 cookie. - -```csharp -app.UseOpenIdConnectAuthentication(new OpenIdConnectOptions("Auth0") -{ - // Some code omitted for brevity - Events = new OpenIdConnectEvents - { - OnRedirectToIdentityProviderForSignOut = context => - { - context.Response.Redirect($"https://{auth0Settings.Value.Domain}/v2/logout?client_id={auth0Settings.Value.ClientId}&returnTo={context.Request.Scheme}://{context.Request.Host}/"); - context.HandleResponse(); - - return Task.FromResult(0); - } - } -}); -``` - -You will also need to ensure that you add your application's URL to the __Allowed Logout URLs__ for your application inside the Auth0 dashboard. For more information refer to [Logout](/logout). - -## Implement Admin permissions - -The easiest way to integrate the groups into an ASP.NET Core application is to user the built-in [Role based Authorization](https://docs.asp.net/en/latest/security/authorization/roles.html) available in ASP.NET Core. In order to achieve this we will need to add a Claim of type - -```text -http://schemas.microsoft.com/ws/2008/06/identity/claims/role -``` - -for each of the groups a user is assigned to. - -Once the claims has been added we can easily ensure that a specific action is available only to `Admin` users by decorating the claim with the `[Authorize(Roles = "Admin")]` attribute. You can also check whether a user is in a specific role from code by making a call to `User.IsInRole("Admin")` from inside your controller. - -The ASP.NET OIDC middleware will automatically add all claims returned in the JWT as claims to the `ClaimsIdentity`. We would therefore need to extract the information from the `authorization` claim, deserialize the JSON body of the claim, and for each of the groups add a `http://schemas.microsoft.com/ws/2008/06/identity/claims/role` claim to the `ClaimsIdentity`. - -```csharp -app.UseOpenIdConnectAuthentication(new OpenIdConnectOptions("Auth0") -{ - // Some configuration omitted for brevity - - Events = new OpenIdConnectEvents - { - OnTicketReceived = context => - { - var options = context.Options as OpenIdConnectOptions; - - // Get the ClaimsIdentity - var identity = context.Principal.Identity as ClaimsIdentity; - if (identity != null) - { - // Add the groups as roles - var authzClaim = context.Principal.FindFirst(c => c.Type == "authorization"); - if (authzClaim != null) - { - var authorization = JsonConvert.DeserializeObject(authzClaim.Value); - if (authorization != null) - { - foreach (var group in authorization.Groups) - { - identity.AddClaim(new Claim(ClaimTypes.Role, group, ClaimValueTypes.String, options.Authority)); - } - } - } - } - - return Task.FromResult(0); - } - } -}); -``` - -And subsequently we can add an action which allows Administrators to approve timesheets: - -```csharp -[Authorize(Roles = "Admin")] -public IActionResult TimesheetApproval() -{ - return View(); -} -``` diff --git a/articles/architecture-scenarios/index.md b/articles/architecture-scenarios/index.md index 72f8f7f92c..5f1cf6d905 100644 --- a/articles/architecture-scenarios/index.md +++ b/articles/architecture-scenarios/index.md @@ -1,57 +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. +

+
-# Architecture Scenarios - -This page describes the typical architecture scenarios we have identified when working with customers on implementing Auth0. - -The first set, called Application Configurations, describes the typical application implementation patterns. - -The second set, called Business Scenarios, describes the architecture depending on the type of businesses, whether that be B2C (Business to Consumer applications), B2B (Business to Business applications), B2E (Enterprise applications), or a combination of B2B and B2E. -Click on any scenario to get more information. - -
-
-
Application Configurations
-

These scenarios describe the different type of technology architectures you application may use, and how Auth0 can help for each of those

- <% cache.find('articles/architecture-scenarios/application', {sort: 'order'}).forEach(article => { %> - -
-
-
-
-
-

<%- article.title %>

-

<%- article.extract %>

-
-
- Read more -
-
- - <% }); %> -
-
-
Business Scenarios
-

These scenarios describe the type of businesses which implement Auth0, and how Auth0 can help in each of those business scenarios

- <% cache.find('articles/architecture-scenarios/business', {sort: 'order'}).forEach(article => { %> - -
-
-
-
-
-

<%- article.title %>

-

<%- article.extract %>

-
-
- Read more -
-
- - <% }); %> -
-
+## 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/articles/integrations/aws-api-gateway/_stepnav.html b/articles/architecture-scenarios/mobile-api/_stepnav.html similarity index 100% rename from articles/integrations/aws-api-gateway/_stepnav.html rename to articles/architecture-scenarios/mobile-api/_stepnav.html diff --git a/articles/architecture-scenarios/mobile-api/api-implementation-nodejs.md b/articles/architecture-scenarios/mobile-api/api-implementation-nodejs.md new file mode 100644 index 0000000000..7f02afc324 --- /dev/null +++ b/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/articles/architecture-scenarios/mobile-api/index.md b/articles/architecture-scenarios/mobile-api/index.md new file mode 100644 index 0000000000..c96949af52 --- /dev/null +++ b/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/articles/architecture-scenarios/mobile-api/mobile-implementation-android.md b/articles/architecture-scenarios/mobile-api/mobile-implementation-android.md new file mode 100644 index 0000000000..13dabfaf1c --- /dev/null +++ b/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 + + + + + + - - - -``` - -## 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 client. 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 user's access token and ID token are saved into 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 those tokens are found, they are saved into local storage and the user is redirected to the home route. - -```js -import { Injectable } from '@angular/core'; -import { tokenNotExpired } from 'angular2-jwt'; -import { Router } from '@angular/router'; - -// Avoid name not found warnings -declare var auth0: any; - -@Injectable() -export class Auth { - - // Configure Auth0 - auth0 = new auth0.WebAuth({ - domain: '${account.namespace}', - clientID: '${account.clientId}', - // specify your desired callback URL - callbackURL: 'http://localhost:3000', - responseType: 'token id_token' - }); - - constructor(private router: Router) { - } - - public handleAuthentication(): void { - this.auth0.parseHash((err, authResult) => { - if (authResult && authResult.accessToken && authResult.idToken) { - window.location.hash = ''; - localStorage.setItem('access_token', authResult.accessToken); - localStorage.setItem('id_token', authResult.idToken); - this.router.navigate(['/home']); - } else if (authResult && authResult.error) { - alert('Error: ' + authResult.error); - } - }); - } - - 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.idToken && authResult.accessToken) { - this.setUser(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 isAuthenticated(): boolean { - // Check whether the id_token is expired or not - return tokenNotExpired(); - } - - public logout(): void { - // Remove token from localStorage - localStorage.removeItem('access_token'); - localStorage.removeItem('id_token'); - } - - private setUser(authResult): void { - localStorage.setItem('access_token', authResult.accessToken); - localStorage.setItem('id_token', authResult.idToken); - } -} -``` - -The service has several other utility methods that are necessary to complete authentication transactions. - -* The `handleAuthentication` method is necessary for redirect-based authentication transactions which, in this example, include `signup` and `loginWithGoogle`. This method needs to be called when the app starts so that the authentication result (which comes back in the hash of a redirection) is properly handled. -* The `logout` method removes the user's tokens from local storage which effectively logs them out of the application. -* The `setUser` method takes an authentication result object and sets the access token and ID token values into local storage -* The `isAuthenticated` method uses `tokenNotExpired` from angular2-jwt to check for the user's authentication state based on the `id_token`'s expiry time. - -The `handleAuthentication` method needs to be called in the application's root component. - -```js -// ... -export class AppComponent { - constructor(private auth: Auth) { - this.auth.handleAuthentication(); - } -} -``` \ No newline at end of file diff --git a/articles/client-platforms/angular2/03-session-handling.md b/articles/client-platforms/angular2/03-session-handling.md deleted file mode 100644 index 168250c954..0000000000 --- a/articles/client-platforms/angular2/03-session-handling.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: Session Handling -description: This tutorial will show you how to integrate Auth0 with angular2 to add session handling and logout to your web app. -budicon: 280 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs2-systemjs-sample', - path: '03-Session-Handling', - requirements: [ - 'Angular 2.0.1' - ] -}) %> - -In the previous steps of this tutorial, we enabled user login with the `Lock` widget and then with `auth0.js`. - -In this step, we will create a session for the user and also allow them to log out. - -## Create Session - -Once the user is authenticated, we need to create a client-side session for them so that our Angular 2 app knows that they are currently authenticated. To do this, we need to store the value of the `id_token` attribute that is returned in the Lock `authenticated` callback parameter. - -**NOTE**: This example uses `localStorage`, but you can use any storage library. - -```typescript -// auth.service.ts - -@Injectable() -export class Auth { - // Configure Auth0 - lock = new Auth0Lock('${account.clientId}', '${account.namespace}', {}); - - constructor() { - // Add callback for lock `authenticated` event - this.lock.on("authenticated", (authResult) => { - localStorage.setItem('id_token', authResult.idToken); - }); - } - // ... -} -``` - -## Check Session - -To check if a user is authenticated, we can use `tokenNotExpired` from [angular2-jwt](https://github.com/auth0/angular2-jwt) which allows us to check whether the user's JWT is expired or not. Since JWT is a "stateless" manner of doing user authentication, the best way to know if the user should be regarded as authenticated on the front end is to know whether the token is unexpired. - -```typescript -// auth.service.ts - -import { tokenNotExpired } from 'angular2-jwt'; - -// ... -public authenticated() { - // Check if there's an unexpired JWT - // It searches for an item in localStorage with key == 'id_token' by default - return tokenNotExpired(); -} -``` - -To use this service, inject `Auth` into your component: - -```typescript -// app/app.component.ts - -@Component({ - selector: 'my-app', - providers: [ Auth ], - templateUrl: 'app/app.template.html' -}) - -export class AppComponent { - constructor(private auth: Auth) {} -} -``` - -and then use it in your component's template: - -```html - -
- Auth0 - Angular 2 - - -
-``` - -## Logout - -Since authentication with JWT is stateless, the only thing necessary for logging the user out is to remove their token from storage. - -```typescript -// auth.service.ts - -// ... -public logout() { - // Remove token from localStorage - localStorage.removeItem('id_token'); -} -``` diff --git a/articles/client-platforms/angular2/04-user-profile.md b/articles/client-platforms/angular2/04-user-profile.md deleted file mode 100644 index f9ed0fb308..0000000000 --- a/articles/client-platforms/angular2/04-user-profile.md +++ /dev/null @@ -1,243 +0,0 @@ ---- -title: User Profile -description: This tutorial will show you how to integrate Auth0 with Angular2 to authenticate and fetch/show profile information. -budicon: 292 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs2-systemjs-sample', - path: '04-User-Profile', - requirements: [ - 'Angular 2.0.1' - ] -}) %> - -In this step, we will retrieve and display user profile information using the same `Auth` service defined in the [Login](/quickstart/spa/angular2/01-login) tutorial. - -## Profile - -To fetch user profile information, call the `lock.getProfile` function, specifying the `idToken` and a callback to process the response. - -Once the user profile is retrieved, we can store it in `localStorage` (or another form of storage if you prefer) and assign it to a `userProfile` attribute so you can access it later. - -```typescript -// auth.service.ts - -import {Injectable} from '@angular/core'; -import {tokenNotExpired} from 'angular2-jwt'; - -// Avoid name not found warnings -declare var Auth0Lock: any; - -@Injectable() -export class Auth { - // Configure Auth0 - lock = new Auth0Lock('${account.clientId}', '${account.namespace}', {}); - - //Store profile object in auth class - userProfile: Object; - - constructor() { - // Set userProfile attribute of already saved profile - this.userProfile = JSON.parse(localStorage.getItem('profile')); - - // Add callback for the Lock `authenticated` event - this.lock.on("authenticated", (authResult) => { - localStorage.setItem('id_token', authResult.idToken); - - // Fetch profile information - this.lock.getProfile(authResult.idToken, (error, profile) => { - if (error) { - // Handle error - alert(error); - return; - } - - localStorage.setItem('profile', JSON.stringify(profile)); - this.userProfile = profile; - }); - }); - } - - public logout() { - // Remove token and profile from localStorage - localStorage.removeItem('id_token'); - localStorage.removeItem('profile'); - this.userProfile = undefined; - } -} -``` - -To see user profile information, inject the `Auth` service into a component: - -```typescript -// home.component.ts - -export class HomeComponent { - - constructor(private auth: Auth) {} - -} -``` - -Then display the `userProfile` attributes in your component's template: - -```html - - -
-

You are logged in

-
-
-

Profile

- -

Name: {{auth.userProfile.name}}

-

Email: {{auth.userProfile.email}}

-

Nickname: {{auth.userProfile.nickname}}

-

Created At: {{auth.userProfile.created_at}}

-

Updated At: {{auth.userProfile.updated_at}}

-
-
-
-

You are not logged in, please click 'Log in' button to login

-``` - -## Custom Sign Up Fields for Lock - -You can add additional input fields to Lock's sign up form by adding `additionalSignUpFields` to the `options` parameter of the `Auth0Lock` instantiation. - -**NOTE:** See [Additional sign up fields](https://github.com/auth0/lock#additional-sign-up-fields) for more information. - -```typescript -// auth.service.ts - - // Configure Auth0 - lock = new Auth0Lock('${account.clientId}', '${account.namespace}', { - additionalSignUpFields: [{ - name: "address", // required - placeholder: "enter your address", // required - icon: "https://example.com/address_icon.png", // optional - validator: function(value) { // optional - // only accept addresses with more than 10 characters - return value.length > 10; - } - }] - }); -``` - -Each `additionalSignUpFields` value is saved to the profile in the `user_metadata` attribute of the user's Auth0 profile. - -To display this data, read it from the profile's `user_metadata`: - -```html - - Address: {{auth.userProfile.user_metadata.address}} -``` - -## Update the User's Profile - -<%= include('../_includes/_profile-metadata-explanation') %> - -You can add an `address` attribute to the user profile's `user_metadata` by creating a component and a simple form. You will need to call the [Update a user](/api/management/v2#!/Users/patch_users_by_id) endpoint on form-submit. - -To call the endpoint, you can use the [AuthHttp](https://github.com/auth0/angular2-jwt#sending-authenticated-requests) helper from `angular2-jwt` which provides the same interface as the `Http` module but automatically adds the authorization header to requests. - -First, add `AUTH_PROVIDERS` from `angular2-jwt`: - -```typescript -// app/app.module.ts - -import { AUTH_PROVIDERS } from 'angular2-jwt'; -import { AppComponent } from './app.component'; - -@NgModule({ - declarations: [ - AppComponent - ], - providers: [ - // ... - AUTH_PROVIDERS, - // ... - ], - imports: [ - // ... - ], - bootstrap: [AppComponent] -}) -``` - -Then import `AuthHttp`, inject it in your component, and use it to make the authenticated request. - -In this example, the `patch` method takes the endpoint URL, body, and headers: - -```typescript -// app/profile_edit.component.ts - -import { AuthHttp } from 'angular2-jwt'; - -@Component({ - selector: 'profile', - templateUrl: 'app/profile_edit.template.html' -}) - -export class ProfileEdit { - - address: String - - constructor(private auth: Auth, private authHttp: AuthHttp, private router: Router) { - if(auth.userProfile.user_metadata && auth.userProfile.user_metadata.address){ - this.address = auth.userProfile.user_metadata.address; - } - } - - onSubmit() { - var headers: any = { - 'Accept': 'application/json', - 'Content-Type': 'application/json' - } - - var data: any = JSON.stringify({ - user_metadata: { - address: this.address - } - }); - - this.authHttp - .patch('https://' + '${account.namespace}' + '/api/v2/users/' + this.auth.userProfile.user_id, data, {headers: headers}) - .map(response => response.json()) - .subscribe( - response => { - //Update profile - this.auth.userProfile = response; - localStorage.setItem('profile', JSON.stringify(response)); - this.router.navigate(['/profile']); - }, - error => alert(error.json().message) - ); - } -} -``` - -Then create a simple form template to add/update the *address* attribute: - -```html - - -
-
-
-

Profile

- -
-
- - -
- -
-
-
-
-

You are not logged in, please click 'Log in' button to login

-``` diff --git a/articles/client-platforms/angular2/05-linking-accounts.md b/articles/client-platforms/angular2/05-linking-accounts.md deleted file mode 100644 index d621a58d0e..0000000000 --- a/articles/client-platforms/angular2/05-linking-accounts.md +++ /dev/null @@ -1,216 +0,0 @@ ---- -title: Linking Accounts -description: This tutorial will show you how to integrate Auth0 with Angular 2 to link accounts. -budicon: 345 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs2-systemjs-sample', - path: '05-Linking-Accounts', - requirements: [ - 'Angular 2.0.1' - ] -}) %> - -<%= include('../../_includes/_linking_accounts') %> - -```typescript -// app/auth.service.ts - -// Lock instance to launch a login to obtain the secondary JWT -lockLink = new Auth0Lock('${account.clientId}', '${account.namespace}', { - auth: { - params: { - state: "linking" - } - }, - allowedConnections: ['Username-Password-Authentication', 'facebook', 'google-oauth2'], - languageDictionary: { // allows to override dictionary entries - title: "Link with:" - } -}); -``` - -Then, when setting the callback for the `authenticated` event with the `on` method, you can determine which login has executed by checking the value of the `authResult.state` attribute: - -```typescript -// app/auth.service.ts - -// Add callback for lock `authenticated` event -this.lock.on("authenticated", (authResult) => { - // Every lock instance listens to the same event, so you have to check if - // it's not the linking login here. - if(authResult.state != "linking"){ - localStorage.setItem('id_token', authResult.idToken); - this.fetchProfile(authResult.idToken); - } -}); - -// Add callback for lockLink `authenticated` event -this.lockLink.on("authenticated", (authResult) => { - // Every lock instance listens to the same event, so you have to check if - // it's the linking login here. - if(authResult.state == "linking"){ - // If it's the linking login, then create the link through the API. - this.doLinkAccounts(authResult.idToken); - } -}); -``` - -Now that the second login is handled, you will need to actually do the linking. - -To call the API, [angular2-jwt](https://github.com/auth0/angular2-jwt) provides the `AuthHttp` helper which has the same interface as the `Http` module but automatically adds the authorization header to requests. - -First, add the `AUTH_PROVIDERS` from angular-jwt: - -```typescript -// app/app.module.ts - -import { AUTH_PROVIDERS } from 'angular2-jwt'; -import { AppComponent } from './app.component'; - -@NgModule({ - declarations: [ - AppComponent - ], - providers: [ - // ... - AUTH_PROVIDERS, - // ... - ], - imports: [ - // ... - ], - bootstrap: [AppComponent] -}) -``` - -Then import `AuthHttp`, inject it into your component and use it to make the authenticated request: - -```typescript -// app/auth.service.ts - -@Injectable() -export class Auth { - - constructor(private authHttp: AuthHttp, private router: Router) { - // ... - } - - public doLinkAccounts(accountToLinkJWT) { - var headers: any = { - 'Accept': 'application/json', - 'Content-Type': 'application/json' - } - - var data: any = JSON.stringify({ - link_with: accountToLinkJWT - }); - - this.authHttp - .post('https://' + '${account.namespace}' + '/api/v2/users/' + this.userProfile.user_id + '/identities', data, {headers: headers}) - .map(response => response.json()) - .subscribe( - response => { - console.log("accounts linked"); - this.fetchProfile(localStorage.getItem('id_token')); - this.router.navigate(['/profile']); - }, - error => alert(error.json().message) - ); - } -} -``` - -The function takes the `id_token` of the account to link with and posts to the API, passing the `link_with` parameter with the JWT value in the body. Then it fetches the profile on success to check that the accounts are now linked. - -Now to begin the link process, call the `show` method on `lockLink` instance: - -```typescript -// app/auth.service.ts -public linkAccount() { - this.lockLink.show(); -} -``` - -## User Profile Linked Accounts Information - -The user profile contains an array of identities which includes the profile information from linked providers. - -To view a user's identities, access the [Users](${manage_url}/#/users) page on the Auth0 dashboard, select a user, and scroll down to `identities`. - -This example shows a user with a linked Google account: - -![User identities](/media/articles/users/user-identities-linked.png) - -If you fetch the profile after linking accounts, this same information will be available. - -You can display this information and provide an **Unlink** button: - -```html - -
-
-
-

Profile

- -

Name: {{auth.userProfile.name}}

-

Email: {{auth.userProfile.email}}

-

Nickname: {{auth.userProfile.nickname}}

-

Created At: {{auth.userProfile.created_at}}

-

Updated At: {{auth.userProfile.updated_at}}

-
- Linked accounts: -
    -
  • - {{identity.connection}} ({{identity.profileData.name || identity.profileData.email }}) - -
    • -
-
- -
-
-
-

You are not logged in, please click 'Log in' button to login

-``` - -This calls the following `linkedAccounts` helper method to filter the primary identity: - -```typescript -// auth.service.ts - -public linkedAccounts() { - return this.userProfile.identities.filter(identity => { - return this.userProfile.user_id != identity.provider + '|' + identity.user_id - }); -} -``` - -## Unlinking Accounts - -You can dissociate a linked account by calling the [Unlink a user account](/api/management/v2#!/Users/delete_provider_by_user_id) endpoint using the primary `user_id`, and the `provider` and `user_id` of the identity to unlink: - -```typescript -// auth.service.ts - -public unLinkAccount(identity) { - var headers: any = { - 'Accept': 'application/json', - 'Content-Type': 'application/json' - } - - this.authHttp - .delete('https://' + '${account.namespace}' + '/api/v2/users/' + this.userProfile.user_id + '/identities/' + identity.provider + "/" + identity.user_id, {headers: headers}) - .map(response => response.json()) - .subscribe( - response => { - console.log("unlinked account"); - this.fetchProfile(localStorage.getItem('id_token')); - this.router.navigate(['Profile']); - }, - error => alert(error.json().message) - ); -} -``` diff --git a/articles/client-platforms/angular2/06-rules.md b/articles/client-platforms/angular2/06-rules.md deleted file mode 100644 index 6d155c9c6e..0000000000 --- a/articles/client-platforms/angular2/06-rules.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: Rules -description: This tutorial demonstrates how to use Auth0 rules -budicon: 173 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs2-systemjs-sample', - path: '06-Rules', - requirements: [ - 'Angular 2.0.1' - ] -}) %> - -<%= include('../_includes/_rules-introduction') %> - -## Create a Rule - -<%= include('../_includes/_rules-create-section') %> - -## Test the Rule - -<%= include('../_includes/_rules-test-result-intro', { profilelink: '/quickstart/spa/angular2/04-user-profile' }) %> - -```html - - -
-
-
-

Profile

- -

Country (added by rule): {{auth.userProfile.country}}

-
-
-
-

You are not logged in, please click 'Log in' button to login

-``` - -![Country rule sample](/media/articles/angularjs2/rule-country-show.png) diff --git a/articles/client-platforms/angular2/07-authorization.md b/articles/client-platforms/angular2/07-authorization.md deleted file mode 100644 index 8bad18d4fe..0000000000 --- a/articles/client-platforms/angular2/07-authorization.md +++ /dev/null @@ -1,121 +0,0 @@ ---- -title: Authorization -description: This tutorial demonstrates how to 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-angularjs2-systemjs-sample', - path: '07-Authorization', - requirements: [ - 'Angular 2.0.1' - ] -}) %> - -<%= include('../_includes/_authorization-introduction', { ruleslink: '/quickstart/spa/angular2/06-rules' }) %> - -### Create a Rule to Assign Roles - -<%= include('../_includes/_authorization-create-rule') %> - -## Restrict a Route Based on User's Roles - -To restrict access to certain routes, Angular's [CanActivate guard](https://angular.io/docs/ts/latest/guide/router.html#!#can-activate-guard) can be used. - -First, add a new `AuthGuard` to the `/admin` route: - -```typescript -// app/app.routes.ts - -import { ModuleWithProviders } from '@angular/core'; -import { Routes, RouterModule } from '@angular/router'; - -import { HomeComponent } from './home.component'; -import { AdminComponent } from './admin.component'; -import { UnauthorizedComponent } from './unauthorized.component'; -import { AuthGuard } from './auth.guard'; - -const appRoutes: Routes = [ - { path: '', component: HomeComponent }, - { path: 'admin', component: AdminComponent, canActivate: [AuthGuard] }, - { path: 'unauthorized', component: UnauthorizedComponent }, - { path: '**', redirectTo: '' } -]; - -export const appRoutingProviders: any[] = [ - AuthGuard -]; - -export const routing: ModuleWithProviders = RouterModule.forRoot(appRoutes); -``` - -To only allow users who have admin roles to access this route, check their status in the guard: - -```typescript -// app/auth.guard.ts - -import { Injectable } from '@angular/core'; -import { Router, - ActivatedRouteSnapshot, - RouterStateSnapshot } from '@angular/router'; -import { CanActivate } from '@angular/router'; -import { Auth } from './auth.service'; - -@Injectable() -export class AuthGuard implements CanActivate { - - constructor(private auth: Auth, private router: Router) {} - - canActivate(next: ActivatedRouteSnapshot, state: RouterStateSnapshot) { - if(this.auth.authenticated()){ - if(this.auth.isAdmin()){ - return true; - } else { - this.router.navigate(['unauthorized']); - return false; - } - } else { - // Save URL to redirect to after login and fetching profile to get roles - localStorage.setItem('redirect_url', state.url); - this.auth.login(); - this.router.navigate(['']); - return false; - } - } -} -``` - -The `canActivate` method checks if the user is authenticated and then checks if they are an admin using a new `isAdmin` function added to the `Auth` service. This method checks if the `roles` attribute of `app_metadata` added by the rule contains `admin`: - -```typescript -// app/auth.service.ts - -public isAdmin() { - return this.userProfile && this.userProfile.app_metadata - && this.userProfile.app_metadata.roles - && this.userProfile.app_metadata.roles.indexOf('admin') > -1; -} -``` - -Since the user's `app_metadata` is read-only for users, checking for their role in this fashion is secure. - -After logging in successfully, the user will be redirected to the saved URL: - -```typescript -// app/auth.service.ts - -// Fetch profile information -this.lock.getProfile(authResult.idToken, (error, profile) => { - // ... - - // Redirect to the saved URL, if present. - var redirectUrl: string = localStorage.getItem('redirect_url'); - if(redirectUrl != undefined){ - this.router.navigate([redirectUrl]); - localStorage.removeItem('redirect_url'); - } -}); -``` - -Now, if a user logs in with an email that contains `@example`, they will be allowed access to the `/admin` route. diff --git a/articles/client-platforms/angular2/08-calling-apis.md b/articles/client-platforms/angular2/08-calling-apis.md deleted file mode 100644 index 2355e3bbe3..0000000000 --- a/articles/client-platforms/angular2/08-calling-apis.md +++ /dev/null @@ -1,117 +0,0 @@ ---- -title: Calling APIs -description: This tutorial demonstrates how to use angular2-jwt in Angular 2 applications to make authenticated API calls -budicon: 546 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs2-systemjs-sample', - path: '08-Calling-Api', - requirements: [ - 'Angular 2.0.1' - ] -}) %> - -<%= include('../../_includes/_calling_apis') %> - -## Sending Authenticated HTTP Requests - -To make an authenticated request, [angular2-jwt](https://github.com/auth0/angular2-jwt) provides the `AuthHttp` helper which has the same interface as the `Http` module but automatically adds the authorization header to requests. - -First, add `AUTH_PROVIDERS` from `angular2-jwt`: - -```typescript -// app/app.module.ts - -import { AUTH_PROVIDERS } from 'angular2-jwt'; -import { AppComponent } from './app.component'; - -@NgModule({ - declarations: [ - AppComponent - ], - providers: [ - // ... - AUTH_PROVIDERS, - // ... - ], - imports: [ - // ... - ], - bootstrap: [AppComponent] -}) -``` - -Then import `AuthHttp`, inject it into your component, and use it to make the authenticated requests. - -```typescript -// app/ping.component.ts - -import {Component} from '@angular/core'; -import {Auth} from './auth.service'; -import {AuthHttp} from 'angular2-jwt'; -import 'rxjs/add/operator/map'; - -@Component({ - selector: 'ping', - templateUrl: 'app/ping.template.html' -}) -export class Ping { - - API_URL: string = 'http://localhost:3001'; - message: string; - - constructor(private auth: Auth, private authHttp: AuthHttp) {} - - public securedPing() { - this.authHttp.get(`<%= "${this.API_URL}" %>/secured/ping`) - .map(res => res.json()) - .subscribe( - data => this.message= data.text, - error => this.message = error._body || error - ); - } -} -``` - -Your request will have the `Authorization` header added automatically. - -`Authorization: Bearer eyJ0eXAiOiJKV1Qi...` - -By default, `AuthHttp` will fetch the token from `localStorage` using the `id_token` key. You can change the key used. Or you can create another function to get the token and set the provider manually. For more detail on available options, see: [Configuration Options](https://github.com/auth0/angular2-jwt#configuration-options). - -## Not sending the JWT for Specific Requests - -If you do not want to send the access token in the authorization header, you can use the default Angular [Http](https://angular.io/docs/ts/latest/guide/server-communication.html) client: - -```typescript -// app/ping.component.ts - -import {Component} from '@angular/core'; -import {Auth} from './auth.service'; -import {AuthHttp} from 'angular2-jwt'; -import {Http} from '@angular/http'; -import 'rxjs/add/operator/map'; - -@Component({ - selector: 'ping', - templateUrl: 'app/ping.template.html' -}) -export class Ping { - API_URL: string = 'http://localhost:3001'; - message: string; - - constructor(private auth: Auth, private http: Http, private authHttp: AuthHttp) {} - - // Makes a get to the api without authorization headers - public ping() { - this.http.get(`<%= "${this.API_URL}" %>/ping`) - .map(res => res.json()) - .subscribe( - data => this.message = data.text, - error => this.message = error._body - ); - } -} -``` diff --git a/articles/client-platforms/angular2/09-mfa.md b/articles/client-platforms/angular2/09-mfa.md deleted file mode 100644 index 29bd67e517..0000000000 --- a/articles/client-platforms/angular2/09-mfa.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Multifactor Authentication -description: This tutorial demonstartes how to add Multifactor Authentication to your Angular 2 app with Auth0. -budicon: 243 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs2-systemjs-sample', - path: '09-MFA', - requirements: [ - 'Angular 2.0.1' - ] -}) %> - -<%= include('../_includes/_mfa-introduction') %> - -## Enable Multifactor Authentication in Your Account - -<%= include('../_includes/_mfa-enable') %> - -## Login - -<%= include('../_includes/_mfa-login', { loginlink: '/quickstart/spa/angular2/01-login' }) %> diff --git a/articles/client-platforms/angular2/10-customizing-lock.md b/articles/client-platforms/angular2/10-customizing-lock.md deleted file mode 100644 index 62736f5bba..0000000000 --- a/articles/client-platforms/angular2/10-customizing-lock.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: Customizing Lock -description: This tutorial demonstrates how to customize Lock. -budicon: 285 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs2-systemjs-sample', - path: '10-Customizing-Lock', - requirements: [ - 'Angular 2.0.1' - ] -}) %> - -Using Lock is easy, but you may want to customize your login UI. For that, there are several [customization options](/libraries/lock/v10/customization) available. - -## Lock Options - -Some UI customization can be done via the `options` parameter when creating a `Lock` instance. - -### Theme Options - -You can set custom theme properties, such as a different logo or primary color, by adding a `theme` property with custom values: - -```typescript -// auth.service.ts - -lock = new Auth0Lock('${account.clientId}', '${account.namespace}', { - theme: { - logo: "test-icon.png", - primaryColor: "#b81b1c" - } -}); -``` -**NOTE**: For more information, see: [Theming options](https://github.com/auth0/lock#theming-options). - -### Language Dictionary Specification - -You can also customize the text that `Lock` will display with the `languageDictionary` option parameter: - -```typescript -// auth.service.ts - -lock = new Auth0Lock('${account.clientId}', '${account.namespace}', { - languageDictionary: { - title: "My Company" - } -}); -``` - -**NOTE**: For more information, see: [Language Dictionary Specification](https://github.com/auth0/lock#language-dictionary-specification). - -### Results - -This is how Lock will appear using a custom logo, color, and title: - -![Custom lock](/media/articles/angularjs2/widget-custom-logo-color.png) diff --git a/articles/client-platforms/angular2/_includes/_dependencies.md b/articles/client-platforms/angular2/_includes/_dependencies.md deleted file mode 100644 index 3563d99879..0000000000 --- a/articles/client-platforms/angular2/_includes/_dependencies.md +++ /dev/null @@ -1,19 +0,0 @@ -## Add the Dependencies - -To integrate your Angular 2 application with Auth0, you will need to add the following two dependencies: - -- [Lock Widget](https://github.com/auth0/lock) is the default authentication widget provided by Auth0. - - From [npm](https://npmjs.org): - - `npm install --save auth0-lock` - - Or the Auth0 CDN: - - `` - -- [angular2-jwt](https://github.com/auth0/angular2-jwt) is a helper library for working with [JWTs](http://jwt.io/introduction) in your Angular 2 applications. - - From [npm](https://npmjs.org): - - `npm install --save angular2-jwt` diff --git a/articles/client-platforms/angular2/_includes/_login.md b/articles/client-platforms/angular2/_includes/_login.md deleted file mode 100644 index bdfffc97f5..0000000000 --- a/articles/client-platforms/angular2/_includes/_login.md +++ /dev/null @@ -1,112 +0,0 @@ -## Login - -The best way to have authentication utilities available across the application is to use an **Injectable** service. - -You will need an `Auth0Lock` instance to receive your Auth0 credentials and an options object. For a full list of Lock's options, see the [customization docs](/libraries/lock/customization). - -Your app will need to listen for Lock's `authenticated` event and have a callback registered to handle authentication. The callback has a single parameter that will have the user's authentication information and it will be invoked once the user is redirected after authenticating. - -There is a property on the object that gets returned by Auth0 called `idToken` which is a [JSON Web Token](https://jwt.io/introduction) identifying the user. It is this token that can be used to give an indication in your Angular 2 application that the user is authenticated, and it is also used to access resources from an API. - -For now, store the `idToken` attribute into `localStorage`. - -In the `login` method, call `lock.show()` to display the login widget. - -To check if a user is authenticated, use `tokenNotExpired` from [angular2-jwt](https://github.com/auth0/angular2-jwt), which allows you to see if there is a non-expired JWT in local storage. - -```typescript -// app/auth.service.ts - -import { Injectable } from '@angular/core'; -import { tokenNotExpired } from 'angular2-jwt'; - -// Avoid name not found warnings -declare var Auth0Lock: any; - -@Injectable() -export class Auth { - // Configure Auth0 - lock = new Auth0Lock('${account.clientId}', '${account.namespace}', {}); - - constructor() { - // Add callback for lock `authenticated` event - this.lock.on("authenticated", (authResult) => { - localStorage.setItem('id_token', authResult.idToken); - }); - } - - public login() { - // Call the show method to display the widget. - this.lock.show(); - } - - public authenticated() { - // Check if there's an unexpired JWT - // This searches for an item in localStorage with key == 'id_token' - return tokenNotExpired(); - } - - public logout() { - // Remove token from localStorage - localStorage.removeItem('id_token'); - } -} -``` - -To use this service, inject the `Auth` service into your component: - -```typescript -//app/app.component.ts - -export class AppComponent { - constructor(private auth: Auth) {} -} -``` - -and into your component's template: - -```html - - -
- Auth0 - Angular 2 - - -
-``` - -And create your [NgModule](https://angular.io/docs/ts/latest/guide/ngmodule.html) in your root app module as follows: - -```typescript -// app/app.module.ts - -import { NgModule } from '@angular/core'; -import { BrowserModule } from '@angular/platform-browser'; -import { AUTH_PROVIDERS } from 'angular2-jwt'; - -import { AppComponent } from './app.component'; -import { HomeComponent } from './home.component'; -import { routing, - appRoutingProviders } from './app.routes'; - -@NgModule({ - declarations: [ - AppComponent, - HomeComponent - ], - providers: [ - appRoutingProviders, - AUTH_PROVIDERS - ], - imports: [ - BrowserModule, - routing - ], - bootstrap: [AppComponent] -}) -export class AppModule {} -``` - -The Lock widget will be displayed when the **Login** button is clicked. - -<%= include('../../_includes/_persisting_state') %> diff --git a/articles/client-platforms/angular2/dashboard-default.md b/articles/client-platforms/angular2/dashboard-default.md deleted file mode 100644 index 9c650df2b8..0000000000 --- a/articles/client-platforms/angular2/dashboard-default.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Login -default: true -description: This tutorial demonstrates how to integrate Auth0 with Angular 2 to add user login to your app ---- - - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs2-systemjs-sample', - path: '01-Login', - requirements: [ - 'Angular 2.0.1' - ] -}) %> - -<%= include('../../_includes/_callback_url') %> - -<%= include('_includes/_dependencies') %> - -<%= include('_includes/_login') %> diff --git a/articles/client-platforms/angular2/index.yml b/articles/client-platforms/angular2/index.yml deleted file mode 100644 index 1558b42fea..0000000000 --- a/articles/client-platforms/angular2/index.yml +++ /dev/null @@ -1,34 +0,0 @@ -title: Angular 2 -image: /media/platforms/angular.png -alias: - - angular2 - - angularjs -language: - - Javascript -framework: - - Angular 2 -tags: - - quickstart -snippets: - dependencies: client-platforms/angular2/dependencies - install: client-platforms/angular2/install - observable: client-platforms/angular2/observable - request: client-platforms/angular2/request - router: client-platforms/angular2/router - setup: client-platforms/angular2/setup - system_map: client-platforms/angular2/system-map - use: client-platforms/angular2/use -seo_alias: angular2 -default_article: dashboard-default -articles: - - 00-intro - - 01-login - - 02-custom-login - - 03-session-handling - - 04-user-profile - - 05-linking-accounts - - 06-rules - - 07-authorization - - 08-calling-apis - - 09-mfa - - 10-customizing-lock diff --git a/articles/client-platforms/angularjs/00-intro.md b/articles/client-platforms/angularjs/00-intro.md deleted file mode 100644 index 0e60077158..0000000000 --- a/articles/client-platforms/angularjs/00-intro.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Introduction -description: This quickstart guide demonstrates how to add authentication to an Angular 1.x application using Auth0 ---- - -This quickstart guide demonstrates how to add authentication to an Angular 1.x application using Auth0. - -Auth0 provides wrappers for using the [Lock widget](/libraries/lock) and the [auth0.js](/libraries/auth0js) library in Angular apps, and these wrappers will be used throughout these quickstart guides. - -## Sample Projects - -If you want to follow along with these quickstart guides, you can download the starter [seed project](https://github.com/auth0-samples/auth0-angularjs-sample/tree/master/00-Starter-Seed) to work from a blank slate. This seed project is a basic Angular 1.x application with all the Bower dependencies included and the required references added to the `index.html` file. - -Each step in the quickstarts contains a sample project available for download which shows the finished result for that step. - -<%= include('../../_includes/_new_app') %> - -<%= include('../../_includes/_callback_url') %> - -<%= include('_includes/_dependencies') %> diff --git a/articles/client-platforms/angularjs/01-login.md b/articles/client-platforms/angularjs/01-login.md deleted file mode 100644 index e3bba84774..0000000000 --- a/articles/client-platforms/angularjs/01-login.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: Login -description: This tutorial demonstrates how to use the Auth0 Angular 1.x SDK to add authentication and authorization to your mobile app. ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs-sample', - path: '01-Login' -}) %> - -The first step in adding authentication to your Angular app is to provide a way for the user to log in. The easiest way to do this with Auth0 is to use the [Lock widget](/libraries/lock). - -**Note:** You should scope your Angular application to a `div` tag inside the `body`. This will prevent issues with Angular incorrectly trying to handle events that are handled properly by Lock. - -```html - -
- ... -
- ... - -``` - -<%= include('_includes/_authservice') %> - -<%= include('_includes/_configuration') %> - -<%= include('_includes/_login') %> diff --git a/articles/client-platforms/angularjs/02-custom-login.md b/articles/client-platforms/angularjs/02-custom-login.md deleted file mode 100644 index 7d9956916c..0000000000 --- a/articles/client-platforms/angularjs/02-custom-login.md +++ /dev/null @@ -1,273 +0,0 @@ ---- -title: Custom Login -description: This tutorial demonstrates how to use the Auth0 Angular 1.x SDK to add authentication and authorization to your mobile app. ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs-sample', - path: '02-Custom-Login' -}) %> - -The previous step explained how you can log users into your application using the [Lock Widget](/libraries/lock). While Lock provides the simplest way to add authentication to your app, you also have the option of creating your own custom user interface. - -::: panel-info Version Requirements -This quickstart and the accompanying sample demonstrate custom login with auth0.js version 8 and angular-auth0 version 2. If you are using auth0.js version 7, please see the [reference guide](/libraries/auth0js/v7) for the library, as well as the [legacy AngularJS custom login sample](https://github.com/auth0-samples/auth0-angularjs-sample/tree/auth0js-v7/02-Custom-Login). - -Auth0.js version 8 verifies ID tokens during authentication transactions. Only tokens which are signed with the RS256 algorithm can be verified on the client side, meaning that your Auth0 client must be configured to sign tokens with RS256. See the [auth0.js migration guide](/libraries/auth0js/migration-guide#switching-from-hs256-to-rs256) for more details. -::: - -## Add auth0.js - -To implement a custom login screen, the **auth0.js** library and **angular-auth0** wrapper are required. Install these packages, along with angular-jwt, and add them to your project. - -```bash -bower install angular-auth0#2.0.0-beta.1 angular-jwt -``` - -```html - - - - - - -``` - -## Initialize angular-auth0 - -To make use of auth0.js, angular-auth0 must be initialized in the application's `config` block. This is where the `domain` and `clientID` for your application are set. - -```js -// app.js - -(function () { - - 'use strict'; - - angular - .module('app', ['auth0.auth0', 'angular-jwt', 'ui.router']) - .config(config); - - function config($locationProvider, angularAuth0Provider, jwtOptionsProvider) { - // ... - - // Initialization for the angular-auth0 library - angularAuth0Provider.init({ - clientID: '${account.clientId}', - domain: '${account.namespace}', - responseType: 'token id_token', - redirectUri: window.location.href - }); - - // Configure a tokenGetter so that the isAuthenticated - // method from angular-jwt can be used - jwtOptionsProvider.config({ - tokenGetter: function() { - return localStorage.getItem('id_token'); - } - }); - - // Remove the ! from the hash so that - // auth0.js can properly parse it - $locationProvider.hashPrefix(''); - } - -})(); -``` - -To make use of the `isAuthenticated` method from angular-jwt, a `tokenGetter` needs to be configured on `jwtOptionsProvider`. This method will be useful later for determining whether or not users are currently authenticated so that various elements can be conditionally hidden or shown. - -> **Note:** As of AngularJS 1.6, the default hash prefix is `!`. This prefix creates issues when auth0.js parses the hash. The snippet above demonstrates how to set the hash prefix to an empty string. - -## Implement the Login Screen - -A `login` controller and view can be used to take user input and make calls to an authentication service with that input. - -Create a `login` controller and bind the `authService` (implemented below) to `vm.auth`. - -```js -// components/login/login.controller.js - -(function () { - - 'use strict'; - - angular - .module('app') - .controller('LoginController', loginController); - - loginController.$inject = ['authService']; - - function loginController(authService) { - - var vm = this; - vm.auth = authService; - - } - -})(); -``` - -Create a `login` view with **username** and **password** `input` elements to allow users to enter their email address and password. You may also display a control to allow users to log in with their Google account. The `vm.username` and `vm.password` values should be passed to the `login` and `signup` method calls from the `authService`. - -```html - - -
-
- -
- - -
- -
- - -
- - - - - -
- -
-``` - -The `authService` is the place where all the calls to angular-auth0, and thus to auth0.js, are made. 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` view above. - -```js -// components/auth/auth.service.js - -(function () { - - 'use strict'; - - angular - .module('app') - .service('authService', authService); - - authService.$inject = ['$state', 'angularAuth0', 'authManager']; - - function authService($state, angularAuth0, authManager) { - - function login(username, password) { - angularAuth0.client.login({ - realm: 'Username-Password-Authentication', - username: username, - password: password, - }, function(err, authResult) { - if (err) alert(err.description); - if (authResult && authResult.idToken) { - setUser(authResult); - $state.go('home'); - } - }); - } - - function signup(username, password) { - angularAuth0.redirect.signupAndLogin({ - connection: 'Username-Password-Authentication', - email: username, - password: password - }); - } - - function loginWithGoogle() { - angularAuth0.authorize({ - connection: 'google-oauth2' - }); - } - - function handleParseHash() { - angularAuth0.parseHash(function(err, authResult) { - if (authResult && authResult.idToken) { - setUser(authResult); - } - }); - } - - function logout() { - localStorage.removeItem('access_token'); - localStorage.removeItem('id_token'); - } - - function setUser(authResult) { - localStorage.setItem('access_token', authResult.accessToken); - localStorage.setItem('id_token', authResult.idToken); - } - - function isAuthenticated() { - return authManager.isAuthenticated(); - } - - return { - login: login, - signup: signup, - loginWithGoogle: loginWithGoogle, - handleParseHash: handleParseHash, - logout: logout, - isAuthenticated: isAuthenticated - } - } -})(); -``` - -The service has several other utility methods that are necessary to complete authentication transactions. - -* The `handleParseHash` method is necessary for redirect-based authentication transactions which, in this example, include `signup` and `loginWithGoogle`. This method needs to be called when the app starts so that the authentication result (which comes back in the hash of a redirection) is properly handled. -* The `logout` method removes the user's tokens from local storage which effectively logs them out of the application. -* The `setUser` method takes an authentication result object and sets the access token and ID token values into local storage -* The `isAuthenticated` method checks for the user's authentication state based on the `id_token`'s expiry time. - -The `handleParseHash` method needs to be called in the application's `run` block. - -```js -// app.run.js - -(function () { - - 'use strict'; - - angular - .module('app') - .run(function (authService) { - // Handle the authentication - // result in the hash - authService.handleParseHash(); - }); - -})(); -``` diff --git a/articles/client-platforms/angularjs/03-session-handling.md b/articles/client-platforms/angularjs/03-session-handling.md deleted file mode 100644 index c8f4bb87e4..0000000000 --- a/articles/client-platforms/angularjs/03-session-handling.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: Session Handling -description: This tutorial demonstrates how to integrate Auth0 with Angular 1.x to add session handling and logout to your web app. ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs-sample', - path: '03-Session-Handling' -}) %> - -In the previous steps, we enabled user login with the `Lock` widget and then with a custom UI using `auth0.js`. In this step, we will create a session for the user. - -## Create a Session - -Once the user is authenticated, we need to create a client-side session for them so that our Angular app knows that they are currently authenticated. To do this, we need to store the user's `id_token` in their browser, which is what we did in the [login](/quickstart/spa/angularjs/01-login) step. - -> **NOTE**: This example uses `localStorage`, but you can use any storage library, including [angular-storage](https://github.com/auth0/angular-storage). - -```js -// components/auth/auth.service.js - -(function () { - - 'use strict'; - - angular - .module('app') - .service('authService', authService); - - function authService(lock, authManager) { - // Set up the logic for when a user authenticates - // This method is called from app.run.js - function registerAuthenticationListener() { - lock.on('authenticated', function (authResult) { - localStorage.setItem('id_token', authResult.idToken); - authManager.authenticate(); - }); - } - }); - -})(); - -``` - -## Check Authentication State on Page Refresh - -After the user authenticates, we call `authManager.authenticate()` which sets an application-wide flag to indicate that the user is logged in. However, when the page is refreshed, this state will be lost. To check if a user is authenticated on page refresh, we can use the `authManager.checkAuthOnRefresh()` method from **angular-jwt**. This allows us to check whether the user's JWT is expired or not. Since JWT is a __stateless__ manner of implementing user authentication, the best way to know if the user should be regarded as authenticated on the front end is to know whether the token they are holding is expired or unexpired. - -```js -// app.run.js - -(function () { - - 'use strict'; - - angular - .module('app') - .run(run); - - function run($rootScope, authService, lock, authManager) { - // Use the authManager from angular-jwt to check for - // the user's authentication state when the page is - // refreshed and maintain authentication - authManager.checkAuthOnRefresh(); - - } - -})(); -``` - -Since the storage mechanism that you use for storing tokens on the front end is at your discretion, the **angular-jwt** library needs to know how to retrieve them. This is done by providing a function which returns the token, and it is this function that is used when `authManager.checkAuthOnRefresh` is called. Setup the `jwtOptionsProvider` in `app.js` with your `tokenGetter` function. - -```js -// app.js - -(function () { - - 'use strict'; - - angular - .module('app', ['auth0.lock', 'angular-jwt', 'ui.router']) - .config(config); - - function config($stateProvider, lockProvider, $urlRouterProvider, jwtOptionsProvider) { - // Configuration for angular-jwt - jwtOptionsProvider.config({ - tokenGetter: function () { - return localStorage.getItem('id_token'); - } - }); - } - -})(); -``` - -Now when the page is refreshed, the user's JWT will be checked for whether it is expired or not. If it isn't expired, the user will be regarded as authenticated. diff --git a/articles/client-platforms/angularjs/04-user-profile.md b/articles/client-platforms/angularjs/04-user-profile.md deleted file mode 100644 index 50fc1700a8..0000000000 --- a/articles/client-platforms/angularjs/04-user-profile.md +++ /dev/null @@ -1,123 +0,0 @@ ---- -title: User Profile -description: This tutorial demonstrates how to display the user's profile ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs-sample', - path: '04-User-Profile' -}) %> - -Auth0 provides a profile object for your users and you can obtain it from Lock's `getProfile` method. - -## Accessing the User's Profile - -To get the user's profile, call the `getProfile` method on `lock`, passing in a token and callback function. - -```js -// components/auth/auth.service.js - -(function () { - - 'use strict'; - - angular - .module('app') - .service('authService', authService); - - function authService($q, lock, authManager) { - - var deferredProfile = $q.defer(); - - function registerAuthenticationListener() { - lock.on('authenticated', function (authResult) { - - lock.getProfile(authResult.idToken, function (error, profile) { - if (error) { - return console.log(error); - } - - localStorage.setItem('profile', JSON.stringify(profile)); - deferredProfile.resolve(profile); - }); - - }); - } - - } - -})(); -``` - -The stringified `profile` object is being stored in local storage in the success callback. Once that is done, all that is needed is to retrieve the profile from local storage at a later stage. For example, we might want to show the user's profile information in the home view. - -```js -// components/home/home.controller.js - -(function () { - - 'use strict'; - - angular - .module('app') - .controller('HomeController', HomeController); - - function HomeController(authService) { - - var vm = this; - vm.authService = authService; - - authService.getProfileDeferred().then(function (profile) { - vm.profile = profile; - }); - } - -})(); -``` - -We get the user profile using the `getProfileDeferred()` method which is implemented in the `authService`. - -```js -// components/auth/auth.service.js - -(function () { - - 'use strict'; - - angular - .module('app') - .service('authService', authService); - - function authService($q, lock, authManager) { - - var userProfile = JSON.parse(localStorage.getItem('profile')) || null; - var deferredProfile = $q.defer(); - - if (userProfile) { - deferredProfile.resolve(userProfile); - } - - function getProfileDeferred() { - return deferredProfile.promise; - } - - return { - getProfileDeferred: getProfileDeferred - } - } -})(); -``` - -Once the profile is retrieved, it can be bound to the view. - -```html - -
-

You are not yet authenticated. Log in.

-
-
-

Welcome, {{ vm.profile.nickname }}

- -
-``` diff --git a/articles/client-platforms/angularjs/05-linking-accounts.md b/articles/client-platforms/angularjs/05-linking-accounts.md deleted file mode 100644 index fa81802951..0000000000 --- a/articles/client-platforms/angularjs/05-linking-accounts.md +++ /dev/null @@ -1,244 +0,0 @@ ---- -title: Linking Accounts -description: This tutorial demonstrates how to integrate Auth0 with Angular 1.x to link accounts ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs-sample', - path: '05-Linking-Accounts' -}) %> - -<%= include('../../_includes/_linking_accounts') %> - -```js -// components/auth/auth.service.js - -(function () { - - 'use strict'; - - angular - .module('app') - .service('authService', authService); - - function authService(lock, authManager, $q, $http) { - - function linkAccount() { - try { - var profile = JSON.parse(localStorage.getItem('profile')); - var token = localStorage.getItem('id_token'); - } catch (e) { - return false; - } - - var options = { - rememberLastLogin: false, - auth: { - redirect: false, - params: { - scope: 'openid' - } - } - }; - - var lockLink = new Auth0Lock('${account.clientId}', '${account.namespace}', options); - var deferred = $q.defer(); - - lockLink.on('authenticated', function (authResult) { - // do linking accounts - }); - - lockLink.show(); - return deferred.promise; - - } - - return { - linkAccount: linkAccount - } - } -})(); - -``` - -Now that the second user is authenticated, the accounts can be linked. - -```js -// components/auth/auth.service.js - -(function () { - - 'use strict'; - - angular - .module('app') - .service('authService', authService); - - function authService(lock, authManager, $q, $http) { - - lockLink.on('authenticated', function (authResult) { - - $http({ - method: 'POST', - url: 'https://${account.namespace}/api/v2/users/' + profile.user_id + '/identities', - headers: { - Authorization: 'Bearer ' + token - }, - data: { - link_with: authResult.idToken - } - }).then(function () { - lockLink.hide(); - - lock.getProfile(token, function (error, profile) { - if (!error) { - localStorage.setItem('profile', JSON.stringify(profile)); - deferred.resolve(profile); - } else { - deferred.reject(error); - } - }); - }); - }); - } -})(); -``` - -This function posts to the API, passing the `link_with` parameter with the JWT value in the body. It then fetches the profile on success to check that the accounts are linked. - -To begin the linking process, call the `linkAccount` method. - -```js -// components/home/home.controller.js - -(function () { - - 'use strict'; - - angular - .module('app') - .controller('HomeController', HomeController); - - function HomeController(authService) { - - function linkAccount() { - authService.linkAccount() - .then(function (profile) { - vm.profile = profile; - refreshIdentities(); - }) - } - } - -})(); -``` - -## Linked Accounts User Profile Information - -The user profile contains an array of identities which includes the profile information from linked providers. - -To view a user's identities, access the [Users](${manage_url}/#/users) page on the Auth0 dashboard, select a user, and scroll down to `identities`. - -This example shows a user with a linked Google account: - -![User identities](/media/articles/users/user-identities-linked.png) - -If you fetch the profile after linking accounts, this same information will be available. - -You can display this information and provide an **Unlink** button: - -```html - - -
- -
    -
  • - - {{ identity.profileData.name || identity.profileData.email }} - -
    • -
-
-``` - -The user's primary identity can be filtered by putting in a function to refresh the identities. - -```js -// components/home/home.controller.js - -(function () { - - 'use strict'; - - angular - .module('app') - .controller('HomeController', HomeController); - - function HomeController(authService) { - - function refreshIdentities() { - vm.profile.identities.shift(); - vm.identities = vm.profile.identities; - } - } - -})(); -``` - -## Unlinking Accounts - -You can dissociate a linked account by calling the [unlink a user account](/api/management/v2#!/Users/delete_provider_by_user_id) endpoint using the primary `user_id`, the `provider`, and `user_id` of the identity to unlink. - -```js -// components/auth/auth.service.js - -(function () { - - 'use strict'; - - angular - .module('app') - .service('authService', authService); - - function authService(lock, authManager, $q, $http) { - - function unLinkAccount(identity) { - try { - var profile = JSON.parse(localStorage.getItem('profile')); - var token = localStorage.getItem('id_token'); - } catch (e) { - return false; - } - - var deferred = $q.defer(); - - $http({ - method: 'DELETE', - url: 'https://${account.namespace}/api/v2/users/' + profile.user_id + '/identities/' + identity.provider + '/' + identity.user_id, - headers: { - Authorization: 'Bearer ' + token - } - }).then(function () { - - lock.getProfile(token, function (error, profile) { - if (!error) { - localStorage.setItem('profile', JSON.stringify(profile)); - deferred.resolve(profile); - } else { - deferred.reject(error); - } - }); - - }); - - return deferred.promise; - } - - return { - unLinkAccount: unLinkAccount - } - } -})(); -``` diff --git a/articles/client-platforms/angularjs/06-rules.md b/articles/client-platforms/angularjs/06-rules.md deleted file mode 100644 index 32ab326f0e..0000000000 --- a/articles/client-platforms/angularjs/06-rules.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: Rules -description: This tutorial demonstrates how to use Auth0 rules to extend what Auth0 has to offer. ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs-sample', - path: '06-Rules' -}) %> - -<%= include('../_includes/_rules-introduction') %> - -## Create a Rule - -<%= include('../_includes/_rules-create-section') %> - -## Test the Rule - -<%= include('../_includes/_rules-test-result-intro', { profilelink: '/quickstart/spa/angularjs/04-user-profile' }) %> - -```html - - -
-

Welcome, {{ vm.profile.nickname }},

-

from {{ vm.profile.country }} (added by rule)

- -
-``` - -![Country rule sample](/media/articles/angularjs/rule-country-show.png) diff --git a/articles/client-platforms/angularjs/07-authorization.md b/articles/client-platforms/angularjs/07-authorization.md deleted file mode 100644 index 2cc6a7efd9..0000000000 --- a/articles/client-platforms/angularjs/07-authorization.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -title: Authorization -description: This tutorial demonstrates how to assign roles to your users, and use those claims to authorize or deny a user to access secure content in the app ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs-sample', - path: '07-Authorization' -}) %> - -<%= include('../_includes/_authorization-introduction', { ruleslink: '/quickstart/spa/angularjs/06-rules' }) %> - -## Create a Rule to Assign Roles - -<%= include('../_includes/_authorization-create-rule') %> - -## Restrict Access to Secure Content - -To restrict secure content to users with a role of `admin`, subscribe to the `$stateChangeStart` event. - -```js -// components/auth/auth.service.js - -(function () { - - 'use strict'; - - angular - .module('app') - .service('authService', authService); - - function authService($rootScope, lock, authManager) { - - $rootScope.$on('$stateChangeStart', function(event, nextRoute) { - if (nextRoute.controller === 'AdminController') { - if (!isAdmin()) { - alert('You are not allowed to see the Admin content'); - return event.preventDefault(); - } - } - }); - - function isAdmin() { - return userProfile && userProfile.app_metadata - && userProfile.app_metadata.roles - && userProfile.app_metadata.roles.indexOf('admin') > -1; - } - } - -})(); -``` - -Now you can create content that should only be visible to those with a role of `admin`. - -```html - - -

Admin

-

You are viewing this because you are logged in and you have 'admin' role

-``` - -Every time the `$stateChangeStart` event fires, a check is done to determine whether the user is an `admin` using a new `isAdmin` function added to the `authService`. This method checks if the `roles` attribute of `app_metadata` added by the rule contains `admin`. - - -> **Note:** Users have no control over their own `app_metadata`, so there is no risk of a user modifying their own access level in Auth0. Keep in mind, however, that the payload of a JSON Web Token can be modified in debuggers such as [jwt.io](https://jwt.io). If a user does this, their JWT will be invalidated and become unusable for accessing server resources; however, the user would be able to access client-side routes with a modified payload. Be sure to keep sensitive information out of the client side completely and rely on XHR requests for that information as this will ensure that resources are properly protected. - -Now if a user logs in with an email that contains `@example`, they will be allowed access to the `/admin` route. diff --git a/articles/client-platforms/angularjs/08-calling-apis.md b/articles/client-platforms/angularjs/08-calling-apis.md deleted file mode 100644 index 6f0e196061..0000000000 --- a/articles/client-platforms/angularjs/08-calling-apis.md +++ /dev/null @@ -1,184 +0,0 @@ ---- -title: Calling APIs -description: This tutorial demonstrates how to make secure calls to an API ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs-sample', - path: '08-Calling-Api' -}) %> - -<%= include('../../_includes/_calling_apis') %> - -## JWT Interceptor - -To attach the user's JWT as an `Authorization` header, we could write a service that returns a token and attaches it to all HTTP requests. However, the **angular-jwt** library already provides this functionality. Ensure that **angular-jwt** is added to your app as a dependency and configure it with `jwtOptionsProvider` in the `config` block. A `tokenGetter` function needs to be provided to inform **angular-jwt** how it should be retrieving the user's JWT. - -```js -// app.js - -(function () { - - 'use strict'; - - angular - .module('app', ['auth0.lock', 'angular-jwt', 'ui.router']) - .config(config); - - function config($httpProvider, jwtOptionsProvider) { - - // Configuration for angular-jwt - jwtOptionsProvider.config({ - tokenGetter: function () { - return localStorage.getItem('id_token'); - }, - whiteListedDomains: ['localhost'], - unauthenticatedRedirectPath: '/login' - }); - - // Add the jwtInterceptor to the array of HTTP interceptors - // so that JWTs are attached as Authorization headers - $httpProvider.interceptors.push('jwtInterceptor'); - } - -})(); -``` - -With the `jwtInterceptor` configured, you can now send authenticated requests to an API that is protected by your Auth0 secret key. - -```js -// components/ping/ping.controller.js - -(function () { - - 'use strict'; - - angular - .module('app') - .controller('PingController', PingController); - - function PingController($http) { - - vm.ping = function () { - $http.get('http://localhost:3001/secured/ping') - .then(function (result) { - vm.pingResult = result.data.text; - }, function (error) { - vm.pingResult = error.statusText; - }); - } - } - -}()); -``` - -## Not Sending the JWT for Specific Requests - -With this configuration, the user's JWT will be sent as an `Authorization` header in all `$http` requests. This may not be desired as some requests don't require authentication. You can choose to not send the JWT by specifying `skipAuthorization: true`. - -```js -// components/ping/ping.controller.js - -(function () { - - 'use strict'; - - angular - .module('app') - .controller('PingController', PingController); - - function PingController($http) { - - vm.ping = function () { - // This request will NOT send the token as it has skipAuthorization - $http.get('http://localhost:3001/secured/ping', { skipAuthorization: true }) - .then(function (result) { - vm.pingResult = result.data.text; - }, function (error) { - vm.pingResult = error.statusText; - }); - } - - } - -}()); -``` - -## Template Requests - -Remember that template requests via `ui-router` or `ng-route` are HTTP requests. This means that by default, `Authorization` headers will be attached when requesting these resources, which isn't required. You may provide some configuration to avoid sending the JWT for template requests. - -```js -// app.js - -(function () { - - 'use strict'; - - angular - .module('app', ['auth0.lock', 'angular-jwt', 'ui.router']) - .config(config); - - function config($httpProvider, jwtOptionsProvider) { - - // Configuration for angular-jwt - jwtOptionsProvider.config({ - tokenGetter: ['options', function (options) { - - // Check for templates and return null to not attach the JWT - if (options && options.url.substr(options.url.length - 5) == '.html') { - return null; - } - return localStorage.getItem('id_token'); - }], - whiteListedDomains: ['localhost'], - unauthenticatedRedirectPath: '/login' - }); - - // Add the jwtInterceptor to the array of HTTP interceptors - // so that JWTs are attached as Authorization headers - $httpProvider.interceptors.push('jwtInterceptor'); - } - -})(); -``` - -## Different Tokens Based on URLs - -If for any reason you would want to send different tokens based on different URLs, you can configure the `tokenGetter` to do so. - -```js -// app.js - -(function () { - - 'use strict'; - - angular - .module('app', ['auth0.lock', 'angular-jwt', 'ui.router']) - .config(config); - - function config($httpProvider, jwtOptionsProvider) { - - // Configuration for angular-jwt - jwtOptionsProvider.config({ - tokenGetter: ['options', function (options) { - - if (options && options.url.indexOf('http://auth0.com') === 0) { - return localStorage.getItem('auth0.id_token'); - } - - return localStorage.getItem('id_token'); - }], - whiteListedDomains: ['localhost'], - unauthenticatedRedirectPath: '/login' - }); - - // Add the jwtInterceptor to the array of HTTP interceptors - // so that JWTs are attached as Authorization headers - $httpProvider.interceptors.push('jwtInterceptor'); - } - -})(); -``` diff --git a/articles/client-platforms/angularjs/09-mfa.md b/articles/client-platforms/angularjs/09-mfa.md deleted file mode 100644 index 2383228351..0000000000 --- a/articles/client-platforms/angularjs/09-mfa.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Multifactor Authentication -description: This tutorial demonstrates how to add Multifactor Authentication to your Angular 1.x app ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs-sample', - path: '09-MFA' -}) %> - -<%= include('../_includes/_mfa-introduction') %> - -This tutorial demonstrates how to enable MFA in the Angular 1.x application you created in the previous steps. - -## Enable Multifactor Authentication in Your Account - -<%= include('../_includes/_mfa-enable') %> - -## Login - -<%= include('../_includes/_mfa-login', { loginlink: '/quickstart/spa/angularjs/01-login' }) %> diff --git a/articles/client-platforms/angularjs/10-customizing-lock.md b/articles/client-platforms/angularjs/10-customizing-lock.md deleted file mode 100644 index 35016da471..0000000000 --- a/articles/client-platforms/angularjs/10-customizing-lock.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: Customizing Lock -description: This tutorial demonstrates how to customize the Lock widget ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs-sample', - path: '10-Customizing-Lock' -}) %> - -Using Lock is easy, but you may want to customize your login UI. There are several options available for this. - -## Lock Options - -Some UI customization can be done via the `options` parameter when initializing a `lockProvider`. - -## Theme Options - -You can set custom theme properties, such as a different logo or primary color, by adding a `theme` property with custom values. - -```js -// app.js - -(function () { - - 'use strict'; - - angular - .module('app', ['auth0.lock', 'angular-jwt', 'ui.router']) - .config(config); - - function config(lockProvider) { - - lockProvider.init({ - clientID: '${account.clientId}', - domain: '${account.namespace}', - options: { - theme: { - logo: 'https://auth0.com/lib/homepage/img/logo-tmz.svg', - primaryColor: "#b81b1c" - } - } - }); - } - -})(); -``` - -**Note**: See the [theming options](https://github.com/auth0/lock#theming-options) documentation for more detail. - -## Language Dictionary Specification - -You can also customize the text that `Lock` will display with the `languageDictionary` option parameter: - -```js -// app.js - -(function () { - - 'use strict'; - - angular - .module('app', ['auth0.lock', 'angular-jwt', 'ui.router']) - .config(config); - - function config(lockProvider) { - - lockProvider.init({ - clientID: '${account.clientId}', - domain: '${account.namespace}', - options: { - languageDictionary: { - title: "Log me in" - } - } - }); - } - -})(); -``` - -> **Note**: See the [Language Dictionary Specification](https://github.com/auth0/lock#language-dictionary-specification) for more information. - -This is how Lock will appear using a custom logo, color, and title: - -![Custom lock](/media/articles/angularjs/widget-custom-logo-color.png) diff --git a/articles/client-platforms/angularjs/11-sso.md b/articles/client-platforms/angularjs/11-sso.md deleted file mode 100644 index 1d8b346eca..0000000000 --- a/articles/client-platforms/angularjs/11-sso.md +++ /dev/null @@ -1,175 +0,0 @@ ---- -title: Single Sign-On -description: This tutorial demonstrates how to use single sign on in Angular 1.x applications ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs-sample', - path: '11-SSO' -}) %> - -Single sign-on (SSO) makes it possible for a user to log into one client and then automatically be logged into other clients, regardless of the platform, technology, or domain the user is using. It works by means of a central authentication service, which Auth0 provides, which means you can easily implement SSO in your Angular apps. - -## How to Implement Single Sign-On with Auth0 - -To enable SSO for one of your **clients** (recall that each client is independent of one another), navigate to the [client's section](${manage_url}/#/clients) of the Auth0 Management Dashboard. Click on **Settings** for the client you would like to enable SSO for. - -![](/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) - -You can also set the client's SSO flag using the [Auth0 Management API](/api/management/v2#!/Clients/patch_clients_by_id). - -Once you have set the SSO flag in Auth0, you must add logic to your client to check the user's SSO status. This logic can be implemented either client-side (using JavaScript) or server-side. - -* [Client-Side SSO (Single Page Apps)](/sso/single-page-apps-sso) -* [Server-Side SSO (Regular Web Apps)](/sso/regular-web-apps-sso) - -### Length of SSO Sessions - -If the SSO flag is set for a client, Auth0 will maintain an SSO session for any user authenticating via that client. 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 client that created the session within the given timeframe. - -## 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. 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. - -## Client-Side SSO - -It may be the case that you'd like to enable SSO in two or more Angular 1.x applications. In this flow, the user would log into one of them (app1.com) and then try to access the second one (app2.com). - -To use SSO in your Angular apps, you will first need to have `angular-auth0` installed and loaded. - -```bash -bower install --save angular-auth0 -``` - -And then add the `auth0.auth0` module and configure the `angularAuth0Provider` provider: - -```js -// app.js - -(function () { - - 'use strict'; - - angular - .module('app', ['auth0.auth0', 'auth0.lock', 'angular-jwt', 'ui.router']) - .config(config); - - function config(angularAuth0Provider) { - - // Initialization for the angular-auth0 library - angularAuth0Provider.init({ - clientID: '${account.clientId}', - domain: '${account.namespace}' - }); - - } - -})(); -``` - -To determine whether the user has a valid SSO session in Auth0, a check needs to be made by sending a request to Auth0 with the `getSSOData` method from `auth0.js`. If there is SSO data present (meaning the user has an SSO session), then the user can be logged in by calling `signin`. - -```js -// components/auth/auth.service.js - -(function () { - - 'use strict'; - - angular - .module('app') - .service('authService', authService); - - function authService($rootScope, angularAuth0, authManager, jwtHelper) { - - function checkAuthOnRefresh() { - var token = localStorage.getItem('id_token'); - if (token) { - if (!jwtHelper.isTokenExpired(token)) { - if (!$rootScope.isAuthenticated) { - authManager.authenticate(); - } - } - } else { - angularAuth0.getSSOData(function (err, data) { - if (!err && data.sso) { - angularAuth0.signin({ - scope: 'openid name picture', - responseType: 'token' - }); - } - }); - } - } - } - -})(); -``` - -To guarantee that the callback for Lock's `authenticated` event is called before auth checking has started, wrap the `authService.checkAuthOnRefresh` method with `$timeout` in `app.run.js`: - -```js -// app.run.js - -(function () { - - 'use strict'; - - angular - .module('app') - .run(run); - - function run($timeout, authService) { - - $timeout(authService.checkAuthOnRefresh); - - } - -})(); -``` - -With SSO enabled in both applications, the user can log into one of them and then be automatically logged into the other. - -## Log Out from Auth0 - -To log the user out of their SSO session completely, call `logout` from `auth0.js`. You may optionally pass a `returnTo` key so that the user is taken back to the app once logout is complete. Your logout domain needs to be whitelisted in your [Client settings](${manage_url}/#/clients/${account.clientId}/settings). Be sure to pass the client ID for the appropriate application as a `client_id` key in the `logout` method. - -Note that you will also likely need to call the existing `logout` method from the `authService` that was created in the earlier steps so that the user's token and profile are removed from local storage for the app being used. - -```js -// components/home/home.controller.js - -(function () { - - 'use strict'; - - angular - .module('app') - .controller('HomeController', HomeController); - - function HomeController(authService, angularAuth0) { - - vm.logoutFromAuth0 = function() { - angularAuth0.logout({ - returnTo: 'http://localhost:3000/', - client_id: ${account.clientId} - }); - authService.logout(); - } - - } - -}()); -``` - diff --git a/articles/client-platforms/angularjs/12-passwordless.md b/articles/client-platforms/angularjs/12-passwordless.md deleted file mode 100644 index b5468cc95e..0000000000 --- a/articles/client-platforms/angularjs/12-passwordless.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: Passwordless -description: This tutorial demonstrates how to use passwordless authentication ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs-sample', - path: '12-Passwordless' -}) %> - -## Passwordless Authentication - -Passwordless connections in Auth0 allow users to log in without the need to remember a password. - -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 different applications. - -## Configuration - -Start by enabling a passwordless authentication connection in your Auth0 dashboard by navigating to [Connections > Passwordless](${manage_url}/#/connections/passwordless). - -![](/media/articles/connections/passwordless/passwordless-connections.png) - -## Update References - -Install and reference the necessary libraries. - -```bash -bower install angular-lock-passwordless -``` - -```html - - - - - - - - -``` - -## Add the Module Dependencies and Configure the Service - -```js -// app.js - -(function () { - - 'use strict'; - - angular - .module('app', ['auth0.lockPasswordless', 'angular-jwt', 'ui.router']) - .config(config); - - function config($stateProvider, lockPasswordlessProvider) { - - $stateProvider - .state('home', { - url: '/home', - controller: 'HomeController', - templateUrl: 'components/home/home.html', - controllerAs: 'vm' - }) - .state('login', { - url: '/login', - controller: 'LoginController', - templateUrl: 'components/login/login.html', - controllerAs: 'vm' - }); - - lockPasswordlessProvider.init({ - clientID: '${account.clientId}', - domain: '${account.namespace}' - }); - } - -})(); -``` - -## Implement the `login` Method - -```js -// components/auth/auth.service.js - -(function () { - - 'use strict'; - - angular - .module('app') - .service('authService', authService); - - function authService(lockPasswordless, authManager, $q, $state) { - - function login() { - lockPasswordless.emailcode(function(error, profile, id_token) { - if (error) { - alert("Error: " + error); - return; - } - localStorage.setItem('id_token', id_token); - authManager.authenticate(); - localStorage.setItem('profile', JSON.stringify(profile)); - - deferredProfile.resolve(profile); - $state.go('home'); - lockPasswordless.close(); - }); - } - - return { - login: login - } - } - -})(); -``` \ No newline at end of file diff --git a/articles/client-platforms/angularjs/13-api-authorization.md b/articles/client-platforms/angularjs/13-api-authorization.md deleted file mode 100644 index 05429dad69..0000000000 --- a/articles/client-platforms/angularjs/13-api-authorization.md +++ /dev/null @@ -1,266 +0,0 @@ ---- -title: OAuth 2.0 API Authorization -description: This tutorial demonstrates how to use API authorization ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs-sample', - path: '13-OAuth2-Authorization' -}) %> - -<%= include('../../_includes/_api_auth_intro') %> - -<%= include('../../_includes/_compat_warning') %> - -### Before Starting - -## Enable OAuth 2.0 API Authorization - -<%= include('../../_includes/_configure_oauth2aas') %> - -<%= include('../../_includes/_new_app_no_sample') %> - -![App Dashboard](/media/articles/angularjs/spa_client_create.png) - -Be sure to register the URL of your app in the Allowed Callback URLs in your Application Settings. - -## Create a Resource Server (API) - -<%= include('../../_includes/_new_api') %> - -![Create API](/media/articles/api-auth/api-5.png) -![Update Scopes](/media/articles/api-auth/api-6.png) - -Take note of the API identifier and scopes you defined in the dashboard, as they will be used later. - -## Add the Module Dependencies and Configure the Service - -First, install the necessary dependencies and add references to them in your `index.html`. - -```bash -bower install angular-auth0 angular-jwt -``` - -```html - - - - - - -``` - -Add the `auth0.auth0`, `angular-jwt` and `ui.router` module dependencies to your Angular app definition and configure `auth0.js` by calling the `init` method of the `angularAuth0Provider`. - -```js -// app.js -(function () { - - 'use strict'; - - angular - .module('app', ['auth0.lock', 'angular-jwt', 'ui.router']) - .config(config); - - function config($stateProvider, angularAuth0Provider, $urlRouterProvider) { - - $stateProvider - .state('home', { - url: '/home', - controller: 'HomeController', - templateUrl: 'components/home/home.html', - controllerAs: 'vm' - }) - .state('ping', { - url: '/ping', - controller: 'PingController', - templateUrl: 'components/ping/ping.html', - controllerAs: 'vm' - }); - - // Initialization for the angular-auth0 library - angularAuth0Provider.init({ - clientID: '${account.clientId}', - domain: '${account.namespace}', - callbackURL: 'YOUR_CALLBACK_URL' - }); - - $urlRouterProvider.otherwise('/home'); - } - -})(); -``` - -Add a call to `authService.registerAuthenticationListener()` and `authManager.checkAuthOnRefresh()` in the `run` method. - -```js -// app.run.js -(function () { - - 'use strict'; - - angular - .module('app') - .run(run); - - function run($rootScope, authService, authManager) { - // Put the authService on $rootScope so its methods - // can be accessed from the nav bar - $rootScope.authService = authService; - // Process the auth token if it exists and fetch the profile - authService.registerAuthenticationListener(); - // Use the authManager from angular-jwt to check for - // the user's authentication state when the page is - // refreshed and maintain authentication - authManager.checkAuthOnRefresh(); - } - -})(); -``` - -## Login - -On a successful login, the hash in the URL bar will contain the user's `access_token` and `id_token`. These values can be retrieved and used with `angularAuth0.parseHash`. - -```js -// components/auth/auth.service.js -(function () { - - 'use strict'; - - angular - .module('app') - .service('authService', authService); - - function authService(angularAuth0, authManager) { - - function login() { - angularAuth0.login({ - responseType: 'id_token token', - scope: 'openid profile {API SCOPES}', - audience: '{API IDENTIFIER}' - }); - } - - function registerAuthenticationListener() { - var result = angularAuth0.parseHash(window.location.hash); - - if (result && result.idToken) { - localStorage.setItem('access_token', result.accessToken); - localStorage.setItem('id_token', result.idToken); - authManager.authenticate(); - } else if (result && result.error) { - alert('error: ' + result.error); - } - } - - return { - login: login, - registerAuthenticationListener: registerAuthenticationListener - } - - } -})(); -``` - -Provide a control for the user to log in which calls the `login` method on the `authService`. - -```html - - -
-

You are not yet authenticated. Log in.

-
-
-

Thank you for logging in! Log out.

-
-``` - -The `access_token` retrieved from the authentication process can be used to make authenticated API calls. Remember that using `response_type: token` means that you cannot get a `refresh_token`. The `id_token` can be used in your application for basic profile data. If you want to retrieve additional profile data for the user, you can use the `userinfo` endpoint with the `access_token` in the `Authorization` header. For more information, see [our API documentation](/api/authentication/reference#get-user-info). - -## Making an Authenticated API Call - -To attach the user's JWT as an `Authorization` header, we could write a service that returns a token and attaches it to all HTTP requests. However, the **angular-jwt** library already provides this functionality. Ensure that **angular-jwt** is added to your app as a dependency and configure it with `jwtOptionsProvider` in the `config` block. A `tokenGetter` function needs to be provided to inform **angular-jwt** how it should be retrieving the user's JWT. - -```js -// app.js - -(function () { - - 'use strict'; - - angular - .module('app', ['auth0.auth0', 'angular-jwt', 'ui.router']) - .config(config); - - function config(jwtOptionsProvider, $httpProvider) { - - // Configuration for angular-jwt - jwtOptionsProvider.config({ - tokenGetter: ['options', function (options) { - if (options && options.url.substr(options.url.length - 5) == '.html') { - return null; - } - return localStorage.getItem('access_token'); - }], - whiteListedDomains: ['localhost'] - }); - - // Add the jwtInterceptor to the array of HTTP interceptors - // so that JWTs are attached as Authorization headers - $httpProvider.interceptors.push('jwtInterceptor'); - } - -})(); -``` - -When you use `$http` to make requests to your API, the `access_token` will be attached as an `Authorization` header. - -```js -// components/ping/ping.controller.js -... -vm.ping = function () { - $http.get('{API URL}') - .then(function (result) { - vm.pingResult = result.data.text; - }, function (error) { - console.log(error); - }); -} -``` - -<%= include('../../_includes/_create_resource_server') %> - -## Log Out - -In this implementation, a logout involves simply deleting the saved tokens from `localStorage` and calling the `unauthenticate` method of `authManager`. - -```js -// components/auth/auth.service.js - -(function () { - - 'use strict'; - - angular - .module('app') - .service('authService', authService); - - function authService(authManager) { - - // Logging out just requires removing the user's - // access_token and id_token - function logout() { - localStorage.removeItem('access_token'); - localStorage.removeItem('id_token'); - authManager.unauthenticate(); - } - - return { - ... - logout: logout - } - } -})(); -``` diff --git a/articles/client-platforms/angularjs/_includes/_authservice.md b/articles/client-platforms/angularjs/_includes/_authservice.md deleted file mode 100644 index 4715654ee6..0000000000 --- a/articles/client-platforms/angularjs/_includes/_authservice.md +++ /dev/null @@ -1,67 +0,0 @@ -## Create an Auth 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. - -At the most basic level, authentication with Auth0's Lock widget requires that the user send their credentials to Auth0 to be verified. If authentication is successful, a [JSON Web Token (JWT)](https://jwt.io/introduction) will be signed and sent back to the user. To do this, you can use Lock's `show` method to open the widget and then listen for successful authentication with the `authenticated` event. When the `authenticated` event is fired, the user's `id_token` will be returned which can then be used to get the user's profile with Lock's `getProfile` method. - -The code for this should be kept in the `authService`, but it will be necessary to use the code in Angular's `run` block. To keep things clean, we can put it all in a single method called `registerAuthenticationListener`. - -```js -// components/auth/auth.service.js - -(function () { - - 'use strict'; - - angular - .module('app') - .service('authService', authService); - - function authService(lock, authManager) { - - function login() { - lock.show(); - } - - // Set up the logic for when a user authenticates - // This method is called from app.run.js - function registerAuthenticationListener() { - lock.on('authenticated', function (authResult) { - localStorage.setItem('id_token', authResult.idToken); - authManager.authenticate(); - }); - } - - return { - login: login, - registerAuthenticationListener: registerAuthenticationListener - } - } -})(); -``` - -When the user successfully authenticates, their JWT will be saved in local storage as `id_token`. - -Now the `registerAuthenticationListener` method can be called in the `run` block so that `authenticated` events can be listened for when the app runs. - -```js -// app.run.js - -(function () { - - 'use strict'; - - angular - .module('app') - .run(run); - - function run(authService, lock) { - - // Register the authentication listener that is - // set up in auth.service.js - authService.registerAuthenticationListener(); - - } - -})(); -``` \ No newline at end of file diff --git a/articles/client-platforms/angularjs/_includes/_configuration.md b/articles/client-platforms/angularjs/_includes/_configuration.md deleted file mode 100644 index 151d9b515b..0000000000 --- a/articles/client-platforms/angularjs/_includes/_configuration.md +++ /dev/null @@ -1,67 +0,0 @@ -## Add the Module Dependencies and Configure the Service - -Add the `auth0.lock`, `angular-jwt` and `ui.router` module dependencies to your Angular app definition and configure the Lock widget by calling the `init` method on `lockProvider`. This is where your Auth0 client ID and domain can be set up. - -```js -// app.js - -(function () { - - 'use strict'; - - angular - .module('app', ['auth0.lock', 'angular-jwt', 'ui.router']) - .config(config); - - function config($stateProvider, lockProvider, $urlRouterProvider) { - - $stateProvider - .state('home', { - url: '/home', - controller: 'HomeController', - templateUrl: 'components/home/home.html', - controllerAs: 'vm' - }); - - lockProvider.init({ - clientID: '${account.clientId}', - domain: '${account.namespace}' - }); - - $urlRouterProvider.otherwise('/home'); - } - -})(); -``` - -Add a call to `authService.registerAuthenticationListener()` and to `lock.interceptHash()` in the `run` block of your application. - -```js -// app.run.js - -(function () { - - 'use strict'; - - angular - .module('app') - .run(run); - - run.$inject = ['$rootScope', 'authService', 'lock']; - - function run($rootScope, authService, lock) { - // Put the authService on $rootScope so its methods - // can be accessed from the nav bar - $rootScope.authService = authService; - - // Register the authentication listener that is - // set up in auth.service.js - authService.registerAuthenticationListener(); - - // Register the synchronous hash parser - // when using UI Router - lock.interceptHash(); - } - -})(); -``` \ No newline at end of file diff --git a/articles/client-platforms/angularjs/_includes/_dependencies.md b/articles/client-platforms/angularjs/_includes/_dependencies.md deleted file mode 100644 index f50d2b74fb..0000000000 --- a/articles/client-platforms/angularjs/_includes/_dependencies.md +++ /dev/null @@ -1,47 +0,0 @@ -## Install the Dependencies - -The easiest way to add authentication to any app with Auth0 is to use the Lock widget. To use the Lock widget in your Angular 1.x apps, and to help manage authentication related tasks, you will need to install several libraries: - -* auth0-lock -* angular-lock -* angular-jwt - -**Installing Dependencies with npm** - -```bash -npm install angular-lock angular-jwt -``` - -or - -**Installing Dependencies with Bower** - -```bash -bower install auth0-lock angular-lock angular-jwt -``` - -Once installed, the scripts for these libraries can be included in your project. - -**After Installation with npm** - -```html - - - -``` - -or, - -**After Installation with Bower** - -```html - - - -``` - -To ensure that the Lock widget displays properly on all devices, add a `meta` tag to set the `viewport`. - -```html - -``` \ No newline at end of file diff --git a/articles/client-platforms/angularjs/_includes/_login.md b/articles/client-platforms/angularjs/_includes/_login.md deleted file mode 100644 index e340e0afe4..0000000000 --- a/articles/client-platforms/angularjs/_includes/_login.md +++ /dev/null @@ -1,103 +0,0 @@ -## Provide Controls for Login and Logout - -The `authService` has a method for showing the Lock widget, but it hasn't been called anywhere yet. The place from which this method is called depends on how your application is set up, but it is common to do so from a header toolbar component or from a dedicated **login** or **user** view. - -### Login - -Start by creating a **login** controller and view. - -```js -// components/login/login.controller.js - -(function () { - 'use strict'; - - angular - .module('app') - .controller('LoginController', LoginController); - - function LoginController(authService) { - - var vm = this; - - vm.authService = authService; - - } -})(); -``` - -With the `authService` injected in this controller, the `login` method can now be called from the view. - -```html - - - -``` - -When the user clicks the **Log In** button, the [Lock widget](/libraries/lock) will be displayed. - -Lastly, add the **login** state to your `$stateProvider` configuration in `app.js`. - -```js -// app.js - -(function () { - - function config($stateProvider, lockProvider, $urlRouterProvider) { - - $stateProvider - .state('home', { - url: '/home', - controller: 'HomeController', - templateUrl: 'components/home/home.html', - controllerAs: 'vm' - }) - .state('login', { - url: '/login', - controller: 'LoginController', - templateUrl: 'components/login/login.html', - controllerAs: 'vm' - }); - } - -})(); -``` - -### Logout - -Since JWT authentication is stateless, logging the user out is simply a matter of removing the user's `id_token` from local storage. Calling `authManager.unauthenticate` will set the user's application-wide authentication status to `false`. - -```js -// components/auth/auth.service.js - -(function () { - - 'use strict'; - - angular - .module('app') - .service('authService', authService); - - function authService(lock, authManager) { - - function logout() { - localStorage.removeItem('id_token'); - authManager.unauthenticate(); - } - - } -})(); -``` - -Remember to also add a **Log Out** button which calls this function. In our example, we call this function from `HomeController`, so this button can be added in `home.html`. - -```html - - -
-

Thank you for logging in!

- -
-``` - -<%= include('../../_includes/_persisting_state') %> diff --git a/articles/client-platforms/angularjs/_includes/_prerequisite.md b/articles/client-platforms/angularjs/_includes/_prerequisite.md deleted file mode 100644 index 22c4bbc864..0000000000 --- a/articles/client-platforms/angularjs/_includes/_prerequisite.md +++ /dev/null @@ -1,6 +0,0 @@ -### Prerequisites -::: panel-info System Requirements -This tutorial and seed project have been tested with the following: - -* Angular 1.5.8 -::: \ No newline at end of file diff --git a/articles/client-platforms/angularjs/dashboard-default.md b/articles/client-platforms/angularjs/dashboard-default.md deleted file mode 100644 index 13fe3167d2..0000000000 --- a/articles/client-platforms/angularjs/dashboard-default.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Auth0 Angular 1.x Tutorial -default: true -description: This tutorial demonstrates how to use the Auth0 with Angular 1.x applications ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-angularjs-sample', - path: '01-Login', - requirements: [ - 'Angular 1.5.8' - ] -}) %> - -<%= include('../../_includes/_callback_url') %> - -<%= include('_includes/_dependencies') %> - -<%= include('_includes/_configuration') %> - -<%= include('_includes/_authservice') %> - -<%= include('_includes/_login') %> \ No newline at end of file diff --git a/articles/client-platforms/angularjs/index.yml b/articles/client-platforms/angularjs/index.yml deleted file mode 100644 index d948f92d5b..0000000000 --- a/articles/client-platforms/angularjs/index.yml +++ /dev/null @@ -1,32 +0,0 @@ -title: Angular 1.x -alias: - - angular - - angularjs - - angular-1 -language: - - Javascript -framework: - - AngularJS -image: /media/platforms/angular.png -tags: - - quickstart -snippets: - dependencies: client-platforms/angularjs/dependencies - setup: client-platforms/angularjs/setup - use: client-platforms/angularjs/use -seo_alias: angularjs -default_article: dashboard-default -articles: - - 00-intro - - 01-login - - 02-custom-login - - 03-session-handling - - 04-user-profile - - 05-linking-accounts - - 06-rules - - 07-authorization - - 08-calling-apis - - 09-mfa - - 10-customizing-lock - - 11-sso - - 12-passwordless diff --git a/articles/client-platforms/aurelia/01-login.md b/articles/client-platforms/aurelia/01-login.md deleted file mode 100644 index 3d088c3b22..0000000000 --- a/articles/client-platforms/aurelia/01-login.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: Login -default: true -description: This tutorial demonstrates how to use Auth0 to add authentication and authorization to Aurelia apps -budicon: 448 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-aurelia-samples', - path: '01-Login', - requirements: [ - 'NodeJS 5.0.0', - 'JSPM 0.16.27', - 'Aurelia-framework 1.0.0-beta.1.1.0' - ] -}) %> - -${include('../\_callback')} - -## 1. Add the Auth0 Scripts - -Add **Lock** to your `index.html` file and set the viewport. - -${snippet(meta.snippets.dependencies)} - -## 2. Import Dependencies and Set Up Auth0Lock - -Later we'll see how to make authenticated HTTP requests, and for that, we'll need `HttpClient` from `aurelia-fetch-client`. We also need to create a new instance of `Auth0Lock`. - -${snippet(meta.snippets.setup)} - -We also set the `isAuthenticated` property to false to start with, but this value will be changed later on to reflect the user's authentication status. - -## 2. Set Up the Login and Logout Methods - -The `login` and `logout` methods will be bound to button clicks in the template. - -We first need to set up the buttons in our template. At the same time, we'll create a button that will be used for authenticated HTTP requests. - -${snippet(meta.snippets.template)} - -The `login` method will show the Lock widget and save the user's profile and JWT in local storage if authentication is successful and set `isAuthenticated` to true. - -${snippet(meta.snippets.login)} - -To log the user out, we just need to remove the JWT and profile from local storage, and then set `isAuthenticated` to false. - -${snippet(meta.snippets.logout)} - -__Note:__ There are multiple ways of implementing login. The example above displays the Lock Widget. However you may implement your own login UI by changing the line `` to ``. - -## 3. Make Secure Calls to an API - -To make secure calls to an API, attach the user's JWT as an `Authorization` header to the HTTP request. This is done in the `RequestInit` object as the second argument to the `fetch` call. - -${snippet(meta.snippets.http)} - -## 4. Configure All HTTP Calls to be Secure - -If you wish to attach the user's JWT as an `Authorization` header on all HTTP calls, you can configure the `HttpClient` to do so. - -${snippet(meta.snippets.configurehttp)} - -You can then remove the `RequestInit` object (the second argument of `fetch`) from individual HTTP calls. - -## 5. Optional: Decode the User's JWT to Check Expiry - -Checking whether the user's JWT has expired is useful for conditionally showing or hiding elements and limiting access to certain routes. This can be done with the `jwt-decode` package and a simple function. First, install the package. - -${snippet(meta.snippets.jwtdecode)} - -Next, we can create a utilities file that will have a function that decodes the JWT and checks whether it has expired. - -${snippet(meta.snippets.tokenisexpired)} - -With this method in place, we can now call it in the constructor so that the user's authentication state is preserved if the page is refreshed. - -${snippet(meta.snippets.constructorexpiry)} - -## 6. Check Whether a Route Can Be Activated - -Aurelia's `canActivate` method can be used to check whether a route can be navigated to. If the user's JWT has expired, we don't want them to be able to navigate to private routes. - -${snippet(meta.snippets.routing)} - -This hook will redirect the user to some other route (`public` in this case) if the user's JWT has expired. - -<%= include('../_includes/_persisting_state') %> diff --git a/articles/client-platforms/aurelia/index.yml b/articles/client-platforms/aurelia/index.yml deleted file mode 100644 index d578c38d92..0000000000 --- a/articles/client-platforms/aurelia/index.yml +++ /dev/null @@ -1,28 +0,0 @@ -title: Aurelia -community: true -alias: - - aurelia - - aureliajs -language: - - Javascript -framework: - - Aurelia -image: -tags: - - quickstart -snippets: - configurehttp: client-platforms/aurelia/configurehttp - constructorexpiry: client-platforms/aurelia/constructorexpiry - dependencies: client-platforms/aurelia/dependencies - http: client-platforms/aurelia/http - jwtdecode: client-platforms/aurelia/jwtdecode - login: client-platforms/aurelia/login - logout: client-platforms/aurelia/logout - routing: client-platforms/aurelia/routing - setup: client-platforms/aurelia/setup - template: client-platforms/aurelia/template - tokenisexpired: client-platforms/aurelia/tokenisexpired -seo_alias: aurelia -default_article: 01-login -articles: - - 01-login diff --git a/articles/client-platforms/cyclejs/01-login.md b/articles/client-platforms/cyclejs/01-login.md deleted file mode 100644 index 7678a25546..0000000000 --- a/articles/client-platforms/cyclejs/01-login.md +++ /dev/null @@ -1,87 +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 ---- - -::: panel-info System Requirements -This tutorial has been tested with the following: - -* NodeJS 6.3 -* npm 3.10.3 -* @cycle/xstream-run 3.0.3 -* cyclejs-auth0 1.1.0 -::: - - - -${include('../\_callback')} - -## 1. Install the `cyclejs-auth0` Package - -To install both `cyclejs-auth0` and the `cyclic-router` (needed to parse the token sent by 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. Configure Secure Calls to Your API - -To configure secure calls to the API you are creating, you need to decorate all your newly secured component's HTTP calls with the [JSON Web Token](/jwt) that has been stored in `localStorage`. To do that, you can set a decorator that will be called on each HTTP request and where you can add the `Authorization` header. - -${snippet(meta.snippets.securize)} - -## 5. Retrieve the User Profile and Display User Information - -Once a component is protected, it is given a `props` object that contains a `token$` 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 `getProfile` 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. - -## 6. 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/client-platforms/cyclejs/index.yml b/articles/client-platforms/cyclejs/index.yml deleted file mode 100644 index c4f0f9ed4d..0000000000 --- a/articles/client-platforms/cyclejs/index.yml +++ /dev/null @@ -1,23 +0,0 @@ -title: Cycle -community: true -alias: - - cyclejs -language: - - JavaScript -framework: - - Cycle.js -image: /media/platforms/cyclejs.svg -tags: - - quickstart -snippets: - dependencies: client-platforms/cyclejs/dependencies - setup: client-platforms/cyclejs/setup - configure: client-platforms/cyclejs/configure - securize: client-platforms/cyclejs/securize - query: client-platforms/cyclejs/query - use: client-platforms/cyclejs/use - logout: client-platforms/cyclejs/logout -seo_alias: cyclejs -default_article: 01-login -articles: - - 01-login diff --git a/articles/client-platforms/ember2js/01-login.md b/articles/client-platforms/ember2js/01-login.md deleted file mode 100644 index 2f6e4c1691..0000000000 --- a/articles/client-platforms/ember2js/01-login.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -title: Login -default: true -description: This tutorial will show you how to use the Auth0 EmberJS 2 SDK to add authentication and authorization to your web app. -budicon: 448 ---- - -You can get started by either downloading the seed project or if you would like to add Auth0 to an existing application you can follow the tutorial steps. - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-emberjs2-sample', - path: '01-Login', - requirements: [ - 'Ember 2.5.0', - 'jQuery 1.11.3', - 'Ember Simple Auth 1.1.0' - ] -}) %> - -__Note:__ This quickstart and seed project are for Ember >= 2.x.x. - -${include('../\_callback')} - -## 1. Install the add-on - -Auth0 Ember simple-auth is an add-on for the [simple-auth](http://ember-simple-auth.com) library, and it's installed via [ember-cli](http://www.ember-cli.com). - -To install this add-on and its dependencies, `cd` to your project directory and execute the following commands: - -``` -ember install ember-simple-auth -ember install auth0/auth0-ember-simple-auth -ember generate scaffold-auth0 -bower install auth0-lock#9.2.3 jsrsasign#5.0.1 --save -``` - -__Note:__ If you are not already using ember-cli, see [ember-cli migration](https://ember-cli.com/user-guide/#migrating-an-existing-ember-project-that-doesnt-use-ember-cli). - -## 2. Configure the add-on - -```js -// config/environment.js -ENV['ember-simple-auth'] = { - authenticationRoute: 'index', - routeAfterAuthentication: 'protected', - routeIfAlreadyAuthenticated: 'protected' -}; - -ENV['auth0-ember-simple-auth'] = { - clientID: "<%= account.clientId %>", - domain: "<%= account.namespace %>" -} -``` - -If you are using a content security policy, add -`https://cdn.auth0.com` to both the `font-src` and `script-src` contentSecurityPolicy entries and `<%= account.namespace %>` to the `connect-src` entry: - -```js -// config/environment.js -ENV['contentSecurityPolicy'] = { - 'font-src': "'self' data: https://cdn.auth0.com", - 'style-src': "'self' 'unsafe-inline'", - 'script-src': "'self' 'unsafe-eval' 'unsafe-inline' https://cdn.auth0.com", - 'connect-src': "'self' http://localhost:* <%= account.namespace %>" -}; -``` - -## 3. Extend routes - -Extend a route and set [user-configurable options](/libraries/lock/customization): - -```js -// app/routes/application.js -import Ember from 'ember'; -import ApplicationRouteMixin from 'ember-simple-auth/mixins/application-route-mixin'; - -export default Ember.Route.extend(ApplicationRouteMixin, { - - actions: { - login () { - var lockOptions = { - auth: { - params: { scope: 'openid' } - } - }; - this.get('session').authenticate('simple-auth-authenticator:lock', lockOptions); - }, - - logout () { - this.get('session').invalidate(); - } - } -}); -``` - -Add a route for signing in: - -```js -// app/routes/login.js -import Ember from 'ember'; -import UnauthenticatedRouteMixin from 'ember-simple-auth/mixins/unauthenticated-route-mixin'; - -export default Ember.Route.extend(UnauthenticatedRouteMixin); -``` - -and add a route for authenticated users: - -```js -// app/routes/home.js -import Ember from 'ember'; -import AuthenticatedRouteMixin from 'ember-simple-auth/mixins/authenticated-route-mixin'; - -export default Ember.Route.extend(AuthenticatedRouteMixin); -``` - -## 4. Login and logout - -Add login and logout links. These routes are handled according to the simple-auth configuration settings. - -```handlebars -{{#if session.isAuthenticated}} - Logout -{{else}} - Login -{{/if}} -``` - -## 5. Authenticated user session data - -Once a user is authenticated, session data received from the popup window will be stored in `localStorage` under the `ember_simple_auth:session` key. This session object is a JSON object that contains user profile data, a JWT token and an access token. - -You can access this session information in the ember templates by using `{{session.data.authenticated}}`. For example, to say "Hi" and show the user's associated avatar: - -```handlebars - -``` - -## 6. Using a JWT token to make API requests - -To make an API request, add the user's [JWT token](/jwt) to an `Authorization` HTTP header: - -```js -fetch('/api/foo', { - method: 'GET', - cache: false, - headers: { - 'Authorization': 'Bearer <%= "${session.data.authenticated.jwt}" %>' - } -}).then(function (response) { - // use response -}); -``` - -<%= include('../_includes/_persisting_state') %> - -### Additional Information - -For Additional information on how to use this SDK, see [Auth0 Ember simple auth](http://github.com/auth0/auth0-ember-simple-auth/blob/master/README.md). diff --git a/articles/client-platforms/ember2js/index.yml b/articles/client-platforms/ember2js/index.yml deleted file mode 100644 index 5640f4bd25..0000000000 --- a/articles/client-platforms/ember2js/index.yml +++ /dev/null @@ -1,16 +0,0 @@ -title: Ember 2 -community: true -alias: - - ember 2 - - emberjs 2 -language: - - Javascript -framework: - - Ember 2 -image: /media/platforms/emberjs.png -tags: - - quickstart -seo_alias: emberjs 2 -default_article: 01-login -articles: - - 01-login diff --git a/articles/client-platforms/emberjs/01-login.md b/articles/client-platforms/emberjs/01-login.md deleted file mode 100644 index ee876c8512..0000000000 --- a/articles/client-platforms/emberjs/01-login.md +++ /dev/null @@ -1,164 +0,0 @@ ---- -title: Login -default: true -description: This tutorial will show you how to use the Auth0 EmberJS SDK to add authentication and authorization to your web app. -budicon: 448 ---- - -You can get started by either downloading the seed project or if you would like to add Auth0 to an existing application you can follow these tutorial steps. - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-emberjs-spa', - path: '00-Starter-Seed', - requirements: [ - 'NodeJS 0.12.7', - 'Ember 1.12.0', - 'jQuery 1.11.1', - 'Ember Simple Auth 1.1.0' - ] -}) %> - -${include('../\_callback')} - -## 1. Install the Add-On - -Auth0 Ember simple-auth is an add-on for the [simple-auth](http://ember-simple-auth.com) library, and is installed via [ember-cli](http://www.ember-cli.com). - -To install this add-on and its dependencies, `cd` to your project directory and execute the following commands: - -```bash -ember install auth0-ember-simple-auth -ember generate scaffold-auth0 -``` - -__Note:__ If you are not already using ember-cli, see [ember-cli migration](http://ember-cli.com/user-guide/#migrating-an-existing-ember-project-that-doesnt-use-ember-cli). - -## 2. Configure the Add-On - -```js -// config/environment.js - -ENV['simple-auth'] = { - authorizer: 'simple-auth-authorizer:jwt', - authenticationRoute: 'sign_in', - routeAfterAuthentication: 'home', - routeIfAlreadyAuthenticated: 'home' -} - -ENV['auth0-ember-simple-auth'] = { - clientID: "<%= account.clientId %>", - domain: "<%= account.namespace %>" -} -``` - -If using a content security policy, add -`https://cdn.auth0.com` to both the `font-src` and `script-src` contentSecurityPolicy entries and `<%= account.namespace %>` to the `connect-src` entry: - -```js -// config/environment.js -ENV['contentSecurityPolicy'] = { - 'font-src': "'self' data: https://cdn.auth0.com", - 'style-src': "'self' 'unsafe-inline'", - 'script-src': "'self' 'unsafe-eval' 'unsafe-inline' https://cdn.auth0.com <%= account.namespace %>", - 'connect-src': "'self' http://localhost:* <%= account.namespace %>" -}; -``` - -## 3. Extend Routes - -Extend a route and set [user-configurable options](/libraries/lock/customization): - -```js -// app/routes/application.js -import Ember from 'ember'; -import ApplicationRouteMixin from 'simple-auth/mixins/application-route-mixin'; - -export default Ember.Route.extend(ApplicationRouteMixin, { - actions: { - sessionRequiresAuthentication: function(){ - // For a list of user-configurable options, see: - // https:///libraries/lock/customization - - // This will launch lock.js in popup mode - var lockOptions = { - auth: { - params: { scope: 'openid' } - } - }; - - this.get('session').authenticate('simple-auth-authenticator:lock', lockOptions); - } - } -}); -``` - -Add a route for signing in: - -```js -// app/routes/sign_in.js - -import Ember from 'ember'; -import UnauthenticatedRouteMixin from 'simple-auth/mixins/unauthenticated-route-mixin'; - -export default Ember.Route.extend(UnauthenticatedRouteMixin); -``` - -and add a route for authenticated users: - -```js -// app/routes/home.js - -import Ember from 'ember'; -import AuthenticatedRouteMixin from 'simple-auth/mixins/authenticated-route-mixin'; - -export default Ember.Route.extend(AuthenticatedRouteMixin); -``` - -## 4. Login and Logout - -Add login and logout links. These routes are handled according to the simple-auth configuration settings. - -```handlebars -{{#if session.isAuthenticated}} - Logout -{{else}} - Login -{{/if}} -``` - -## 5. Authenticated User Session Data - -Once a user is authenticated, session data received from the popup window will be stored in `localStorage` under the `ember_simple_auth:session` key. This session object is a JSON object that contains user profile data, a JWT token and an access token. - -You can access this session information in the Ember templates by using `{{session.secure}}`. For example, to say "Hi" and show the user's associated avatar: - -```handlebars - -``` - -## 6. Using a JWT Token to Make API Requests - -To make an API request, add the user's [JWT token](/jwt) to an `Authorization` HTTP header: - -```js -fetch('/api/foo', { - method: 'GET', - cache: false, - headers: { - 'Authorization': 'Bearer <%= "${session.secure.jwt}" %>' - } -}).then(function (response) { - // use response -}); -``` - -<%= include('../_includes/_persisting_state') %> - -### Additional information - -For Additional information on how to use this SDK, see [Auth0 Ember simple auth](http://github.com/auth0/auth0-ember-simple-auth/blob/master/README.md). diff --git a/articles/client-platforms/emberjs/index.yml b/articles/client-platforms/emberjs/index.yml deleted file mode 100644 index c0b8c23286..0000000000 --- a/articles/client-platforms/emberjs/index.yml +++ /dev/null @@ -1,16 +0,0 @@ -title: Ember -community: true -alias: - - ember - - emberjs -language: - - Javascript -framework: - - EmberJS -image: /media/platforms/emberjs.png -tags: - - quickstart -seo_alias: emberjs -default_article: 01-login -articles: - - 01-login diff --git a/articles/client-platforms/jquery/00-intro.md b/articles/client-platforms/jquery/00-intro.md deleted file mode 100644 index 6dac4a4e4e..0000000000 --- a/articles/client-platforms/jquery/00-intro.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Introduction -description: A multi-step quickstart guide to setup and manage authentication in your jQuery app using Auth0. -budicon: 715 ---- - -This multistep quickstart guide will walk you through setting up and managing authentication in your jQuery apps using Auth0. - -<%= include('../../_includes/_new_app') %> - -## Dependencies - -To integrate your jQuery application with Auth0, add the Lock widget. You can get it from Bower or from the Auth0 CDN. - -**Bower** - -```bash -bower install auth0-lock -``` - -**CDN** - -```html - -``` diff --git a/articles/client-platforms/jquery/01-login.md b/articles/client-platforms/jquery/01-login.md deleted file mode 100644 index e4777af6e7..0000000000 --- a/articles/client-platforms/jquery/01-login.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: Login -description: This tutorial demonstrates how to use the Auth0 jQuery SDK to add authentication and authorization to your web app -budicon: 448 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-jquery-samples', - path: '01-Login', - requirements: [ - 'jQuery 3.1.0' - ] -}) %> - -${include('../\_callback')} - -<%= include('_includes/_dependencies') %> - -<%= include('_includes/_configuration') %> - -<%= include('_includes/_login') %> - -## 4. Retrieve the User Profile and Display User Information - -Use the `id_token` to retrieve the user profile and display the user's nickname: - -```js -//retrieve the profile - -var id_token = localStorage.getItem('id_token'); -if (id_token) { - lock.getProfile(id_token, function (err, profile) { - if (err) { - return alert('There was an error getting the profile: ' + err.message); - } - // Display user information - $('.nickname').text(profile.nickname); - $('.avatar').attr('src', profile.picture); - }); -} -``` - -```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. Log Out - -In this implementation, a logout involves simply deleting the saved token from `localStorage` and redirecting the user to the home page: - -```js -// app.js - -localStorage.removeItem('id_token'); -userProfile = null; -window.location.href = "/"; -``` - -<%= include('../_includes/_persisting_state') %> diff --git a/articles/client-platforms/jquery/02-custom-login.md b/articles/client-platforms/jquery/02-custom-login.md deleted file mode 100644 index 66c0de584a..0000000000 --- a/articles/client-platforms/jquery/02-custom-login.md +++ /dev/null @@ -1,210 +0,0 @@ ---- -title: Custom Login -description: This tutorial demonstrates how to use the Auth0 library to add custom authentication and authorization to your web app. -budicon: 448 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-jquery-samples', - path: '02-Custom-Login', - requirements: [ - 'jQuery 3.1.0' - ] -}) %> - -In the [previous step](/quickstart/spa/jquery/01-login), we enabled login with the Auth0 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-info 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 jQuery custom login sample](https://github.com/auth0-samples/auth0-jquery-samples/tree/auth0js-v7/02-Custom-Login). - -Auth0.js version 8 verifies ID tokens during authentication transactions. Only tokens which are signed with the RS256 algorithm can be verified on the client side, meaning that your Auth0 client must be configured to sign tokens with RS256. See the [auth0.js migration guide](https://auth0.com/docs/libraries/auth0js/migration-guide#switching-from-hs256-to-rs256) for more details. -::: - -## Getting Started - -Include the auth0.js library in your application. It can be retrieved from Auth0's CDN. - -```html - - - -``` - -## Create a Login Template - -Create a template which has a `form` for users to submit their credentials. The form should include fields for the user's `username` and `password`, as well as controls for triggering either a login, signup, or social authentication transaction. A button for allowing the user to log out can also be included. - -```html - - - - - -``` -The buttons in this template will have event listeners registered from an `app.js` file. This will be the file from which authentication transaction methods will be called from auth0.js. - -## Create the Authentication Functions - -All authentication transactions should be handled from a single JavaScript file which can act as a service. The service requires functions named `login`, `signup`, and `loginWithGoogle` which all make calls to the appropriate auth0.js methods to handle those actions. - -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 client. A `responseType` of `token id_token` should also be specified. - -The `login` and `signup` functions 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 user's access token and ID token are saved into local storage if the transaction is successful. - -The `signup` method is a redirect-based flow and the authentication result is handled by the `parseHash` function. This function 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 UI changes to reflect that the user has logged in. - -```js -// app.js - -$(document).ready(function() { - - auth = new auth0.WebAuth({ - domain: '${account.namespace}', - clientID: '${account.clientId}', - redirectUri: window.location.href, - responseType: 'token id_token' - }); - - $('#btn-login').on('click', login); - $('#btn-register').on('click', signup); - $('#btn-google').on('click', loginWithGoogle); - $('#btn-logout').on('click', logout); - - function login() { - var username = $('#username').val(); - var password = $('#password').val(); - auth.client.login({ - realm: 'Username-Password-Authentication', - username: username, - password: password, - }, function(err, authResult) { - if (err) { - alert("something went wrong: " + err.message); - return - } - if (authResult && authResult.idToken && authResult.accessToken) { - setUser(authResult); - show_logged_in(); - } - }); - } - - function signup() { - var username = $('#username').val(); - var password = $('#password').val(); - auth.redirect.signupAndLogin({ - connection: 'Username-Password-Authentication', - email: username, - password: password, - }, function(err) { - if (err) alert("something went wrong: " + err.message); - }); - } - - function loginWithGoogle() { - auth.authorize({ - connection: 'google-oauth2' - }); - } - - function logout() { - localStorage.removeItem('id_token'); - localStorage.removeItem('access_token'); - window.location.href = "/"; - } - - function show_logged_in(username) { - $('form.form-signin').hide(); - $('div.logged-in').show(); - } - - function show_sign_in() { - $('div.logged-in').hide(); - $('form.form-signin').show(); - } - - function parseHash() { - var token = localStorage.getItem('id_token'); - if (token) { - show_logged_in(); - } else { - auth.parseHash(function(err, authResult) { - if (authResult && authResult.accessToken && authResult.idToken) { - window.location.hash = ''; - setUser(authResult); - show_logged_in(); - } else if (authResult && authResult.error) { - alert('error: ' + authResult.error); - show_sign_in(); - } - }); - } - } - - function setUser(authResult) { - localStorage.setItem('access_token', authResult.accessToken); - localStorage.setItem('id_token', authResult.idToken); - } - - parseHash(); - -}); - -``` - -The service has several other utility functions that are necessary to complete authentication transactions. - -* The `parseHash` function is necessary for redirect-based authentication transactions which, in this example, include `signup` and `loginWithGoogle`. -* The `logout` function removes the user's tokens from local storage which effectively logs them out of the application. -* The `setUser` function takes an authentication result object and sets the access token and ID token values into local storage -* The `show_logged_in` function hides the login form and displays the **Log Out** button. This is called after the user authenticates to reflect that they are logged in. -* The `show_sign_in` function does the opposite of `show_logged_in` and is called when the user logs out. - -With the login form and the authentication functions in place, users can now authenticate with a custom UI. \ No newline at end of file diff --git a/articles/client-platforms/jquery/03-session-handling.md b/articles/client-platforms/jquery/03-session-handling.md deleted file mode 100644 index 8e7901909b..0000000000 --- a/articles/client-platforms/jquery/03-session-handling.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -title: Session Handling -description: This tutorial demonstrates how to integrate Auth0 with jQuery to add session handling and logout to your web app. -budicon: 280 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-jquery-samples', - path: '03-Session-Handling', - requirements: [ - 'jQuery 3.1.0' - ] -}) %> - -In the previous steps of this tutorial, you enabled user login with the `Lock` widget and then with `Auth0.js`. - -In this step, you will create a session for that user and also allow the user to log out. - -## Create Session - -Once the user is logged in, you will want to create a session for that user. To do this, you only need to store the value of the `id_token` attribute that is returned in the Lock `authenticated` callback parameter. - -**NOTE**: This example uses `localStorage`, but you can use any storage library. At the end of this guide, you can see how to do the same with `Lockr` storage library. - -```javascript -// app.js - -var lock = new Auth0Lock(AUTH0_CLIENT_ID, AUTH0_DOMAIN, { - auth: { - params: { - scope: 'openid email' - } //Details: https://auth0.com/docs/scopes - } -}); - -lock.on("authenticated", function(authResult) { - localStorage.setItem('id_token', authResult.idToken); -}); -``` - -## Check Session - -To check if a user is authenticated, we read the `id_token` value from localStorage: - -```javascript -// app.js - -var id_token = localStorage.getItem('id_token'); - -if (null != id_token) { - lock.getProfile(id_token, function (err, profile) { - if (err) { - // Remove expired token (if any) from localStorage - localStorage.removeItem('id_token'); - return alert('There was an error getting the profile: ' + err.message); - } // else: user is authenticated - }); -} -``` - -## Logout - -To log out a user, remove the token from `localStorage`: - -```javascript -// app.js - -var logout = function() { - localStorage.removeItem('id_token'); - window.location.href = "/"; -} -``` - -Then create the buttons for login and logout: - -```html - - - - -``` - -And add their functionality: - -```javascript -// app.js - -var btn_login = $('#btn-login'); -var btn_logout = $('#btn-logout'); - -btn_login.click(function(e) { - e.preventDefault(); - lock.show(); -}); - -btn_logout.click(function(e) { - e.preventDefault(); - logout(); -}); -``` - -## Session handling example using [Lockr](https://github.com/tsironis/lockr) storage library - -```javascript -// app.js - -// Create session - -lock.on("authenticated", function(authResult) { - Lockr.set('id_token', authResult.idToken); -}); - -var id_token = Lockr.get('id_token'); -if (null != id_token) { - lock.getProfile(id_token, function (err, profile) { - if (err) { - // Remove expired token (if any) from storage - Lockr.rm('id_token'); - return alert('There was an error getting the profile: ' + err.message); - } // else: user is authenticated - }); -} - -// Logout - -var logout = function() { - Lockr.rm('id_token'); - window.location.href = "/"; -} -``` diff --git a/articles/client-platforms/jquery/04-user-profile.md b/articles/client-platforms/jquery/04-user-profile.md deleted file mode 100644 index a2db630613..0000000000 --- a/articles/client-platforms/jquery/04-user-profile.md +++ /dev/null @@ -1,211 +0,0 @@ ---- -title: User Profile -description: This tutorial demonstrates how to integrate Auth0 with jQuery to authenticate and fetch/show/update profile information. -budicon: 292 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-jquery-samples', - path: '04-User-Profile', - requirements: [ - 'jQuery 3.1.0' - ] -}) %> - -## Profile - -To fetch user profile information, call the `lock.getProfile` function, specifying the `idToken` and a callback to process the response. - -Once you retrieve the user profile, you can store it in `localStorage` (or any store). - -```javascript -// app.js - -$(document).ready(function() { - var lock = null; - - lock = new Auth0Lock('${account.clientId}', '${account.namespace}', { - auth: { - params: { - scope: 'openid email' - } //Details: https://auth0.com/docs/scopes - } - }); - - lock.on("authenticated", function(authResult) { - lock.getProfile(authResult.idToken, function (err, profile) { - if (err) { - // Remove expired token (if any) - localStorage.removeItem('id_token'); - // Remove expired profile (if any) - localStorage.removeItem('profile'); - return alert('There was an error getting the profile: ' + err.message); - } else { - localStorage.setItem('id_token', authResult.idToken); - localStorage.setItem('profile', JSON.stringify(profile)); - showUserProfile(profile); - } - }); - }); - - var logout = function() { - localStorage.removeItem('id_token'); - localStorage.removeItem('profile'); - window.location.href = "/"; - } -}); -``` - -Then display `user profile` attributes in your HTML: - -```javascript -// app.js - -var showUserProfile = function(profile) { - - // Editing purposes only - user_id = profile.user_id; - - // ... - $('#avatar').attr('src', profile.picture); - $('#name').text(profile.name); - $('#email').text(profile.email); - $('#nickname').text(profile.nickname); - $('#created_at').text(profile.created_at); - $('#updated_at').text(profile.updated_at); -} -``` - -```html - - -
-

You are not logged in

- -
- - -``` - -## Custom Sign Up Fields - -<%= include('../_includes/_profile-metadata-explanation') %> - -You can add input fields to the sign-up form by adding `additionalSignUpFields` to the `options` parameter of the `Auth0Lock` instantiation. - -**NOTE:** See [Additional Sign-Up Fields](/libraries/lock/v10/customization#additionalsignupfields-array-) for more information (**only available for Lock 10**). - -```javascript -// app.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 - validator: function(value) { // optional - // only accept addresses with more than 10 characters - return value.length > 10; - } - }] -}); -``` - -Each `additionalSignUpFields` value is saved to the profile in the `user_metadata` attribute. - -To display this data, read it from the profile's `user_metadata`: - -```javascript -// app.js - -var showUserProfile = function(profile) { - - // ... - if (profile.hasOwnProperty('user_metadata')) { - $('#address').text(profile.user_metadata.address); - } -} -``` - -```html - - -Address: -``` - -## Update User Profile - -You can add an `address` attribute to the user profile's `user_metadata` by creating an AJAX call and a simple form. You will need to call the [Update a User](/api/management/v2#!/Users/patch_users_by_id) endpoint on form-submit. - -To call the endpoint we need to add the Authorization header to requests. - -First, use `$.ajaxSetup()` for setting `Authorization` header automatically for all the requests: - -```javascript -// app.js - -$.ajaxSetup({ - 'beforeSend': function(xhr) { - if (localStorage.getItem('id_token')) { - xhr.setRequestHeader('Authorization', - 'Bearer ' + localStorage.getItem('id_token')); - } - } -}); -``` - -Then use `$.ajax()` with `method = 'PATCH'` to update the user's data. - -```javascript -// app.js - -$('#btn-edit-submit').on('click', function(ev) { - ev.preventDefault(); - var user_address = $('#edit_address').val(); - $.ajax({ - url: 'https://' + '${account.namespace}' + '/api/v2/users/' + user_id, - method: 'PATCH', - data: { user_metadata: {address: user_address} } - }).done(function(updated_profile) { - localStorage.setItem('profile', JSON.stringify(updated_profile)); - showUserProfile(updated_profile); - }).fail(function(jqXHR, textStatus) { - alert("Request failed: " + textStatus); - }); -}); -``` - -Then create a simple form to add/update the *address* attribute: - -```html - - - -``` diff --git a/articles/client-platforms/jquery/05-linking-accounts.md b/articles/client-platforms/jquery/05-linking-accounts.md deleted file mode 100644 index 85f6d0ccb9..0000000000 --- a/articles/client-platforms/jquery/05-linking-accounts.md +++ /dev/null @@ -1,181 +0,0 @@ ---- -title: Linking Accounts -description: This tutorial demonstrates how to integrate Auth0 with jQuery to link accounts. -budicon: 345 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-jquery-samples', - path: '05-Linking-Accounts', - requirements: [ - 'jQuery 3.1.0' - ] -}) %> - -<%= include('../../_includes/_linking_accounts') %> - -```js -// app.js - -// Lock instance to launch a login to obtain the secondary id_token -var lockLink = new Auth0Lock('${account.clientId}', '${account.namespace}', { - auth: {params: {state: "linking"}}, - allowedConnections: ['Username-Password-Authentication', 'facebook', 'google-oauth2'], - languageDictionary: { // allows to override dictionary entries - title: "Link with:" - } -}); -``` - -Then, when setting the callback for the `authenticated` event with the `on` method, you can determine which login was executed by checking the value of the `authResult.state` attribute: - -```javascript -// app.js - -lock.on("authenticated", function(authResult) { - // Every lock instance listen to the same event, so we have to check if - // it's not the linking login here. - if (authResult.state != "linking") { - localStorage.setItem('id_token', authResult.idToken); - lock.getProfile(authResult.idToken, function(err, profile) { - if (err) { - return alert("There was an error getting the profile: " + err.message); - } else { - localStorage.setItem('profile', JSON.stringify(profile)); - showUserIdentities(profile); - // Linking purposes only - localStorage.setItem('user_id', profile.user_id); - } - }); - } -}); - -lockLink.on("authenticated", function(authResult) { - // Every lock instance listen to the same event, so we have to check if - // it's the linking login here. - if (authResult.state == "linking") { - // If it's the linking login, then do the link through the API. - linkAccount(authResult.idToken); - } -}); -``` - -Now that the second login is handled, you will need to actually do the linking. - -Before doing the linking we need to configure AJAX to send an `Authorization` header automatically for each request: - -```javascript -// app.js - -$.ajaxSetup({ - 'beforeSend': function(xhr) { - if (localStorage.getItem('id_token')) { - xhr.setRequestHeader('Authorization', - 'Bearer ' + localStorage.getItem('id_token')); - } - } -}); -``` - -After that we can link the accounts: - -```javascript -// app.js - -var linkAccount = function(id_token) { - // Get user_id value stored at login step - var user_id = localStorage.getItem('user_id'); - var data = JSON.stringify({ link_with: id_token }); - $.ajax({ - url: 'https://' + '${account.namespace}' + '/api/v2/users/' + user_id + '/identities', - method: 'POST', - headers: {'Accept': 'application/json', - 'Content-Type': 'application/json'}, - data: data - }).done(function() { - fetchProfile(); - }).fail(function(jqXHR, textStatus) { - alert("Request failed: " + textStatus); - }); -} -``` - -The function takes the `id_token` of the account to link with and posts to the API, passing the `link_with` parameter with the `id_token` value in the body. Then it fetches the profile on success to check that the accounts are now linked. - -Now to begin the linking process, call the `show` method on the `lockLink` instance: - -```javascript -// app.js - -$('#btn-link-account').on('click', function() { - lockLink.show(); -}); -``` - -```html - -``` - -## User Profile Linked Accounts Information - -The user profile contains an array of identities which includes the profile information from linked providers. - -To view a user's identities, access the [Users](${manage_url}/#/users) page on the Auth0 dashboard, select a user, and scroll down to `identities`. - -This example shows a user with a linked Google account: - -![User identities](/media/articles/users/user-identities-linked.png) - -Therefore, if you fetch the profile after linking accounts, this same information will be available. - -You can display this information and provide an **Unlink** button: - -```html - - -

Linked accounts

-
    -
-``` - -```javascript -// app.js - -var showUserIdentities = function(profile) { - var linked_accounts = ''; - $.each(profile.identities, function(index, identity) { - // Print all the identities but the main one (Auth0). - if (profile.user_id != identity.provider + '|' + identity.user_id) { - var identity_stringified = JSON.stringify(identity); - var btn = ""; - linked_accounts += - '
  • ' + identity.connection + ' ' + identity.profileData.name + ' ' + btn + '
    • '; - } - }) - $('#linked-accounts-list').html(linked_accounts); -} -``` - -## Unlinking Accounts - -You can disassociate a linked account by calling the [Unlink a user account](/api/management/v2#!/Users/delete_provider_by_user_id) endpoint using the primary `user_id`, and the `provider` and `user_id` of the identity to unlink: - -```javascript -// app.js - -var unlinkAccount = function(identity) { - // Get user_id value stored at login step - var user_id = localStorage.getItem('user_id'); - $.ajax({ - url: 'https://' + '${account.namespace}' + '/api/v2/users/' + user_id + '/identities/' + identity.provider + '/' + identity.user_id, - method: 'DELETE', - headers: {'Accept': 'application/json', - 'Content-Type': 'application/json'} - }).done(function() { - fetchProfile(); - }).fail(function(jqXHR, textStatus) { - alert("Request failed: " + textStatus); - }); -} -``` diff --git a/articles/client-platforms/jquery/06-rules.md b/articles/client-platforms/jquery/06-rules.md deleted file mode 100644 index a41849f2ee..0000000000 --- a/articles/client-platforms/jquery/06-rules.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: Rules -description: This tutorial demonstrates how to use Auth0 rules to extend what Auth0 has to offer. -budicon: 173 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-jquery-samples', - path: '06-Rules', - requirements: [ - 'jQuery 3.1.0' - ] -}) %> - -<%= include('../_includes/_rules-introduction') %> - -## Create a Rule - -<%= include('../_includes/_rules-create-section') %> - -## Test the Rule - -<%= include('../_includes/_rules-test-result-intro', { profilelink: '/quickstart/spa/jquery/04-user-profile' }) %> - -```html - - - -``` - -```javascript -// app.js - -var showUserProfile = function(profile) { - $('#country').text(profile.country); -} -``` diff --git a/articles/client-platforms/jquery/07-authorization.md b/articles/client-platforms/jquery/07-authorization.md deleted file mode 100644 index 663d6d14aa..0000000000 --- a/articles/client-platforms/jquery/07-authorization.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: Authorization -description: This tutorial demonstrates how to 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-jquery-samples', - path: '07-Authorization', - requirements: [ - 'jQuery 3.1.0' - ] -}) %> - -<%= include('../_includes/_authorization-introduction', { ruleslink: '/quickstart/spa/jquery/06-rules' }) %> - -### Create a Rule to assign roles - -<%= include('../_includes/_authorization-create-rule') %> - -## Restrict a route based on user's roles - -In order to restrict access to certain routes, we are going to use a `switch` inside *route* function (executed every time the page is loaded). - -```javascript -// app.js - -var route = function() { - var id_token = localStorage.getItem('id_token'); - var current_location = window.location.pathname; - if (undefined != id_token) { - var profile = JSON.parse(localStorage.getItem('profile')); - - switch(current_location) { - case "/": - $('#btn-login').hide(); - $('#btn-logout').show(); - if (isAdmin(profile)) { $('#btn-go-admin').show(); } - if (isUser(profile)) { $('#btn-go-user').show(); } - break; - case "/user.html": - if (true != isUser(profile)) { - window.location.href = "/"; - } else { - $('.container').show(); - $('#btn-logout').show(); - $('#nickname').text(profile.nickname); - } - break; - case "/admin.html": - if (true != isAdmin(profile)) { - window.location.href = "/"; - } else { - $('.container').show(); - $('#btn-logout').show(); - $('#nickname').text(profile.nickname); - } - break; - }; - } else { // user is not logged in. - // Call logout just to be sure our local session is cleaned up. - if ("/" != current_location) { - logout(); - } - } -}; - -route(); -``` - -The route function checks if the user is authenticated then checks if he/she is an *admin* or *user* using `isAdmin` and `isUser` functions, respectively. This method checks if the `roles` attribute of `app_metadata` added by the rule contains `admin` or `user`: - -```javascript -// app.js - -var isAdmin = function(profile) { - if (profile && - profile.app_metadata && - profile.app_metadata.roles && - profile.app_metadata.roles.indexOf('admin') > -1) { - return true; - } else { - return false; - } -}; - -var isUser = function(profile) { - if (profile && - profile.app_metadata && - profile.app_metadata.roles && - profile.app_metadata.roles.indexOf('user') > -1) { - return true; - } else { - return false; - } -} -``` - -Now, if a user logs in with an email that contains `@example`, he/she will be allowed to access the `/admin.html` route. Otherwise, the user is just allowed to access `/` and `/user.html` routes. diff --git a/articles/client-platforms/jquery/08-calling-apis.md b/articles/client-platforms/jquery/08-calling-apis.md deleted file mode 100644 index 79d45f18fc..0000000000 --- a/articles/client-platforms/jquery/08-calling-apis.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: Calling APIs -description: This tutorial demonstrates how to use $.ajaxSetup() to make authenticated API calls. -budicon: 546 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-jquery-samples', - path: '08-Calling-Api', - requirements: [ - 'jQuery 3.1.0' - ] -}) %> - -<%= include('../../_includes/_calling_apis') %> - -## Sending Authenticated HTTP Requests - -In order to make an authenticated request, you need to use `$.ajaxSetup()` in order to automatically add the `Authorization` header to every request. - -```javascript -// app.js - -$.ajaxSetup({ - 'beforeSend': function(xhr) { - if (localStorage.getItem('id_token')) { - xhr.setRequestHeader('Authorization', - 'Bearer ' + localStorage.getItem('id_token')); - } - } -}); -``` - -Your requests will have the `Authorization` header added automatically: - -`Authorization: Bearer eyJ0eXAiOiJKV1Qi...` - -Here, before every AJAX request, we are fetching the token from `localStorage` stored in the `id_token` key. You can choose a different key name if you like. diff --git a/articles/client-platforms/jquery/09-mfa.md b/articles/client-platforms/jquery/09-mfa.md deleted file mode 100644 index 111d9f57ee..0000000000 --- a/articles/client-platforms/jquery/09-mfa.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Multifactor Authentication -description: This tutorial demonstrates how to add Multifactor Authentication to your jQuery app with auth0. -budicon: 243 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-jquery-samples', - path: '09-MFA', - requirements: [ - 'jQuery 3.1.0' - ] -}) %> - -<%= include('../_includes/_mfa-introduction') %> - -In this tutorial, you will learn how to enable MFA in the jQuery application you created in the previous steps. - -## Enable Multifactor Authentication in Your Account - -<%= include('../_includes/_mfa-enable') %> - -## Login - -<%= include('../_includes/_mfa-login', { loginlink: '/quickstart/spa/jquery/01-login' }) %> - -# Summary - -In this guide, you learned how to use Auth0 Guardian to add multifactor authentication to your jQuery project. diff --git a/articles/client-platforms/jquery/10-customizing-lock.md b/articles/client-platforms/jquery/10-customizing-lock.md deleted file mode 100644 index 1768957f32..0000000000 --- a/articles/client-platforms/jquery/10-customizing-lock.md +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: Customizing Lock -description: This tutorial demonstrates how to customize Lock. -budicon: 285 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-jquery-samples', - path: '10-Customizing-Lock', - requirements: [ - 'jQuery 3.1.0' - ] -}) %> - -Using Lock is easy, but you may want to customize your login UI. For that, there are several [customization options](/libraries/lock/v10/customization) available. - -## Lock Options - -Some UI customization can be done via the `options` parameter when creating a `Lock` instance. - -### Theme Options - -You can set custom theme properties, such as a different logo or primary color, by adding a `theme` property with custom values: - -```javascript -// app.js - -var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', { - theme: { - logo: "test-icon.png", - primaryColor: "#b81b1c" - } -}); -``` -For more information, see the [theming options](/libraries/lock/v10/ui-customization) documenation. - -### Language Dictionary Specification - -You can also customize the text that `Lock` will display with the `languageDictionary` option parameter: - -```javascript -// app.js - -var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', { - languageDictionary: { - title: "My Company" - } -}); -``` - -For more information, see the [language dictionary specification](/libraries/lock/v10/i18n) documenation. diff --git a/articles/client-platforms/jquery/11-api-authorization.md b/articles/client-platforms/jquery/11-api-authorization.md deleted file mode 100644 index 38a657f8be..0000000000 --- a/articles/client-platforms/jquery/11-api-authorization.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: OAuth 2.0 API Authorization -description: This tutorial demonstrates how to use Auth0 to make authorized API calls from your web app. -budicon: 500 ---- - -<%= include('../../_includes/_api_auth_intro') %> - -<%= include('../../_includes/_compat_warning') %> - -### Before Starting - -## 1. Enable OAuth 2.0 API Authorization - -<%= include('../../_includes/_configure_oauth2aas') %> - -## 2. Create an Application - -<%= include('../_includes/_new_app_no_sample') %> - -![App Dashboard](/media/articles/angularjs/spa_client_create.png) - -Be sure to register the URL of your app in the Allowed Callback URLs in your Client Settings. - -## 3. Create a Resource Server (API) - -<%= include('../../_includes/_new_api') %> - -![Create API](/media/articles/api-auth/api-5.png) -![Update Scopes](/media/articles/api-auth/api-6.png) - -Take note of the API Identifier and Scopes you defined in the Dashboard, as they will be used later. - -<%= include('./_includes/_api_authz') %> diff --git a/articles/client-platforms/jquery/12-api-refresh-tokens.md b/articles/client-platforms/jquery/12-api-refresh-tokens.md deleted file mode 100644 index b1ba5024ab..0000000000 --- a/articles/client-platforms/jquery/12-api-refresh-tokens.md +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: OAuth 2.0 Refreshing Access Tokens -description: This tutorial demonstrates how to use Auth0 to refresh Access Tokens in Single Page Applications. ---- - -JQuery applications, as with all client-based applications, are not trusted to maintain the safety of a client secret or Refresh Token. Therefore, these application should not be issued Refresh Tokens. However, it is still possible to renew an Access Token. This tutorial demonstrates how to renew an Access Token using auth0.js. For more information, check out [our documentation](https://auth0.com/docs/api-auth). - -<%= include('../../_includes/_compat_warning') %> - -## Refreshing an Access Token - -If you invoke your API and you get a `401` response, this tells you that you might need to refresh your Access Token since it is expired. - -In order to refresh your Access Token, you can use `prompt=none` in your `/authorize` call. With auth0.js, this is done using the `silentAuthentication` function. - -```js - -// get a new Access Token -auth0.silentAuthentication({ - responseType: 'id_token token', - scope: 'openid profile {OTHER API SCOPES}', - audience: '{YOUR API IDENTIFIER}' -}, function(err, result){ - // result.accesstoken available here - // result.idToken also available here if you used response type id_token - localStorage.setItem('access_token', result.accessToken); - localStorage.setItem('id_token', result.idToken); -}); -``` - -This by default will use the callback url defined in the constructor. If you want to use a different one, you can send the new callbackURL in the options param. An error will be returned if the end user is not already authenticated. - -You should include the `scope` parameter, including any or all of the scopes that were originally requested. If you ask for scopes for which the user did not already provide consent, the returned `access_token` will not include them. By including `id_token` in the response_type, you will also get back an `id_token`. Also note that the renewed Access Token has an expiration time equal to the `Token Expiration (Seconds)` setting for your API. diff --git a/articles/client-platforms/jquery/_includes/_api_authz.md b/articles/client-platforms/jquery/_includes/_api_authz.md deleted file mode 100644 index c9fc866a77..0000000000 --- a/articles/client-platforms/jquery/_includes/_api_authz.md +++ /dev/null @@ -1,98 +0,0 @@ -## Configuring Your Application - -## Initialize - -First, add Auth0's JavaScript SDK to your jQuery application. - -```html - -``` - -Create a new Auth0 client instance as follows: - -```js -var auth0 = new Auth0({ - domain: '${account.namespace}', - clientID: '${account.clientId}', - callbackURL: '${account.callback}' -}); -``` - -Note that the `callbackURL` must be defined in Dashboard for your client. - -## Login - -Within your application's HTML, create an element with id `btn-login`. Then trigger the login on any of your enabled `Connections` with the following code. This will direct the user to the /authorize URL, which is the first step in the Implicit Grant OAuth flow. You can read more about API Authorization [here](/api-auth/grant/implicit). - -```js -// trigger login to Auth0 when the Login button is clicked -$('#btn-login').click(function(e) { - auth0.login({ - responseType: 'id_token token', - scope: 'openid profile {API SCOPES}', - audience: '{API IDENTIFIER}' - }); -}); -``` - -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 (separated by a space) you defined in the Dashboard for your API, in addition to any of the standard [OpenID scopes](/scopes). - -## Process the Callback - -Once you have succesfully authenticated, Auth0 will redirect to the `callbackURL` parameter defined in the constructor. Auth0 will append a few extra parameters after a hash on the URL. These include an `access_token` and an `id_token`, both JSON Web Tokens (JWTs). You can parse the hash and grab the tokens as follows: - -```js -var result = auth0.parseHash(window.location.hash); - -if (result && result.idToken) { - // keep these in localStorage to use later - localStorage.setItem('access_token', result.accessToken); - localStorage.setItem('id_token', result.idToken); - - auth0.getProfile(result.idToken, function (err, profile) { - alert('hello ' + profile.name); - }); - -} else if (result && result.error) { - alert('error: ' + result.error); -} -``` - -The `access_token` will be used to make an Authenticated API call. Remember that using `response_type: token` means that you cannot get a `refresh_token`. The `id_token` can be used in your application for basic profile data. If you want to retrieve additional profile data for the user, you can use the `userinfo` endpoint with the `access_token` in the `Authorization` header. For more information, see [our API documentation](/api/authentication/reference#get-user-info). - -## Make an Authenticated API Call - -Use the `access_token` to invoke your Resource Server (API): - -```js -var accessToken = localStorage.getItem('accessToken'); -fetch('{API URL}', { - method: 'get', - headers: new Headers({ - 'Content-Type': 'application/json', - 'Authorization' : 'Bearer ' + accessToken - }) -}).then(function(response) { - response.text().then(function(t) { - if (response.status !== 200) { - console.log('error'); - return; - } - alert('API Response: ' + JSON.stringify(JSON.parse(t))); - }) -}).catch(function(err) { - alert('error: ' + err); -}); -``` - -<%= include('../../../_includes/_create_resource_server') %> - -## Log Out - -In this implementation, a logout involves simply deleting the saved tokens from `localStorage` and redirecting the user to the home page: - -```js -localStorage.removeItem('access_token'); -localStorage.removeItem('id_token'); -window.location.href = "/"; -``` diff --git a/articles/client-platforms/jquery/_includes/_configuration.md b/articles/client-platforms/jquery/_includes/_configuration.md deleted file mode 100644 index 57d40a49da..0000000000 --- a/articles/client-platforms/jquery/_includes/_configuration.md +++ /dev/null @@ -1,7 +0,0 @@ -## 2. Configure Lock - -Configure Lock with your `clientID` and `domain`: - -All of the available options for `Auth0Lock` can be viewed in the [Lock customization documentation](/libraries/lock/customization). - -${snippet(meta.snippets.setup)} \ No newline at end of file diff --git a/articles/client-platforms/jquery/_includes/_dependencies.md b/articles/client-platforms/jquery/_includes/_dependencies.md deleted file mode 100644 index f06d2bb9f1..0000000000 --- a/articles/client-platforms/jquery/_includes/_dependencies.md +++ /dev/null @@ -1,5 +0,0 @@ -## 1. Add the Lock Widget and Set the Viewport - -To get started, add Auth0's Lock widget and set the viewport so that it displays correctly on all devices. - -${snippet(meta.snippets.dependencies)} \ No newline at end of file diff --git a/articles/client-platforms/jquery/_includes/_login.md b/articles/client-platforms/jquery/_includes/_login.md deleted file mode 100644 index 0d6261ae04..0000000000 --- a/articles/client-platforms/jquery/_includes/_login.md +++ /dev/null @@ -1,28 +0,0 @@ -## 3. Implement the Login - -To implement the login, call the `.show()` method of Auth0's `Lock` instance when a user clicks the login button. - -${snippet(meta.snippets.use)} - -After authentication, Auth0 will redirect the user back to your application with an identifying token. This token is used to retrieve the user's profile from Auth0 and to call your backend APIs. - -In this example, the `id_token` is stored in `localStorage` to keep the user authenticated after each page refresh: - -```js -// app.js - -lock.on("authenticated", function(authResult) { - lock.getProfile(authResult.idToken, function(error, profile) { - if (error) { - // Handle error - return; - } - - localStorage.setItem('id_token', authResult.idToken); - - // Display user information - $('.nickname').text(profile.nickname); - $('.avatar').attr('src', profile.picture); - }); -}); -``` diff --git a/articles/client-platforms/jquery/dashboard-default.md b/articles/client-platforms/jquery/dashboard-default.md deleted file mode 100644 index 42742ec796..0000000000 --- a/articles/client-platforms/jquery/dashboard-default.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Login -default: true -description: This tutorial demonstrates how to use the Auth0 jQuery SDK to add authentication and authorization to your web app ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-jquery-samples', - path: '01-Login', - requirements: [ - 'jQuery 3.1.0' - ] -}) %> - -${include('../\_callback')} - -<%= include('_includes/_dependencies') %> - -<%= include('_includes/_configuration') %> - -<%= include('_includes/_login') %> - -<%= include('../_includes/_persisting_state') %> \ No newline at end of file diff --git a/articles/client-platforms/jquery/index.yml b/articles/client-platforms/jquery/index.yml deleted file mode 100644 index b34cbdf216..0000000000 --- a/articles/client-platforms/jquery/index.yml +++ /dev/null @@ -1,28 +0,0 @@ -title: jQuery -alias: - - jquery -language: - - Javascript -framework: - - jQuery -image: //upload.wikimedia.org/wikipedia/en/9/9e/JQuery_logo.svg -tags: - - quickstart -snippets: - dependencies: client-platforms/jquery/dependencies - setup: client-platforms/jquery/setup - use: client-platforms/jquery/use -seo_alias: jquery -default_article: dashboard-default -articles: - - 00-intro - - 01-login - - 02-custom-login - - 03-session-handling - - 04-user-profile - - 05-linking-accounts - - 06-rules - - 07-authorization - - 08-calling-apis - - 09-mfa - - 10-customizing-lock \ No newline at end of file diff --git a/articles/client-platforms/react/00-getting-started.md b/articles/client-platforms/react/00-getting-started.md deleted file mode 100644 index bcde0c17f7..0000000000 --- a/articles/client-platforms/react/00-getting-started.md +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: Getting Started -description: Initial steps to integrate Auth0 in a React application. -budicon: 715 ---- - -This quickstart guide contains individual steps which demonstrate how to use various Auth0 features in your React applications. Each step has a dedicated sample project which can be downloaded directly from the doc or forked on Github. If you are logged in to your Auth0 account, the samples will have your Auth0 credentials pre-populated for you. - -::: panel-info Using create-react-app? -Auth0 has its own fork of **[react-scripts](https://github.com/auth0-community/auth0-react-scripts)** which means you can install an Auth0-powered React app with a single command: - -```bash -create-react-app my-app --scripts-version auth0-react-scripts -``` - -The `auth0-react-scripts` app demonstrates **login**, **session handling**, and **user profiles**. -::: - -<%= include('../../_includes/_new_app') %> - -## About the Sample Applications - -The code snippets within this quickstart guide are based on the downloadable samples. Within each of these samples, you will find a very simple React application which utilizes a few views and containers. The samples use **react-router** (with `browserHistory`) and **react-bootstrap**. - -It should be noted that a simplistic React application is used in the samples and snippets intentionally. The focus of this quickstart guide is on how to use Auth0 in a React application in general rather than on how to approach various architectural scenarios. However, Auth0 works well in any React setup and can be integrated with Flux, Redux, and other flavors that you may be interested in. - -## Auth0 Dependencies - -<%= include('_includes/_dependencies') %> diff --git a/articles/client-platforms/react/01-login.md b/articles/client-platforms/react/01-login.md deleted file mode 100644 index 3d12f81bb0..0000000000 --- a/articles/client-platforms/react/01-login.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Login -description: This tutorial demonstrates how to integrate Auth0 with ReactJS to add authentication and authorization to your app -budicon: 448 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-react-sample', - path: '01-Login', - requirements: [ - 'React 15.3' - ] -}) %> - -<%= include('_includes/_login') %> diff --git a/articles/client-platforms/react/02-custom-login.md b/articles/client-platforms/react/02-custom-login.md deleted file mode 100644 index 9747e1c041..0000000000 --- a/articles/client-platforms/react/02-custom-login.md +++ /dev/null @@ -1,289 +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-info 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). - -Auth0.js version 8 verifies ID tokens during authentication transactions. Only tokens which are signed with the RS256 algorithm can be verified on the client side, meaning that your Auth0 client must be configured to sign tokens with RS256. See the [auth0.js migration guide](https://auth0.com/docs/libraries/auth0js/migration-guide#switching-from-hs256-to-rs256) for more details. -::: - -## 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 client. 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 user's access token and ID token are saved into local storage if the transaction is successful. - -The `signup` method is a redirect-based flow 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.client.login({ - realm: 'Username-Password-Authentication', - username, - password - }, (err, authResult) => { - if (err) { - alert('Error: ' + err.description) - return - } - if (authResult && authResult.idToken && authResult.accessToken) { - this.setToken(authResult.accessToken, authResult.idToken) - browserHistory.replace('/home') - } - }) - } - - 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 }, (err, authResult) => { - if (authResult && authResult.accessToken && authResult.idToken) { - this.setToken(authResult.accessToken, authResult.idToken) - browserHistory.replace('/home') - this.auth0.client.userInfo(authResult.accessToken, (error, profile) => { - if (error) { - console.log('Error loading the Profile', error) - } else { - this.setProfile(profile) - } - }) - } else if (authResult && authResult.error) { - alert('Error: ' + authResult.error) - } - }) - } - - 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('id_token') - localStorage.removeItem('profile') - } -} -``` - -The service has several other utility methods that are necessary to complete authentication transactions. - -* The `parseHash` method is necessary for redirect-based authentication transactions which, in this example, include `signup` and `loginWithGoogle`. -* 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 ( - - - - - - ) -} -``` \ No newline at end of file diff --git a/articles/client-platforms/react/03-session-handling.md b/articles/client-platforms/react/03-session-handling.md deleted file mode 100644 index c018f9128e..0000000000 --- a/articles/client-platforms/react/03-session-handling.md +++ /dev/null @@ -1,185 +0,0 @@ ---- -title: Session Handling -description: This tutorial demonstrates how to integrate Auth0 with ReactJS to add session handling and logout to your web app -budicon: 280 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-react-sample', - path: '03-Session-Handling', - requirements: [ - 'React 15.3' - ] -}) %> - -The previous steps of this tutorial explain how to implement login using either `Lock` or the `Auth0.js` library to authenticate users in your application. - -Usually, when a user logs in, you will want to create a session for that user and also allow the user to logout. The following steps show you how to implement this. - -## Create a Session - -Once the user is logged in, you can create a session for that user by storing the `idToken` attribute, which is passed as a Lock `authenticated` event callback parameter. - -The `AuthService` helper class uses local storage to keep the current user idToken valid for the session: - -```javascript -// src/utils/AuthService.js - -import Auth0Lock from 'auth0-lock' -import { browserHistory } from 'react-router' - -export default class AuthService { - constructor(clientId, domain) { - // Configure Auth0 - this.lock = new Auth0Lock(clientId, domain, { - auth: { - redirectUrl: 'http://localhost:3000/login', - responseType: 'token' - } - }) - // Add callback for lock `authenticated` event - this.lock.on('authenticated', this._doAuthentication.bind(this)) - // binds login functions to keep this context - this.login = this.login.bind(this) - } - - _doAuthentication(authResult) { - // Saves the user token - this.setToken(authResult.idToken) - // navigate to the home route - browserHistory.replace('/home') - } - - login() { - // Call the show method to display the widget. - this.lock.show() - } - - loggedIn() { - // Checks if there is a saved token and it's still valid - return !!this.getToken() - } - - setToken(idToken) { - // Saves user token to local storage - localStorage.setItem('id_token', idToken) - } - - getToken() { - // Retrieves the user token from local storage - return localStorage.getItem('id_token') - } - - logout() { - // Clear user token and profile data from local storage - localStorage.removeItem('id_token'); - } -} -``` - -In the code, you see the `login` method using `Lock` to show the sign in window, and the `_doAuthentication` private method, which stores the `idToken` provided by Auth0 to local storage. The `logout` method removes the stored token, and `loggedIn` checks if there is a token and returns a boolean. - -However, just checking if there is a stored token is not enough to validate the session because the returned [JSON Web Token](/jwt) has an expiration date. The next section explains how to properly validate the session. - -## Check if the Session is Valid - -In order to know if a user is authenticated, you need to make sure the `idToken` is stored and still valid. A token is valid if its expiration date has not passed. - -To check this, save the new `isTokenExpired` method in a new helper file named `jwtHelper.js`: - -```javascript -// src/utils/jwtHelper.js - -import decode from 'jwt-decode'; - -export function getTokenExpirationDate(token) { - const decoded = decode(token) - if(!decoded.exp) { - return null - } - - const date = new Date(0) // The 0 here is the key, which sets the date to the epoch - date.setUTCSeconds(decoded.exp) - return date -} - -export function isTokenExpired(token) { - const date = getTokenExpirationDate(token) - const offsetSeconds = 0 - if (date === null) { - return false - } - return !(date.valueOf() > (new Date().valueOf() + (offsetSeconds * 1000))) -} -``` - -The `jwtHelper` library exports two methods: `isTokenExpired` and `getTokenExpirationDate`. It also imports `jwt-decode` as a dependency, so you must include it in your `package.json` or use npm to install it: - -```bash -npm install jwt-decode --save -``` - -Now you are able to import `isTokenExpired` into `AuthService` to improve the `loggedIn` method: - -```javascript -// src/utils/AuthService.js - -import Auth0Lock from 'auth0-lock' -import { isTokenExpired } from './jwtHelper' - -export default class AuthService { - - loggedIn() { - // Checks if there is a saved token and it's still valid - const token = this.getToken() - return !!token && !isTokenExpired(token) - } - -} -``` - -## Logout Button - -In Home view, you may want to show a logout button that destroys the user session and redirects to the `/login` page. Since the `AuthService` helper class already includes a `logout` function, you can simply hook it to a logout button. - -The updated Home component code with the logout button is as follows: - -```javascript -// src/views/Main/Home/Home.js - -import React, { PropTypes as T } from 'react' -import {Button} from 'react-bootstrap' -import AuthService from 'utils/AuthService' -import styles from './styles.module.css' - -export class Home extends React.Component { - static contextTypes = { - router: T.object - } - - static propTypes = { - auth: T.instanceOf(AuthService) - } - - logout() { - // destroys the session data - this.props.auth.logout() - // redirects to login page - this.context.router.push('/login'); - } - - render() { - return ( -
    -

    Home

    -

    Welcome!

    - -
    - ) - } -} - -export default Home; -``` - diff --git a/articles/client-platforms/react/04-user-profile.md b/articles/client-platforms/react/04-user-profile.md deleted file mode 100644 index 0d41e2de1e..0000000000 --- a/articles/client-platforms/react/04-user-profile.md +++ /dev/null @@ -1,442 +0,0 @@ ---- -title: User Profile -description: This tutorial demonstrates how to integrate Auth0 with ReactJS to authenticate and fetch/show profile information -budicon: 292 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-react-sample', - path: '04-User-Profile', - requirements: [ - 'React 15.3' - ] -}) %> - -The [Login step](/quickstart/spa/react/01-login) of this tutorial explains how to use Auth0 Lock to show a login window and authenticate a user and how to protect routes by making them available only for authenticated users. - -This step demonstrates how to retrieve and show user profile information. - -## Create the AuthService Class - -The best way to have authentication utilities available across your application is to create a helper class. Then you can share an instance of this class by passing it to the React Component as a prop. - -First, you will create the `AuthService` helper class to encapsulate the login functionality and save it inside the `src/utils` folder as `AuthService.js`. - -Inside this class, you will create an `Auth0Lock` instance that receives your Auth0 credentials and an options object. (For a list of available options, see: [Lock: User configurable options](/libraries/lock/v10/customization)). Instead of hard-coding your credentials in this class, they are passed from the `AuthService` constructor parameters to the `Auth0Lock` instance. - -Then, with the `Auth0Lock` instance, you can hook a callback for the `authenticated` event. This event will be triggered after every successful login, passing the user authentication token (`idToken`) as a parameter. Then the `setToken` method stores the `idToken` value in local storage. - -```javascript -// src/utils/AuthService.js - -import Auth0Lock from 'auth0-lock' -import { browserHistory } from 'react-router' - -export default class AuthService { - constructor(clientId, domain) { - // Configure Auth0 - this.lock = new Auth0Lock(clientId, domain, { - auth: { - redirectUrl: 'http://localhost:3000/login', - responseType: 'token' - } - }) - // Add callback for lock `authenticated` event - this.lock.on('authenticated', this._doAuthentication.bind(this)) - // binds login functions to keep this context - this.login = this.login.bind(this) - } - - _doAuthentication(authResult) { - // Saves the user token - this.setToken(authResult.idToken) - // navigate to the home route - browserHistory.replace('/home') - } - - login() { - // Call the show method to display the widget. - this.lock.show() - } - - loggedIn() { - // Checks if there is a saved token and it's still valid - return !!this.getToken() - } - - setToken(idToken) { - // Saves user token to local storage - localStorage.setItem('id_token', idToken) - } - - getToken() { - // Retrieves the user token from local storage - return localStorage.getItem('id_token') - } - - logout() { - // Clear user token from local storage - localStorage.removeItem('id_token'); - } -} -``` - -The other helper methods shown above include: `login` (to call `lock.show()` and display the login widget), `logout` (to remove the local storage data), and `loggedIn` (that checks if an `idToken` exists and returns a boolean). - -## Request User Profile Data - -To fetch user profile information, call the `lock.getProfile` function, specifying the token and a callback to process the response. - -Below you can see the `getProfile` code that has been added to fetch the user profile after successful authentication and store the response in local storage. Also, since the profile data request is asynchronous, `EventEmitter` has been added to allow sending notifications after a profile update. - -```javascript -// src/utils/AuthService.js - -import { EventEmitter } from 'events' -import Auth0Lock from 'auth0-lock' -import { browserHistory } from 'react-router' - -export default class AuthService extends EventEmitter { - constructor(clientId, domain) { - super() - // Configure Auth0 - this.lock = new Auth0Lock(clientId, domain, { - auth: { - redirectUrl: 'http://localhost:3000/login', - responseType: 'token' - } - }) - // Add callback for lock `authenticated` event - this.lock.on('authenticated', this._doAuthentication.bind(this)) - // Add callback for lock `authorization_error` event - this.lock.on('authorization_error', this._authorizationError.bind(this)) - // binds login functions to keep this context - this.login = this.login.bind(this) - } - - _doAuthentication(authResult) { - // Saves the user token - this.setToken(authResult.idToken) - // navigate to the home route - browserHistory.replace('/home') - // Async loads the user profile data - this.lock.getProfile(authResult.idToken, (error, profile) => { - if (error) { - console.log('Error loading the Profile', error) - } else { - this.setProfile(profile) - } - }) - } - - // ... - - setProfile(profile) { - // Saves profile data to local storage - 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 local storage - const profile = localStorage.getItem('profile') - return profile ? JSON.parse(localStorage.profile) : {} - } - - logout() { - // Clear user token and profile data from local storage - localStorage.removeItem('id_token'); - localStorage.removeItem('profile'); - } -} -``` - -## 3. Show User Profile Data in Home - -For example, instead of displaying only a logout button, you can update the Home view component to render user profile info: - -```javascript -// src/views/Main/Home/Home.js - -import React, { PropTypes as T } from 'react' -import {Button} from 'react-bootstrap' -import AuthService from 'utils/AuthService' -import ProfileDetails from 'components/Profile/ProfileDetails' -import styles from './styles.module.css' - -export class Home extends React.Component { - static contextTypes = { - router: T.object - } - - static propTypes = { - auth: T.instanceOf(AuthService) - } - - constructor(props, context) { - super(props, context) - this.state = { - profile: props.auth.getProfile() - } - // listen to profile_updated events to update internal state - props.auth.on('profile_updated', (newProfile) => { - this.setState({profile: newProfile}) - }) - } - - logout() { - this.props.auth.logout() - this.context.router.push('/login'); - } - - render() { - const { profile } = this.state - return ( -
    -

    Home

    - - -
    - ) - } -} - -export default Home; -``` - -Home is now listening for `profile_updated` events from the `AuthService` instance, which keeps profile data in its internal state. Now, each time user profile data is updated, the component state is changed, which updates the props sent to the `ProfileDetails` component. - -The `Profile` component is still missing. Create a new `ProfileDetails.js` file in `src/components/Profile/` with the following: - -```javascript -// src/components/Profile/ProfileDetails.js - -import React, { PropTypes as T } from 'react' -import {Row, Col, Image} from 'react-bootstrap' - -export class ProfileDetails extends React.Component { - static propTypes = { - profile: T.object - } - - render() { - const { profile } = this.props - return ( - - - - - -

    Profile

    -

    Name: {profile.name}

    -

    Email: {profile.email}

    -

    Nickname: {profile.nickname}

    -

    Created At: {profile.created_at}

    -

    Updated At: {profile.updated_at}

    - -     - ) - } -} - -export default ProfileDetails; -``` - -Now, after authentication, the home page will display the user's avatar and info. - -## 4. Custom Sign Up Fields - -If you need extra fields on user sign up, you can add the `additionalSignUpFields` key to the Lock options parameter. For more information, see: [additionalSignUpFields](/libraries/lock/v10/customization#additionalsignupfields-array-). - -As an example, the `AuthService` constructor can be modified to request a user's `address`: - -```javascript -// src/utils/AuthService.js - -import Auth0Lock from 'auth0-lock' -import { browserHistory } from 'react-router' - -export default class AuthService extends EventEmitter { - constructor(clientId, domain) { - super() - // Configure Auth0 - this.lock = new Auth0Lock(clientId, domain, { - auth: { - redirectUrl: 'http://localhost:3000/login', - responseType: 'token' - }, - additionalSignUpFields: [{ - name: "address", // required - placeholder: "enter your address", // required - icon: "https://example.com/address_icon.png", // optional - validator: function(value) { // optional - // only accept addresses with more than 10 chars - return value.length > 10; - } - }] - }) - // Add callback for lock `authenticated` event - this.lock.on('authenticated', this._doAuthentication.bind(this)) - // Add callback for lock `authorization_error` event - this.lock.on('authorization_error', this._authorizationError.bind(this)) - // binds login functions to keep this context - this.login = this.login.bind(this) - } -} -``` - -Each `additionalSignUpFields` value is saved to the profile in the `user_metadata` attribute. - -Now, update the `Profile` component to display the address: - -```javascript -// src/components/Profile/ProfileDetails.js - -export class ProfileDetails extends React.Component { - // ... - render() { - const { profile } = this.props - const { address } = profile.user_metadata || {} // new address field - return ( - - - - - -

    Profile

    -

    Name: {profile.name}

    -

    Email: {profile.email}

    -

    Nickname: {profile.nickname}

    -

    Address: {address}

    -

    Created At: {profile.created_at}

    -

    Updated At: {profile.updated_at}

    - -     - ) - } -} -``` - -## 5. Update User Profile - -<%= include('../_includes/_profile-metadata-explanation') %> - -To update the user profile, call the [Update a user](/api/management/v2#!/Users/patch_users_by_id) endpoint with the new profile values. - -Update the `AuthService` class to add a new `updateProfile` method to make the http request with the correct request headers using the [fetch standard](https://fetch.spec.whatwg.org/). - -```javascript -// src/utils/AuthService.js - -export default class AuthService extends EventEmitter { - // a small constructor change to make domain accessible in other methods - constructor(clientId, domain) { - super() - this.domain = domain // setting domain parameter as an instance attribute - // ... - } - - // the new updateProfile - updateProfile(userId, data) { - const headers = { - 'Accept': 'application/json', - 'Content-Type': 'application/json', - 'Authorization': 'Bearer ' + this.getToken() //setting authorization header - } - // making the PATCH http request to auth0 api - return fetch(`https://<%= "${this.domain}" %>/api/v2/users/<%="${userId}"%>`, { - method: 'PATCH', - headers: headers, - body: JSON.stringify(data) - }) - .then(response => response.json()) - .then(newProfile => this.setProfile(newProfile)) //updating current profile - } - // ... -} -``` - -This `updateProfile` method can be used in a new `ProfileEdit` component, which includes a form to update the custom `address` field: - -```javascript -// src/components/Profile/ProfileEdit.js - -import React, { PropTypes as T } from 'react' -import ReactDOM from 'react-dom' -import AuthService from 'utils/AuthService' -import {Row, Col, Image, Form, FormGroup, FormControl, ControlLabel, Button} from 'react-bootstrap' -import s from './styles.module.css' - -export class ProfileEdit extends React.Component { - // receiving AuthService instance and profile data as props - static propTypes = { - profile: T.object, - auth: T.instanceOf(AuthService) - } - - // method trigged when edit form is submitted - handleSubmit(e) { - e.preventDefault() - const { profile, auth } = this.props - auth.updateProfile(profile.user_id, { - user_metadata: { - address: ReactDOM.findDOMNode(this.refs.address).value // the new address - } - }) - } - - render() { - const { profile } = this.props - const { address } = profile.user_metadata || {} - return ( - - -

    Editing Profile

    -
    - - - Address - - - - - - - - - - -
    - -     - ) - } -} - -export default ProfileEdit; -``` -Lastly, render the `ProfileEdit` component below the `ProfileDetails` on the Home page by updating the `Home` component render method: - -```javascript -// src/views/Main/Home/Home.js - -export class Home extends React.Component { - - render() { - const { profile } = this.state - return ( -
    -

    Home

    - - - -
    - ) - } -} -``` - -Now, if you reload your application, you will be able to view and edit the `address` value for the current user profile. - diff --git a/articles/client-platforms/react/05-linking-accounts.md b/articles/client-platforms/react/05-linking-accounts.md deleted file mode 100644 index 91733ae0bb..0000000000 --- a/articles/client-platforms/react/05-linking-accounts.md +++ /dev/null @@ -1,413 +0,0 @@ ---- -title: Linking Accounts -description: This tutorial demonstrates how to integrate Auth0 with ReactJS to link accounts. -budicon: 345 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-react-sample', - path: '05-Linking-Accounts', - requirements: [ - 'React 15.3' - ] -}) %> - -<%= include('../../_includes/_linking_accounts') %> - -## Show Linked Accounts Information - -The user profile contains an array of identities which consists of profile information from all linked providers. You can verify this by accessing the Auth0 [Users page](${manage_url}/#/users), selecting a user and scrolling down to `identities` under **Identity Provider Attributes**. - -This is how a profile looks after linking to Gmail: - -![User identities](/media/articles/users/user-identities-linked.png) - -If you fetch a profile containing linked accounts, you will have all this information available. - -To display this data, create two new components: `LinkedAccountsList` (to render a list of linked accounts) and `LinkedAccountItem` (to render an html row for each identity). - -```javascript -// src/components/LinkedAccount/LinkedAccountItem.js - -import React, { PropTypes as T } from 'react' -import {ListGroupItem, Button} from 'react-bootstrap' -import AuthService from 'utils/AuthService' -import styles from './styles.module.css' - -export class LinkedAccountItem extends React.Component { - static propTypes = { - auth: T.instanceOf(AuthService), - profile: T.object, - identity: T.object - } - - render() { - const { identity } = this.props - const profileName = identity.profileData ? identity.profileData.name : 'Main' - - return ( - - {identity.connection} - - ) - } -} - -export default LinkedAccountItem; -``` - -```javascript -// src/components/LinkedAccount/LinkedAccountsList.js - -import React, { PropTypes as T } from 'react' -import {ListGroup, Button} from 'react-bootstrap' -import LinkedAccountItem from './LinkedAccountItem' -import AuthService from 'utils/AuthService' -import styles from './styles.module.css' - -export class LinkedAccountsList extends React.Component { - static propTypes = { - auth: T.instanceOf(AuthService), - profile: T.object - } - - render() { - const { profile, auth } = this.props - let items = [] - if (profile && profile.identities) { - items = profile.identities.map(identity => { - return () - }) - } - - return ( -
    -

    Linked Accounts

    - {items} -
    - ) - } -} - -export default LinkedAccountsList; -``` - -`LinkedAccountsList` renders a container and one `LinkedAccountItem` for each identity in the user profile. It's expecting `profile` and `auth` as props, which will be sent by its parent, the `Home` component: - -```javascript -// src/views/Main/Home/Home.js - -import React, { PropTypes as T } from 'react' -import {Row, Col, Thumbnail, Button} from 'react-bootstrap' -import AuthService from 'utils/AuthService' -import LinkedAccountsList from 'components/LinkedAccount/LinkedAccountsList' -import styles from './styles.module.css' - -export class Home extends React.Component { - static contextTypes = { - router: T.object - } - - static propTypes = { - auth: T.instanceOf(AuthService) - } - - constructor(props, context) { - super(props, context) - this.state = { - profile: props.auth.getProfile() - } - props.auth.on('profile_updated', (newProfile) => { - this.setState({profile: newProfile}) - }) - } - - logout() { - this.props.auth.logout() - this.context.router.push('/login'); - } - - render() { - const { profile } = this.state - return ( -
    -

    Home

    - - - -

    Welcome {profile.name}!

    -

    - -

    -     - - - - -     -
    - ) - } -} - -export default Home; -``` - -Note that `Home.js` has been updated to render a left column with profile information such as name and avatar, and a **Logout** button. The `LinkedAccountsList` is rendered in right column. - -If you run the application, you should see the new home page after a successful login. The __Linked Accounts__ list will only show the main account. The next section shows how to add a button to link an account from another provider. - -## Linking Accounts - -To link accounts, call the [Link a user account](/api/management/v2#!/Users/post_identities) Auth0 API endpoint. To complete the request, you must provide the primary account Auth0 JWT (the token provided when the user logged in), the user id (from the JWT or the profile API) and the JWT of the account you want to link (secondary account). - -Since you need to do a second login to get the secondary account JWT, you will need a second `Auth0Lock` instance managed by a new helper class created in `src/utils/LinkAccountService.js`: - -```javascript -// src/utils/LinkAccountService.js - -import Auth0Lock from 'auth0-lock' - -export default class LinkAccountService { - constructor(auth) { - this.auth = auth - // the Auth0Lock instance to show signin window to link a provider - this.lock = new Auth0Lock(auth.clientId, auth.domain, { - auth: {params: {state: 'linking'}}, // state to identify in the callback - allowedConnections: ['facebook', 'google-oauth2'], - languageDictionary: { // allows to override dictionary entries - title: 'Link with:' // new window title - } - }) - this.link = this.link.bind(this) - } - - link() { - // Call the show method to display the authentication window. - this.lock.show() - } -} -``` - -`AuthService` continues to listen to `authenticated` events, but you will need to determine if a callback was triggered by the regular sign in process or the linking one. - -In the code above, the new `Auth0Lock` instance receives specific options, in this case `auth: {params: {state: 'linking'}}`. (For more information, see: -[Authentication Options](/libraries/lock/v10/customization#authentication-options).) - -In the updated `AuthService` class, the `_doAuthentication` callback checks for the `linking` state and calls the `LinkAccount` method if present. - -```javascript -// src/utils/AuthService.js - -import { EventEmitter } from 'events' -import Auth0Lock from 'auth0-lock' -import { browserHistory } from 'react-router' - -export default class AuthService extends EventEmitter { - constructor(clientId, domain) { - super() - this.clientId = clientId - this.domain = domain - // Configure Auth0 - this.lock = new Auth0Lock(clientId, domain, { - auth: { - redirectUrl: 'http://localhost:3000/login', - responseType: 'token' - } - }) - // Add callback for lock `authenticated` event - this.lock.on('authenticated', this._doAuthentication.bind(this)) - // Add callback for lock `authorization_error` event - this.lock.on('authorization_error', this._authorizationError.bind(this)) - // binds login functions to keep this context - this.login = this.login.bind(this) - } - - _doAuthentication(authResult) { - authResult.state = authResult.state || '' //making sure state exists - if (authResult.state.includes('linking')) { - this.linkAccount(authResult.idToken) // linkAccount when state is linking - } else { - // Otherwise saves the user token - this.setToken(authResult.idToken) - // navigate to the home route - browserHistory.replace('/home') - // Async loads the user profile data - this.lock.getProfile(authResult.idToken, (error, profile) => { - if (error) { - console.log('Error loading the Profile', error) - } else { - this.setProfile(profile) - } - }) - } - } - - // ... - - fetchApi(url, options) { - // performs api calls sending the required authentication headers - const headers = { - 'Accept': 'application/json', - 'Content-Type': 'application/json', - 'Authorization': 'Bearer ' + this.getToken() - } - - const userId = this.getProfile().user_id - return fetch(`<%= "https://${this.domain}/api/v2/users/${userId}/${url}" %>`, { - headers, - ...options - }) - .then(response => response.json()) - } - - linkAccount(token) { - // prepares api request body data - const data = { - link_with: token - } - // sends a post to auth0 api to create a new identity - return this.fetchApi('identities', { - method: 'POST', - body: JSON.stringify(data) - }) - .then(response => { - const profile = this.getProfile() - if (response.error) { - alert(response.message) - } else { - // updates profile identities - this.setProfile({...profile, identities: response}) - } - }) - } -} -``` - -This code also introduces two new methods: `fetchApi` (which constructs a request to the Auth0 API with the required headers and parses the response to JSON) and `linkAccount` (which uses `fetchApi` to send a _POST_ request to create a new identity in the user account, and updates the stored profile after a successful response). - -**NOTE**: For more details, see the [Link a user account](/api/management/v2#!/Users/post_identities) endpoint documentation. - -Now you can update the `LinkedAccountsList` component to render a __Link Account__ button using the `LinkAccountService.link` method: - -```javascript -// src/components/LinkedAccount/LinkedAccountsList.js - -import React, { PropTypes as T } from 'react' -import LinkAccountService from 'utils/LinkAccountService' - -export class LinkedAccountsList extends React.Component { - - render() { - const { profile, auth } = this.props - const linker = new LinkAccountService(auth) // initializing the new helper - let items = [] - if (profile) { - items = profile.identities.map(identity => { - return () - }) - } - - return ( -
    -

    Linked Accounts

    - {items} - // the button to call auth0lock and show sign in window - -
    - ) - } -} - -export default LinkedAccountsList; -``` - -Now, if you run the application, you will be able to click the __Link Account__ button on the user home page to link a Facebook or Google account. After a successful link, the new identity will be displayed in the __Linked Accounts__ list. - -## Un-Linking Accounts - -You can dissociate a linked account by calling the [Delete a linked user account](/api/management/v2#!/Users/delete_provider_by_user_id) Auth0 API endpoint. - -You will need to include the primary account `user_id`, and the `provider/user_id` of the identity you want to unlink. - -Update `AuthService` to provide an `UnlinkAccount` method: - -```javascript -// src/utils/AuthService.js - -import { EventEmitter } from 'events' -import Auth0Lock from 'auth0-lock' - -export default class AuthService extends EventEmitter { - // ... - unlinkAccount(identity) { - // sends a delete request to unlink the account identity - this.fetchApi(`<%= "identities/${identity.provider}/${identity.user_id}" %>`, { - method: 'DELETE' - }) - .then(response => { - const profile = this.getProfile() - if (response.error) { - alert(response.message) - } else { - // updates profile identities - this.setProfile({...profile, identities: response}) - } - }) - } -} -``` - -The `unlinkAccount` method takes an identity object, sends a `DELETE` request to the identities endpoint and, upon success, updates the stored profile with the current identities list. Since `setProfile` emits the `profile_updated` event, the view components will be properly updated. - -Lastly, update the `LinkedAccountItem` component to include an __unlink__ button: - -```javascript -// src/components/LinkedAccount/LinkedAccountItem.js -import React, { PropTypes as T } from 'react' -import {ListGroupItem, Button} from 'react-bootstrap' -import AuthService from 'utils/AuthService' -import styles from './styles.module.css' - -export class LinkedAccountItem extends React.Component { - // ... - unlink(identity) { - // shows a basic confirmation window, and calls auth0 unlink api - if (window.confirm(`Are you sure you want to unlink <%= "${identity.connection}" %>?`)) { - this.props.auth.unlinkAccount(identity) - } - } - - renderUnlink() { - // renders the unlink button, excluding the main identify row, which cannot be removed - const { profile, identity } = this.props - if (profile.user_id != identity.provider + '|' + identity.user_id) { - return ( - - ) - } - } - - render() { - const { identity } = this.props - const profileName = identity.profileData ? identity.profileData.name : 'Main' - - return ( - - {identity.connection} - {this.renderUnlink()} - - ) - } -} - -export default LinkedAccountItem; -``` - -When you run the application, you will see an __unlink__ button for each linked account. - diff --git a/articles/client-platforms/react/06-rules.md b/articles/client-platforms/react/06-rules.md deleted file mode 100644 index bac090cd87..0000000000 --- a/articles/client-platforms/react/06-rules.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: Rules -description: This tutorial will show you how to use Auth0 rules to extend what Auth0 has to offer. -budicon: 173 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-react-sample', - path: '06-Rules', - requirements: [ - 'React 15.3' - ] -}) %> - -<%= include('../_includes/_rules-introduction') %> - -## Create a Rule - -<%= include('../_includes/_rules-create-section') %> - -## Test the Rule Result - -<%= include('../_includes/_rules-test-result-intro', { profilelink: '/quickstart/spa/react/04-user-profile' }) %> - -```javascript -// src/components/Profile/ProfileDetails.js - -import React, { PropTypes as T } from 'react' -import {Row, Col, Image} from 'react-bootstrap' -import s from './styles.module.css' - -export class ProfileDetails extends React.Component { - static propTypes = { - profile: T.object - } - - render() { - const { profile } = this.props - return ( - - - - - -

    Profile Details

    -

    Name: {profile.name}

    -

    Email: {profile.email}

    -

    Nickname: {profile.nickname}

    -

    Created At: {profile.created_at}

    -

    Updated At: {profile.updated_at}

    -

    Country (added by rule): {profile.country}

    - -     - ) - } -} - -export default ProfileDetails; -``` - -![Country rule sample](/media/articles/reactjs/rule-country-show.png) - diff --git a/articles/client-platforms/react/07-authorization.md b/articles/client-platforms/react/07-authorization.md deleted file mode 100644 index 852427f23f..0000000000 --- a/articles/client-platforms/react/07-authorization.md +++ /dev/null @@ -1,157 +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: 500 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-react-sample', - path: '07-Authorization', - requirements: [ - 'React 15.3' - ] -}) %> - -<%= include('../_includes/_authorization-introduction', { ruleslink: '/quickstart/spa/react/06-rules' }) %>_ - -## Create a Rule to Assign Roles - -<%= include('../_includes/_authorization-create-rule') %>_ - -## Check if a User's Role is Present - -After creating the new rule, update the `AuthService` helper class with a new `isAdmin` method. This method will be useful in other parts of your application. It returns `true` for admin users and `false` otherwise. - -Included this snippet in the `AuthService.js` file: - -```javascript -// src/utils/AuthService.js - -export default class AuthService extends EventEmitter { - // ... - isAdmin() { - // Checks if the user has an `admin` role in the profile app_metadata - const profile = this.getProfile(); - const { roles } = profile.app_metadata || {}; - return !!roles && roles.indexOf('admin') > -1; - } -} -``` - -## 3. Restrict a Route based on User's Roles - -To demonstrate how to restrict access to certain routes based on a user's roles, you can update the `routes.js` file as shown below. - -The new `/admin` route requires the current user to have an __admin__ role, and redirects to `/unauthorized` if `auth.isAdmin()` returns `false`. - -Here is the complete `routes.js` code: - -```javascript -// src/views/Main/routes.js - -import React from 'react' -import {Route, IndexRedirect, Link} from 'react-router' -import AuthService from 'utils/AuthService' -import Container from './Container' -import Home from './Home/Home' -import Login from './Login/Login' -import Admin from './Admin/Admin' -import Unauthorized from './Unauthorized/Unauthorized' - -// initializing the AuthService instance -const auth = new AuthService('${account.clientId}', '${account.namespace}'); -// redirecting to saved url after a successful login -const redirectAfterLogin = (replace) => { - const url = localStorage.getItem('redirect_after_login') - if (url) { - localStorage.removeItem('redirect_after_login') - replace({ pathname: url }) - } -} -// onEnter callback to validate authentication in private routes -const requireAuth = (nextState, replace) => { - if (!auth.loggedIn()) { - // saving the current url to redirect later - localStorage.setItem('redirect_after_login', nextState.location.pathname) - replace({ pathname: '/login' }) - } else { - redirectAfterLogin(replace) - } -} -// onEnter callback to require admin role -const requireAdminAuth = (nextState, replace) => { - if (!auth.isAdmin()) { - replace({ pathname: '/unauthorized' }) - } -} - -export const makeMainRoutes = () => { - return ( - - - // all nested routes require authentication - - // only /admin route required also 'admin' role - - - - - - ) -} - -export default makeMainRoutes -``` - -<%= include('_includes/_env-note') %> - -Another feature introduced in the above code is correct redirection after a successful login. Now the current URL is stored as a local storage item before the user is directed to the login page. Later, the value is retrieved in the `redirectAfterLogin` method. - -## Admin and Unauthorized Views - -As a final step, add View Components for the two new routes: `Admin` and `Unauthorized` as shown below: - -```javascript -// src/views/Main/Admin/Admin.js - -import React from 'react' -import {Link} from 'react-router' - -export class Admin extends React.Component { - render() { - return ( -
    -

    Admin

    -

    You are viewing this because you are logged in and you have 'admin' role

    - Back to Home -
    - ) - } -} - -export default Admin; -``` - -```javascript -// src/views/Main/Unauthorized/Unauthorized.js - -import React from 'react' -import {Link} from 'react-router' - -export class Unauthorized extends React.Component { - render() { - return ( -
    -

    Unauthorized: you are not allowed to see this content

    - Back to Home -
    - ) - } -} - -export default Unauthorized; -``` - -Now you can verify that only users logged in with an email that contains `@example` (or whichever criteria is enforced by the rule you create) will be able to access the `/admin` route. - diff --git a/articles/client-platforms/react/08-calling-apis.md b/articles/client-platforms/react/08-calling-apis.md deleted file mode 100644 index 74c2a34140..0000000000 --- a/articles/client-platforms/react/08-calling-apis.md +++ /dev/null @@ -1,262 +0,0 @@ ---- -title: Calling APIs -description: This tutorial will show you how to make authenticated api calls with ReactJS. -budicon: 546 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-react-sample', - path: '08-Calling-Api', - requirements: [ - 'React 15.3' - ] -}) %> - -Auth0 exposes an assortment of API endpoints to assist you with authentication in your application. Auth0 suggests you conform to the RFC standard by sending the token through Authorization header when calling an API. - -## Add the Authorization Header to Requests - -In order to make an authorized request, you need to send the `Authorization` header containing the JWT Token. (For more information, see the [JSON Web Tokens](https://jwt.io/introduction/) documentation.) The token will be extracted from the request header and decoded by the server, validating the authenticated user. - -To send requests with the correct headers, update `AuthService` by adding a new helper method to wrap the native [fetch](https://fetch.spec.whatwg.org/) and add the authorization value: - -```javascript -// src/utils/AuthService.js - -import { EventEmitter } from 'events' -import { isTokenExpired } from './jwtHelper' -import Auth0Lock from 'auth0-lock' - -export default class AuthService extends EventEmitter { - // ... - _checkStatus(response) { - // raises an error in case response status is not a success - if (response.status >= 200 && response.status < 300) { - return response - } else { - var error = new Error(response.statusText) - error.response = response - throw error - } - } - - fetch(url, options) { - // performs api calls sending the required authentication headers - const headers = { - 'Accept': 'application/json', - 'Content-Type': 'application/json' - } - // if logged in, includes the authorization header - if (this.loggedIn()) { - headers['Authorization'] = 'Bearer ' + this.getToken() - } - - return fetch(url, { - headers, - ...options - }) - .then(this._checkStatus) // to raise errors for wrong status - .then(response => response.json()) // to parse the response as json - } -} -``` - -The new `fetch` method constructs requests to send to private endpoints. As the native `fetch` always resolves the returned promise, even for the 401 (unauthorized) response status, this code also adds a method to the promise stack that throws an `Error` for the `_checkStatus` case. - -## Create a Simple Server - -To demonstrate how a server would handle public and private endpoints, you can create a simple `node.js` server based on [express](https://expressjs.com/) and [express-jwt](https://github.com/auth0/express-jwt) with only two endpoints: `/api/public` and `/api/private`: - -```javascript -// server.js - -var express = require('express'); -var app = express(); -var jwt = require('express-jwt'); -require('dotenv').config(); - -var authenticate = jwt({ - secret: process.env.AUTH0_SECRET, - audience: process.env.AUTH0_CLIENT_ID -}); - -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'); -``` - -Both endpoints send a JSON response with a message attribute, but `/api/private` uses the __authenticate__ callback to validate the token received in the `Authorization` header. `express-jwt` is responsible for parsing and validating the token. (For more details, see the [express-jwt](https://github.com/auth0/express-jwt) documentation). - -> **Note:** The **client ID** and **secret** for your application are passed to the `jwt` middleware in the above snippet. These values should be provided to a `.env` file in your project. - -To test the server, run `node server.js`. It should be listening on port 3001 of `localhost`. - -## Add a Proxy and Start the Server - -Since you will be calling the server API from the client code and to prevent having to use [cors](https://github.com/expressjs/cors), you will need to proxy the calls from the client on port 3000 to the server API on 3001. - -To create the proxy, add a new setting to [webpack-dev-server](https://webpack.github.io/docs/webpack-dev-server.html) in the `webpack.config.js` file: - -```javascript -// webpack.config.js - -var config = getConfig({ - isDev: isDev, - in: join(src, 'app.js'), - out: dest, - html: function (context) { - return { - 'index.html': context.defaultTemplate({ - title: 'auth0 React Sample', - publicPath: isDev ? 'http://localhost:3000/' : '', - meta: { - 'name': 'auth0 React Sample', - 'description': 'A minimal reactJS sample application showing auth0 integration' - } - }) - } - }, - devServer: { // settings for webpack-dev-server - proxy: { //proxying /api calls to 3001 port - context: "/api", - options: { - target: "http://localhost:3001" - } - } - } -}); -``` - -With the proxy ready, update the `start` script to start both `webpack-dev-server` and `server.js` at the same time. As both servers will stay running in development mode, you will need to introduce the [npm-run-all](https://github.com/mysticatea/npm-run-all) tool in order to run them in parallel. - -The updated `scripts` entry in `package.json` looks like: - -```javascript -"scripts": { - "start": "npm-run-all --parallel dev-server server-api", - "dev-server": "NODE_ENV=development cross-env hjs-dev-server", - "server-api": "node server.js", - // ... -} -``` - -Now, when you run `npm start`, both servers should be up and the proxy active. - -## Show Public and Private Responses - -Now that you have updated `AuthService` to provide a custom `fetch` method for private requests and created a sample server, you are ready to update your ReactJS application to render the server responses. - -Create a new component named `Messages` in the folder `src/components/Messages`: - -```javascript -// src/components/Messages/Messages.js - -import React, { PropTypes as T } from 'react' -import {ListGroup, ListGroupItem} from 'react-bootstrap' -import AuthService from 'utils/AuthService' -import styles from './styles.module.css' - -export class Messages extends React.Component { - static propTypes = { - auth: T.instanceOf(AuthService) - } - - constructor(props, context) { - super(props, context) - this.state = { - publicMsg: "", - privateMsg: "" - } - this.callApis() - } - - callApis() { - const { auth } = this.props - // public http request - fetch('/api/public') - .then(response => response.json()) - .then(response => this.setState({publicMsg: response.message})) - // using auth to send an http request with authorization header - auth.fetch('/api/private') - .then(response => this.setState({privateMsg: response.message})) - .catch(error => this.setState({privateMsg: "" + error})) - } - - render() { - return ( - - - {this.state.publicMsg} - - - {this.state.privateMsg} - - - ) - } -} - -export default Messages; -``` - -Note that both server endpoints will receive requests as soon as the component is created. `callApis` uses the regular `fetch` for the public API, and the `auth.fetch` for the private API, and updates the component internal state after receiving the responses. - -Also note that `auth` is an `AuthService` instance expected as a prop, and that the component renders a `ListGroup` with two `ListGroupItem` to display the server messages. - -Lastly, include the `Messages` component in an application view. - -To show how this component works in both authenticated and not authenticated situations, do not only include it in `Home` (where the user is already authenticated) but also in `Login`, to demonstrate that the private API request fails: - -```javascript -// src/views/Main/Home/Home.js - -export class Home extends React.Component { - // ... - render() { - const { profile } = this.state - return ( -
    -

    Home

    -

    Welcome {profile.name}!

    - - -
    - ) - } -} - -export default Home; -``` - -```javascript -// src/views/Main/Login/Login.js - -export class Login extends React.Component { - // ... - render() { - const { auth } = this.props - return ( -
    -

    Login

    - - - - -
    - ) - } -} - -export default Login; -``` - -When you run the application, you will see the server API responses for both the public and private calls on the Home and Login pages. However, the private calls from the Login page will return an authorization error. - diff --git a/articles/client-platforms/react/09-mfa.md b/articles/client-platforms/react/09-mfa.md deleted file mode 100644 index fa9c52a965..0000000000 --- a/articles/client-platforms/react/09-mfa.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Multifactor Authentication -description: This tutorial will show you how to add Multifactor Authentication to your ReactJS with auth0. -budicon: 243 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-react-sample', - path: '09-MFA', - requirements: [ - 'React 15.3' - ] -}) %> - -<%= include('../_includes/_mfa-introduction') %> - - -In this tutorial, you will learn how to enable MFA in the ReactJS application created in previous steps, such as [Login](/quickstart/spa/react/01-login). - -## Enable Multifactor Authentication in Your Account - -<%= include('../_includes/_mfa-enable') %> - -## Login - -<%= include('../_includes/_mfa-login', { loginlink: '/quickstart/spa/react/01-login' }) %> - diff --git a/articles/client-platforms/react/10-customizing-lock.md b/articles/client-platforms/react/10-customizing-lock.md deleted file mode 100644 index 283b59f7a0..0000000000 --- a/articles/client-platforms/react/10-customizing-lock.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: Customizing Lock -description: This tutorial will show you how to customize lock widget. -budicon: 285 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-react-sample', - path: '10-Customizing-Lock', - requirements: [ - 'React 15.3' - ] -}) %> - -Using Lock is easy, but you may want to customize your login UI. For that, there are several [customization options](/libraries/lock/v10/customization) available. - -## Lock options - -Some UI customization can be done via the `options` parameter when creating a `Lock` instance. - -## Theme options - -You can set custom theme properties, such as a different logo or primary color, by adding a `theme` property with custom values when initializing the auth0 Lock widget. For more information, see: [Theming Options](/libraries/lock/v10/customization#theming-options). - -Modify `AuthService.js` to apply a custom theme: - -```javascript -// src/utils/AuthService.js - -import LogoImg from 'images/test-icon.png'; - -export default class AuthService extends EventEmitter { - constructor(clientId, domain) { - super() - // Configure Auth0 - this.lock = new Auth0Lock(clientId, domain, { - theme: { - logo: LogoImg, - primaryColor: "#b81b1c" - }, - auth: { - redirectUrl: 'http://localhost:3000/login', - responseType: 'token' - } - }) - // ... - } - // ... -} -``` - -## Language Dictionary Specification - -You can also customize the text that `Lock` will display with the `languageDictionary` option parameter. - For more information, see: [Language Dictionary Specification](/libraries/lock/v10/customization#languagedictionary-object-). - -```javascript -// src/utils/AuthService.js - -export default class AuthService extends EventEmitter { - constructor(clientId, domain) { - super() - // Configure Auth0 - this.lock = new Auth0Lock(clientId, domain, { - languageDictionary: { - title: "My Company" - } - }) - // ... - } - // ... -} -``` - -## Results - -This is how Lock will appear using a custom logo, color, and title: - -![Custom lock](/media/articles/reactjs/widget-custom-logo-color.png) diff --git a/articles/client-platforms/react/11-api-authorization.md b/articles/client-platforms/react/11-api-authorization.md deleted file mode 100644 index 4c843a802e..0000000000 --- a/articles/client-platforms/react/11-api-authorization.md +++ /dev/null @@ -1,189 +0,0 @@ ---- -title: OAuth 2.0 API Authorization -description: This tutorial demonstrates how to use API authorization ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-react-sample', - path: '11-OAuth2-Authorization' -}) %> - -<%= include('../../_includes/_api_auth_intro') %> - -<%= include('../../_includes/_compat_warning') %> - -### Before Starting - -## Enable OAuth 2.0 API Authorization - -<%= include('../../_includes/_configure_oauth2aas') %> - -## Create an Application - -<%= include('../../_includes/_new_app_no_sample') %> - -![App Dashboard](/media/articles/angularjs/spa_client_create.png) - -Be sure to register the URL of your app in the Allowed Callback URLs in your Application Settings. - -## Create a Resource Server (API) - -<%= include('../../_includes/_new_api') %> - -![Create API](/media/articles/api-auth/api-5.png) -![Update Scopes](/media/articles/api-auth/api-6.png) - -Take note of the API identifier and scopes you defined in the dashboard, as they will be used later. - -## Configure the AuthService - -The best way to coordinate the tasks related to authentication in your React app is to create a reusable service. Start by creating an `AuthService.js` file in the `src/utils` directory. At a minimum, the service needs to create an `Auth0` instance and have methods for logging the user in and parsing the hash string that comes back on successful authentication. - -```js -// src/utils/AuthService.js - -import { EventEmitter } from 'events' -import { isTokenExpired } from './jwtHelper' -import Auth0 from 'auth0-js' - -export default class AuthService extends EventEmitter { - constructor(clientId, domain) { - super() - // Configure Auth0 - this.auth0 = new Auth0({ - clientID: clientId, - domain: domain, - callbackURL: `<%= "${window.location.origin}/login" %>` - }); - - this.login = this.login.bind(this) - } - - login() { - this.auth0.login({ - responseType: 'id_token token', - scope: 'openid profile {API SCOPES}', - audience: '{API IDENTIFIER}' - }) - } - - parseHash(hash) { - const authResult = this.auth0.parseHash(hash) - if (authResult && authResult.idToken) { - localStorage.setItem('id_token', authResult.idToken); - localStorage.setItem('access_token', authResult.accessToken); - } - } -} -``` - -The `Auth0` instance is provided with the `clientId` and `domain` for your application and these values should be set in a `.env` file at the root of your project. - -The `login` method redirects the user to Auth0's hosted login page and the `parseHash` method retrieves the authentication information for the user after they are redirected back to your application. If authentication was successful, an `access_token` and `id_token` will be returned and these values can be stored in local storage for later use. - -The `access_token` retrieved from the authentication process can be used to make authenticated API calls. Remember that using `response_type: token` means that you cannot get a `refresh_token`. The `id_token` can be used in your application for basic profile data. If you want to retrieve additional profile data for the user, you can use the `userinfo` endpoint with the `access_token` in the `Authorization` header. For more information, see [our API documentation](/api/authentication/reference#get-user-info). - -## Trigger the Login - -The `login` method should be called from the appropriate component in your app. - -```js -// src/views/Main/Login/Login.js - -export class Login extends React.Component { - - render() { - const { auth } = this.props - return ( -
    -

    Login

    - - - - -
    - ) - } -} - -export default Login; -``` - -## Making an Authenticated API Call - -To make authenticated API calls, the user's `access_token` should be attached as an `Authorization` header using the `Bearer` scheme. One way to accomplish this is to extend the `fetch` API to include the header. - -```js -// src/util/AuthService.js - -export default class AuthService extends EventEmitter { - // ... - loggedIn() { - // Checks if there is a saved token and it's still valid - const token = this.getAccessToken() - return !!token && !isTokenExpired(token) - } - - getAccessToken() { - // Retrieves the user token from localStorage - return localStorage.getItem('access_token') - } - - fetch(url, options){ - // performs api calls sending the required authentication headers - const headers = { - 'Accept': 'application/json', - 'Content-Type': 'application/json' - } - - if (this.loggedIn()) { - headers['Authorization'] = 'Bearer ' + this.getAccessToken() - } - - return fetch(url, { - headers, - ...options - }) - .then(this._checkStatus) - .then(response => response.json()) - } -} -``` - -Note that the `Authorization` header is only set if the user has an unauthenticated `access_token`. - -The API call can now be made from the appropriate location in your app. - -```js -// src/components/Messages/Messages.js - -// ... -componentDidMount(){ - const { auth } = this.props - - // using auth to send an http request with authorization header - auth.fetch('{API URL}') - .then(response => console.log(response)) - .catch(error => console.log(error)) -} -``` - -<%= include('../../_includes/_create_resource_server') %> - -## Log Out - -Logging the user out simply requires removing their `access_token` and `id_token` from local storage. - -```js -// src/util/AuthService.js - -export default class AuthService extends EventEmitter { - // ... - logout() { - // Clear access and id tokens from local storage - localStorage.removeItem('id_token'); - localStorage.removeItem('access_token'); - } -} -``` diff --git a/articles/client-platforms/react/_includes/_dependencies.md b/articles/client-platforms/react/_includes/_dependencies.md deleted file mode 100644 index 8d573f9f8f..0000000000 --- a/articles/client-platforms/react/_includes/_dependencies.md +++ /dev/null @@ -1,15 +0,0 @@ -The only Auth0-related dependency that is required to get started is the [Lock widget](/lock). The widget can be retrieved either from npm or from Auth0's CDN. - -**npm** - -```bash -npm install auth0-lock -``` - -**CDN** - -```html - -``` - -> **Note**: The samples utilize the auth0-lock package from npm rather than referencing the CDN link. \ No newline at end of file diff --git a/articles/client-platforms/react/_includes/_env-note.md b/articles/client-platforms/react/_includes/_env-note.md deleted file mode 100644 index 6fa1a1a9f0..0000000000 --- a/articles/client-platforms/react/_includes/_env-note.md +++ /dev/null @@ -1 +0,0 @@ -> **Note:** The **client ID** and **domain** for your application are passed to the `AuthService` in the above snippet, but the downloadable samples contain a `.env.example` file that should be renamed to `.env` and populated with these values. \ No newline at end of file diff --git a/articles/client-platforms/react/_includes/_login.md b/articles/client-platforms/react/_includes/_login.md deleted file mode 100644 index c31e6fed94..0000000000 --- a/articles/client-platforms/react/_includes/_login.md +++ /dev/null @@ -1,180 +0,0 @@ -## Create an AuthService Class - -The best way to have authentication utilities available across your application is to create a helper class. With the class in place, you can share an instance of it by passing it as a prop. - -First, create an `AuthService` helper class to encapsulate the login functionality and save it inside the `src/utils` folder as `AuthService.js`. - -Inside this class, create an `Auth0Lock` class that receives your Auth0 credentials and an options object. (For a list of available options, see: [Lock: User configurable options](/libraries/lock/v10/customization)). Instead of hard-coding your credentials in this class, they are passed from the `AuthService` constructor parameters to the `Auth0Lock` instance. - -With the `Auth0Lock` instance, you can hook a callback for the `authenticated` event. This event will be triggered after every successful login, passing the user authentication token (`idToken`) as a parameter. The `setToken` method stores the `idToken` value in local storage. - -```js -// src/utils/AuthService.js - -import Auth0Lock from 'auth0-lock' -import { browserHistory } from 'react-router' - -export default class AuthService { - constructor(clientId, domain) { - // Configure Auth0 - this.lock = new Auth0Lock(clientId, domain, { - auth: { - redirectUrl: 'http://localhost:3000/login', - responseType: 'token' - } - }) - // Add callback for lock `authenticated` event - this.lock.on('authenticated', this._doAuthentication.bind(this)) - // binds login functions to keep this context - this.login = this.login.bind(this) - } - - _doAuthentication(authResult) { - // Saves the user token - this.setToken(authResult.idToken) - // navigate to the home route - browserHistory.replace('/home') - } - - login() { - // Call the show method to display the widget. - this.lock.show() - } - - loggedIn() { - // Checks if there is a saved token and it's still valid - return !!this.getToken() - } - - setToken(idToken) { - // Saves user token to local storage - localStorage.setItem('id_token', idToken) - } - - getToken() { - // Retrieves the user token from local storage - return localStorage.getItem('id_token') - } - - logout() { - // Clear user token and profile data from local storage - localStorage.removeItem('id_token'); - } -} -``` - -The other helper methods shown above include: `login` (to call `lock.show()` and display the login widget), `logout` (to remove the local storage data), and `loggedIn` (that checks if an `idToken` exists and returns a boolean). - -## Use the AuthService to Protect Private Routes - -To use the new class to protect routes, import `AuthService` in `src/views/Main/routes.js` and create a new instance. - -```js -// src/views/Main/routes.js - -import React from 'react' -import {Route, IndexRedirect} from 'react-router' -import AuthService from 'utils/AuthService' -import Container from './Container' -import Home from './Home/Home' -import Login from './Login/Login' - -const auth = new AuthService('${account.clientId}', '${account.namespace}'); - -// validate authentication for private routes -const requireAuth = (nextState, replace) => { - if (!auth.loggedIn()) { - replace({ pathname: '/login' }) - } -} - -export const makeMainRoutes = () => { - return ( - - - - - - ) -} - -export default makeMainRoutes -``` - -<%= include('_env-note') %> - -In `routes.js`, there is now an `onEnter` callback assigned to the `/home` route. This calls `requireAuth`, which checks whether the user is authenticated, and redirects to `/login` if they are not. - -## Create the Login View - -Create a new `Login` component and save it in `src/views/Main/Login/`. This React component should accept an `auth` object (which is an instance of the `AuthServce`) as a prop. - -```js -// src/views/Main/Login/Login.js - -import React, { PropTypes as T } from 'react' -import {ButtonToolbar, Button} from 'react-bootstrap' -import AuthService from 'utils/AuthService' -import styles from './styles.module.css' - -export class Login extends React.Component { - static propTypes = { - location: T.object, - auth: T.instanceOf(AuthService) - } - - render() { - const { auth } = this.props - return ( -
    -

    Login

    - - - -
    - ) - } -} - -export default Login; -``` - -The **Login** button `onClick` event calls `login` to show the Auth0 Lock widget. - -For this to work, `auth` needs to be included as a prop, which can be done from another component called `Container`. - -## Send `auth` from Router to Container Children - -To use the `auth` parameter in various child components, it needs to be propagated down from the `Container` component. - -```javascript -// src/views/Main/Container.js - -import React, { PropTypes as T } from 'react' -import { Jumbotron } from 'react-bootstrap' -import styles from './styles.module.css' - -export class Container extends React.Component { - render() { - let children = null; - if (this.props.children) { - children = React.cloneElement(this.props.children, { - auth: this.props.route.auth //sends auth instance from route to children - }) - } - - return ( - -

    - -

    - {children} -     - ) - } -} - -export default Container; -``` - -<%= include('../../_includes/_persisting_state') %> diff --git a/articles/client-platforms/react/dashboard-default.md b/articles/client-platforms/react/dashboard-default.md deleted file mode 100644 index ef86a078e5..0000000000 --- a/articles/client-platforms/react/dashboard-default.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Login -default: true -description: This tutorial demonstrates how to integrate Auth0 with ReactJS to add authentication and authorization to your app ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-react-sample', - path: '01-Login', - requirements: [ - 'React 15.3' - ] -}) %> - -## Install the Dependencies - -<%= include('_includes/_dependencies') %> - -<%= include('_includes/_login') %> \ No newline at end of file diff --git a/articles/client-platforms/react/index.yml b/articles/client-platforms/react/index.yml deleted file mode 100644 index 6125b57107..0000000000 --- a/articles/client-platforms/react/index.yml +++ /dev/null @@ -1,29 +0,0 @@ -title: React -alias: - - react - - reactjs -language: - - Javascript -framework: - - React -image: /media/platforms/react.png -tags: - - quickstart -snippets: - dependencies: client-platforms/react/dependencies - setup: client-platforms/react/setup - use: client-platforms/react/use -seo_alias: react -default_article: dashboard-default -articles: - - 00-getting-started - - 01-login - - 02-custom-login - - 03-session-handling - - 04-user-profile - - 05-linking-accounts - - 06-rules - - 07-authorization - - 08-calling-apis - - 09-mfa - - 10-customizing-lock diff --git a/articles/client-platforms/socket-io/01-login.md b/articles/client-platforms/socket-io/01-login.md deleted file mode 100644 index 1a1ecd56a0..0000000000 --- a/articles/client-platforms/socket-io/01-login.md +++ /dev/null @@ -1,95 +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 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-socket.io-samples', - path: '00-Starter-Seed', - requirements: [ - 'Socket.io 1.4.5', - 'NodeJS 5.0.0' - ] -}) %> - - -## 1. Set up the Allowed Origin (CORS) in Auth0 - -
    -

    Go to the Client 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 - -``` -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)} - -## 6. Set Authorization for Socket.io - -Add the following to your `index.js` file. - -```javascript -var app = require('express')(); -var http = require('http').Server(app); -var io = require('socket.io')(http); -var socketioJwt = require('socketio-jwt'); - -io - .on('connection', socketioJwt.authorize({ - secret: '${account.clientSecret}', - timeout: 15000 // 15 seconds to send the authentication message - })).on('authenticated', function(socket) { - //this socket is authenticated, we are good to handle more events from it. - console.log('hello! ' + JSON.stringify(socket.decoded_token)); - }); -``` - -## 7. Load the socket.io-client - -Add the following snippet before the `` on `index.html` - -```html - - -``` - -No URL is specified when doing `var socket = io();`, because the default behaviour is to connect to the host that serves the page. - -<%= include('../_includes/_persisting_state') %> diff --git a/articles/client-platforms/socket-io/index.yml b/articles/client-platforms/socket-io/index.yml deleted file mode 100644 index 7ae20d4261..0000000000 --- a/articles/client-platforms/socket-io/index.yml +++ /dev/null @@ -1,19 +0,0 @@ -title: Socket.io -community: true -alias: - - socket.io -language: - - Javascript -framework: - - socket.io -image: /media/platforms/socketio.svg -tags: - - quickstart -snippets: - dependencies: client-platforms/socket-io/dependencies - setup: client-platforms/socket-io/setup - use: client-platforms/socket-io/use -seo_alias: socket-io -default_article: 01-login -articles: - - 01-login diff --git a/articles/client-platforms/vanillajs/00-intro.md b/articles/client-platforms/vanillajs/00-intro.md deleted file mode 100644 index 989296351b..0000000000 --- a/articles/client-platforms/vanillajs/00-intro.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Introduction -description: This is a multi-step quickstart guide that demonstrates how to setup and manage authentication in your JavaScript app using Auth0 -budicon: 715 ---- - -This multi-step quickstart guide will walk you through setting up and managing authentication in your vanilla JS apps using Auth0. - -<%= include('../../_includes/_new_app') %> - -## Dependencies - -To integrate your JavaScript application with Auth0, add the Lock widget. You can get it from Bower or from the Auth0 CDN. - -**Bower** - -```bash -bower install auth0-lock -``` - -**CDN** - -```html - -``` diff --git a/articles/client-platforms/vanillajs/01-login.md b/articles/client-platforms/vanillajs/01-login.md deleted file mode 100644 index af7c4b093a..0000000000 --- a/articles/client-platforms/vanillajs/01-login.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: Login -description: This tutorial demonstrates how to use Auth0 to add authentication and authorization to your web app -budicon: 448 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-javascript-spa', - path: '01-Login' -}) %> - - -**If you have an existing application, follow the steps below.** - -${include('../\_callback')} - -<%= include('_includes/_login') %> - -### 4. Retrieve the User Profile and Display User Information - -Use the `id_token` to retrieve the user profile and display the user's nickname: - -```js -// app.js - -var retrieve_profile = function() { - var id_token = localStorage.getItem('id_token'); - if (id_token) { - lock.getProfile(id_token, function (err, profile) { - if (err) { - return alert('There was an error getting the profile: ' + err.message); - } - // Display user information - show_profile_info(profile); - }); - } -}; - -var show_profile_info = function(profile) { - var avatar = document.getElementById('avatar'); - document.getElementById('nickname').textContent = profile.nickname; - btn_login.style.display = "none"; - avatar.src = profile.picture; - avatar.style.display = "block"; - btn_logout.style.display = "block"; -}; - -// ... -retrieve_profile(); -``` - -```html - - - -

    Welcome

    -``` - -To discover all of 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. Log out - -In this implementation, a logout involves simply deleting the saved token from `localStorage` and redirecting the user to the home page: - -```js -// app.js - -var logout = function() { - localStorage.removeItem('id_token'); - window.location.href = "/"; -}; -``` - -<%= include('../_includes/_persisting_state') %> \ No newline at end of file diff --git a/articles/client-platforms/vanillajs/02-custom-login.md b/articles/client-platforms/vanillajs/02-custom-login.md deleted file mode 100644 index 55f714f774..0000000000 --- a/articles/client-platforms/vanillajs/02-custom-login.md +++ /dev/null @@ -1,209 +0,0 @@ ---- -title: Custom Login -description: This tutorial demonstrates how to use the Auth0 library to add custom authentication and authorization to your web app -budicon: 448 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-javascript-spa', - path: '02-Custom-Login' -}) %> - -In the [previous step](/quickstart/spa/vanillajs/01-login), we enabled login with the Auth0 Lock widget. You can also build your own custom 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-info 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 JavaScript custom login sample](https://github.com/auth0-samples/auth0-javascript-spa/tree/auth0js-v7/02-Custom-Login). - -Auth0.js version 8 verifies ID tokens during authentication transactions. Only tokens which are signed with the RS256 algorithm can be verified on the client side, meaning that your Auth0 client must be configured to sign tokens with RS256. See the [auth0.js migration guide](https://auth0.com/docs/libraries/auth0js/migration-guide#switching-from-hs256-to-rs256) for more details. -::: - - -## Getting Started - -Include the auth0.js library in your application. It can be retrieved from Auth0's CDN. - -```html - - - -``` - -## Create a Login Template - -Create a template which has a `form` for users to submit their credentials. The form should include fields for the user's `username` and `password`, as well as controls for triggering either a login, signup, or social authentication transaction. A button for allowing the user to log out can also be included. - -```html - - - - - -``` - -The buttons in this template will have event listeners registered from an `app.js` file. This will be the file from which authentication transaction methods will be called from auth0.js. - -## Create the Authentication Functions - -All authentication transactions should be handled from a single JavaScript file which can act as a service. The service requires functions named `login`, `signup`, and `loginWithGoogle` which all make calls to the appropriate auth0.js methods to handle those actions. - -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 client. A `responseType` of `token id_token` should also be specified. - -The `login` and `signup` functions 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 user's access token and ID token are saved into local storage if the transaction is successful. - -The `signup` method is a redirect-based flow and the authentication result is handled by the `parseHash` function. This function 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 UI changes to reflect that the user has logged in. - -```js -// app.js - -window.addEventListener('load', function() { - - var auth = new auth0.WebAuth({ - domain: '${account.namespace}', - clientID: '${account.clientId}', - redirectUri: window.location.href, - responseType: 'token id_token' - }); - - document.getElementById('btn-login').addEventListener('click', login); - document.getElementById('btn-register').addEventListener('click', signup); - document.getElementById('btn-google').addEventListener('click', loginWithGoogle); - document.getElementById('btn-logout').addEventListener('click', logout); - - function login() { - var username = document.getElementById('username').value; - var password = document.getElementById('password').value; - auth.client.login({ - realm: 'Username-Password-Authentication', - username: username, - password: password, - }, function(err, authResult) { - if (err) { - alert("something went wrong: " + err.message); - return - } - if (authResult && authResult.idToken && authResult.accessToken) { - setUser(authResult); - show_logged_in(); - } - }); - } - - function signup() { - var username = document.getElementById('username').value; - var password = document.getElementById('password').value; - auth.redirect.signupAndLogin({ - connection: 'Username-Password-Authentication', - email: username, - password: password, - }, function(err) { - if (err) alert("something went wrong: " + err.message); - }); - } - - function loginWithGoogle() { - auth.authorize({ - connection: 'google-oauth2' - }); - } - - function logout() { - localStorage.removeItem('access_token'); - localStorage.removeItem('id_token'); - window.location.href = "/"; - } - - function show_logged_in(username) { - document.querySelector('form.form-signin').style.display = "none"; - document.querySelector('div.logged-in').style.display = "block"; - } - - function show_sign_in() { - document.querySelector('div.logged-in').style.display = "none"; - document.querySelector('form.form-signin').style.display = "block"; - } - - function parseHash() { - var token = localStorage.getItem('id_token'); - if (token) { - show_logged_in(); - } else { - auth.parseHash(function(err, authResult) { - if (authResult && authResult.accessToken && authResult.idToken) { - window.location.hash = ''; - setUser(authResult); - show_logged_in(); - } else if (authResult && authResult.error) { - alert('error: ' + authResult.error); - show_sign_in(); - } - }); - - } - } - - function setUser(authResult) { - localStorage.setItem('access_token', authResult.accessToken); - localStorage.setItem('id_token', authResult.idToken); - } - - parseHash(); - -}); -``` - -The service has several other utility functions that are necessary to complete authentication transactions. - -* The `parseHash` function is necessary for redirect-based authentication transactions which, in this example, include `signup` and `loginWithGoogle`. -* The `logout` function removes the user's tokens from local storage which effectively logs them out of the application. -* The `setUser` function takes an authentication result object and sets the access token and ID token values into local storage -* The `show_logged_in` function hides the login form and displays the **Log Out** button. This is called after the user authenticates to reflect that they are logged in. -* The `show_sign_in` function does the opposite of `show_logged_in` and is called when the user logs out. - -With the login form and the authentication functions in place, users can now authenticate with a custom UI. \ No newline at end of file diff --git a/articles/client-platforms/vanillajs/03-session-handling.md b/articles/client-platforms/vanillajs/03-session-handling.md deleted file mode 100644 index bc8f56a652..0000000000 --- a/articles/client-platforms/vanillajs/03-session-handling.md +++ /dev/null @@ -1,122 +0,0 @@ ---- -title: Session Handling -description: This tutorial demonstrates how to add session handling and logout to your web app -budicon: 280 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-javascript-spa', - path: '03-Session-Handling' -}) %> - -In the previous steps of this tutorial, you enabled the user login with `Lock` and then with `auth0.js`. In this step, you will create a session for that user and also allow them to log out. - -## Create Session - -Once the user is logged in, a client-side session should be created for them. To do this, the user's `id_token` that is returned in the Lock `authenticated` callback parameter should be stored in `localStorage`. - -**NOTE**: This example uses `localStorage`, but you can use any storage library. At the end of this guide, you can see how to do the same with the `Lockr` storage library. - -```js -// app.js - -var lock = new Auth0Lock('<%= account.clientId %>', '<%= account.namespace %>'); - -lock.on("authenticated", function(authResult) { - localStorage.setItem('id_token', authResult.idToken); - // ... - -}); -... -``` - -## Check the Session - -Determining whether the user is authenticated on the client side is simply a matter of checking whether they have a JWT in local storage. Since JWT authentication is stateless (no session exists on the server), the presence of a JWT is all that is needed to give the front-end application some indication that the user is authenticated. - -```js -// app.js - -var init = function() { - var id_token = localStorage.getItem('id_token'); - if (id_token) { - - // perform logic for an authenticated user - // ... - } -}; - -init(); -``` - -## Logout - -To log a user out, provide a method that removes their token from `localStorage`. - -```js -// app.js - -var logout = function() { - localStorage.removeItem('id_token'); - window.location.href = "/"; -}; -``` - -Create buttons that will be used to log the user in and out. - -```html - - - - -``` - -Attach event listeners to the button clicks. The `login` button should call `lock.show()` and the `logout` button should call the `logout()` function above. - -```javascript -// app.js - -var btn_login = document.getElementById('btn-login'); -var btn_logout = document.getElementById('btn-logout'); - -btn_login.addEventListener('click', function() { - lock.show(); -}); - -btn_logout.addEventListener('click', function() { - logout(); -}); -... -``` - -## Session Handling Example using [Lockr](https://github.com/tsironis/lockr) Storage Library - -```js -// app.js - -// Create a session - -lock.on("authenticated", function(authResult) { - Lockr.set('id_token', authResult.idToken); -}); - -// Check the session - -var init = function() { - var id_token = Lockr.get('id_token'); - if (id_token) { - // ... - - } -}; - -init(); - -// Logout - -var logout = function() { - Lockr.rm('id_token'); - window.location.href = "/"; -}; -``` diff --git a/articles/client-platforms/vanillajs/04-user-profile.md b/articles/client-platforms/vanillajs/04-user-profile.md deleted file mode 100644 index 664aa479ba..0000000000 --- a/articles/client-platforms/vanillajs/04-user-profile.md +++ /dev/null @@ -1,200 +0,0 @@ ---- -title: User Profile -description: This tutorial demonstrates how to fetch, show, and update user profile information in your web app -budicon: 292 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-javascript-spa', - path: '04-User-Profile' -}) %> - -## Profile - -To fetch user profile information, call the `lock.getProfile` function, specifying the `idToken` and a callback to process the response. - -Once you retrieve the user profile, you can store it in `localStorage`. - -```js -// app.js - -window.addEventListener('load', function() { - var lock = new Auth0Lock('<%= account.clientId %>', '<%= account.namespace %>'); - - lock.on("authenticated", function(authResult) { - lock.getProfile(authResult.idToken, function (err, profile) { - if (err) { - - // Remove expired token (if any) - localStorage.removeItem('id_token'); - - // Remove expired profile (if any) - localStorage.removeItem('profile'); - - return alert('There was an error getting the profile: ' + err.message); - - } else { - - localStorage.setItem('id_token', authResult.idToken); - - localStorage.setItem('profile', JSON.stringify(profile)); - - showUserProfile(profile); - } - }); - }); - - // ... - - var logout = function() { - localStorage.removeItem('id_token'); - localStorage.removeItem('profile'); - window.location.href = "/"; - }; -}); -``` - -With the user's profile saved, attributes from it can be displayed on the page. - -```js -// app.js - -var showUserProfile = function(profile) { - - // Used for editing - var user_id = profile.user_id; - // ... - document.getElementById('avatar').src = profile.picture; - document.getElementById('name').textContent = profile.name; - document.getElementById('email').textContent = profile.email; - document.getElementById('nickname').textContent = profile.nickname; - document.getElementById('created_at').textContent = profile.created_at; - document.getElementById('updated_at').textContent = profile.updated_at; -}; -``` - -```html - - -
    -

    You are not logged in

    - -
    - - -``` - -## Custom Sign Up Fields - -<%= include('../_includes/_profile-metadata-explanation') %> - -You can add input fields to the sign up form by adding `additionalSignUpFields` to the `options` parameter of the `Auth0Lock` instance. - -**NOTE:** See [Additional sign up fields](/libraries/lock/v10/customization#additionalsignupfields-array-) for more information (**only available for Lock 10**). - -```js -// app.js - -var lock = new Auth0Lock('<%= account.clientId %>', '<%= account.namespace %>', { - additionalSignUpFields: [{ - name: "address", // required - placeholder: "Enter your address", // required - icon: "./address_icon.png", // optional - validator: function(value) { // optional - // only accept addresses with more than 10 characters - return value.length > 10; - } - }] -}); -``` - -Each `additionalSignUpFields` value is saved to the profile in the `user_metadata` attribute. - -To display this data, read it from the profile's `user_metadata`. - -```js -// app.js - -var showUserProfile = function(profile) { - - if (profile.hasOwnProperty('user_metadata')) { - document.getElementById('address').textContent = profile.user_metadata.address; - // ... - } -} -``` - -```html - - -Address: -``` - -## Update the User Profile - -You can add an `address` attribute to the profile's `user_metadata` by creating an AJAX call and a simple form. You will need to call the [update a user](/api/management/v2#!/Users/patch_users_by_id) endpoint on form-submit with a method of `PATCH` to update the user's data. This endpoint will return the user profile information updated with the new address. - -To successfully call the endpoint, add the user's JWT to the request as an `Authorization` header. - -```js -// app.js - -document.getElementById('btn-edit-submit').addEventListener('click', function() { - - var user_address = document.getElementById('edit_address').value; - var url = 'https://' + '<%= account.namespace %>' + '/api/v2/users/' + user_id; - var data = JSON.stringify({ user_metadata: {address: user_address} }); - var xhr = new XMLHttpRequest(); - - xhr.open('PATCH', url); - xhr.setRequestHeader('Content-Type', 'application/json'); - xhr.setRequestHeader('Accept', 'application/json'); - xhr.setRequestHeader('Authorization', 'Bearer ' + localStorage.getItem('id_token')); - - xhr.onload = function() { - if (xhr.status == 200) { - localStorage.setItem('profile', xhr.responseText); - showUserProfile(JSON.parse(xhr.responseText)); - } else { - alert("Request failed: " + xhr.statusText); - } - }; - - xhr.send(data); -}); -``` - -Create a simple form to add/update the `address` attribute. - -```html - - - -``` diff --git a/articles/client-platforms/vanillajs/05-linking-accounts.md b/articles/client-platforms/vanillajs/05-linking-accounts.md deleted file mode 100644 index b8bcfd1fab..0000000000 --- a/articles/client-platforms/vanillajs/05-linking-accounts.md +++ /dev/null @@ -1,195 +0,0 @@ ---- -title: Linking Accounts -description: This tutorial demonstrates how to link different user accounts in your web app -budicon: 345 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-javascript-spa', - path: '05-Linking-Accounts' -}) %> - -<%= include('../../_includes/_linking_accounts') %> - - -```js -// app.js - -var lock = new Auth0Lock('<%= account.clientId %>', '<%= account.namespace %>'); - -// Lock instance to launch a login to obtain the secondary id_token -lockLink = new Auth0Lock('<%= account.clientId %>', '<%= account.namespace %>', { - auth: { - params: { - state: 'linking' - } - }, - allowedConnections: ['Username-Password-Authentication', 'facebook', 'google-oauth2'], - languageDictionary: { // allows us to override dictionary entries - title: 'Link with:' - } -}); -``` - -When setting the callback for the `authenticated` event with the `on` method, you can determine which login was executed by checking the value of the `authResult.state` attribute. - -```js -// app.js - -lock.on('authenticated', function(authResult) { - // Every lock instance listens to the same event, so we need to check if - // it's not the linking login here. - if (authResult.state != 'linking') { - localStorage.setItem('id_token', authResult.idToken); - - lock.getProfile(authResult.idToken, function(err, profile) { - if (err) { - - return alert('There was an error getting the profile: ' + err.message); - - } else { - - localStorage.setItem('profile', JSON.stringify(profile)); - showUserIdentities(profile); - - // Linking purposes only - localStorage.setItem('user_id', profile.user_id); - login_div.style.display = 'none'; - logged_div.style.display = 'inline-block'; - } - }); - } -}); - -lockLink.on('authenticated', function(authResult) { - // Every lock instance listens to the same event, so we need to check if - // it's not the linking login here. - if (authResult.state == 'linking') { - // If it's the linking login, then do the link through the API. - linkAccount(authResult.idToken); - } -}); -``` - -Now that the second login is handled, you will need to actually do the linking. - -```js -// app.js - -var linkAccount = function(id_token) { - - // Get user_id value stored at login step - var user_id = localStorage.getItem('user_id'); - var url = 'https://' + '<%= account.namespace %>' + '/api/v2/users/' + user_id + '/identities'; - var data = JSON.stringify({ link_with: id_token }); - var xhr = new XMLHttpRequest(); - - xhr.open('POST', url); - xhr.setRequestHeader('Content-Type', 'application/json'); - xhr.setRequestHeader('Accept', 'application/json'); - xhr.setRequestHeader('Authorization', 'Bearer ' + localStorage.getItem('id_token')); - - xhr.onload = function() { - if (xhr.status == 201) { - fetchProfile(); - } else { - alert("Request failed: " + xhr.statusText); - } - }; - - xhr.send(data); -}; -``` - -The function takes the `id_token` of the account to link with and posts to the API, passing the `link_with` parameter with the `id_token` value in the body. If the request is successful, it fetches the profile to ensure that the accounts are linked. - -To begin the linking process, call the `show` method on `lockLink` instance: - -```js -// app.js - -document.getElementById('btn-link-account').addEventListener('click', function() { - lockLink.show(); -}); -``` - -```html - - -``` - -## User Profile from the Linked Accounts - -The user profile contains an array of identities, which includes the profile information from linked providers. - -To view a user's identities, access the [Users](${manage_url}/#/users) page on the Auth0 dashboard, select a user, and scroll down to `identities`. - -This example shows a user with a linked Google account: - -![User identities](/media/articles/users/user-identities-linked.png) - -If you fetch the profile after linking accounts, this same information will be available. You can display this information and provide an **Unlink** button. - -```html - - -

    Linked accounts

    -
      -``` - -```js -// app.js - -var showUserIdentities = function(profile) { - - login_div.style.display = "none"; - logged_div.style.display = "inline-block"; - - var linked_accounts = ''; - - profile.identities.forEach(function(identity) { - // Print all the identities but the main one (Auth0). - if (profile.user_id != identity.provider + '|' + identity.user_id) { - var identity_stringified = JSON.stringify(identity); - var btn = ""; - linked_accounts += - '
    • ' + identity.connection + ' ' + identity.profileData.name + ' ' + btn + '
      • '; - } - }); - - document.getElementById('linked-accounts-list').innerHTML = linked_accounts; - bind_unlink_buttons(); -}; -``` - -## Unlinking Accounts - -You can disassociate a linked account by calling the [unlink a user account](/api/management/v2#!/Users/delete_provider_by_user_id) endpoint using the primary `user_id` and the `provider` and `user_id` of the identity to unlink. - -```js -// app.js - -var unlinkAccount = function(identity) { - - // Get user_id value stored at login step - var user_id = localStorage.getItem('user_id'); - var url = 'https://' + '<%= account.namespace %>' + '/api/v2/users/' + user_id + '/identities/' + identity.provider + '/' + identity.user_id; - var xhr = new XMLHttpRequest(); - - xhr.open('DELETE', url); - xhr.setRequestHeader('Content-Type', 'application/json'); - xhr.setRequestHeader('Accept', 'application/json'); - xhr.setRequestHeader('Authorization', 'Bearer ' + localStorage.getItem('id_token')); - - xhr.onload = function() { - if (xhr.status == 200) { - fetchProfile(); - } else { - alert("Request failed: " + xhr.statusText); - } - }; - - xhr.send(); -}; -``` diff --git a/articles/client-platforms/vanillajs/06-rules.md b/articles/client-platforms/vanillajs/06-rules.md deleted file mode 100644 index f7611cb2d5..0000000000 --- a/articles/client-platforms/vanillajs/06-rules.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: Rules -description: This tutorial demonstrates how to use rules to easily customize and extend Auth0's capabilities -budicon: 173 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-javascript-spa', - path: '06-Rules' -}) %> - -<%= include('../_includes/_rules-introduction') %> - -## Create a Rule - -<%= include('../_includes/_rules-create-section') %> - -## Test the Rule - -<%= include('../_includes/_rules-test-result-intro', { profilelink: '/quickstart/spa/vanillajs/04-user-profile' }) %> - -```html - - - -``` - -```js -// app.js - -var showUserProfile = function(profile) { - // ... - document.getElementById('country').textContent = profile.country; - -}; -``` diff --git a/articles/client-platforms/vanillajs/07-authorization.md b/articles/client-platforms/vanillajs/07-authorization.md deleted file mode 100644 index 5295f4ecf3..0000000000 --- a/articles/client-platforms/vanillajs/07-authorization.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -title: Authorization -description: This tutorial demonstrates how to 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-javascript-spa', - path: '07-Authorization' -}) %> - -<%= include('../_includes/_authorization-introduction', { ruleslink: '/quickstart/spa/vanillajs/06-rules' }) %> - -### Create a Rule to Assign Roles - -<%= include('../_includes/_authorization-create-rule') %> - -## Restrict a Route Based on User's Roles - -To restrict access to certain routes, create a function that handles conditionally allowing or disallowing access to routes based on the user's `role`. - -```js -// app.js - -var route = function() { - - var id_token = localStorage.getItem('id_token'); - var current_location = window.location.pathname; - - if (id_token) { - - var profile = JSON.parse(localStorage.getItem('profile')); - - switch(current_location) { - case "/": - hide(document.getElementById('btn-login')); - show(document.getElementById('btn-logout')); - if (isAdmin(profile)) show(document.getElementById('btn-go-admin')); - if (isUser(profile)) show(document.getElementById('btn-go-user')); - break; - case "/user.html": - if (true != isUser(profile)) { - window.location.href = "/"; - } else { - show(document.querySelector('.container')); - show(document.getElementById('btn-logout')); - document.getElementById('nickname').textContent = profile.nickname; - } - break; - case "/admin.html": - if (true != isAdmin(profile)) { - window.location.href = "/"; - } else { - show(document.querySelector('.container')); - show(document.getElementById('btn-logout')); - document.getElementById('nickname').textContent = profile.nickname; - } - break; - }; - } else { // user is not logged in. - // Call logout just to be sure our local session is cleaned up. - if ("/" != current_location) { - logout(); - } - } -}; - -// ... - -var hide = function(element) { - element.style.display = "none"; -}; - -var show = function(element) { - element.style.display = "inline-block"; -}; - -route(); -``` - -The route function checks to determine whether the user is authenticated and then checks to see if he/she is an `admin` or `user` by employing the `isAdmin` and `isUser` functions, respectively. This method checks if the `roles` attribute of `app_metadata` added by the rule contains either `admin` or `user`. - -```js -// app.js - -var isAdmin = function(profile) { - if (profile && - profile.app_metadata && - profile.app_metadata.roles && - profile.app_metadata.roles.indexOf('admin') > -1) { - return true; - } else { - return false; - } -}; - -var isUser = function(profile) { - if (profile && - profile.app_metadata && - profile.app_metadata.roles && - profile.app_metadata.roles.indexOf('user') > -1) { - return true; - } else { - return false; - } -}; -``` - -Now, if the user logs in with an email that contains `@example.com`, they will be allowed to access the `/admin` route. Otherwise, the user will only be allowed to access `/` and `/user`. diff --git a/articles/client-platforms/vanillajs/08-calling-apis.md b/articles/client-platforms/vanillajs/08-calling-apis.md deleted file mode 100644 index 45c7867dd2..0000000000 --- a/articles/client-platforms/vanillajs/08-calling-apis.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: Calling APIs -description: This tutorial demonstrates how to make authenticated API calls -budicon: 546 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-javascript-spa', - path: '08-Calling-Api' -}) %> - -<%= include('../../_includes/_calling_apis') %> - -## Sending Authenticated HTTP Requests - -To make an authenticated request, add the user's JWT as an `Authorization` header to requests that go to secured endpoints. - -```js -// app.js - -var authenticate_request = function(xhr) { - var id_token = localStorage.getItem('id_token'); - xhr.setRequestHeader('Authorization', 'Bearer ' + id_token); -}; -``` diff --git a/articles/client-platforms/vanillajs/09-mfa.md b/articles/client-platforms/vanillajs/09-mfa.md deleted file mode 100644 index 35c2cb2208..0000000000 --- a/articles/client-platforms/vanillajs/09-mfa.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Multifactor Authentication -description: This tutorial demonstrates how to add Multifactor Authentication to your web app -budicon: 243 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-javascript-spa', - path: '09-MFA' -}) %> - -<%= include('../_includes/_mfa-introduction') %> - -## Enable Multifactor Authentication in Your Account - -<%= include('../_includes/_mfa-enable') %> - -## Login - -<%= include('../_includes/_mfa-login', { loginlink: '/quickstart/spa/vanillajs/01-login' }) %> diff --git a/articles/client-platforms/vanillajs/10-customizing-lock.md b/articles/client-platforms/vanillajs/10-customizing-lock.md deleted file mode 100644 index cbfd458473..0000000000 --- a/articles/client-platforms/vanillajs/10-customizing-lock.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: Customizing Lock -description: This tutorial demonstrates how to customize the Lock widget -budicon: 285 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-javascript-spa', - path: '10-Customizing-Lock' -}) %> - -Using Lock is easy, but you may want to customize your login UI. For that, there are several [customization options](/libraries/lock/v10/customization) available. - -## Lock Options - -Some UI customization can be done via the `options` parameter when creating a `Auth0Lock` instance. - -### Theme Options - -You can set custom theme properties, such as a different logo or primary color, by adding a `theme` property with custom values. - -```js -// app.js - -var lock = new Auth0Lock('<%= account.clientId %>', '<%= account.namespace %>', { - theme: { - logo: "test-icon.png", - primaryColor: "#b81b1c" - } -}); -``` - -For more information, see the [theming options](/libraries/lock/v10/ui-customization). - -### Language Dictionary Specification - -You can also customize the text that Lock will display with the `languageDictionary` option parameter. - -```js -// app.js - -var lock = new Auth0Lock('<%= account.clientId %>', '<%= account.namespace %>', { - languageDictionary: { - title: "My Company" - } -}); -``` - -For more information, see [language dictionary specification](/libraries/lock/v10/i18n). diff --git a/articles/client-platforms/vanillajs/_includes/_login.md b/articles/client-platforms/vanillajs/_includes/_login.md deleted file mode 100644 index d2fcdefd56..0000000000 --- a/articles/client-platforms/vanillajs/_includes/_login.md +++ /dev/null @@ -1,67 +0,0 @@ -## 1. Add the Auth0 Scripts and set the Viewport - -Add the code below to the `index.html` file to include the Lock widget library and set the viewport: - -```html - - - - - - - - - -``` - -## 2. Configure Lock - -Configure Lock with your `client ID` and `domain`: - -To discover all the available options for `Auth0Lock`, see [the Lock customization documentation](/libraries/lock/customization). - -```js -// app.js - -var lock = new Auth0Lock('<%= account.clientId %>', '<%= account.namespace %>'); -``` - -## 3. Implement the Login - -To implement the login, call the `.show()` method of Auth0's `lock` instance when a user clicks the login button. - -```js -// app.js - -var btn_login = document.getElementById('btn-login'); - -btn_login.addEventListener('click', function() { - lock.show(); -}); -``` - -```html - - - -``` - -After authentication, Auth0 will redirect the user back to your application with an identifying token. This token is used to retrieve the user's profile from Auth0 and to call your backend APIs. - -In this example, the `id_token` is stored in `localStorage` to keep the user authenticated after each page refresh: - -```js -// app.js - -lock.on("authenticated", function(authResult) { - lock.getProfile(authResult.idToken, function(error, profile) { - if (error) { - // Handle error - return; - } - localStorage.setItem('id_token', authResult.idToken); - // Display user information - show_profile_info(profile); - }); -}); -``` diff --git a/articles/client-platforms/vanillajs/dashboard-default.md b/articles/client-platforms/vanillajs/dashboard-default.md deleted file mode 100644 index 056269f8c9..0000000000 --- a/articles/client-platforms/vanillajs/dashboard-default.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Login -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-spa', - path: '01-Login' -}) %> - -${include('../\_callback')} - -<%= include('_includes/_login') %> - -<%= include('../_includes/_persisting_state') %> \ No newline at end of file diff --git a/articles/client-platforms/vanillajs/index.yml b/articles/client-platforms/vanillajs/index.yml deleted file mode 100644 index fb0d8d386c..0000000000 --- a/articles/client-platforms/vanillajs/index.yml +++ /dev/null @@ -1,32 +0,0 @@ -title: JavaScript -language: - - JavaScript -image: /media/platforms/html5.png -tags: - - quickstart -snippets: - dependencies: client-platforms/vanillajs/dependencies - setup: client-platforms/vanillajs/setup - use: client-platforms/vanillajs/use -alias: - - vanilla - - vanillajs - - spa - - single-page-app - - html5 - - backendless - - javascript-app -seo_alias: vanillajs -default_article: dashboard-default -articles: - - 00-intro - - 01-login - - 02-custom-login - - 03-session-handling - - 04-user-profile - - 05-linking-accounts - - 06-rules - - 07-authorization - - 08-calling-apis - - 09-mfa - - 10-customizing-lock diff --git a/articles/client-platforms/vuejs/01-login.md b/articles/client-platforms/vuejs/01-login.md deleted file mode 100644 index e001f075c9..0000000000 --- a/articles/client-platforms/vuejs/01-login.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -title: Login -description: This tutorial will show you how to use the Auth0 Vue.js SDK to add authentication and authorization to your web app. -budicon: 448 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-vue-samples', - path: '01-Login', - requirements: [ - 'Vue.js 1.0.16' - ] -}) %> - -${include('../\_callback')} - -## 1. Add the Auth0 Scripts - -Add **Lock** to your `index.html` file and set the viewport. - -${snippet(meta.snippets.dependencies)} - -## 2. Set Up Login and Logout on a Standard Vue Instance (No Routing) - -If your app does not require routing, set up a standard Vue.js instance that is attached to a DOM element. - -### 2.1 Login - -On the Vue instance, create a login method that calls `lock`. - -${snippet(meta.snippets.login)} - -In this example, the Vue instance is attached to an element with an ID of `app`. The `authenticated` property is used to keep track of the user's authentication state and is initially set to false. It is set to true upon a successful login. When the user authenticates successfully, their `profile` and `token` are saved in local storage. - -### 2.2 Logout - -To log the user out, simply remove their `profile` and `token` from local storage. - -${snippet(meta.snippets.logout)} - -These methods can now be attached to elements in the template. - -${snippet(meta.snippets.loginlogout)} - -__Note:__ There are multiple ways of implementing login. The example above displays the Lock Widget. However you may implement your own login UI by changing the line `` to ``. - -## 3. Make Secure Calls to an API - -To make secure calls to an API, attach the user's JWT as an `Authorization` header to the HTTP request. Be sure that you have **[vue-resource](https://github.com/vuejs/vue-resource)** in your project to make HTTP requests. - -${snippet(meta.snippets.http)} - -This method can then be used in your template to make the API call. - -${snippet(meta.snippets.httpcall)} - -## 4. Implement Routing - -For routing in a single page Vue.js app, use **[vue-router](https://github.com/vuejs/vue-router)**. To make use of the router, create Vue components for your application's states. - -${snippet(meta.snippets.routing)} - -The `canActivate` lifecycle hook is used to determine whether the route can be navigated to. If the user has a JWT in local storage, they are able to reach the route. The `checkAuth` method is used to check for the presence of a JWT in local storage. - -## 5. Intercept Unauthorized Requests - -An HTTP interceptor can be used to define custom actions for any unauthorized requests. In many cases, an `HTTP 401` will be returned when the user's JWT is expired or otherwise invalid. When this happens, you will likely want to invalidate the user's `authenticated` state on the front end and redirect them to the home or login route. - -${snippet(meta.snippets.interceptors)} - -<%= include('../_includes/_persisting_state') %> diff --git a/articles/client-platforms/vuejs/index.yml b/articles/client-platforms/vuejs/index.yml deleted file mode 100644 index 4f84d87aed..0000000000 --- a/articles/client-platforms/vuejs/index.yml +++ /dev/null @@ -1,25 +0,0 @@ -title: Vue -language: - - Javascript -framework: - - Vue.js -image: /media/platforms/vue.png -tags: - - quickstart -snippets: - dependencies: client-platforms/vuejs/dependencies - http: client-platforms/vuejs/http - httpcall: client-platforms/vuejs/httpcall - interceptors: client-platforms/vuejs/interceptors - login: client-platforms/vuejs/login - loginlogout: client-platforms/vuejs/loginlogout - logout: client-platforms/vuejs/logout - routing: client-platforms/vuejs/routing -alias: - - vue - - vuejs - - vue.js -seo_alias: vuejs -default_article: 01-login -articles: - - 01-login diff --git a/articles/clients/addons.md b/articles/clients/addons.md deleted file mode 100644 index 04a2772a95..0000000000 --- a/articles/clients/addons.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -description: Explains what Add-ons are and how they are associated with Auth0 Clients. ---- - -# Client Add-ons - -Add-ons are plugins associated with a client in Auth0. Usually, they are third-party APIs used by the client(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 a client navigate to [Dashboard > Clients > Addons](${manage_url}/#/clients/${account.clientId}/addons). - -![Client 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 a Client'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/clients/connections.md b/articles/clients/connections.md deleted file mode 100644 index 8218e2a79a..0000000000 --- a/articles/clients/connections.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -description: Explains what Connections are and how they are associated with Auth0 Clients. ---- - -# Client Connections - -Connections are sources of users. They are categorized into Database, Social, Enterprise and Passwordless and can be shared among different applications. - -Connections may be shared among multiple clients. You can configure any number of connections, and then, at client level, choose which of them should be enabled for the given client. - -To view all available connections for a client navigate to [Dashboard > Clients > Connections](${manage_url}/#/clients/${account.clientId}/connections). - -![Client Connections List](/media/articles/applications/connections-dashboard-list.png) - -To enable or disable a connection toggle the switch. In the screenshot above the user has many connections configured (a `Helpdesk` database connection, an Amazon social connection, a Bitbucket social connection, and more) but only two are enabled for this client: a database connection named `test-db` and the Facebook social connection. So when the users want to access this client, they have to either login using username and password or their Facebook connection. - -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 configuration - -Let's suppose that you want to implement this architecture. - -![Client connections example](/media/articles/applications/applications-connections-example.png) - -You have two applications: a 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 ADFS, Azure AD, Google Apps or LinkedIn authentication. - -You can configure this in Auth0 as follows: -- Create a client for the timesheets application: `Fabrikam Employee Timesheets`. -- Create a client for the customer portal: `Fabrikam Customer Portal`. -- Configure the following four [Enterprise connections](${manage_url}/#/connections/enterprise): Active Directory / LDAP, ADFS, Microsoft Azure AD and Google Apps. -- Configure the following [Social connection](${manage_url}/#/connections/social): LinkedIn. -- For the `Fabrikam Employee Timesheets` client enable the Active Directory / LDAP and Google Apps connections. -- For the `Fabrikam Customer Portal` client enable the ADFS, Microsoft Azure AD, Google Apps and LinkedIn connections. -- That's it! diff --git a/articles/clients/index.md b/articles/clients/index.md deleted file mode 100644 index c0b48ddaf2..0000000000 --- a/articles/clients/index.md +++ /dev/null @@ -1,108 +0,0 @@ ---- -description: Explains the basics of creating and using Auth0 Clients. -toc: true ---- - -# Clients - -## Overview - -An Auth0 **client** maps to your application and allows use of Auth0 for authentication. The term *client* 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. - -## Client Types - -There are four client types in Auth0. - -- **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). - -- **Non Interactive Clients**: 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 a Client - -Navigate to the [dashboard](${manage_url}) and click on the [Clients](${manage_url}/#/clients) menu option on the left. By default, you should have one client named *Default App*. You can either configure this one or create a new one by clicking the **+ Create Client** button. - -The *Create Client* windows pops open. Set a descriptive name for your client and select the client type. The client type should match your application. - -![Create Client window](/media/articles/applications/create-client-popup.png) - -After you set the name and client type, click **Create**. - -A new client will be created and you will be redirected to this client's view that has four tabs: - -- [Quick Start](${manage_url}/#/clients/${account.clientId}/quickstart): Lists all available Quick Starts, filtered by your client's type. - -- [Settings](${manage_url}/#/clients/${account.clientId}/settings): Lists all the available settings for your client. - -- [Addons](${manage_url}/#/clients/${account.clientId}/addons): Add-ons are extensions associated with clients. They are typically third-party APIs used by the client(s) for which Auth0 generates access tokens. For more details refer to: [Addons](/clients/addons). - -- [Connections](${manage_url}/#/clients/${account.clientId}/connections): Connections are sources of users. They are categorized into Database, Social and Enterprise and can be shared among different clients. For more details refer to: [Connections](/clients/connections). For a detailed list on the supported Identity Providers refer to: [Identity Providers Supported by Auth0](/identityproviders). - -### Client Settings - -Click on the [Settings](${manage_url}/#/clients/${account.clientId}/settings) tab of your client to review the available settings: - -- **Name**: The name of your client. This information is editable and you will see in the portal, emails, logs, and so on. - -- **Domain**: Your Auth0 account name. Note that the domain name is chosen when you create a new Auth0 account and cannot be changed. If you need a different one you have to register for a new account by selecting *New Account* at the top right menu. - -- **Client ID**: The unique identifier for your client. This is the ID you will use with when configuring authentication with Auth0. It is generated by the system when you create a new client 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. - -::: panel-warning Keep it safe -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. -::: - -- **Client Type**: The type of client you are implementing. Depending on which you choose, the available settings differ to show you only the settings applicable to your Client Type. You can change this value at any time by selecting one of the following: Native, Non Interactive Client, Regular Web Application, or Single Page Application. - -- **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). - -- **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 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 taking 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 querystrings and hash information are not taking into account when validating these URLs. - -- **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. - -- **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). - -## How to Delete a Client - -Navigate to the [Client Settings](${manage_url}/#/clients/${account.clientId}/settings) and scroll to the end of the page. Under the *Danger Zone* section you can find the **Delete Client** 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 client** to permanently remove the client. - -**Note**: You can also delete a client using the [DELETE /api/v2/clients/{id} endpoint](/api/management/v2#!/Clients/delete_clients_by_id) of the Management API. - -## Client 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 a client 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 clients, 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 - -Once you have configured your Client, some common next steps to take are: - -- **Configure a Connection** and enable it for your Client. For details refer to [Client Connections](/clients/connections). For a list of the supported Identity Providers refer to [Identity Providers Supported by Auth0](/identityproviders). - -- **Configure your app** to use your Auth0 Client. 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. - - **NOTE**: For background theory on client authentication flows, refer to [Client Authentication](/client-auth). - -- Use our latest [API Authorization](/api-auth) features to **call an API**. You need to [configure your tenant for the new API Authorization flows](/api-auth/tutorials/configuring-tenant-for-api-auth). - -- **Use [our APIs](/api/info)**. - - - 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. - - - The [Management API](/api/management/v2) can be used to automate various tasks in Auth0 such as creating users. diff --git a/articles/cms/index.md b/articles/cms/index.md index e93f5817e6..a213594235 100644 --- a/articles/cms/index.md +++ b/articles/cms/index.md @@ -1,20 +1,27 @@ --- url: /cms description: Explains CMS Identity Plugins such as WordPress and Joomla. +topics: + - wordpress + - joomla + - cms +contentType: concept +useCase: + - add-login --- # CMS Identity Plugins -Auth0 provides Content Management System Plugins/Extensions to integrate your CMS installation with your Auth0 account. These plugins enable Single Sign On for Enterprises, social login and user/password login through all your instances and platforms. +Auth0 provides Content Management System Plugins/Extensions to integrate your CMS installation with your Auth0 account. These plugins enable Single Sign-on (SSO) for Enterprises, social login and user/password login through all your instances and platforms. Login features are implemented through a new Login Widget (powered by Auth0) that enables: -- Single Sign On with Enterprise Directories (LDAP, AD, Google Apps, Office365 and SAML Provider) -- Shared User/Password between multiple WordPress accounts for Single Sign On -- Single Sign On with over 30 [Social Providers](/identityproviders) +- SSO with Enterprise Directories (LDAP, AD, G Suite, Office365 and SAML Provider) +- Shared User/Password between multiple WordPress accounts for SSO +- SSO with over 30 [Social Providers](/identityproviders) - User Management Dashboard - Optional Two Factor Authentication -- Single Sign On between WordPress and other applications +- SSO between WordPress and other applications - Reporting and Analytics diff --git a/articles/cms/joomla/configuration.md b/articles/cms/joomla/configuration.md index a2da1d4300..2219d97919 100644 --- a/articles/cms/joomla/configuration.md +++ b/articles/cms/joomla/configuration.md @@ -1,59 +1,76 @@ --- -description: How to configure a Joomla application with Auth0. +description: How to configure your Joomla instance for use with Auth0. +topics: + - joomla + - cms +contentType: how-to +useCase: + - add-login --- -# Joomla Configuration - -## Component configuration - -### Set up your *Auth0 Domain*, *Client Id* and *Client Secret* - -Copy the *Auth0 Domain*, *Client Id* and *Client Secret* settings from your app's *Application Settings* page on Auth0 to the *Auth0 Setup* page of your Joomla installation. - -#### Existing App -1. From the Joomla administrator interface, select *Auth0 > Auth0* from the **Components** dropdown menu. -2. Click on the *Options* button on the upper right of the *Auth0 Setup* page. -So, go to your account and under the [Apps section](${manage_url}/#/applications) and access to the setting of the app you want to use (or create a new one). If you don't have an account, create one [here](https://auth0.com) and the create a new app. -4. From the *Application Settings* page on Auth0, copy the *Auth0 Domain*, *Client Id* and *Client Secret* to the *Auth0 Setup* page of the Joomla interface. -5. Click on *Save & Close*. -6. Select the *Test* menu option to check that the Auth0 app data is complete. - -#### New App -1. From the Joomla administrator interface, select *Auth0 > Auth0* from the **Components** drop-down menu. -2. On the *Auth0 Setup* page, click *Create a free Auth0* or *Create an Auth0 App*. -3. In the new browser window, login to Auth0. (If you don't already have an Auth0 account, you can [create one](https://auth0.com).) -4. Select the **Apps / APIs** menu item then click on *+ New App / API*. -5. On the *Apps / APIs* page, name the new app and click *Save*. -6. On the new app's *Quick Settings* page, click *Settings*. -7. From the *Application Settings* page on Auth0, copy the *Auth0 Domain*, *Client Id* and *Client Secret* to the *Auth0 Setup* page of the Joomla interface. -8. Click on *Save & Close*. -9. Select the *Test* menu option to check that the Auth0 app data is complete. - -## Module configuration - -1. From the Joomla administrator interface, select *Module Manager* from the **Extensions** drop-down menu. -2. To publish the Auth0 module, click on the small red icon to the left of the module name. -3. Click on the module name to access the settings page. -4. Select from the *Position* drop-down menu a location where the module will be displayed. -5. Under the *Menu Assignment* tab, select *On all pages* from the drop-down. -6. Click on *Save & Close*. -7. The Auth0 *Login* button will now appear on your Joomla homepage. - -## Settings - -### Module - -- **Show login form**: Toggles Lock visibility. Deselect to disable login through the Auth0 extension. -- **Show as modal**: If enabled, displays a *Login* button that triggers Lock to appear as a modal form. If disabled, Lock is embedded in your page. -- **Form Title:** Sets the Lock title. -- **Show big social buttons:** Toggles the social buttons size between big and small -- **Icon URL:** Sets the Lock icon. -- **Enable Gravatar integration:** When user enters their email, their associated gravatar picture is displayed in the Lock header. -- **Customize the Login Widget CSS:** A valid CSS applied to the login page. For more information on customizing Lock, see [Can I customize the Login Widget?](https://github.com/auth0/wp-auth0#can-i-customize-the-login-widget) - -### Advanced Settings - -- **Translation:** A valid JSON object representing the Lock's dict parameter. If set, will override the Title setting. For more info see [dict {String|Object}](/libraries/lock/customization#dict-string-object-). -- **Username style:** Set this to *username* if you don't wish to force a username to be a valid email. -- **Remember last login:** Requests SSO data and enables *Last time you signed in with[...]* message. For more info see [rememberLastLogin {Boolean}](/libraries/lock/customization#rememberlastlogin-boolean-). -- **Widget URL:** The URL of to the latest available widget in the CDN. +# Joomla Integration + +Before you can use Auth0 to handle authentication and authorization requests for your Joomla users, you'll need to do some configuration from both sides of the integration. + +## Configure Application Values + +To use Auth0 with Joomla, be sure you have a valid [Application](/applications). You'll need to provide information about your application to the Auth0-Joomla extension you [installed](/cms/joomla/installation). + +1. Log in to the Joomla Control Panel using an admin account. Using the top navigation bar, go to **Components > Auth0 > Auth0**. Click **Options** (located in the top right of the window). + + ![](/media/articles/cms/joomla/configuration/joomla-1.png) + +2. Provide the requested values for your Auth0 application. You can find the **Domain**, **Client ID**, and **Client Secret** values using the [Application Settings page](${manage_url}/#/applications/${account.clientId}/settings). Click **Save & Close** to proceed. + + ![](/media/articles/cms/joomla/configuration/joomla-2.png) + +3. On the left-hand side, select **Test** (if you're not automatically redirected to the page). Make sure that the **Auth0 App Data** setting indicates **Complete**. + + ![](/media/articles/cms/joomla/configuration/joomla-3.png) + +## Configure the Joomla Module + +1. Log in to the Joomla Control Panel using an admin account. Using the top navigation bar, go to **Extensions > Modules**. + + ![](/media/articles/cms/joomla/configuration/joomla-4.png) + +2. Publish the module but clicking on the small, red icon located immediately to the left of the module name. + + ![](/media/articles/cms/joomla/configuration/joomla-5.png) + +3. Click on the name of the module `Auth0` to launch the settings page. On the right-hand side, use the **Position** drop-down menu to indicate [where the Auth0 Login button will be located](https://docs.joomla.org/Module_Position) on your site. + + ![](/media/articles/cms/joomla/configuration/joomla-6.png) + +4. Switch over the **Menu Assignment** tab, and using the **Module Assignment** drop-down menu, select **On all pages**. + +![](/media/articles/cms/joomla/configuration/joomla-7.png) + +5. Click **Save & Close**. The Auth0 Login button will now appear in the location you selected on your Joomla pages. Whenever a user clicks **Login**, they will see the [Auth0 Lock widget](/libraries/lock). + +![](/media/articles/cms/joomla/configuration/joomla-8.png) + +## Module Settings + +You can configure your Auth0-Joomla Extension by adjusting the **Module** and **Advanced** Settings. + +### Settings Located Under the Module Tab + +| Parameter | Description | +| - | - | +| Show login form | Toggles Lock visibility. Deselect to disable login through the Auth0 extension | +| Show as modal | If enabled, displays a *Login* button that triggers Lock to appear as a modal form; if disabled, Lock is embedded in your page. | +| Form title | Title displayed in Lock | +| Show big social buttons | Sets the size of the Social buttons in Lock | +| Icon URL | Sets the Lock icon | +| Enable Gravatar integration | Displays the user's gravatar picture when they enter their email address | +| Customize the Login Widget CSS | CSS snippet that will [apply custom styles to the login widget](https://github.com/auth0/wp-auth0#can-i-customize-the-login-widget) | + +### Settings Located Under the Advanced Settings Tab + +| Parameter | Description | +| - | - | +| Translation | A valid JSON object representing the [Lock's `dict` parameter](/libraries/lock/customization#dict-string-object-). If set, this overrides the Title setting | +| Username style | Toggles whether the username should be a value selected by the user or their email address | +| Remember last login | Requests Single Sign-on (SSO) data and [enables SSO](/libraries/lock/customization#rememberlastlogin-boolean-) | +| Widget URL | The URL of the [latest Lock version](https://github.com/auth0/lock#install) | diff --git a/articles/cms/joomla/installation.md b/articles/cms/joomla/installation.md index ecad485bdb..5da40cf615 100644 --- a/articles/cms/joomla/installation.md +++ b/articles/cms/joomla/installation.md @@ -1,12 +1,27 @@ --- -description: How to install a Joomla application with Auth0. +description: How to install Auth0 onto your Joomla platform. +topics: + - joomla + - cms +contentType: how-to +useCase: + - add-login --- - # Joomla Installation -1. Download the latest release of the Joomla extension from [auth0-joomla](https://github.com/auth0/auth0-joomla/releases). -2. Access the Joomla administrator interface and select *Extension Manager* from the **Extensions** dropdown menu. -3. Select *Choose File* under *Upload & Install Joomla Extension* and select the downloaded zip file. -4. Click *Upload & Install*. -5. [Setup the plugin](/cms/joomla/configuration) +1. [Download](https://github.com/auth0/auth0-joomla/releases) the latest release of the Auth0-Joomla extension. + +2. Log in to the Joomla Control Panel using an admin account. + + ![](/media/articles/cms/joomla/installation/joomla1.png) + +3. Click **Install Extensions** from the left-hand navigation menu. + + ![](/media/articles/cms/joomla/installation/joomla2.png) + +4. On the **Upload & Install Joomla Extension** tab, select the `.zip` file you downloaded above containing the Auth0-Joomla extension. Once you've selected your file, Joomla automatically installs your extension. + +![](/media/articles/cms/joomla/installation/joomla3.png) + +You're now ready to [set up the Auth0-Joomla extension](/cms/joomla/configuration). diff --git a/articles/cms/wordpress/configuration.md b/articles/cms/wordpress/configuration.md index b07bcf471b..e8807a0561 100644 --- a/articles/cms/wordpress/configuration.md +++ b/articles/cms/wordpress/configuration.md @@ -1,135 +1,244 @@ --- -description: How to configure WordPress as a client with Auth0. +description: How to configure WordPress as an application with Auth0. +topics: + - wordpress + - cms +contentType: how-to +useCase: + - add-login + - build-an-app + - customize-connections + - secure-an-api + - manage-users --- +# Configuring Login by Auth0 -# WordPress Configuration +Login by Auth0 can be configured using the Setup Wizard in the plugin ([covered here](/cms/wordpress/installation#setup-wizard)) or manually for more control over the process. The instructions below can also be used if the Setup Wizard did not complete or as part of troubleshooting login issues. -To configure the *Auth0 for WordPress* plugin, you will need to copy the *Domain*, *Client Id* and *Client Secret* from the *Settings* page of your app in the Auth0 dashboard to the *Basic* settings page of the Auth0 plugin in WordPress. +::: note +You will need to be logged into your Auth0 account before starting the steps below. If you don't have one yet, [create one here](https://auth0.com/signup). +::: -**Note:** In order to install or customize plugins, you will need to use a self-hosted WordPress.org site. Using the WordPress.com site does not allow installing plugins. +## Auth0 configuration -## Create a New Client +Your [Auth0 tenant](/getting-started/the-basics#account-and-tenants) must be configured to accept login requests from your WordPress site and source user identities from at least one [Connection](/identityproviders), whether that's an Auth0 database, a social connection, or a business directory. -You must first create a client in the Auth0 dashboard before you can configure the *Auth0 for WordPress* plugin. If you already have created the client you want to connect to WordPress, you can skip to the next section. +### Application setup -1. Log in to the [Auth0 dashboard](${manage_url}). (If you don't already have an Auth0 account, you can [create one](https://auth0.com). -2. Navigate to the *Clients* page and click **+ Create Client**. +1. First, we need an Application for your WordPress site: - ![Listing of Auth0 Clients in the Management Dashboard](/media/articles/cms/wordpress/management-dashboard.png) + - **If you're troubleshooting the Setup Wizard**, navigate to the [Applications](${manage_url}/#/applications) screen and look for an Application that is similar to your WordPress site name. If you don't find one, it means that an Application was not created by the Wizard. Restart the Setup Wizard in WordPress or follow the step just below to create an Application manually. + - **If you're configuring manually**, navigate to the [Applications](${manage_url}/#/applications) screen and click **Create Application**. Enter a name for the Application, select **Regular Web Applications**, and click **Create**. -3. In the *Create Client* window, name your Client and select your Client type, and click **Save**. + ![Auth0 Applications in the Management Dashboard](/media/articles/cms/wordpress/application-listing.png) - ![Creating the Client in the Management Dashboard](/media/articles/cms/wordpress/create-client.png) +2. Click on the **Settings** tab for the Application. You will see your Domain, Client ID, and Client Secret, which are used in **wp-admin > Auth0 > Settings** to connect to Auth0. -## Get your Domain, Client Id and Client Secret + ![Application Settings](/media/articles/cms/wordpress/auth0-app-settings.png) -1. Go to the [Clients](${manage_url}/#/clients) of the Auth0 dashboard and select the client you want to connect to WordPress. +3. **Application Type** must be set to **Regular Web Application** and **Token Endpoint Authentication Method** must be set to **Post** - ![Client Settings in the Management Dashboard](/media/articles/cms/wordpress/auth0-client-settings.png) +4. Scroll down to **Allowed Callback URLs** and provide the WordPress site URL with `?auth0=1` appended: -2. Leave this browser window open. +``` +https://your-wordpress-domain.com/index.php?auth0=1 +``` + +::: warning +The Callback URL here **must not** be cached, or you might see an "Invalid state" error during login. Please see [these troubleshooting steps](/cms/wordpress/invalid-state#cached-callback-urls) for more information. +::: + +5. Enter your WordPress site's **WordPress Address (URL)** (where the WordPress site appears publicly) and, if different, the **Site Address (URL)** (where wp-admin is served from) in the **Allowed Web Origins** field. Both of these values are found on your WordPress site's general settings screen. + +6. Enter your WordPress site's login URL in the **Allowed Logout URLs** field + +7. Leave the **Allowed Origins (CORS)** field blank (it will use the **Allowed Callback URLs** values from above) + +::: note +Make sure to match your site's protocol (http or https) and use the home URL as a base, found in **wp-admin > Settings > General > WordPress Address (URL)** for all URL fields above. +::: + +8. Scroll down and click the **Show Advanced Settings** link, then the **OAuth** tab and make sure **JsonWebToken Signature Algorithm** is set to RS256. If this needs to be changed later, it should be changed here as well as in wp-admin (see Settings > Basic below). + +9. Turn on **OIDC Conformant**. + + ![Application - Advanced Settings - OAuth](/media/articles/cms/wordpress/app-advanced-settings.png) + +10. Click the **Grant Types** tab and select at least **Authorization Code** and **Client Credentials**. + + ![Application - Advanced Settings - Grant Types](/media/articles/cms/wordpress/client-grant-types.png) + +11. Click **Save Changes**. + +### Authorize the Application for the Management API + +In order for your WordPress site to perform certain actions on behalf of your Auth0 tenant, you'll need to authorize the Application created above to access the Management API. This is not required but will enable retrieving complete user data on login (including `user_metadata` and `app_metadata`), email and password changes for users, and email verification re-sending when verified emails are required. + +1. Make sure your Application allows the Client Credentials grant (step 10 in the section above). + +2. Navigate to the [APIs](${manage_url}/#/apis) page. + +3. Click on **Auth0 Management API**, then the **Machine to Machine Applications** tab. + +4. Look for the WordPress Application and click **Unauthorized** to grant access. + +5. In the panel that appears, select only the `read:users` and `update:users` scopes and click **Update** (you can search using the **Filter scopes** field). + +![Application Advanced Settings](/media/articles/cms/wordpress/grant-app-access-to-api.png) + +### Database Connection setup + +Database Connections enable username and password login with user records stored at Auth0. This type of Connection is not required and can be skipped if you're using passwordless, social, or enterprise logins only. + +1. If you used the wizard during setup, navigate to the [Connections > Database](${manage_url}/#/connections/database) page and look for a Connection that has a similar name to the Application setup above. Otherwise, you can create a new Connection, use an existing Connection, or use the default **Username-Password-Authentication**. Click an existing Connection name to view settings or click **Create DB Connection** and follow the steps. + + ![Database Connection Listing](/media/articles/cms/wordpress/db-connection-listing.png) + +1. Click the **Applications** tab and activate the Application created above. + + ![Database Connection Settings](/media/articles/cms/wordpress/db-connection-apps.png) + +### Social Connection setup + +See [Social Connections](/connections/identity-providers-social) for detailed information on how to activate and configure this login method. + +### Enterprise Connection setup + +See [Enterprise Connections](/connections/identity-providers-enterprise) for detailed information on how to activate and configure this login method. + +## WordPress Configuration -## Set your Domain, Client Id and Client Secret +1. Go to back to the [Applications](${manage_url}/#/applications) page and select the Application created above. -1. Log in as an administrator of your WordPress installation. -2. Click on **Plugins** in the left menu of the WordPress dashboard and select the **Settings** link associated with the Auth0 plugin. +1. In a new tab/window, log into wp-admin for your WordPress site and go to **wp-admin > Auth0 > Settings**. - ![Navigating to Settings Page in WordPress](/media/articles/cms/wordpress/plugin-settings.png) +1. Copy **Domain**, **Client ID**, and **Client Secret** from your Auth0 Application page to your WordPress settings using the Copy to Clipboard buttons next to each field. -3. Copy the **Domain**, **Client Id** and **Client Secret** settings from the *Settings* page of your app in the Auth0 dashboard to the *Auth0 Settings > Basic* page of your WordPress account. +1. Scroll down and click **Save Changes**. - ![Providing Auth0 Client Settings to WordPress](/media/articles/cms/wordpress/auth0-plugin-settings-page.png) +## PHP Constant Setting Storage -4. Click **Save Changes** at the bottom of the page. +Plugin settings can be saved to the database (default) or they can be set using a specifically named PHP constant. This will allow for sensitive data like the client secret, API token, and migration token to be stored more securely (assuming that file they are defined in is [stored securely](https://codex.wordpress.org/Hardening_WordPress)). -## Auth0 for WordPress Plugin Settings +The constant **must** be defined before the plugin is loaded or it will not be used. This should happen in your `wp-config.php` file or in a [must-use plugin](https://codex.wordpress.org/Must_Use_Plugins). If the constant is defined in your theme's `functions.php` or in a plugin that loads after Auth0, the value will be ignored. + +The PHP constants are defined like so: + +```php +// Storing the client secret in a constant. +// Add to wp-config.php or anywhere before WP_Auth0_Options_Generic is instantiated. +// Constant name is "AUTH0_ENV_" + option key in caps. +define( 'AUTH0_ENV_CLIENT_SECRET', 'YOUR_CLIENT_SECRET_HERE' ); +``` + +The default constant name should be `AUTH0_ENV_` followed by the option name to override in all caps (the prefix can be modified with the `auth0_settings_constant_prefix` filter [explained here](/cms/wordpress/extending#auth0_settings_constant_prefix)). All plugin options that can be overridden and their keys can be found in the `WP_Auth0_Options::defaults()` [method](https://github.com/auth0/wp-auth0/blob/master/lib/WP_Auth0_Lock_Options.php). + +**Note:** The `migration_token` value is generated by the plugin when user migration is turned on. If there is already a value in the admin, make sure to set the constant to the same value. If that value needs to change, it also must be changed in the custom scripts for the database Connection being used in the Auth0 dashboard. + +The settings field will change its display based on this new value and show the constant being used for reference. This value will be used everywhere in the plugin automatically. + +**Important:** Saving the settings page after setting a constant value will validate the constant-set values (but not change them) and delete them from the options array being saved to the database. If you are just testing this functionality, do not save settings in the WordPress admin page until you're ready to delete that value. + +All sites in a WordPress multi-site network will use the same constant value making this an easy way to setup a network using a single Application and database Connection. + +## Plugin settings ### Basic -* **Domain:** The app domain copied from the app settings in your dashboard. -* **Client Id:** The app client id copied from the app settings in your dashboard. -* **Client Secret:** The app client secret copied from the app settings in your dashboard. -* **Client token:** The token required to allow the plugin to communicate with Auth0 to update your account settings. If the token has been set, this field will display "Not Visible". If blank, no token has been provided and you will have to [generate a token](/api/v2) with the appropriate scopes listed here. -* **WordPress login enabled:** If enabled, displays a link on the login page to access the regular WordPress login. -* **Allow signup:** User signup will be available only if the WordPress *Anyone can register* option is enabled. You can find this setting under **Settings > General > Membership**. +* **Domain:** The Domain copied from the Application settings in your dashboard. Option name is `domain`. + +* **Custom Domain:** The Custom Domain for your tenant, if one is configured. See [Custom Domains](/custom-domains) for more information. Option name is `custom_domain`. + +* **Client ID:** The Client ID copied from the Application settings in your dashboard. Option name is `client_id`. + +* **Client Secret:** The Client Secret copied from the Application settings in your dashboard. Option name is `client_secret`. + +* **JWT Signature Algorithm** The algorithm used for signing tokens from the Advanced Application Settings, OAuth tab; default is RS256. Option name is `client_signing_algorithm`. + +* **JWKS Cache Time (in minutes):** How long the JWKS information should be stored when using the RS256 JWT Signature Algorithm. Option name is `cache_expiration`. + +* **Original Login Form on wp-login.php:** Provides ways to access or block the core WordPress login page. Option name is `wordpress_login_enabled`. Login page code option name is `wle_code`. + + * **Never** will not allow the core WordPress login form to display. + * **Via a link under the Auth0 form** will display a link to the WordPress core login form directly below the Auth0 embedded one on `wp-login.php`. The login page can also be accessed directly by adding `?wle` to the login URL. + * **When "wle" query parameter is present** will allow the login page to be accessed directly by adding `?wle` to the login URL. This will bypass the Universal Login Page redirect. + * **When "wle" query parameter contains specific code** will allow the login page to be accessed directly by adding `?wle=` plus a code to the login URL. The code is generated automatically and will be shown below the controls for this setting. This will bypass the Universal Login Page redirect. + +* **Allow Signups:** User signup will be available only if the WordPress *Anyone can register* option is enabled. You can find this setting under **Settings > General > Membership**. ### Features -* **Password Policy:** Select the level of complexity you want to enforce for user passwords. For more information on password policies, see [Password Strength in Auth0 Database Connections](/password-strength). -* **Single Sign On (SSO):** Enables SSO on your WordPress, allowing users to log in once and be automatically logged into any of your sites which use Auth0. For more information, see [What is SSO?](/sso). -* **Single Logout:** Enable this option for Single Logout. For more information, see [What is Single Log Out?](/sso/single-sign-on#what-is-single-log-out-). -* **Multifactor Authentication (MFA):** Enable this option for multifactor authentication with Google Authenticator. (See [Multifactor Authentication in Auth0](/multifactor-authentication) for more information.) You can enable other MFA providers on the [Auth0 dashboard](${manage_url}/#/multifactor). -* **FullContact integration:** Enable this option to fill your user profiles with the data provided by FullContact. A valid API key is required. For more information, see [Augment User Profile with FullContact](/scenarios/mixpanel-fullcontact-salesforce#2-augment-user-profile-with-fullcontact-). -* **Store geolocation:** Enable this option to store geolocation information based on the IP addresses saved in `user_metadata`. -* **Store zip-code income:** Enable this option to store income data based on the zip-code calculated from each user's IP address. +* **Universal Login Page:** Redirects the `wp-login.php` page to the Universal Login Page for Single Sign-on (SSO) authentication using all active Connections for this Application. Option name is `auto_login`. + +* **Auto Login Method:** A single, active connection to use for authentication when **Universal Login Page** is turned on. Leave this blank to show all active Connections on the Universal Login Page. Option name is `auto_login_method`. + +* **Auth0 Logout:** Enable this option to log out of Auth0 when logging out of WordPress. Option name is `singlelogout`. + +* **Override WordPress Avatars:** Forces WordPress to use Auth0 avatars. Option name is `override_wp_avatars`. + +### Embedded + +Options here do not affect the Universal Login Page (see [this page](/universal-login) for customization options). + +* **Passwordless Login:** Enable this option to turn on Passwordless login on all embedded Auth0 login forms. Passwordless connections are managed in the Auth0 dashboard and at least one must be active and enabled on this Application for this to work. Option name is `passwordless_enabled`. + +* **Icon URL:** Sets the icon above the embedded Auth0 login form. Option name is `icon_url`. -### Connections +* **Form Title:** Sets the title of the embedded Auth0 login form. Option name is `form_title`. -Enable the supported social identity providers you want to allow users to login with. You can configure your own app keys and settings for these connections in the [Auth0 Dashboard](${manage_url}/#/connections/social). +* **Enable Gravatar Integration:** When user enters their email, their associated Gravatar picture is displayed in the embedded Auth0 login form. Option name is `gravatar`. -### Appearance +* **Login Name Style:** Selecting **Email** will require users to enter their email address to login. Set this to **Username** if you do not want to force a username to be a valid email address. Option name is `username_style`. Option name is `client_secret_b64_encoded`. -* **Form Title:** Sets the title of the Lock widget. -* **Show big social buttons:** Toggles the social buttons size between big and small. -* **Icon URL:** Sets the Lock display icon. -* **Enable Gravatar integration:** When user enters their email, their associated gravatar picture is displayed in the Lock header. -* **Customize the Login Widget CSS:** A valid CSS that will be applied to the login page. For more information on customizing Lock, see [Can I customize the Login Widget?](https://github.com/auth0/wp-auth0#can-i-customize-the-login-widget) -* **Username style:** Selecting **Email** will require users to enter their email address to login. Set this to *username* if you do not want to force a username to be a valid email address. -* **Remember last login:** Requests SSO data and enables the *Last time you signed in with[...]* option. For more information, see [rememberLastLogin {Boolean}](/libraries/lock/customization#rememberlastlogin-boolean-). -* **Translation:** A valid JSON object representing the Lock's dict parameter. The 'dict' parameter can be a string matching any supported language ('en', 'es', 'it', etc...) or an object containing customized label text. If set, this will override the Title setting. For more info see [dict {String|Object}](/libraries/lock/customization#dict-string-object-). +* **Primary Color:** Information on this setting is [here](/libraries/lock/v11/configuration#primarycolor-string-). Option name is `primary_color`. + +* **Extra Settings:** A valid JSON object that includes options to call Lock with. This overrides all other options set above. For a list of available options, see [Lock: User configurable options](/libraries/lock/customization) (e.g.: `{"disableResetAction": true }`). Option name is `extra_conf`. + +* **Use Custom Lock JS URL:** When turned off, WordPress will use the latest tested version of Lock (Auth0 embedded login form) automatically. When turned on, administrators can provide a custom Lock URL to use. Option name is `custom_cdn_url`. + +* **Custom Lock JS URL:** A valid URL pointing to a version of Lock. This field will be automatically hidden when **Use Custom Lock JS URL** is turned off. Option name is `cdn_url`. + +* **Connections to Show:** List here each of the identity providers you want to allow users to login with. If left blank, all enabled providers will be allowed. (See [connections {Array}](/libraries/lock/customization#connections-array-) for more information.) Option name is `lock_connections`. + + ::: note + If you have enabled Passwordless login, you must list here all allowed social identity providers. (See [.social(options, callback)](https://github.com/auth0/lock-passwordless#socialoptions-callback) for more information.) + ::: ### Advanced -* **Use passwordless login:** Enable this option to replace the login widget with Lock Passwordless. -* **Widget URL:** The URL of to the latest available widget in the CDN. -* **Connections:** List here each of the identity providers you want to allow users to login with. If left blank, all enabled providers will be allowed. (See [connections {Array}](/libraries/lock/customization#connections-array-) for more information.) -**NOTE:** If you have enabled Passwordless login, you must list here all allowed social identity providers. (See [.social(options, callback)](https://github.com/auth0/lock-passwordless#socialoptions-callback) for more information.) -* **Remember users session:** By default, user sessions live for two days. Enable this setting to keep user sessions live for 14 days. -* **Link users with same email:** This option enables the linking of accounts with the same verified e-mail address. -* **Twitter consumer key and consumer secret:** The credentials from your Twitter app. For instructions on creating an app on Twitter, see [Obtain Consumer and Secret Keys for Twitter](/connections/social/twitter). -* **Facebook app key and app secret:** The credentials from your Facebook app. For instructions on creating an app on Facebook, see [Obtain an App ID and App Secret for Facebook](/connections/social/facebook). -* **User Migration:** Enabling this option will expose the Auth0 migration web services. However, the connection will need to be manually configured in the [Auth0 dashboard](${manage_url}). For more information on the migration process, see [Import users to Auth0](/connections/database/migrating). -* **Migration IPs whitelist:** Only requests from listed IPs will be allowed access to the migration webservice. -* **Auth0 Implicit Flow:** If enabled, uses the [Implicit Flow](/protocols#oauth-for-native-clients-and-javascript-in-the-browser) protocol for authorization in cases where the server is without internet access or behind a firewall. -* **Login redirection URL:** If set, redirects users to the specified URL after login. -* **Requires verified email:** If set, requires the user to have a verified email to login. -* **Auto Login (no widget):** Skips the login page (a single login provider must be selected). -* **Enable on IP Ranges:** Select to enable the Auth0 plugin only for the IP ranges you specify in the **IP Ranges** textbox. -* **IP Ranges:** Enter one range per line. Range format should be: `xx.xx.xx.xx - yy.yy.yy.y` -* **Valid Proxy IP:** List the IP address of your proxy or load balancer to enable IP checks for logins and migration web services. -* **Extra settings:** A valid JSON object that includes options to call Lock with. This overrides all other options set above. For a list of available options, see [Lock: User configurable options](/libraries/lock/customization) (e.g.: `{"disableResetAction": true }`). -* **Anonymous data:** The plugin tracks anonymous usage data by default. Click to disable. -* **Enable JWT Auth integration:** This enables JWT Auth integration. +* **Require Verified Email:** If set, requires the user to have a verified email to log in. This can prevent some Connections from working properly if they do not provide an email address or an `email_verified` flag in the user profile data. Option name is `requires_verified_email`. -### Dashboard +* **Skip Strategies:** If Require Verified Email is turned on, this setting will display. This field accepts strategy names to skip the verified email requirement on login and account association. This should **only** be used for strategies that do not provide an `email_verified` flag. -Here you can customize the dashboard's display and segmentation of data. +* **Remember User Session:** By default, user sessions live for two days. Enable this setting to keep user sessions live for 14 days. Option name is `remember_users_session`. -## Integrate the Plugin +* **Login Redirection URL:** If set, redirects users to the specified URL after login. This does not affect logging in via the `[auth0]` shortcode. Option name is `default_login_redirection`. To change the redirect for the shortcode, add a `redirect_to` attribute, like so: -The plugin includes an `auth0_user_login` action to provide notification for each time a user logs in or is created in WordPress. + `[auth0 redirect_to="http://yourdomain.com/redirect-here"]` -[Learn more about WordPress actions](https://codex.wordpress.org/Plugin_API#Actions). +* **Force HTTPS Callback:** Enable this option if your site allows HTTPS but does enforce it. This will force Auth0 callbacks to HTTPS in the case where your home URL is not set to HTTPS. Option name is `force_https_callback`. -This action accepts five parameters: +* **Auto Provisioning:** Should new users from Auth0 be stored in the WordPress database if new registrations are not allowed? This will create WordPress users that do no exist when they log in via Auth0 (for example, if a user is created in the Auth0 dashboard). Option name is `auto_provisioning`. -1. `$user_id` (int): The id of the user logged in. -2. `$user_profile` (stdClass): The Auth0 profile of the user. -3. `$is_new` (boolean): If the user has created a new WordPress login, this is set to `true`, otherwise `false`. Not to be confused with Auth0 registration, this flag is `true` only if a new user is created in the WordPress database. -4. `$id_token` (string): The user's JWT. -5. `$access_token` (string): The user's access token. + ::: note + If registrations are allowed in WordPress, new users will be created regardless of this setting. + ::: - **Note:** An access token is not provided when using *Implicit Flow*. +* **User Migration:** Enabling this option will expose the Auth0 migration web services. However, the Connection will need to be manually configured in the [Auth0 dashboard](${manage_url}). For more information on the migration process, see our [documentation page on user migrations](/cms/wordpress/user-migration). The **Generate New Migration Token** button can be used to replace the saved token with a new one. Make sure to have your database Connection configuration page open to the **Custom Database** tab so you can replace the existing token with the new one in both scripts. Option name is `migration_ws`. Migration token option name is `migration_token`. -To hook to this action, include the following code: +* **Migration IPs Whitelist:** Only requests from listed IPs will be allowed access to the migration webservice. Option name is `migration_ips_filter`. -```js -// php -add_action( 'auth0_user_login', 'auth0UserLoginAction', 0,5 ); +* **Valid Proxy IP:** List the IP address of your proxy or load balancer to enable IP checks for logins and migration web services. Option name is `valid_proxy_ip`. -function auth0UserLoginAction($user_id, $user_profile, $is_new, $id_token, $access_token) { - ... -} -``` +* **Auth0 Server Domain:** The Auth0 domain, it is used by the setup wizard to fetch your account information. Option name is `auth0_server_domain`. + +## Keep Reading + +More information on the Login by Auth0 WordPress plugin: -[Click here to learn more about the `add_action` function.](https://developer.wordpress.org/reference/functions/add_action/) +::: next-steps +* [How does it work?](/cms/wordpress/how-does-it-work) +* [Install the plugin](/cms/wordpress/installation) +* [Troubleshooting](/cms/wordpress/troubleshoot) +* [Extend the plugin](/cms/wordpress/extending) +::: diff --git a/articles/cms/wordpress/extending.md b/articles/cms/wordpress/extending.md new file mode 100644 index 0000000000..a2dc98c9f6 --- /dev/null +++ b/articles/cms/wordpress/extending.md @@ -0,0 +1,629 @@ +--- +title: Extending the Login by Auth0 WordPress Plugin +description: Learn how to extend the Login by Auth0 WordPress Plugin with hooks, filters, and functions. +toc: true +topics: + - wordpress + - cms +contentType: + - how-to +useCase: + - add-login + - build-an-app + - customize-connections +--- +# Extending Login by Auth0 + +WordPress plugins can be extended to fit your specific requirements by using actions and filters to run custom code at specific points during runtime. This document outlines the existing hooks in the Login by Auth0 plugin. We're happy to review and approve new filters and actions that help you integrate even further in this plugin. Please see the Contributing section on the [GitHub repo readme for this plugin](https://github.com/auth0/wp-auth0/blob/master/README.md). + +## Actions + +Actions in WordPress run custom code at specific points during processing. [Learn more about actions here](https://developer.wordpress.org/plugins/hooks/actions/). These examples are maintained [here](https://github.com/joshcanhelp/auth0-wp-test/blob/master/inc/hooks-core-actions.php). + +### auth0_before_login + +This action runs in `WP_Auth0_LoginManager` after a user has been authenticated successfully but before they have been logged into WordPress. It can be used to stop the login process if needed using `wp_die()` or throwing an exception. + +```php +/** + * Stop login process before logging in and output the current $user object. + * NOTE: The example below will break the user login process. + * + * @see WP_Auth0_LoginManager::do_login() + * + * @param WP_User $user - WordPress user object. + */ +function auth0_docs_hook_auth0_before_login( $user ) { + echo 'WP user:
      ' . print_r( $user, true ) . '
      '; + wp_die( 'Login process started!' ); +} +add_action( 'auth0_before_login', 'auth0_docs_hook_auth0_before_login', 10, 1 ); +``` + +### auth0_user_login + +This action runs in `WP_Auth0_LoginManager` after a user has been authenticated successfully and logged into WordPress. It can be used to set specific meta values, send notifications, or ping other services. + +```php +/** + * Stop the login process after WP login. + * NOTE: The example below will break the user login process. + * + * @see WP_Auth0_LoginManager::do_login() + * + * @param integer $user_id - WordPress user ID for logged-in user + * @param stdClass $userinfo - user information object from Auth0 + * @param boolean $is_new - true if the user was created in WordPress, false if not + * @param string $id_token - ID Token for the user from Auth0 + * @param string $access_token - Bearer Access Token from Auth0 (not used in implicit flow) + * @param string $refresh_token - Refresh Token from Auth0 (not used in implicit flow) + */ +function auth0_docs_hook_auth0_user_login( $user_id, $userinfo, $is_new, $id_token, $access_token, $refresh_token ) { + echo 'WP user ID:
      ' . $user_id . '
      '; + echo 'Auth0 user info:
      ' . print_r( $userinfo, true ) . '
      '; + echo 'Added to WP DB?:
      ' . ( $is_new ? 'yep' : 'nope' ) . '
      '; + echo 'ID Token:
      ' . ( $id_token ? $id_token : 'not provided' ) . '
      '; + echo 'Access Token:
      ' . ( $access_token ? $access_token : 'not provided' ) . '
      '; + echo 'Refresh Token:
      ' . ( $refresh_token ? $refresh_token : 'not provided' ) . '
      '; + wp_die( 'Login successful! Home' ); +} +add_action( 'auth0_user_login', 'auth0_docs_hook_auth0_user_login', 10, 6 ); +``` + +### wpa0_user_created + +This action runs in `WP_Auth0_Users` just after a WordPress user is successfully created. It can be used to change user values, set additional user metas, or trigger other new user actions. + +```php +/** + * Stop the login process after a new user has been created. + * NOTE: The example below will break the user login process. + * + * @see WP_Auth0_Users::create_user() + * + * @param integer $user_id - WordPress user ID for created user + * @param string $email - email address for created user + * @param string $password - password used for created user + * @param string $f_name - first name for created user + * @param string $l_name - last name for created user + */ +function auth0_docs_hook_wpa0_user_created( $user_id, $email, $password, $f_name, $l_name ) { + echo 'User ID:
      ' . $user_id . '
      '; + echo 'Email:
      ' . $email . '
      '; + echo 'Password:
      ' . $password . '
      '; + echo 'First name:
      ' . $f_name . '
      '; + echo 'Last name:
      ' . $l_name . '
      '; + wp_die( 'User created!' ); +} +add_action( 'wpa0_user_created', 'auth0_docs_hook_wpa0_user_created', 10, 5 ); +``` + +## Filters + +Filters in WordPress also run custom code at specific points during processing but always return a modified value of the same type that was passed in. [Learn more about filters here](https://developer.wordpress.org/plugins/hooks/filters/). These examples are maintained [here](https://github.com/joshcanhelp/auth0-wp-test/blob/master/inc/hooks-core-filters.php). + +### auth0_get_wp_user + +This filter is called after the plugin finds the related user to login (based on the auth0 `user_id`) and is used to override the default behavior with custom matching rules (for example, always match by email). + +If the filter returns null, it will lookup by email as described in the [How does it work?](/cms/wordpress/how-does-it-work) document. + +```php +/** + * Filter the WordPress user found during login. + * + * @see WP_Auth0_LoginManager::login_user() + * + * @param WP_User|null $user - found WordPress user, null if no user was found. + * @param stdClass $userinfo - user information from Auth0. + * + * @return WP_User|null + */ +function auth0_docs_hook_auth0_get_wp_user( ?WP_User $user, stdClass $userinfo ) { + $found_user = get_user_by( 'email', $userinfo->email ); + $user = $found_user instanceof WP_User ? $user : null; + return $user; +} +add_filter( 'auth0_get_wp_user', 'auth0_docs_hook_auth0_get_wp_user', 1, 2 ); +``` + +### auth0_verify_email_page + +This filter runs in `WP_Auth0_Email_Verification` to change the HTML rendered when a user who is logging in needs to verify their email before gaining access to the site. Note that this HTML is passed to `wp_die()` where it is modified before being displayed (see the `_default_wp_die_handler()` definition in core for more information). + +```php +/** + * Filter the HTML used on the email verification wp_die page. + * + * @see WP_Auth0_Email_Verification::render_die() + * + * @param string $html - HTML to modify, echoed out within wp_die(). + * @param stdClass $userinfo - user info object from Auth0. + * + * @return string + */ +function auth0_docs_hook_auth0_verify_email_page( string $html, stdClass $userinfo ) { + $html = 'Hi ' . $userinfo->email . '!
      ' . $html; + $html = str_replace( 'email', 'banana', $html ); + return $html; +} +add_filter( 'auth0_verify_email_page', 'auth0_docs_hook_auth0_verify_email_page', 10 ); +``` + +### auth0_get_auto_login_connection + +This filter is used in `WP_Auth0_LoginManager` to modify what connection is used for the auto-login process. The setting in wp-admin is pulled and then passed through this filter. + +```php +/** + * Filter the auto-login connection used by looking for a URL parameter. + * + * @param string $connection - name of the connection, initially pulled from Auth0 plugin settings. + * + * @return string mixed + */ +function auth0_docs_hook_auth0_get_auto_login_connection( ?string $connection ) { + return ! empty( $_GET['connection'] ) ? rawurlencode( $_GET['connection'] ) : $connection; +} +add_filter( 'auth0_get_auto_login_connection', 'auth0_docs_hook_auth0_get_auto_login_connection' ); +``` + +### wp_auth0_get_option + +This filter is used by option-getting functions and methods to modify the output value. + +```php +/** + * Adjust an options value before use. + * + * @param mixed $value - value of the option, initially pulled from the database. + * @param string $key - key of the settings array. + * + * @return mixed + */ +function auth0_docs_hook_wp_auth0_get_option( $value, string $key ) { + $value = 'bad_key' === $key ? 'That is a bad key and you know it' : $value; + return $value; +} +add_filter( 'wp_auth0_get_option', 'auth0_docs_hook_wp_auth0_get_option', 10, 2 ); +``` + +### auth0_migration_ws_authenticated + +This filter is used in `WP_Auth0_Routes` to alter the WP_User object that is JSON-encoded and returned to Auth0 during a user migration. + +```php +/** + * Filter the WP user object before sending back to Auth0 during migration. + * + * @param WP_User $user - WordPress user object found during migration and authenticated. + * + * @return WP_User + */ +function auth0_docs_hook_auth0_migration_ws_authenticated( WP_User $user ) { + $user->data->display_name = 'Sir ' . $user->data->display_name . ', Esquire'; + return $user; +} +add_filter( 'auth0_migration_ws_authenticated', 'auth0_docs_hook_auth0_migration_ws_authenticated' ); +``` + +### wpa0_should_create_user + +This filter is used in `WP_Auth0_Users` when deciding whether a user should be created. The initial value passed in is `TRUE`. If `FALSE` is returned for any reason, registration will be rejected and the registering user will see an error message (see `WP_Auth0_UsersRepo::create()`). + +```php +/** + * Should a new user be created? + * + * @param bool $should_create - should the user be created, initialized as TRUE + * @param stdClass $userinfo - Auth0 user information + * + * @return bool + */ +function auth0_docs_hook_wpa0_should_create_user( bool $should_create, stdClass $userinfo ) { + $should_create = ( false === strpos( 'josh', $userinfo->email ) ); + return $should_create; +} +add_filter( 'wpa0_should_create_user', 'auth0_docs_hook_wpa0_should_create_user' ); +``` + +### auth0_login_css + +This filter is used to modify the CSS on the login page, including the login widget itself. This filter runs before CSS is retrieved from the wp-admin settings page. + +```php +/** + * Add CSS to the Auth0 login form. + * + * @param string $css - initialized as empty. + * + * @return string + */ +function auth0_docs_hook_auth0_login_css( ?string $css ) { + $css .= ' + body {background: radial-gradient(#01B48F, #16214D)} + #login h1 {display: none} + .login form.auth0-lock-widget {box-shadow: none} + '; + return $css; +} +add_filter( 'auth0_login_css', 'auth0_docs_hook_auth0_login_css' ); +``` + +### auth0_login_form_tpl + +Filters the template used for the Auth0 login form. This should return a path to a file containing HTML that replaces what is in `wp-content/plugins/auth0/templates/auth0-login-form.php`. The standard Lock initiation JS looks for an ID attribute of `auth0-login-form` to instantiate the login form so make sure that's present or replace the `wp-content/plugins/auth0/assets/js/lock-init.js` file with your own. + +```php +/** + * Override the Lock login form template. + * + * @param string $tpl_path - original template path. + * @param array $lock_options - Lock options. + * @param boolean $show_legacy_login - Should the template include a link to the standard WP login? + * + * @return string + */ +function auth0_docs_hook_auth0_login_form_tpl( string $tpl_path, array $lock_options, bool $show_legacy_login ) { + return get_stylesheet_directory_uri() . '/templates/auth0-login-form.html'; +} +add_filter( 'auth0_login_form_tpl', 'auth0_docs_hook_auth0_login_form_tpl', 10, 3 ); +``` + +### auth0_settings_fields + +This filter is used to modify an existing form field or to add a new one. This should return a modified `$options` array with your changes or additions. New fields must have a field callback, as shown below. + +```php +/** + * Modify existing or add new settings fields. + * + * @param array $options - array of options for a specific settings tab. + * @param string $id - settings tab id. + * + * @return array + * + * @see WP_Auth0_Admin_Generic::init_option_section() + */ +function auth0_docs_hook_auth0_settings_fields( array $options, string $id ) { + switch ( $id ) { + case 'basic': + $options[] = array( + 'name' => __( 'A Custom Basic Setting' ), + 'opt' => 'custom_basic_opt_name', + 'id' => 'wpa0_custom_basic_opt_name', + 'function' => 'auth0_docs_render_custom_basic_opt_name', + ); + break; + case 'features': + break; + case 'appearance': + break; + case 'advanced': + break; + } + return $options; +} +add_filter( 'auth0_settings_fields', 'auth0_docs_hook_auth0_settings_fields', 10, 2 ); + +/** + * Callback for add_settings_field + * + * @param array $args - 'label_for' = id attr, 'opt_name' = option name + * + * @see auth0_docs_hook_auth0_settings_fields() + */ +function auth0_docs_render_custom_basic_opt_name( array $args ) { + $options = WP_Auth0_Options::Instance(); + printf( + '', + esc_attr( $options->get_options_name() ), + esc_attr( $args['opt_name'] ), + esc_attr( $args['label_for'] ), + esc_attr( $options->get( $args['opt_name'] ) ) + ); +} +``` + +### auth0_auth_scope + +This filter allows developers to add or change the scope requested during login. This can be used to add [custom claims](/api-auth/tutorials/adoption/scope-custom-claims#custom-claims) or request a Refresh Token. + +```php +/** + * Add or modify requested Access Token scopes during login. + * + * @param array $scopes - current array of scopes to add/delete/modify + * + * @return array + */ +function auth0_docs_hook_auth0_auth_scope( array $scopes ) { + // Add offline_access to include a Refresh Token. + // See auth0_docs_hook_auth0_user_login() for how this token can be used. + $scopes[] = 'offline_access'; + return $scopes; +} +add_filter( 'auth0_auth_scope', 'auth0_docs_hook_auth0_auth_scope' ); +``` + +### auth0_nonce_cookie_name + +Use this filter to modify the cookie name used for nonce validation. See the `auth0_state_cookie_name` filter below for an example. + +### auth0_state_cookie_name + +Use this filter to modify the cookie name used for the [state](/protocols/oauth2/oauth-state) parameter value. This can add a prefix or suffix or replace the string entirely. Make sure to use valid characters in any modifications made: + +> A `` can be any US-ASCII characters except control characters (CTLs), spaces, or tabs. It also must not contain a separator character like the following: ( ) < > @ , ; : \ " / [ ] ? = { }. + +Read more about the `Set-Cookie` HTTP response header at the [MDN's Set-Cookie documentation](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie). + +```php +/** + * Prefix state and nonce cookie names. + * + * @param string $cookie_name - Cookie name to modify. + * + * @return string + */ +function auth0_docs_hook_prefix_cookie_name( string $cookie_name ) { + return 'prefix_' . $cookie_name; +} +add_filter( 'auth0_state_cookie_name', 'auth0_docs_hook_prefix_cookie_name' ); +add_filter( 'auth0_nonce_cookie_name', 'auth0_docs_hook_prefix_cookie_name' ); +``` + +### auth0_settings_constant_prefix + +Use this filter to change the prefix for the constant used to override plugin settings. Please note that this filter **must** run before the Auth0 plugin is loaded so it needs to be located in an [MU plugin](https://codex.wordpress.org/Must_Use_Plugins). + +```php +/** + * Prefix used for constant-based options. + * + * @param string $prefix - Constant prefix to modify or replace. + * + * @return string + */ +function auth0_docs_hook_settings_constant_prefix( string $prefix ) { + // Replace the prefix with something else. + // return 'AUTH_ENV_'; + + // Prefix the prefix. + return 'PREFIX_' . $prefix; +} +add_filter( 'auth0_settings_constant_prefix', 'auth0_docs_hook_settings_constant_prefix' ); +``` + +### auth0_authorize_url_params + +This filter allows developers to adjust the `/authorize` endpoint parameters as needed. The function must return a dictionary-type array of URL parameters. See the [Login section of the Authentication API docs](/api/authentication#login) for more information on how these parameters are used. + +```php +/** + * Adjust the authorize URL parameters used for auto-login and universal login page. + * + * @param array $params - Existing URL parameters. + * @param string $connection - Connection for auto-login, optional. + * @param string $redirect_to - URL to redirect to after logging in. + * + * @return array + */ +function auth0_docs_hook_authorize_url_params( array $params, ?string $connection, string $redirect_to ) { + if ( 'twitter' === $connection ) { + $params[ 'param1' ] = 'value1'; + } + + if ( FALSE !== strpos( 'twitter', $redirect_to ) ) { + $params[ 'param2' ] = 'value2'; + } + + return $params; +} +add_filter( 'auth0_authorize_url_params', 'auth0_docs_hook_authorize_url_params', 10, 3 ); +``` + +### auth0_authorize_url + +This filter allows developers to adjust the complete `/authorize` URL before use. The function must return a valid URL as a string. See the [Login section of the Authentication API docs](/api/authentication#login) for more information on how this URL is used. + +```php +/** + * Adjust the authorize URL before redirecting. + * + * @param string $auth_url - Built authorize URL. + * @param array $auth_params - Existing URL parameters. + * + * @return mixed + */ +function auth0_docs_hook_authorize_url( string $auth_url, array $auth_params ) { + + if ( 'twitter' === $auth_params['connection'] ) { + $auth_url .= '¶m1=value1'; + } + + if ( ! empty( $auth_params['display'] ) ) { + $auth_url .= '¶m2=value2'; + } + + $auth_url .= '¶m3=value3'; + return $auth_url; +} +add_filter( 'auth0_authorize_url', 'auth0_docs_hook_authorize_url', 10, 2 ); +``` + +### auth0_die_on_login_output + +This filter lets you modify or replace the HTML content passed to `wp_die()` when there is an error during login. This filter does not affect the verify email content (see [auth0_verify_email_page](#auth0_verify_email_page)). + +```php +/** + * Filter the output of the wp_die() screen when the login callback fails. + * + * @see \WP_Auth0_LoginManager::die_on_login() + * + * @param string $html - Original HTML; modify and return or return something different. + * @param string $msg - Error message. + * @param string|integer $code - Error code. + * @param boolean $login_link - True to link to login, false to link to logout. + * + * @return string + */ +function auth0_docs_hook_die_on_login_output( string $html, string $msg, $code, string $login_link ) { + return sprintf( + 'Original: %s + Message: %s
      Code: %s
      Link: %s
      ', + esc_html( $html ), + sanitize_text_field( $msg ), + sanitize_text_field( $code ), + $login_link ? 'TRUE' : 'FALSE' + ); +} +add_filter( 'auth0_die_on_login_output', 'auth0_docs_hook_die_on_login_output', 10, 4 ); +``` + +### auth0_coo_auth0js_url + +This filter lets you override the default CDN URL for Auth0.js when loading the COO fallback page. + +### auth0_slo_return_to + +This filter lets you override the default `returnTo` URL when logging out of Auth0. + +```php +/** + * URL to return to after logging out of Auth0. + * + * @param string $default_return_url - Return URL, default is home_url(). + * + * @return string + */ +function auth0_wp_test_hook_auth0_slo_return_to( string $default_return_url ) { + $default_return_url = add_query_arg( 'cache-break', uniqid(), $default_return_url ); + return $default_return_url; +} +add_filter( 'auth0_slo_return_to', 'auth0_docs_hook_auth0_slo_return_to', 10 ); +``` + +### auth0_logout_url + +This filter lets you override the Auth0 logout URL. See the [Auth0 Logout page](/logout) for more information on how this is used. + +```php +/** + * URL used to logout of Auth0. + * + * @param string $default_logout_url - Logout URL. + * + * @return string + */ +function auth0_docs_hook_auth0_logout_url( string $default_logout_url ) { + $default_logout_url = add_query_arg( 'federated', 1, $default_logout_url ); + return $default_logout_url; +} +add_filter( 'auth0_logout_url', 'auth0_docs_hook_auth0_logout_url' ); +``` + +### auth0_use_management_api_for_userinfo + +This filter determines whether or not user profile data retrieved from the Management API should when you're *not* using the Implicit Login Flow. Return a boolean `true` (default) to use the API, `false` to use the ID token. + +```php +// Always use the ID token for user profile data. +add_filter( 'auth0_use_management_api_for_userinfo', '__return_false', 100 ); +``` + +### auth0_lock_options + +This filter can be used to modify the options for the embedded Lock login form used in shortcodes, widgets, and on the wp-login.php page when **Features > Universal Login Page** is turned off. + +```php +/** + * Filter the options passed to Lock. + * + * @param array $options - Existing options built from plugin and additional settings. + * + * @return array + */ +function auth0_docs_hook_lock_options( array $options ) { + if ( ! empty( $_GET[ 'lock_language' ] ) ) { + $options['language'] = sanitize_title( $_GET[ 'lock_language' ] ); + } + return $options; +} +add_filter( 'auth0_lock_options', 'auth0_docs_hook_lock_options', 10 ); +``` + +### auth0_jwt_leeway + +This filter lets you adjust the leeway time used to validate ID tokens and should return a number of seconds as an integer. + +```php +/** + * Filter the JWT leeway. + * + * @param integer $leeway - Existing JWT leeway time in seconds; default is 60. + * + * @return integer + */ +function auth0_docs_hook_jwt_leeway( ?int $leeway ) { + return 120; +} +add_filter( 'auth0_jwt_leeway', 'auth0_docs_hook_jwt_leeway' ); +``` + +### auth0_jwt_max_age + +This filter lets you adjust the `max_age` URL parameter sent on the authorize URL. + +```php +/** + * Filter the max_age login parameter. + * + * @param integer $max_age - Existing max_age time, defaults to empty. + * + * @return integer + */ +function auth0_docs_hook_jwt_max_age( ?int $max_age ) { + return 1200; +} +add_filter( 'auth0_jwt_max_age', 'auth0_docs_hook_jwt_max_age' ); +``` + +### auth0_authorize_state + +This filter lets you filter the state data before being encoded and used for login. This data will be verified after a successful login and provided as-is for use. + +```php +/** + * Add, modify, or remove state values on login redirect. + * + * @param array $state Current state array. + * @param array $auth_params Authorization URL parameters. + * + * @return array + */ +function auth0_docs_hook_authorize_state( array $state, array $auth_params ) { + $redirect_to = parse_url( $state['redirect_to'] ?? '' ); + if ( '/checkout' === ( $redirect_to['path'] ?? '' ) ) { + $state['cart_id'] = namspace_get_cart_id(); + } + return $state; +} +add_filter( 'auth0_authorize_state', 'auth0_docs_hook_authorize_state', 10, 2 ); +``` + +## Additional Extensions + +Additional examples can be found [here](https://github.com/joshcanhelp/auth0-wp-test/blob/master/inc/hooks-other.php). + +## Keep Reading + +More information on the Login by Auth0 WordPress plugin: + +::: next-steps +* [How does it work?](/cms/wordpress/how-does-it-work) +* [Install the plugin](/cms/wordpress/installation) +* [Configure the plugin](/cms/wordpress/configuration) +* [Troubleshooting](/cms/wordpress/troubleshoot) +::: diff --git a/articles/cms/wordpress/how-does-it-work.md b/articles/cms/wordpress/how-does-it-work.md index 030de2bfa3..9b47083e4b 100644 --- a/articles/cms/wordpress/how-does-it-work.md +++ b/articles/cms/wordpress/how-does-it-work.md @@ -1,57 +1,68 @@ --- description: This page explains the scenarios of how Auth0 integrates with WordPress. +topics: + - wordpress + - cms +contentType: concept +useCase: + - add-login + - build-an-app + - customize-connections + - secure-an-api + - manage-users --- - # How Auth0 Integrates with WordPress -There are several business flows that can occur when integrating Auth0 with your WordPress site. - -![](/media/articles/cms/wordpress/plugin-auth-page.png) - -### Scenario 1: A user that doesn't exist in WordPress, but exists in Auth0, attempts to log in. - -1. The user access your WordPress site's login page. -2. The user provides their credentials. -3. Auth0 attempts to authenticate the user. -4. The Auth0-WordPress plugin receives the user's Auth0 profile. -5. The Auth0-WordPress plugin checks to see if there is a user in the WordPress database with credentials that match their Auth0 `user_id`. - - * If there **is** a user whose credentials match an Auth0 `user_id`, the Auth0-Wordpress plugin checks to see if there is a user with the same `email`. - * If there **is not** a user whose credentials match an Auth0 `user_id`, the Auth0-Wordpress plugin creates a new user profile and logs the user in. - - -### Scenario 2: A user that exists in WordPress **and** in Auth0 attempts to log in. - -In this scenario, the user has existed in your WordPress database and Auth0 *prior* to you installing the Auth0-Wordpress plugin. - -1. The user access your WordPress site's login page. -2. The user provides their credentials. -3. Auth0 attempts to authenticate the user. -4. The Auth0-WordPress plugin receives the user's Auth0 profile. -5. The Auth0-WordPress plugin checks to see if there is a user in the WordPress database with credentials that match their Auth0 `user_id`. -6. Because the Auth0-WordPress plugin can't find a user whose WordPress database credentials match any of the Auth0 `user_id` fields, it will check if there is a user with the same `email`. -7. The Auth0-Wordpress plugin identifies a user with the provided `email`. -8. The Auth0-Wordpress plugin checks to see if the Auth0 user has verified their email. - - * If the user has **verified** their email, the Auth0-WordPress plugin will update the WordPress user's `user_id` and log the user in. - * If the user has **not** verified their email, the Auth0-WordPress plugin will end the authentication process, indicating that the user needs to verify their email prior to proceeding. - -### Scenario 3: A newly-created Wordpress user that exists in Auth0 attempts to log in. - -1. The user access your WordPress site's login page. -2. The user provides their credentials. -3. Auth0 attempts to authenticate the user. -4. The Auth0-WordPress plugin receives the user's Auth0 profile. -5. The Auth0-WordPress plugin checks to see if there is a user in the WordPress database with credentials that match their Auth0 `user_id`. -6. The Auth0-Wordpress plugin finds the user in the WordPress database using their Auth0 user_id, so it logs the user in. - -### Scenario: Data Migration - -If you enable [data migration](/connections/database/migrating), the Auth0-WordPress plugin will expose two secure endpoints that allow Auth0 authenticate the users. These endpoints are secured with a secret token and only available to IP addresses associated with Auth0. You can change this in the Auth0 Dashboard's Client [Advanced Settings](${manage_url}/#/clients) page. - -The login flow is as follows: - -1. The user access your WordPress site's login page and provides their credentials. -2. Auth0 can't find a user associated with the provided credentials, so it proceeds to call the migration endpoint. -3. The Auth0-WordPress plugin find a user in your WordPress database with the provided username/email, so it verifies the password. -4. Auth0 creates the user in your Auth0 account, authenticates the user, and logs them in. +The Login by Auth0 plugin handles login and account creation flows automatically by creating or matching user accounts with incoming Auth0 profile data. The login process and the signup process are similar and an account will be created or matched based on the data in your WordPress database rather than the initial action taken. In other words, logging in via Auth0 can create a WordPress account and signing up via Auth0 can match an existing WordPress account. + + ::: note + If you are using the User Migration setting in the plugin, the login flow will be slightly different than what is explained below. Please see our documentation on [User Migration in WordPress](/cms/wordpress/user-migration). + ::: + +The process runs as follows: + +1. The user accesses the WordPress site's login page. This could be the main login page at `[SITE URL]/wp-login.php` or a page containing a widget or shortcode. +2. The user provides their username and password, clicks on a social icon to use another identity provider, or completes the Passwordless process in the Auth0 login form, Lock. +3. Auth0 attempts to authenticate the user with the method selected. + - If login or signup with a username + password or with Passwordless fails, an error message will appear on Lock. + - If it is successful, the process continues below. +4. The user is redirected to the `/authorize` endpoint with a login ticket and a `state` value generated by the plugin. Once this is complete, the Auth0 user record has been created and the rest of the process happens on the WordPress site. +5. The actual login process differs whether you are using the Authorization Code Flow or the Implicit Flow ("Implicit Login Flow" on the Advanced tab of the plugin settings is turned off [default] for the former, on for the latter): + - For [Authorization Code Flow](/flows/guides/auth-code/add-login-auth-code) logins: + 1. The user is redirected back to a callback URL, `SITE URL/index.php?auth0=1` with an authorization code and the same `state` value in URL parameters. + 2. The `state` value is validated. If validation does not pass, an "Invalid state" error is shown and the login process stops ([see the Troubleshooting page](/cms/wordpress/troubleshoot) for more information on state validation). + 3. The ID token is validated to make sure nothing was modified during transit. If the ID token is invalid, an error message is shown and the login process stops ([see the Troubleshooting page](/cms/wordpress/troubleshoot) for more information on ID token validation) + 4. The user profile data is retrieved via the Management API using the [Machine-to-Machine Flow](/flows/concepts/client-credentials). + - For [Implicit Flow](/flows/guides/implicit/add-login-implicit) logins: + 1. The user is redirected back to a callback URL, `SITE URL/wp-login.php?auth0=implicit` with an ID token and the same `state` value in an anchor link. + 2. This anchor link is [parsed in JS](https://github.com/auth0/wp-auth0/blob/master/assets/js/implicit-login.js) and then POSTed back to a callback URL `SITE URL/index.php?auth0=implicit` with those 2 same values in URL parameters. + 3. The ID token is validated to make sure nothing was modified during transit. If the ID token is invalid, an error message is shown and the login process stops ([see the Troubleshooting page](/cms/wordpress/troubleshoot) for more information on ID token validation) + 4. The information in the valid ID token is used as the user profile data. +6. At this point, the Auth0 authentication process is complete and the plugin attempts to match the profile data with a user in WordPress. +7. The plugin checks whether the site requires an email address (plugin settings **Advanced** tab) and if the incoming profile has an `email_verified` flag set. + - If the site requires an email address and the incoming user does not provide an email address (some social identity providers, like Twitter, do not include an email address), the login process stops with an error message stating "This account does not have an email associated." + - If the site requires an email address and the incoming user does not have the `email_verified` flag set to `true`, the login process stops with an error message stating "This site requires a verified email address" and a link to re-send the verification email. This will continue to show until the user successfully verifies their email address. + - If the site does not require an email address or the incoming user has the `email_verified` flag set to `true`, then the login process continues. +8. The plugin checks to see if there is a user in the WordPress database with a `usermeta` value that matches the incoming Auth0 user ID (meaning that the user has signed up or logged in with Auth0 before): + - If a user is found that has the incoming user ID then the login process continues. + - If a user was not found with the incoming Auth0 user ID, the plugin will look for an email address matching the incoming user: + - If a match is found, that user is selected and the login process continues. + - If a match is not found, the plugin check if registration is turned on for the WordPress site: + - If registration is turned off, the login process stops with an error message stating `Could not create user. The registration process is not available.` + - If registration is turned on, a new user is created and the login process continues. +9. The found or created user is updated with the incoming Auth0 profile data, including their Auth0 user ID. +10. The user is logged into their WordPress account with `wp_set_auth_cookie` and the core `do_login` action fires. +11. Finally, the user is redirected to a page on the site (this could be the default one set in the plugin settings **Advanced** tab or the original login URL if a shortcode or widget was used or a different one provided during the login process). + +The user is now logged into Auth0 and their WordPress account with the two associated by their Auth0 user ID. + +## Keep Reading + +More information on the Login by Auth0 WordPress plugin: + +::: next-steps +* [Install the plugin](/cms/wordpress/installation) +* [Configure the plugin](/cms/wordpress/configuration) +* [Troubleshooting](/cms/wordpress/troubleshoot) +* [Extend the plugin](/cms/wordpress/extending) +::: diff --git a/articles/cms/wordpress/index.md b/articles/cms/wordpress/index.md index cc362768f3..bbdf88e486 100644 --- a/articles/cms/wordpress/index.md +++ b/articles/cms/wordpress/index.md @@ -1,27 +1,45 @@ --- +description: This page explains the basics of the Login by Auth0 WordPress plugin. url: /cms/wordpress -description: This page explains the basics of the WordPress plugin. +topics: + - wordpress + - cms +contentType: + - index + - concept +useCase: + - add-login + - build-an-app + - customize-connections + - secure-an-api + - manage-users --- +# Login by Auth0 WordPress Plugin -# Auth0 WordPress plugin +![WordPress-Auth0 Plugin Banner](/media/articles/cms/wordpress/wordpress-plugin-banner.png) -Auth0 provides a WordPress Plugin to integrate your sites with your Auth0 account. These plugin enable Single Sign On for Enterprises, social login, user/password and passwordless login through all your instances. +Auth0 provides a WordPress Plugin to integrate your sites with your Auth0 account. This plugin enables Single Sign-on (SSO) for Enterprises, social login, user/password, and passwordless login through all your instances. -Login features are implemented through a new Login Widget (powered by Auth0) that enables: +Login features are implemented through a new form (powered by Auth0) that enables: -- Single Sign On with Enterprise Directories (LDAP, AD, Google Apps, Office365 and SAML Provider) -- Shared User/Password between multiple WordPress accounts for Single Sign On -- Single Sign On with over 30 [Social Providers](/identityproviders) +- SSO with Enterprise Directories (LDAP, AD, G Suite, Office365, and SAML Provider) +- SSO with over 30 [Social Providers](/identityproviders) +- SSO between WordPress installs and other applications - User Management Dashboard -- Optional Two Factor Authentication -- Single Sign On between WordPress and other applications +- Optional Multi-factor Authentication +- Optional Passwordless Authentication - Reporting and Analytics + -## WordPress Plugin +## Keep Reading -- [How does it work?](/cms/wordpress/how-does-it-work) -- [Installation](/cms/wordpress/installation) -- [Configuration](/cms/wordpress/configuration) -- [JWT Authentication](/cms/wordpress/jwt-authentication) -- [Troubleshoot](/cms/wordpress/troubleshoot) +More information on the Login by Auth0 WordPress plugin: + +::: next-steps +* [Download on WordPress.org](https://wordpress.org/plugins/auth0/) +* [How does it work?](/cms/wordpress/how-does-it-work) +* [Install the plugin](/cms/wordpress/installation) +* [Configure the plugin](/cms/wordpress/configuration) +* [Troubleshooting](/cms/wordpress/troubleshoot) +::: diff --git a/articles/cms/wordpress/installation.md b/articles/cms/wordpress/installation.md index 5e74edf75e..09e513a4d0 100644 --- a/articles/cms/wordpress/installation.md +++ b/articles/cms/wordpress/installation.md @@ -1,66 +1,139 @@ --- description: Explains how to install the Auth0 WordPress plugin. +topics: + - wordpress + - cms +contentType: how-to +useCase: + - add-login + - build-an-app + - customize-connections + - secure-an-api + - manage-users --- +# Installing Login by Auth0 -# WordPress Installation +::: note +In order to install or customize plugins, you must use a self-hosted WordPress.org site. Using a WordPress.com site does not allow installing plugins. [More information on the differences here](https://en.support.wordpress.com/com-vs-org/). +::: -![WordPress-Auth0 Plugin Banner](/media/articles/cms/wordpress/wordpress-plugin-banner.png) +This plugin can be added to your WordPress site using the **Plugins** screen in the wp-admin: -There are two ways to install the Auth0-Wordpress plugin: +1. Log into an existing WordPress site as an administrator. +2. Go to **Plugins > Add New** in the admin menu on the left. +3. Search for "Login by Auth0" +4. For the Login by Auth0 plugin, click **Install Now**, then **Activate**. -- Installing via the [WordPress Store](#installing-via-the-wordpress-store) -- Uploading the [`wp-auth0` folder](#manually-uploading-the-plugin-file) to the `/wp-content/plugins` directory +This process and other methods are covered [in the WordPress documentation](https://wordpress.org/support/article/managing-plugins/#installing-plugins). -## Installing via the WordPress Store +As soon as the plugin is activated, you are redirected to the start of the Setup Wizard. -While logged in as an administrator of your WordPress installation, go to the **Plugins** menu item. +If you don't already have an Auth0 account, click the **[Sign Up For Free](https://auth0.com/signup).** button and create one before proceeding. -![WordPress Dashboard](/media/articles/cms/wordpress/plugins.png) +::: note +Auth0 will not replace your login forms until a **Domain**, **Client ID**, and **Client Secret** have been added to the Basic tab of the settings page. +::: -Click **Add New**. +## Multisite setup -![Where to Add New Plugins in WordPress](/media/articles/cms/wordpress/add-new.png) +The Login by Auth0 plugin is compatible with WordPress multisite networks. The plugin can be network activated to automatically protect network sites (once configuration is complete) or activated only on a sub-set of the network. -Search for the Auth0 plugin, and click **Install Now**. +There are a few ways that a network of sites can be setup in Auth0: -![Installing New WordPress Plugins](/media/articles/cms/wordpress/search-and-install.png) +1. **All sites can share both an Application and a database connection** + 1. Run the Setup Wizard steps to completion for the main site. + 2. Setup all other sites manually using the **Domain**, **Client ID**, and **Client Secret** from the main site in the Basic tab of the Auth0 settings page. + 3. Update the Application's **Allowed Callback URLs**, **Allowed Web Origins**, and **Allowed Logout URLs** to include each site (wildcards can be used if your network uses subdomains). +1. **Each site can have its own Application and share a database connection** + 1. Run the Setup Wizard steps to completion for the main site. + 2. Next, create an Application for each of the sites [manually](/cms/wordpress/configuration) and add each one to the previously-created database connection. + 3. Add the **Domain**, **Client ID**, and **Client Secret** values to the Basic tab of the Auth0 settings page for each site. +1. **Each site can have its own Application and its own database connection.** In this case, Run the Setup Wizard steps to completion for each site. -Once the installation completes, click **Activate Plugin**. +Each of the options above has trade-offs. Option 1 has the least number of different entities to manage in Auth0 but, if your network has hundreds of sites and you're not using subdomains, you might run into limitations with the number of callback URLs. Option 2 will require managing many different Applications but will allow you to configure each site's Application differently. -![Activating Installed WordPress Plugins](/media/articles/cms/wordpress/activate.png) +As always, if you have any questions about this setup process, create a post on our [Community](https://community.auth0.com/tags/wordpress) tagged "wordpress." -At this point, your installation is complete, and you can now [configure the plugin](/cms/wordpress/configuration). +## Setup Wizard -![Installed Plugins List in the WordPress Dashboard](/media/articles/cms/wordpress/installed.png) +The Setup Wizard will attempt to create all the necessary components needed to use Auth0 on your WordPress site. If you have an existing Application or Database Connection you want to use, please see the [Manual Setup](#manual-setup) steps below. -## Manually Uploading the Plugin File +### Option 1: Standard Setup -Download the plugin zip file from the [WordPress Plugins site](https://wordpress.org/plugins/auth0/). +This will create and configure an Application and a Database Connection for this site. -While logged in as an administrator of your WordPress installation, go to the **Plugins** menu item. +First, [follow the instructions](/api/management/v2/get-access-tokens-for-test#get-access-tokens-manually) for generating a Management API token. Once the token is generated, make a note of the domain name used in the **Identifier** field under the **Settings** tab. For example, if your Identifier is `https://tenant-name.auth0.com/api/v2/`, then the tenant domain is `tenant-name.auth0.com`. [More about tenant Domains can be found here](/getting-started/the-basics#domains). -![Navigating to the Plugins Menu in WordPress](/media/articles/cms/wordpress/plugins.png) +Back in the WordPress admin's Setup Wizard, click **Standard**. In the modal that appears, click **Start Standard Setup**. -Click **Add New**. +![WordPress Installation standard setup fields](/media/articles/cms/wordpress/setup-wizard-standard.png) -![Where to Add New Plugins](/media/articles/cms/wordpress/add-new.png) +Enter the tenant domain and API token from above. This token is only used for the setup process and will not be saved in the database. -Click on **Upload Plugin**. +If the first part of the setup successfully completes, you'll see the "Configure your social connections" screen. Click **Next** to continue the setup process by migrating your administrator account. -![How to Manually Upload Plugins](/media/articles/cms/wordpress/upload-and-install.png) +![WordPress Setup Wizard migration admin user](/media/articles/cms/wordpress/setup-wizard-migrate-admin.png) -Select the zip file you just downloaded. +This step connects your WordPress user with an Auth0 user that authorizes you to log in. You can choose the same password as your admin account or different but make sure it conforms to the [password policy described here](/connections/database/password-strength#password-policies) for the database Connection being used. -![Selecting the Plugin File to Upload Manually](/media/articles/cms/wordpress/select-upload.png) +The Setup Wizard must run to completion for your site to be setup correctly. If the Wizard fails for any reason before the "setup successful" screen, check the plugin error log at **wp-admin > Auth0 > Error Log** and the steps below to determine the issue. -Click on **Install Now**. +To start the process over completely, delete any Applications or Database Connections that were created in the Auth0 Dashboard. In WordPress, to go **Auth0 > Settings > Basic**, delete the Domain, Client ID, and Client Secret fields, and click **Save**. Now, click **Setup Wizard** in the admin menu to start the process over again. -![Installing the Chosen File](/media/articles/cms/wordpress/install-now.png) +If you're still not able to install, [please post a thread in our Community](https://community.auth0.com/tags/wordpress) with the error messages you're seeing in the Error Log and we'll be happy to help! -Once the installation completes, click **Activate Plugin**. +### Option 2: User Migration Setup -![Activating an Installed Plugin](/media/articles/cms/wordpress/activate-upload.png) +This will create and configure an Application and a database connection plus data migration from your WordPress database. This requires an inbound connection from Auth0 servers and cannot be changed later without losing data. [More information on user migration is here](/cms/wordpress/user-migration). -At this point, your installation is complete, and you can now [configure the plugin](/cms/wordpress/configuration). +::: warning +If you have more than one custom database connection in Auth0, you'll need to make sure that the user IDs are namespaced to avoid conflicts. This is done automatically for sites installing version 3.11.0 or later. If your connections are/were being created with an earlier version, please see the [troubleshooting steps here](/cms/wordpress/user-migration#cannot-change-email-or-incorrect-user-data). +::: -![Viewing Installed Plugins in the WordPress Dashboard](/media/articles/cms/wordpress/installed.png) +![WordPress-Auth0 Plugin Banner](/media/articles/cms/wordpress/auth0-authorize-app.png) + +Once the setup process is complete, log out of your WordPress site and attempt to log back in using your existing WordPress credentials in the Auth0 login form. This should create an Auth0 user linked to your WordPress account. + +### Option 3: Manual Setup + +This will skip the automatic setup and allow you to create and configure your own Application and database connection ([see below](#manual-setup)). This should be used if you want this site to use an existing Application or database connection. + +### Option 4: Import Setup + +The site can also be set up by importing settings from another site. This is useful if you're migrating between environments or have a similar WordPress site that's already setup. + +## Setup complete + +When you see the "Done" screen, Auth0 is setup and ready to accept logins and, if configured, signups! + +This is a good time to confirm that the basics are working for your site before changing any of the default settings: + +1. Log out of WordPress and confirm that the Auth0 form now appears at `/wp-login.php`. +1. Log in with the Auth0 user created above. +1. Log out and try creating an account with a different email address (if you have "Anyone can register" turned on in your General WordPress settings). +1. Try logging in using a social connection (if you've turned those on). + +Now you're ready to [Configure](/cms/wordpress/configuration)! + +## Manual setup + +The plugin can be configured using the built-in setup wizard (covered below) or manually by creating an Application and +assigning connections. The completely manual setup process can be used if you're having trouble with the +wizard, have been through the setup process before, or want to share a database connection between Applications. + +1. In your Auth0 [Dashboard](${manage_url}), click **Applications** then **Create Application** +1. Give your Application a descriptive name, select **Regular Web Applications**, then **Create** +1. Follow the [Application setup instructions](/cms/wordpress/configuration) closely through the "Update Auth0 settings in WordPress" section to configure the application for your WordPress installation + +Once the steps above are complete, your site will be configured and ready to use! + +## Keep reading + +More information on the Login by Auth0 WordPress plugin: + +::: next-steps +* [How does it work?](/cms/wordpress/how-does-it-work) +* [Configure the plugin](/cms/wordpress/configuration) +* [Troubleshooting](/cms/wordpress/troubleshoot) +* [Extend the plugin](/cms/wordpress/extending) +::: diff --git a/articles/cms/wordpress/invalid-state.md b/articles/cms/wordpress/invalid-state.md new file mode 100644 index 0000000000..1a0f862a22 --- /dev/null +++ b/articles/cms/wordpress/invalid-state.md @@ -0,0 +1,128 @@ +--- +description: Troubleshooting invalid state errors in the Login by Auth0 WordPress plugin. +topics: + - wordpress + - cms + - state +contentType: reference +useCase: + - add-login + - build-an-app + - customize-connections + - secure-an-api + - manage-users +--- + +# Troubleshoot WordPress Plugin Invalid State Errors + +We added state validation to the WordPress plugin in [version 3.6.0](https://github.com/auth0/wp-auth0/releases/tag/3.6.0). This security measure helps mitigate CSRF attacks by ensuring that the response belongs to a request initiated by the same user For more information, see [State Parameter](/protocols/oauth2/oauth-state). + +## How state validation works + +The plugin performs state validation by: + +1. Setting an `auth0_state` cookie in the browser via Javascript when the Lock login form is shown (on `wp-login.php` or any other page when using a shortcode or widget). +2. Passing that value to the Lock embedded login form so it can be sent with the authentication request. +3. Receiving that value back from Auth0 unchanged in a `state` URL parameter if the Auth0 login was successful. +4. Validating the that value received matches the value sent and stored in the `auth0_state` cookie. If it's valid, then the login process continues. If not, the process stops and an "Invalid state" error message is shown. +5. Deleting the cookie, regardless of validity. +6. Using values in the base64 decoded object to redirect or perform other login actions, if valid. + +This process should be completely opaque to both the logging-in user and the site admin. The Auth0 server does not validate or require a state value and returns it untouched to the callback URL. If the "Invalid state" message is seen, then one of the first 4 steps above is not happening. + +## Common causes of the invalid state error + +Below are some common causes of the invalid state error as well troubleshooting steps you can take. + +### Cached callback URLs + +The most common cause of the invalid state error is when the callback URL is cached on the server. + +Exclude caching on your server for all the URLs listed in the **Allowed Callback URLs** field for your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) in the Auth0 Dashboard and test again. In addition, exclude caching the site URL (`/index.php` on a regular install) if it has an Auth0 URL parameter. + +Check to see if your server’s time is not set properly. The `BeforeValidException` error can occur when the token is perceived to have been generated before the current time, which can happen if the server times are off. You can check server time by using `echo current_time( 'c' )`. A temporary workaround may also be to modify the plugin to add a time offset if you cannot modify the server time, but it should be fixed for production. + +If that does not solve the issue, continue with the troubleshooting steps below. + +### Cached cookies and URL parameters + +If you're on a managed host like WP-Engine, you may need to contact their support team for additional assistance. We've had reports of issues accessing required cookies on the callback URL, as well as problems with checking authentication on the final page that users see after logging in. Specifically, ask to have cache exclusions added for: + +- **Cookie:** `auth0_state` +- **Cookie:** `auth0_nonce` +- **Arg/URL parameter:** `auth0` +- **Arg/URL parameter:** `code` +- **Arg/URL parameter:** `state` +- **Arg/URL parameter:** `id_token` + +### Page refresh after error message + +If you refresh the page after seeing a different error message (email verification, etc) the invalid state message will appear, as it’s trying to revalidate an already used value. This is expected. + +### Cookie names requirement + +Some hosts, like Pantheon, require specific cookie names to be used. You can alter the cookie name using the [`auth0_state_cookie_name`](/cms/wordpress/extending#auth0_state_cookie_name) filter (see the [issue here](https://github.com/auth0/wp-auth0/issues/494) and [fix here](https://github.com/auth0/wp-auth0/pull/495)) in your theme or a custom plugin. + +### Universal Login Page and link building + +If your site is using the Universal Login Page and you're building the link yourself in a theme or plugin, you need to: + +* Set a cookie called `auth0_state` with a randomly-generated value +* Send that value in a `state` URL parameter. + +Alternatively, you can go to Settings > Features tab > Universal Login Page and redirect login requests to the `wp-login.php` page where that cookie and URL parameter will be set automatically. The code that runs this process is [here](https://github.com/auth0/wp-auth0/blob/master/lib/WP_Auth0_LoginManager.php#L90) if you want to continue to use a custom-built `/authorize` URL. + +### Visiting the callback URL directly + +If you visit your callback URL (typically `yourdomain.com/index.php?auth0=1`) directly or a second time after the authorization code has been exchanged, the invalid state error might display. This indicates that the state has already been verified and deleted. + +## Troubleshoot invalid state errors + +Note that some of the steps below will require the login process to be broken during the process (marked as such): + +1. While logged out of WordPress and Auth0, visit the login page being tested. +2. Check if the `auth0_state` cookie is being set (in Chrome, View > Developer > JavaScript Console > Application tab > Storage on the left > Cookies > domain being tested, look for an `auth0_state` cookie with a non-empty value). + + * If this value is not set, check for errors in the JS console and that your browser can accept cookies (login will not work without cookies). This is set in `/assets/js/lock-init.js` ([code on GitHub](https://github.com/auth0/wp-auth0/blob/master/assets/js/lock-init.js#L22)) + * If the value is set, copy the value and view the source code of the page (in Chrome, **View** > **Developer** > **View Source**). Search for the value, and it should appear as the value associated with parameter `wpAuth0LockGlobal.settings.auth.params.state` ([sample JSON](https://gist.github.com/joshcanhelp/1b8bb990048325eb7214e2b3d7136b78)). Make a note of this value (you'll need it in a following step). + +3. If the value appears there and the Lock form is loading normally then steps 1 and 2 from the first list above are functioning properly. +4. Before logging in, add [this snippet](https://gist.github.com/joshcanhelp/ba98f748747c7fd2ecdf54e73c6110f3) to the top of your `wp-config.php`. **WARNING**: This will break login for the WordPress site being tested so use it only on a non-production install. +5. Log in normally. +6. After you're redirected back to your site's callback URL, the process will stop. You should see an output like what's shown in the linked Gist in step #4 above. If you see something like `Array()` with no additional values, then one of two things could be happening: + + * The WordPress callback URL is cached. Page caching can happen in many different ways so there are not explicit steps we can provide here. Check any caching plugins you may have installed, they usually have some kind of URL exclusion built-in. Also check with your host as caching may be automatic and require support involvement. + * The server is not reading the Auth0 cookie. See the [issue here](https://github.com/auth0/wp-auth0/issues/494) and [fix here](https://github.com/auth0/wp-auth0/pull/495) for a possible solution. + +7. If the values are present, check the response headers for the callback URL being loaded (in Chrome, View > Developer > JavaScript Console > Network tab, click the first "document" listed with a 500 status and look for "Response Headers"). Look for any evidence of caching here, like a `Cache-Control` with a non-zero `max-age`, an `x-cache` of something other than `MISS`, or any other clue that this page is being served from a cache. +8. Also in the response headers, check that `set-cookie` includes a directive like `auth0_state=deleted` to confirm the validation process is happening. +9. Make sure that the `state` parameter in the URL matches the one recorded from the cookie being set in step #3 above. +10. If there is no evidence of caching, remove the debugging snippet from `wp-config.php` and refresh the callback URL. You should see the "Invalid state" message again. If any caching changes were made, attempt the login process all the way through (make sure to clear your cookies and browser cache for the site before testing). + +The following troubleshooting steps require plugin changes that will break the login process and need to be rolled back once complete. These steps should be performed on a test or staging server. + +11. Next, we need to check why the state is coming in but does not match the stored value. +12. In `lib/WP_Auth0_LoginManager.php`, output the values of the stored and returned state and kill the process after. Just before [this line](https://github.com/auth0/wp-auth0/blob/master/lib/WP_Auth0_LoginManager.php#L148), add: + +```php +echo '

      $_REQUEST

      '; var_dump($_REQUEST); echo '

      $_COOKIE

      '; var_dump($_COOKIE); die('

      Done

      '); +``` + +13. Once again, make sure you're logged out and complete the login process. +14. You should see values output when redirected back to the WordPress callback URL. +15. Check if the `state` value in `$_REQUEST` exists and matches the `auth0_state` value in `$_COOKIE`. + + * If it's different, it should match the original value recorded in step #3 above. This means that the `$_COOKIE` state value has changed somewhere in the process. + +If none of the steps above resolve the issue, please collect the results of the steps above and [contact support](https://support.auth0.com/) or post on [Community](https://community.auth0.com/tags/wordpress) with the tag `wordpress`. Also include: + +- PHP version +- WordPress version +- Auth0 plugin version +- Browser and OS used to test +- A [HAR file](/troubleshoot/guides/generate-har-files) recording the entire process from loading the page with the login form all the way through the "Invalid state" message. + +## Related posts: + +- ["Invalid state" error during Auth0 WordPress redirect](https://community.auth0.com/t/invalid-state-error-during-auth0-wordpress-redirect/12552/16) +- [Invalid state when visiting the callback URL directly](https://wordpress.org/support/topic/unable-to-resolve-troubleshooting-with-a-client-grant-for-already-exists/) diff --git a/articles/cms/wordpress/jwt-authentication.md b/articles/cms/wordpress/jwt-authentication.md deleted file mode 100644 index e4f048f487..0000000000 --- a/articles/cms/wordpress/jwt-authentication.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -description: Explains how to install the WordPress JWT Authentication and integration with the Auth0 plugin. ---- - -# Wordpress JWT Authentication - -Auth0 provides a plugin to enable JWT authentication for your APIs. It is compatible with any API that uses the `determine_current_user` function to retrieve the logged in user (such as [WP REST API](https://wordpress.org/plugins/json-rest-api/)). - -## Installation - -1. Install **WordPress JWT Authentication** from the WordPress Store or download the zip file from [WordPress JWT Authentication](https://wordpress.org/plugins/wp-jwt-auth/) and upload the `wp-jwt-auth` folder to the `/wp-content/plugins/` directory your WordPress installation. -2. Activate the plugin through the **Plugins** menu in WordPress. - -### Settings - -- **Aud:** Usually your *Client Id*. Verifies that the token was intended for you. -- **Secret:** Your *Client Secret*. Verifies the token signature. -- **Base64 Secret Encoded:** If enabled, encodes the secret in based64. -- **User Repository:** Empty by default. If empty, the plugin checks for a user whose `User Property` matches the `JWT Attribute` defined in each field. You can create a custom *User Repository* by implementing a static method called `getUser` to receive the decoded JWT and return a `WP_User` instance. - -## Integration with Auth0 plugin - -If the WordPress JWT Authentication plugin is installed and enabled, the latest version of the Auth0 plugin will give you the option to configure the WordPress plugin automatically, setting your *client id*, *client secret* and the *Auth0 User Repository*. - -## Authenticating requests - -To authenticate a request using JWT, add an `Authorization` header to the request: - -```txt -Authorization: Bearer YOUR-TOKEN -``` - -for example: - -```txt -Authorization: Bearer eyJhbGciOiJIUzIsNiIsInR5cCI6IkpXVCJ9.eyJjb250ZW50IjoiVGhpcyBpcyB5b3VyIHVzZXIgSldUIHByb3ZpZGVkIGJ5IHRoZSBBdXRoMCBzZXJ2rXIifQ.b47GoWoY_5n4jIyGghPTLFEQtSegnVydcvl6gpWNeUE -``` - -## Resources - -- [Cookies vs Tokens. Getting auth right with Angular.JS](https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/) -- [10 Things You Should Know about Tokens](https://auth0.com/blog/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/) diff --git a/articles/cms/wordpress/troubleshoot.md b/articles/cms/wordpress/troubleshoot.md index 458a0dff9b..b694b8ad52 100644 --- a/articles/cms/wordpress/troubleshoot.md +++ b/articles/cms/wordpress/troubleshoot.md @@ -1,82 +1,240 @@ --- -description: This page explains common troubleshooting issues with WordPress. +description: This page explains common troubleshooting issues with the Login by Auth0 WordPress plugin. +toc: true +topics: + - wordpress + - cms +contentType: reference +useCase: + - add-login + - build-an-app + - customize-connections + - secure-an-api + - manage-users --- +# Troubleshooting Login by Auth0 -# WordPress Troubleshooting +Here are some common troubleshooting questions. If the items below do not solve your issue, then consider the following alternatives: -### The Auth0 settings page in WordPress displays the warning: "The current user is not authorized to manage the Auth0 account...". +* If you're setting up the plugin for the first time or having problems with users logging in, please review the [configuration](/cms/wordpress/configuration) page in this section. +* If you found a bug in the plugin code [submit an issue](https://github.com/auth0/wp-auth0/issues) or [create a pull request](https://github.com/auth0/wp-auth0/pulls) on GitHub. +* If you have questions about how to use Auth0 or the plugin, please [post on our community site](https://community.auth0.com/) or create a [support forum request here](https://wordpress.org/support/plugin/auth0). +* You can also see additional documentation and answers on our [support site](https://support.auth0.com/). Customers on a paid Auth0 plan can [submit a trouble ticket](https://support.auth0.com/tickets) for a fast response. -If you updated your plugin to version 2 or configured the plugin without following the Quick Start Guide, you may need to provide an API token that the plugin will use to update your account settings. You can [generate a new token](/api/v2) and enter it into the **App Token** field of the the **Basic** settings page of the plugin. (The required scopes for the token are listed there.) You can also ignore this warning. Some operations will not be available from the plugin (like enabling rules or SSO). You will need to make these configuration changes manually in the [Auth0 dashboard](${manage_url}/#/applications)). +## I'm seeing the error message "Invalid state" that prevents me from logging in -### My configuration is wrong and I can't authenticate using Auth0. Is there another way to access the plugin? +State validation is a security feature added in [version 3.6.0](https://github.com/auth0/wp-auth0/releases/tag/3.6.0). A cached callback URL usually causes this error message (see your Application settings for the callback URLs that should not be cached). If this is not the issue or you need more information, please see [Troubleshoot WordPress Plugin Invalid State Errors](/cms/wordpress/invalid-state). -The plugin can be accessed using valid WordPress credentials through the regular WordPress login by adding `?wle` to the login url. For example: `http://yourdomain.com/wp-login.php?wle`. +## I'm having an issue logging in or changing email/password using a custom database -### I am having problems when a user logs in. Where can I find a log of what is happening? +[Please see our specific troubleshooting page](/cms/wordpress/user-migration#troubleshooting). -The plugin provides an error log where you can check what has happened. Access it through the **Error Log** sub-item of the **Auth0** plugin menu. +## I'm seeing the error message "Invalid ID token" or "Expired ID token" that prevents me from logging in -### How can I show the widget or shortcode in signup mode as default? +This is typically caused by a server set to an incorrect time. If the error message includes "used too early," then your server time is set in the future. If it says that the token is expired, then the server time is set too far in the past. A difference in time between two servers is common. Output `echo date(DateTime::ISO8601)` in PHP on your server and compare that, including seconds, to the current UTC time. If your server's time is more than 60 seconds (the default leeway) off from UTC time, then you’ll need to set a longer leeway to account for your server’s clock skew. You can paste the below code in your theme's `functions.php` or anywhere else that would run it after the plugin loads and before the login hook runs: -You can use the widget `Extra configuration` setting (or the `extra_conf` attribute in the shortcode) and add this json `{"mode":"signup" }` that will force the plugin to be shown in this mode. +``` +add_filter( 'auth0_jwt_leeway', function( $default_leeway ) { return 120; } ); +``` -### When using a plugin to force the login, the user is not logged in. +This would provide a 120 second leeway. You may need to adjust this depending upon how skewed your server's time is. -Be sure to **whitelist** the Auth0 `callback_url`. +## I see the error message "This account does not have an email associated..." that prevents me from logging in -#### The user is not logged in when using the `wp-force-login` plugin. +If you get this error, make sure you are requesting an email from each provider in the Auth0 Dashboard under Connections -> Social (expand each provider). Take into account that not all providers return email addresses for users (e.g., Twitter). If this happens, you can always add an Email address to any logged in user through the Auth0 Dashboard (or API). See Users -> Edit. -This is because the callback URL has not been whitelisted. Try adding this code to the `my_forcelogin_whitelist` filter: +For Connections that don't provide an `email_verified` flag (some Enterprise connections will not include this) *or* to skip this validation for specific Social Connections, add the strategy for that Connection in the "Skip Strategies" field. This field is located below the **Require Verified Email** switch accessible via **wp-admin** > **Auth0** > **Settings** > **Advanced**. -```php -function my_forcelogin_whitelist( $whitelist ) { +**This field should only be used if necessary because it circumvents the security precautions recommended Auth0.** -... +## I see the error message "There is a user with the same email" that prevents me from logging in - if( $_GET['auth0'] == 1 ) { - $whitelist[] = site_url($_SERVER['REQUEST_URI']); - } +This means that there is a user in WordPress that has the same email as the one being used to login associated with a different Auth0 user. If you're in the process of testing the plugin or want to associate the existing user with the new Auth user instead: + +1. Log in as an admin +1. Go to wp-admin > Users and search for the email being used +1. View the user's profile and scroll down to the bottom +1. Click **Delete Auth0 Data** and confirm + +::: note +If you have 2 user accounts in Auth0 with the same email address, this error message will persist. We recommend looking into [user account linking](/users/concepts/overview-user-account-linking). +::: + +## I see the error message "Failed cross origin authentication" or "No verifier returned from client" in my browser's console logs when trying to log in + +Check your "Allowed Callback URLs" and "Allowed Origins (CORS)" fields in the [Application](${manage_url}/#/applications) settings for your WordPress site to make sure those are correct. If you're using a Chromium-based browser, see [Cross-Origin Authentication](/cross-origin-authentication#limitations) to make sure you don't have third-party cookies turned off. + +## I need to rerun the Setup Wizard, but I don't see that menu option anymore. + +This means that the plugin is already configured with a Domain, Client ID, and Client Secret. Running the Setup Wizard a second time can have unpredictable results. If you're setting up WordPress for the first time and want to start over before any logins have occurred: + +1. Go to **wp-admin** > **Auth0** > **Settings** > **Basic**. +1. Delete the Domain and Client ID. Scroll down and click **Save Changes**. +1. Go to [Auth0 Dashboard > Applications](${manage_url}/#/applications) +1. Find the Application that was created by WordPress (its name should be the site name of your WordPress site) +1. Click on the Application to view its settings. Scroll to the bottom of the screen and click the **Delete Application** button. +1. Go to the [Auth0 Dashboard > Connections > Database](${manage_url}/#/connections/database) +1. Find the Connection that was created by WordPress (its name should be the site name of your WordPress site prepended with "DB-") +1. Click on the Connection to view the settings. Scroll down to the bottom, and click **I Want To Delete This Connection*. ***Please note that this will delete the Connection and all users that were created within.*** +1. Return to WordPress. You will now see the Setup Wizard option under Auth0 in the admin menu. + +## How do I setup Passwordless login? + +Passwordless login is possible any Auth0-enabled website using email or SMS. To make this work on your WordPress site: + +1. Turn on "Passwordless Login" from the plugin settings' **Features** tab and save +2. In your Auth0 dashboard, go to **[Connections > Passwordless](${manage_url}/#/connections/passwordless)** + - To use email, turn on the **Email** connection and modify the settings if desired. This will turn on email code login (users are emailed a code which is then typed into the login form on your site). + - To use a "magic link" (emailed link will automatically log users in), add `{passwordlessMethod: 'code'}` to the "Extra Settings" field in the plugin settings' **Advanced** tab. + - To use SMS login, turn on the **SMS** connection and follow the steps to set up a Twilio developer account (this will require a paid Twilio account depending on usage). + +The Auth0 login form will select a Passwordless method depending on which connection is activated above. If you have both connections active, it will default to email. In this case, either turn off the email connection to show SMS or add `sms` to the **Connections** field in the plugin settings' **Advanced** tab. + +## I have two accounts for the same user in WordPress + +Under some situations, you may end up with a user with two accounts. WordPress allows you to merge users by deleting one of the accounts and attributing that account's content to another user. Go to wp-admin > Users, select the account you want to remove, and in the confirmation dialog select another user to transfer the content. + +## My configuration is wrong, and I can't authenticate using Auth0. Is there another way to access the plugin? + +The plugin can be accessed using valid WordPress credentials through the regular WordPress login by adding `?wle` to the login URL. For example: `http://yourdomain.com/wp-login.php?wle`. + +## I am having problems when a user logs in. Where can I find a log of what is happening? + +The plugin provides an error log where you can check what has happened. Access it through the **Error Log** sub-item of the **Auth0** plugin menu. The [logs](${manage_url}/#/logs) in your Auth0 dashboard can also provide additional information. + +## How can I show the widget or shortcode in signup mode by default? + +You can use the widget `Extra configuration` setting (or the `extra_conf` attribute in the shortcode) and add this JSON `{"mode":"signup" }` that will force the plugin to be shown in this mode. + +## When using a plugin to force the login, the user is not logged in + +This is typically caused by a cached page after login. Check with your host for strategies to mitigate this or try adding a cache-busting parameter to the URL ([see this Gist for instructions](https://gist.github.com/joshcanhelp/e3eb693749f0fe66aad097c3bbb3b415)). + +### The user is not logged in when using the "Force Login" plugin -... +This is because the callback URL has not been whitelisted. Try adding this code to the `my_forcelogin_whitelist` filter: +```php +function wp_auth0_forcelogin_whitelist( $whitelist ) { + if ( ! empty( $_GET['auth0'] ) ) { + $whitelist[] = site_url($_SERVER['REQUEST_URI']); + } return $whitelist; } -add_filter('v_forcelogin_whitelist', 'my_forcelogin_whitelist', 10, 1); +add_filter('v_forcelogin_whitelist', 'wp_auth0_forcelogin_whitelist', 10, 1); ``` -### How can I redirect the users to a certain URL after login? +## How can I redirect the users to a specific URL after login? -#### On the login page +::: note +All redirects are checked using `wp_safe_redirect()` before being performed. If you're trying to redirect to a domain that is not your main domain, add that domain to the check using the core WordPress `allowed_redirect_hosts` filter ([documentation](https://developer.wordpress.org/reference/hooks/allowed_redirect_hosts/)). +::: -This plugin leverages WordPress features to work seamless with default settings. To add a redirect, you can append the `redirect_to` query parameter to the URL when you direct the user to the login page. The plugin will redirect the user to this URL after a successful login. +### On the login page + +This plugin leverages WordPress features to work seamlessly with default settings. To add a redirect, you can append the `redirect_to` query parameter to the URL when you direct the user to the login page. The plugin will redirect the user to this URL after a successful login. You can also use the **Login redirection URL** setting in the Auth0 plugin settings page. This will URL be used to redirect the user when the `redirect_to` parameter is not provided. -#### Using the widget +### Using the widget The widget will automatically redirect to the same page where the user was before authentication. You can override this using the `Redirect after login:` setting. -#### Using the shortcode +### Using the shortcode The shortcode will automatically redirect to the same page where the user was before authentication. You can override this using the `redirect_to` attribute. -### How can I migrate my WordPress users to Auth0? +## How can I migrate my WordPress users to Auth0? -The current version of the plugin does not provide a way to automatically migrate users to Auth0, but you have a few options: +The current version of the plugin does not provide a way to migrate users to Auth0 automatically, but you have a few options: -- The plugin exposes two endpoints to mark your custom database connection for **import to Auth0** mode as described in [Import users to Auth0](/connections/database/migrating). You can use these [plugin scripts](https://github.com/auth0/wp-auth0/blob/master/lib/WP_Auth0_CustomDBLib.php) to setup your connection. +- The plugin exposes two endpoints to mark your custom database connection for **import to Auth0** mode as described in [Import users to Auth0](/connections/database/migrating). You can use these [plugin scripts](https://github.com/auth0/wp-auth0/blob/master/lib/WP_Auth0_CustomDBLib.php) to set up your connection. - Export your user data to a JSON file and upload it for batch-import into Auth0. Initially, your users will have to reset their passwords when logging in using Auth0 because there is no way for Auth0 to decrypt the WordPress passwords during migration. To generate the JSON file, follow the instructions at [Mass-importing users to Auth0](/bulk-import). Then you will need to upload the file using the [Import users](/api/v2#!/Jobs/post_users_imports) endpoint. - Use the [WordPress XML RPC](https://codex.wordpress.org/XML-RPC_Support) endpoint to setup the migration flow using a custom database connection as described in [Import users to Auth0](/connections/database/migrating) with [this script](https://gist.github.com/glena/b31716e3c8fe48927be2). +## The form_title setting is ignored when I set up the dict setting + +Internally, the plugin uses the dict setting to change the Auth0 widget title. When you set up the dict field, it overrides the form_title one. + +To change the form_title in this case, you need to add the following attribute to the dict JSON: + +```json +{ + "signin": { + "title": "The desired form title" + } +} +``` + +## How can I modify the embedded Auth0 login form? + +There are many options on the **Appearance** tab of the plugin settings page that can change the look and feel of the login form that is embedded on your site (`wp-login/php` page, shortcodes, or widgets). These options are covered on the [Configuration page](/cms/wordpress/configuration#appearance). This will not affect the the login form on the Auth0-hosted Universal Login Page. + +There is also a field called "Extra Settings" on the **Advanced** tab that accepts a valid JSON object with all the settings you want to configure. This will override any changes made on the **Appearance** tab. For all the possible configuration options, please see our [documentation](/libraries/lock/v11/configuration). + +To use custom styling or JavaScript with the embedded Auth0 login form, please see our [documentation here](https://auth0.com/docs/libraries/lock/v11/ui-customization#overriding-css). External style sheets and JS files should be loaded in your theme using the [`wp_enqueue_scripts`](https://developer.wordpress.org/reference/hooks/wp_enqueue_scripts/) hook for shortcodes/widgets and the [`login_enqueue_scripts`](https://developer.wordpress.org/reference/hooks/login_enqueue_scripts/) hook for `wp-login.php`. + +## The session expires too soon + +The Auth0 plugin does not handle sessions; it uses the WordPress settings. By default, user sessions are kept alive for two days. You can enable the `Remember users session` setting on the plugin settings' **Advanced** tab to allow sessions to remain live for up to 14 hours. + +## How do I implement a Refresh Token? + +We implemented additional parameters in the login methods used by the plugin to allow for Refresh Tokens. Use the [`auth0_auth_scope`](/cms/wordpress/extending#auth0_auth_scope) filter combined with the [`auth0_user_login`](/cms/wordpress/extending#auth0_user_login) action to accomplish this. + +## Profile data saved in WordPress is not being synced to the Auth0 user account. + +This is a current limitation of the plugin but something we're looking at in a future release. The one exception to this is the user password. If the password is changed in WordPress and it passes the security policy set for the database connection being used, then that password will update for the Auth0 user as well. We'll be adding an error message in a future release to stop the process if the password is not strong enough. + +## How do I migrate from "Social Login with Auth0" to "Login by Auth0"? + +Historically, Auth0 has maintained two WordPress plugins: + +- [Login by Auth0](https://wordpress.org/plugins/auth0/) +- [Social Login with Auth0](https://wordpress.org/plugins/social-login-with-auth0/) + +These two plugins are effectively the same, but **Social Login with Auth** will not receive any updates past version 3.7.0 (released 13 August 2018). Migrating from **Social Login with Auth** to **Login by Auth0** is simple and won't result in any Auth0 or WordPress data loss. + +::: note +Moving from **Social Login with Auth** to **Login by Auth0** will update the version number you see, so make sure to test this change out on a staging or development server first (just as you would if you were updating the plugin in wp-admin). Furthermore, logins may not work during the migration process, so be sure to use a maintenance mode plugin or complete the migration during off-peak hours. +::: + +The easiest way to migrate is via (S)FTP: + +1. Log in to the WordPress site as an administrator. +1. [Download Login by Auth0](https://downloads.wordpress.org/plugin/auth0.zip) and unzip it locally. +1. Deactivate the **Social Login with Auth0** plugin from the WordPress admin > Plugins screen. +1. Log in to the server you want to migrate to and navigate to `wp-content/plugins`. +1. Move the `social-login-with-auth0` folder out of the plugins folder to back up the contents. +1. Upload the new `auth0` plugin folder to the plugins directory. +1. Activate the new "Login by Auth0" plugin from the WordPress **Admin** > **Plugins** screen. + +If you're unable to access the site via FTP, you can also run the process directly from the WordPress admin: -### Database migration does not work. +1. Log in to the WordPress site as an administrator. +1. Go to **Auth0** > **Import-Export Settings**. +1. Click **Export Settings**, then **Export**. +1. Deactivate the **Social Login with Auth0** plugin from the WordPress **Admin** > **Plugins** screen. +1. Delete the **Social Login with Auth0** plugin and confirm. +1. Go to **Plugins** > **Add New** and search for "Auth0". +1. For the **Login by Auth0** plugin (make sure to check the name), click **Install Now**. +1. When this completes, click **Activate**. +1. Check **Auth0** > **Settings** and make sure the previous settings remain. If not: + 1. Go to **Auth0** > **Import-Export Settings**. + 1. Paste in the settings JSON exported previously and click **Import**. +1. Completely delete the settings file export JSON (it contains sensitive information). -Your server needs to allow inbound connections from Auth0. +Everything should now be working as expected with the new plugin and updates will resume as usual. -### The session expires too soon. +## Keep Reading -The Auth0 plugin does not handle sessions, it uses the WordPress settings. By default, user sessions are kept alive for 2 days. You can enable the `Remember users session` setting to allow sessions to remain live for up to 14 hours. +More information on the Login by Auth0 WordPress plugin: -**NOTE:** This plugin leverages WordPress session handling and uses [wp_set_auth_cookie()](https://developer.wordpress.org/reference/functions/wp_set_auth_cookie/) to create the session cookie. This setting will send `true` as a second parameter to allow the session to last longer. +::: next-steps +* [How does it work?](/cms/wordpress/how-does-it-work) +* [Install the plugin](/cms/wordpress/installation) +* [Configure the plugin](/cms/wordpress/configuration) +* [Extend the plugin](/cms/wordpress/extending) +::: diff --git a/articles/cms/wordpress/user-migration.md b/articles/cms/wordpress/user-migration.md new file mode 100644 index 0000000000..ec221f0d38 --- /dev/null +++ b/articles/cms/wordpress/user-migration.md @@ -0,0 +1,161 @@ +--- +description: This page explains the user migration feature of the Login by Auth0 WordPress Plugin +toc: true +topics: + - wordpress + - cms +--- +# User Migration in Login by Auth0 + +The User Migration functionality uses a core Auth0 feature, [Custom Databases](https://auth0.com/docs/connections/database/custom-db), combined with URL endpoints in the Login by Auth0 plugin to allow users to authenticate with existing WordPress user accounts. + +## How It Works + +When you enable data migration, the plugin exposes two secure endpoints that allow Auth0 to authenticate users using WordPress accounts. These endpoints are secured with a secret token and can be set only to allow IP addresses used by Auth0. + +The login flow is as follows: + +1. A user attempts to login with an Auth0 login form (embedded on your site or hosted at Auth0). +2. If Auth0 can't find a user associated with the provided credentials in your database connection, it proceeds to call the migration endpoint on your WordPress site with the user credentials and the migration token. +3. The plugin finds a user in your WordPress database with the provided username/email and verifies the password. +4. If a user can be successfully authenticated, Auth0 creates the user in the database connection for your site, authenticates the user, and logs them in. +5. The next time the user logs in, they will use the Auth0 user, and the migration endpoint will be skipped. + +User Migration must be set up when the site is first connected to Auth0. Attempting to turn on or off custom database scripts for a database connection that has already had users will fail. See the **Troubleshooting** section for more information about moving between modes. + +## Setup and Configuration + +The easiest way to setup User Migration is to use the Setup Wizard when the plugin is first installed. [That process is described here](https://auth0.com/docs/cms/wordpress/installation#option-2-user-migration-setup). + +If the User Migration Setup Wizard could not complete or you want to see the process in more detail, follow the steps below. Again, this is starting from scratch with a database connection that does not have any users. The following process should be completed on a site with no traffic or with maintenance mode turned on. + +1. Make sure you have an Application [created and configured correctly](https://auth0.com/docs/cms/wordpress/configuration#application-setup) and an empty Database Connection [created and activated for the Application](https://auth0.com/docs/cms/wordpress/configuration#database-connection-setup). These can be the same as the ones created in the [Standard Setup Wizard process](https://auth0.com/docs/cms/wordpress/installation#option-1-standard-setup) or created from scratch. +2. In the **Auth0 > Settings** screen in WordPress, make sure the Application's Domain, Client ID and Client Secret are saved in the correct fields in the **Basic** tab. +3. On the **Advanced** tab, turn on the "User Migration Endpoints" setting and click **Save Changes**. If you are using [constant-based settings](https://auth0.com/docs/cms/wordpress/configuration#php-constant-setting-storage), set `AUTH0_ENV_MIGRATION_WS` to `true` and `AUTH0_ENV_MIGRATION_TOKEN` to a secure random string at least 16 digits long and without single quotes or backslashes. +4. Under the settings, you should now see a **Security Token**. Keep this page open as you will need this value later on in the process. +5. In the Auth0 Dashboard, go to the Database Connection you want to use and turn on **Requires Username** and **Import Users to Auth0**. +6. Now click the **Custom Database** tab and turn on **Use my own database** +7. There should be two tabs below this setting under the "Database Action Scripts" heading, one for **Login** and one for **Get User** +8. Click on the **Login** tab +9. Clear out all the existing code, open [this link](https://raw.githubusercontent.com/auth0/wp-auth0/master/lib/scripts-js/db-login.js) in a new tab, copy all the code there, and paste it into the code editor back in Auth0. +10. **This step is for versions 3.10.0 and earlier:** Look for `{THE_WS_URL}` and replace that with your WordPress instance's site URL, followed by `/index.php?a0_action=migration-ws-login`. The site URL can be found in the **Settings > General** screen in wp-admin. You can test this by pasting the complete URL in your browser. You should see `{"status":401,"error":"Unauthorized"}`. +11. **This step is for versions 3.10.0 and earlier:** Look for `{THE_WS_TOKEN}` and replace that with the token that appears under the "User Migration Endpoints" setting. +12. There should be no errors in the editor. If everything looks good, click **Save** at the top. +13. **This step is for 3.11.0 and later:** Scroll down to **Settings** and add the following configuration variables: + - `endpointUrl` set to your WordPress instance's site URL (**wp-admin > Settings > General >** "Site URL" field), followed by `/index.php?a0_action=`. + - `migrationToken` set to the security token value seen in step 4 above. + - `userNamespace` set to your Application name in Auth0 or any other value only including letters, numbers, and dashes. + +![WordPress User Migration - Database Configuration](/media/articles/cms/wordpress/auth0-custom-database-config.png) + +14. Click the **Try** button at the top and use a valid WordPress user account in the form that appears. You should see the "The profile is" followed by the user's data. If not, please see the [**Troubleshooting**](#troubleshooting) section below. +15. Now click on the **Get User** tab, clear out all the existing code, open [this link](https://raw.githubusercontent.com/auth0/wp-auth0/master/lib/scripts-js/db-get-user.js) in a new tab, copy all the code there, and paste it into the code editor back in Auth0. +16. **This step is for 3.10.0 and earlier:** Look for `{THE_WS_URL}` and replace that with your WordPress instance's site URL, followed by `/index.php?a0_action=migration-ws-get-user`. The site URL can be found in the **Settings > General** screen in wp-admin. You can test this by pasting the complete URL in your browser. You should see `{"status":401,"error":"Unauthorized"}`. +17. **This step is for 3.10.0 and earlier:** Look for `{THE_WS_TOKEN}` and replace that with the token that appears under the "User Migration Endpoints" setting. +18. There should be no errors in the editor. If everything looks good, click **Save** at the top. +19. Click the **Try** button at the top and use an email with a valid WordPress user account in the form that appears. You should see the "The profile is" followed by the user's data. If not, please see the [**Troubleshooting**](#troubleshooting) section below. +20. In a new browser session, navigate to a login page on the WordPress site and attempt to login (the user should not already exist in the database). You'll notice that the login process takes a little longer than usual at first but should succeed. Subsequent logins will be faster. +21. (OPTIONAL) To turn on additional security for the migration endpoints, go to **Auth0 > Settings** screen in WordPress, turn on "Migration IPs Whitelist," and then **Save Changes**. Attempt to log in with a different user to test that Auth0 can still reach the endpoints. + +At this point, the User Migration setup is complete, and existing WordPress users will be trickle migrated to the Auth0 Database Connection. + +## Troubleshooting + +Issues with the User Migration typically come from a few places: + +- Incorrect URL or token in the custom database scripts. +- IP whitelist turned on but with incorrect IP addresses. +- Restricted or cached endpoints on your WordPress instance. + +The best way to start troubleshooting the issue is to use the **Try** button for the **Login** script found in the Custom Database tab of the Database Connection being used on [Auth0 Dashboard > Connections > Database Connections](${manage_url}/#/connections/database). The following are the error messages you might see and the steps to take to fix. + +### "Unexpected token < in JSON at position 0" + +This means the custom script is not getting data back in a format it can use. An incorrect endpoint URL likely causes this in the database script. + +First, copy the URL on line 10 in the script and paste it in your browser. If the endpoint is correct, it should display one of the two messages below: + +``` +{"status":401,"error":"Unauthorized"} + +// or + +{"status":403,"error":"Forbidden"} +``` + +If what you're seeing is the home page or a 404, then the URL is incorrect. Look for your site URL under **Settings > General > Site URL** in the WordPress admin. Add `/index.php?a0_action=migration-ws-login` to the end for the Login script and `/index.php?a0_action=migration-ws-get-user` to the end for the Get User script. + +- **For versions 3.10.0 and earlier**: The URL value should appear in the script itself as the first parameter in the `request.post` call. +- **For versions 3.11.0 and later**: The token value should be saved in a configuration variable. Add the following to the first line of the function and use the **Try** button to see what is stored for `endpointUrl`: + +```js +callback(null, configuration); +``` + +If you're sure the URLs are correct and are still having this issue, check with your host to make sure those URLs are not cached or restricted in any way. + +### "Wrong email or password" + +This is the default error shown if anything else goes wrong. The easiest way to troubleshoot what's happening is to temporarily output the error that's being sent back (these are opaque by default to avoid displaying anything that might give attackers something to work with). + +On line 30 of the Login script, change: + +```js +callback(null); +``` + +... to: + +```js +callback(wpUser.error); +``` + +... save the script, and try the connection again. You should see one of the following messages and be able to pinpoint the issue with the steps below. Once you've solved the issue, change the script back to what it was. + +#### "Forbidden" + +This means that the migration endpoints are turned off in your WordPress install. Go to **Auth0 > Settings > Advanced** and turn on the "User Migration Endpoints" setting. Make sure the token that appears there is the same as what is used for both custom database scripts: + +- **For versions 3.10.0 and earlier**: The token value should appear in the script itself after `access_token:` +- **For versions 3.11.0 and later**: The token value should be saved in a configuration variable. Add the following to the first line of the function and use the **Try** button to see what is stored for `migrationToken`: + +```js +callback(null, configuration); +``` + +#### "Unauthorized" + +This means that the migration IP whitelist is turned on, but the incoming IP address is not on the list. Just below the Login script you should see a list of IP addresses: + +![WordPress User Migration - Auth0 IP Addresses](/media/articles/cms/wordpress/auth0-incoming-ip-addresses.png) + +Make sure all of those IP addresses appear below the "Migration IPs Whitelist" field under **Auth0 > Settings > Advanced** in the plugin: + +![WordPress User Migration - IP Whitelist](/media/articles/cms/wordpress/migration-ip-whitelist-setting-field.png) + +If one or more of the IP addresses listed in Auth0 do not appear in WordPress, add the missing ones into the field and save the settings page. Also, please post in the Auth0 [Community](https://community.auth0.com/tags/wordpress) (tagged `wordpress`) with the missing IP address(es), so we can address the issue. + +#### "Unauthorized: missing authorization header" + +The security token is either missing in the database script (line 16), or your server is not processing the headers correctly. Check the Login script and make sure that the token exists and matches what is in WordPress. If the token is there and correct, then you'll need to talk to your host to enable the `Authorization` header to be parsed. See [this StackOverflow thread](https://stackoverflow.com/questions/17018586/apache-2-4-php-fpm-and-authorization-headers) for server troubleshooting and use [the plugin code](https://github.com/auth0/wp-auth0/blob/master/lib/WP_Auth0_Routes.php#L138) as a reference for how the token is retrieved. + +#### "Invalid token" + +The security token in the database script is incorrect. Check the Login script line 16 and make sure that the token matches what is in WordPress. + +#### "Invalid Credentials" + +The email address and/or password being used is incorrect. Check to make sure you're entering the correct email address and that the password is correct. You can reset the user password to something else to make sure you have the correct one. + +### Cannot Change Email or Incorrect User Data + +If you are using more than one custom database connection in your Auth0 tenant and you're unable to change the email address or are getting user data stored for the wrong user, it's likely that you have overlapping user IDs in Auth0. This problem has been fixed for new sites installing 3.11.0 but, for connections created before then, this will need to be manually fixed by doing one of the following: + +* If you don’t have any user data stored that needs to be kept (if you’re only using the connection to support login and not storing any metadata), you can create a new custom database connection using the steps above (using the 3.11.0 notes) and switch the Application to this new connection (make sure to turn the old connection off). The migration will be restarted, and there will be no impact on the user experience. +* If you do have data in Auth0 that needs to be kept, you can use our [User Import/Export Extension](/extensions/user-import-export) to adjust the user data. + 1. Create a new custom database connection using the steps above (using the 3.11.0 notes). + 2. Export all users from the existing connection (we recommend putting your site in maintenance mode while doing the switch-over, so no users are missed). + 3. Change all user IDs to add the namespace used when creating the new connection. User IDs should go from something like `auth0|123` to `auth0|Your-WP-Site-Name|123`. Adjust all other fields you need to follow the [import schema](/users/references/bulk-import-database-schema-examples). + 4. Turn the new connection on and the old connection off for your application. + 5. Import the new user data into the new connection and test. +* If you have a paid account, you can contact our support team to run a database update script to change the user IDs to a namespaced version and add the namespace to your database script at the same time (step 12 in [Setup and Configuration](#setup-and-configuration) above). diff --git a/articles/compliance/gdpr/data-processing.md b/articles/compliance/gdpr/data-processing.md new file mode 100644 index 0000000000..b26cd5e768 --- /dev/null +++ b/articles/compliance/gdpr/data-processing.md @@ -0,0 +1,28 @@ +--- +title: Auth0 Data Processing +description: How Auth0 processes data in its possession +topics: + - compliance + - gdpr +contentType: concept +useCase: compliance +--- +# Auth0 Data Processing + +This document discusses what data Auth0 has, as well as how it processes this data. + +## Data Auth0 Possesses + +All of the data Auth0 has about an end user is located in the Auth0 user profile. The specific attributes contained in the user profile vary based on customer implementation and are based on a number of factors, such as connection type, user consent during the authentication flow, and whether you've augmented the user profiles with additional information. + +## When Auth0 Data is Stored + +The Auth0 user profile information is stored in Auth0 when you use a database connection. If a user logs in using any other type of connection (including custom database connections), Auth0 stores information provided by the external identity provider for future queries. + +## How Auth0 Uses the Data It Stores + +The personal data stored in Auth0 is used only for the purposes of providing its services, namely authenticating users + +## What Happens to Data When an End User's Account is Deleted + +When an end user's account is deleted, their user profile, included metadata, is removed. See [Right to be Forgotten](/compliance/gdpr/features-aiding-compliance#right-to-be-forgotten) for additional information. \ No newline at end of file diff --git a/articles/compliance/gdpr/definitions.md b/articles/compliance/gdpr/definitions.md new file mode 100644 index 0000000000..5acd82b904 --- /dev/null +++ b/articles/compliance/gdpr/definitions.md @@ -0,0 +1,19 @@ +--- +title: General Data Protection Regulation (GDPR) Definitions +description: Definitions used for Auth0's documentation on GDPR +topics: + - compliance + - gdpr +contentType: reference +useCase: compliance +--- +# Definitions + +| Term | Definition | +| - | - | +| Subject | An individual/natural person | +| Data Controller | The entity that collects and processes data on subjects (see [GDPR for exact definition](https://gdpr-info.eu/art-4-gdpr/)) | +| Data Processor | The entity that processes data on behalf of a data controller (see [GDPR for exact definition](https://gdpr-info.eu/art-4-gdpr/)) | +| Personal Data | Data that can be used to identify (directly or indirectly) a subject, particularly via reference to an identifier (such as a name, identification number, location data, or online identifier), or to the physical, physiological, genetic, mental, economic, cultural, or social identity of that person | +| Sensitive Personal Data | Personal data that reveals racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade-union membership; genetic data or biometric data | +| Auth0 Subprocessors | Third party systems to which Auth0 provides personal data | diff --git a/articles/compliance/gdpr/features-aiding-compliance/_encrypt-data.md b/articles/compliance/gdpr/features-aiding-compliance/_encrypt-data.md new file mode 100644 index 0000000000..55566bda13 --- /dev/null +++ b/articles/compliance/gdpr/features-aiding-compliance/_encrypt-data.md @@ -0,0 +1,32 @@ +You can encrypt user information before you save it in the user profile. You can use any encryption mechanism you like prior to storing data in the metadata fields. When a user sets sensitive information, call the [Update a user endpoint](/api/management/v2#!/Users/patch_users_by_id). + +For example, to save the encrypted `passportNumber` in the user's profile, send this request: + +```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\": {\"passportNumber\": \"B9MuhaDoreVr69MDqx3p8A==\"}}" + }, + "headersSize": -1, + "bodySize": -1, + "comment": "" +} +``` + +::: note +Replace the `YOUR_ACCESS_TOKEN` placeholder with a token that will allow you to access this endpoint. This should be a [Management API Token](/api/management/v2/tokens), with the scopes `update:users` and `update:users_app_metadata`. +::: + diff --git a/articles/compliance/gdpr/features-aiding-compliance/_legal-warning.md b/articles/compliance/gdpr/features-aiding-compliance/_legal-warning.md new file mode 100644 index 0000000000..3fe2af97dc --- /dev/null +++ b/articles/compliance/gdpr/features-aiding-compliance/_legal-warning.md @@ -0,0 +1,3 @@ +::: warning +The contents of this document are **not** intended to be legal advice, nor should they be considered a substitute for legal assistance. The final responsibility for understanding and complying with GDPR resides with you, though Auth0 will assist you in meeting GDPR requirements where possible. +::: \ No newline at end of file diff --git a/articles/compliance/gdpr/features-aiding-compliance/data-minimization.md b/articles/compliance/gdpr/features-aiding-compliance/data-minimization.md new file mode 100644 index 0000000000..26405dc51e --- /dev/null +++ b/articles/compliance/gdpr/features-aiding-compliance/data-minimization.md @@ -0,0 +1,125 @@ +--- +title: "GDPR: Data Minimization" +description: This article discusses how customers can minimize the personal data they collect for processing and ensure their security +toc: true +topics: + - compliance + - gdpr +contentType: how-to +useCase: compliance +--- +# GDPR: Data Minimization + +According to Article 5 of GDPR, the personal data you collect must be limited to what is necessary for processing and must be kept only as long as needed. Appropriate security must be ensured during data processing, including protection against unauthorised or unlawful processing and against accidental loss, destruction, or damage. + +There are several Auth0 features than can help you achieve these goals, like account linking, user profile encryption, and more. + +<%= include('./_legal-warning.md') %> + +## Restrict user profile information + +To limit the amount of personal information in the Auth0 user profile, you can: + +- Minimize (or avoid) saving personal information in the metadata section of the user profile +- If you use [enterprise directories](/connections/identity-providers-enterprise), configure them to return only the minimum information needed +- If you use [social providers](/connections/identity-providers-social), configure them to return only the minimum information needed +- [Blacklist the user attributes](/security/blacklisting-attributes) that you do not want to persist in the Auth0 databases + +## Encrypt user profile information + +<%= include('./_encrypt-data.md') %> + +## Use account linking + +Every time a user uses a connection to log in to your application, a user profile is created if it doesn't already exist. Note that this is per connection. + +To better understand this, consider the following scenario. Your application offers three different options for signup: +- sign up with email/password +- login with Google +- login with Facebook + +If a user signs up with Google, this will create a user profile in Auth0. If the same user, upon return, does not remember what he signed up with, and chooses to login with Facebook, Auth0 will create another user profile for the user. So now you have two profiles for the same user. + +You can fix this with [account linking](/users/concepts/overview-user-account-linking). You can link multiple accounts under a single user profile, regardless of the connection's type (for example, user/password, social, or SAML). + +There are two ways to implement this: + +- **User-initiated** account linking: your app must provide the UI so an authenticated user can link their accounts manually. For a sample implementation, see [Link User Accounts Server-Side Scenario](/users/references/link-accounts-user-initiated-scenario) +- **Suggested** account linking: in this case you still configure a rule that will link accounts with the same verified email address. However, instead of completing the link automatically, your app will first prompt the user to link their identities. For a sample implementation, see [Link User Accounts Server-Side Scenario](/users/references/link-accounts-server-side-scenario) + +## Export 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. + +### Export logs with the API + +You can use the Management API to export logs and store them yourself. There are the two available endpoints, each providing slightly different information. + +#### Search all logs + +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 + +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" +}] +} +``` + +### Use Extensions to export to an external service + +You can install and configure an Auth0 Extension in order 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). + + +## Keep sensitive information from logs + +You should minimize any sensitive information contained in URLs that might be captured by Auth0 log files. For example, consider using `health-site` or similar as your domain name instead of `cancer-treatments`. + +--- + +:::panel What else do I have to do? +- Analyze what you are collecting in sign up and through social media and whether that is necessary for the purpose of your service +- Configure enterprise identity providers to control what data is returned to Auth0 +- Specify what data you want to collect from the social provider and negotiate any particular terms around social login with the social provider around use of the data they will get around your users’ login +::: diff --git a/articles/compliance/gdpr/features-aiding-compliance/data-portability.md b/articles/compliance/gdpr/features-aiding-compliance/data-portability.md new file mode 100644 index 0000000000..9494372ef5 --- /dev/null +++ b/articles/compliance/gdpr/features-aiding-compliance/data-portability.md @@ -0,0 +1,31 @@ +--- +title: "GDPR: Data Portability" +description: This article discusses how customers can export user data in order to comply with data portability GDPR requirements +toc: true +topics: + - compliance + - gdpr +contentType: how-to +useCase: compliance +--- +# GDPR: Data Portability + +According to Article 20 of GDPR, users have the right to receive the personal data concerning them in a structured, commonly used and machine-readable format. + +You can export user data, stored in the Auth0 user store, either manually or programmatically. Raw data from Auth0 can be exported in JSON format (which is machine-readable). + +<%= include('./_legal-warning.md') %> + +## Export data manually + +To export a user's data manually from the Dashboard: + +1. Go to [Dashboard > Users](${manage_url}/#/users) +1. Search for the user and drill down on their name +1. Click the **Raw JSON** tab. Here you can see the complete user profile in JSON format +1. Click **Copy JSON**. The profile is copied to your clipboard +1. Paste the clipboard contents to an editor and save + +## Export data using the API + +You can export a user's full profile using our Management API. The response will be in JSON format. You can either [search for a user using their ID](/best-practices/search-best-practices#users-by-id), or [export a list of your users](/best-practices/search-best-practices#user-export). diff --git a/articles/compliance/gdpr/features-aiding-compliance/index.md b/articles/compliance/gdpr/features-aiding-compliance/index.md new file mode 100644 index 0000000000..ec4b898cf5 --- /dev/null +++ b/articles/compliance/gdpr/features-aiding-compliance/index.md @@ -0,0 +1,70 @@ +--- +title: "How Auth0 can help with GDPR" +description: This article discusses the Auth0 features that can help customers comply with GDPR requirements +toc: true +topics: + - compliance + - gdpr +contentType: + - concept + - index +useCase: compliance +--- +# How Auth0 Can Help With GDPR Compliance + +In this article, you will find a list of GDPR regulations and how Auth0 can help you comply with them. + +<%= include('./_legal-warning.md') %> + +## Conditions for consent + +According to Article 7 of GDPR, you must: +- ask users to consent on the processing of their personal data in a clear and easily accessible form +- be able to show that the user has consented, and +- provide an easy way to withdraw consent at any time + +You can use Auth0 to ask your users for consent upon signup (using either Lock or a custom form) and save this information at the user profile. You can later update this information using the Management API. + +For details, see [Conditions for consent](/compliance/gdpr/features-aiding-compliance/user-consent). + +## Right to access, correct, and erase data + +According to Articles 15, 16, 17, and 19 of GDPR, users have the right to: +- get a copy of their personal data you are processing +- ask for rectifications if they are inaccurate, and +- ask you to delete their personal data + +With Auth0, you can access, edit, and delete user information, either manually or using our API. + +For details, see [Right to access, correct, and erase data](/compliance/gdpr/features-aiding-compliance/right-to-access-data). + +## Data minimization + +According to Article 5 of GDPR: +- the personal data you collect must be limited to what is necessary for processing +- must be kept only as long as needed, and +- appropriate security must be ensured during data processing, including protection against unauthorised or unlawful processing and against accidental loss, destruction, or damage + +There are several Auth0 features than can help you achieve these goals, like account linking, user profile encryption, and more. + +For details, see [Data minimization](/compliance/gdpr/features-aiding-compliance/data-minimization). + +## Data portability + +According to Article 20 of GDPR, users have the right to receive the personal data concerning them in a structured, commonly used and machine-readable format. + +You can export user data, stored in the Auth0 user store, either manually or programmatically. Raw data from Auth0 can be exported in JSON format (which is machine-readable). + +For details, see [Data portability](/compliance/gdpr/features-aiding-compliance/data-portability). + +## Protect and secure user data + +According to Article 32 of GDPR, you must implement appropriate measures to ensure a level of security, including (but not limited to): +- data encryption +- ongoing confidentiality +- data integrity, and +- availability and resilience of processing systems and services + +There are several Auth0 features than can help you meet this requirement, like user profile encryption, brute-force protection, breached password detection, step-up authentication, and more. + +For details, see [Protect and secure user data](/compliance/gdpr/features-aiding-compliance/protect-user-data). diff --git a/articles/compliance/gdpr/features-aiding-compliance/protect-user-data.md b/articles/compliance/gdpr/features-aiding-compliance/protect-user-data.md new file mode 100644 index 0000000000..880ffc78d8 --- /dev/null +++ b/articles/compliance/gdpr/features-aiding-compliance/protect-user-data.md @@ -0,0 +1,121 @@ +--- +title: "GDPR: Protect and secure user data" +description: This article discusses how customers can use Auth0 to better protect and secure their user's personal data +toc: true +topics: + - compliance + - gdpr +contentType: concept +useCase: compliance +--- +# GDPR: Protect and secure user data + +As per article 32 of GDPR, you must implement appropriate security measures in order to ensure a level of security appropriate to the risk, including (but not limited to): + +- Τhe encryption of personal data +- Τhe ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services +- Τhe ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident + +There are several Auth0 features than can help you achieve that, like user profile encryption, brute-force protection, breached password detection, step-up authentication, and more. + +<%= include('./_legal-warning.md') %> + +## Encrypt user profile information + +<%= include('./_encrypt-data.md') %> + +## Enable brute-force protection + +Auth0's brute-force protection shield is enabled by default to stop malicious attempts to access your application. + +There are two types of triggers for this shield: + +* 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. + +Every time Auth0 detects 10 failed login attempts into a single account from the same IP, we will: + +- Send a notification email to the user. +- Block the suspicious IP address for that user. + +Every time Auth0 detects 100 failed login attempts in 24 hours or 50 sign up attempts from the same IP address, we will: + +- Notify dashboard administrator(s). +- Block suspicious addresses for 15 minutes. + +You can enable brute-force protection, configure which actions you want to take, and customize the blocked account email using the Dashboard. + +For more information, see [Brute Force Protection](/anomaly-detection#brute-force-protection). + +## Enable breached password detection + +The breached password detection shield helps you identity user credentials that might have been compromised in a public data breech. + +Auth0 tracks large security breaches that are happening on major third party sites. If one of your users' credentials were included in a public security breech, you can take action and: + +- 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 + +You can enable breached password detection and configure which actions you want to take using the Dashboard. + +For more information and steps to follow, see [Breached Password Detection](/anomaly-detection#breached-password-detection). + +## Harden your security with multi-factor authentication + +With multi-factor authentication (MFA), you can add an additional layer of security to your applications. It is a method of verifying a user's identity by asking them to present more than one piece of identifying information. + +We support MFA using push notifications, SMS, Voice, one-time password authentication services, and custom providers. You can enable MFA for specific users or specific actions (for example, access to screens with sensitive data). You can also define the conditions that will trigger additional authentication challenges, such as changes in geographic location or logins from unrecognized devices. + +To review all available options and their features, and get implementation details for the one that suits your needs, see [Multi-factor Authentication in Auth0](/mfa). + +## Help your users choose better passwords + +You can customize the level of password complexity for new sign ups. For example, you can ask for a password that has at least 10 characters and includes at least one upper-case letter, a number, and a special character. + +You can also forbid the use of previous passwords using our Password History feature and stop users from choosing common passwords using our Password Dictionary. + +All three features are configurable from the Dashboard. + +For information on how to use them see [Password Strength](/connections/database/password-strength) and [Password Options](/connections/database/password-options). + +## Step-up authentication + +With step-up authentication, applications can ask users to authenticate with a stronger authentication mechanism to access sensitive resources. For example, you may have a banking application which does not require [Multi-factor Authentication (MFA)](/mfa) to view the accounts basic information, but when users try to transfer money between accounts then they must authenticate with one more factor (for example, a code sent via SMS). + +You can check if a user has logged in with MFA by reviewing the contents of their ID Token or Access Token. You can then configure your application to deny access to sensitive resources if the token indicates that the user did not log in with MFA. + +For details see [Step-up Authentication](/mfa/concepts/step-up-authentication). + +## Availability and resilience + +Auth0 is designed and built as a scalable, highly available, multi-tenant cloud service. We are highly resilient to the failure of any of our components, because we implement redundant components at all levels. We also detect failures rapidly and our failover is very quick. + +We support three deployment models: + + + + + + + + + + + + + + + + + + +
      DeploymentDescription
      Public CloudA multi-tenant cloud service running on Auth0's cloud
      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
      + +You decide which deployment model works best for you based on your business and security requirements. + +For more information on Auth0 architecture, see [Availability & Trust](https://auth0.com/availability-trust). + +For more information on the available deployment models of Auth0, see [Auth0 Deployment Models](/getting-started/deployment-models). diff --git a/articles/compliance/gdpr/features-aiding-compliance/right-to-access-data.md b/articles/compliance/gdpr/features-aiding-compliance/right-to-access-data.md new file mode 100644 index 0000000000..5f37b3f90a --- /dev/null +++ b/articles/compliance/gdpr/features-aiding-compliance/right-to-access-data.md @@ -0,0 +1,103 @@ +--- +title: "GDPR: Right to access, correct, and erase data" +description: This article discusses which Auth0 features can help customers comply with the GDPR requirements on the user's right to access, correct, and erase their personal data +toc: true +topics: + - compliance + - gdpr +contentType: concept +useCase: compliance +--- +# GDPR: Right to access, correct, and erase data + +As per articles 15, 16, 17, and 19 of GDPR, users have the right to get a copy of their personal data you are processing, ask for rectifications if they are inaccurate, and ask you to delete their personal data. + +With Auth0, you can access, edit, and delete user information: +- manually, using the [Dashboard](${manage_url}/#/users), or +- programmatically, using the [Management API](/api/management/v2) + +<%= include('./_legal-warning.md') %> + +## Manual process + +You can view, edit, and delete user information at [Dashboard > Users](${manage_url}/#/users). Drill down to a user to view their info. The information you can change are: + +| **Field** | **How to edit** +|-|-| +| **Email** | Click Edit. Set the new email. +| **Email verified** | Click **Edit** at the **Εmail** field. Click the **Set email as verified** link. +| **Metadata** | Both the `app_metadata` and the `user_metadata` objects are editable from this screen. Edit the JSON at the **Metadata** section and save your changes. +| **Blocked** | Not directly editable. Click **Actions > Block User** at the top right of this screen. To unblock click **Actions > Unblock User**. +| **Email** | Not directly editable. Click **Actions > Change Email** at the top right of this screen. +| **Password** | Not directly editable. Click **Actions > Change Password** at the top right of this screen. + +To delete a user, drill down and click **Actions > Delete User**. + +## Programmatic process + +You can also retrieve, edit, and delete user information using our API. + +First, pick an endpoint that matches your needs: + +- [Retrieve a user using the ID as search criteria](/best-practices/search-best-practices#users-by-id) +- [Retrieve a user using the Email as search criteria](/best-practices/search-best-practices#users-by-email) +- [Export all users to a file using a long running job](/best-practices/search-best-practices#user-export) +- [Update a user](/api/management/v2#!/Users/patch_users_by_id). Note that not all fields are editable (see the next paragraph: [Editable data](#editable-data)). Keep in mind that: + - The properties of the new object will replace the old ones. The **user_metadata** and **app_metadata** fields are an exception to this rule. These properties are merged instead of being replaced, though the merge happens only on the first level. + - If you are updating **email_verified**, **phone_verified**, **username**, or **password**, you must set the **connection** parameter. + - If your are updating **email** or **phone_number**, you must set the **connection** and the **client_id** parameters. +- [Delete a user based on the ID](/api/management/v2#!/Users/delete_users_by_id) + +In order to call any of the API's endpoints, you will need an valid Access Token. This token must have the required permissions per endpoint. + +:::note +Each endpoint at the [Management API explorer](/api/management/v2) has a section **Scopes** that lists the scope(s) that the Access Token must contain in order to access it. For example, the [Delete user endpoint](/api/management/v2#!/Users/delete_users_by_id) requires the `delete:users` scope. +::: + +To learn more about these tokens and how you can generate one, see [Access Tokens for the Management API](/api/management/v2/tokens). + +Once you know which endpoint you want to access, and you have a valid Access Token, you are ready to send your request. + +## Editable data + +The following user information can be updated using the API: + +- blocked +- email_verified +- email +- verify_email +- password +- phone_number +- phone_verified +- verify_password +- user_metadata +- app_metadata +- username + +::: note +For a list of all the user attributes, refer to the [Structure of the User Profile](/users/references/user-profile-structure). +::: + +The following user information are **not** editable: +- given_name +- family_name +- name +- nickname +- picture + +## Searchable fields + +You can search for users using the following: + +- All the [normalized user profile fields](/users/normalized/auth0/normalized-user-profile-schema) +- The profile information under the **user_metadata** object: + - name + - nickname + - given_name + - family_name + +--- + +:::panel What else do I have to do? +You are responsible for ensuring customer is erased or data is updated in any other databases that Auth0 is not connected to. +::: diff --git a/articles/compliance/gdpr/features-aiding-compliance/user-consent/_redirect.md b/articles/compliance/gdpr/features-aiding-compliance/user-consent/_redirect.md new file mode 100644 index 0000000000..00e39c917a --- /dev/null +++ b/articles/compliance/gdpr/features-aiding-compliance/user-consent/_redirect.md @@ -0,0 +1,56 @@ +For simplicity, we will use [this sample consent form](https://github.com/auth0/rules/blob/master/redirect-rules/simple/webtask.js#L31). + +You will need to host this form, and the URL for the form must be publicly-accessible. You'll need to provide the URL where the form can be accessed to Auth0 at a later step of this tutorial. + +1. Add the [redirect rule](/rules/redirect). Go to [Dashboard > Rules](${manage_url}/#/rules), and click **Create Rule**. At **Rules Templates**, select **empty rule**. Change the default rule's name from `empty rule` to something descriptive (e.g., `Redirect to consent form`). + +2. Add the following JavaScript code to the script editor, and **Save** your changes. + + ```js + function redirectToConsentForm (user, context, callback) { + var consentGiven = user.user_metadata && user.user_metadata.consentGiven; + + // redirect to consent form if user has not yet consented + if (!consentGiven && context.protocol !== 'redirect-callback') { + var auth0Domain = auth0.baseUrl.match(/([^:]*:\/\/)?([^\/]+\.[^\/]+)/)[2]; + + context.redirect = { + url: configuration.CONSENT_FORM_URL + + (configuration.CONSENT_FORM_URL.indexOf('?') === -1 ? '?' : '&') + + 'auth0_domain=' + encodeURIComponent(auth0Domain) + }; + } + + // if user clicks 'I agree' on the consent form, save it to their profile so they don't get prompted again + if (context.protocol === 'redirect-callback') { + if (context.request.body.confirm === 'yes') { + user.user_metadata = user.user_metadata || {}; + user.user_metadata.consentGiven = true; + user.user_metadata.consentTimestamp = Date.now(); + + auth0.users.updateUserMetadata(user.user_id, user.user_metadata) + .then(function(){ + callback(null, user, context); + }) + .catch(function(err){ + callback(err); + }); + } else { + callback(new UnauthorizedError('User did not consent!')); + } + } + + callback(null, user, context); + } + ``` + +3. Return to [Dashboard > Rules](${manage_url}/#/rules) and scroll down to the bottom of the page where the **Settings** section is. Create a key/value pair as follows: + + - **Key**: `CONSENT_FORM_URL` + - **Value**: `your-consent-form-url.com` + +Be sure to provide the publicly-accessible URL where your consent form can be found. + +::: warning +When setting up redirection to your consent form for use in a Production environment, be sure to review [Trusted Callback URLs](https://github.com/auth0/rules/tree/master/redirect-rules/simple#trusted-callback-urls) and [Data Integrity](https://github.com/auth0/rules/tree/master/redirect-rules/simple#data-integrity) regarding security concerns. +::: \ No newline at end of file diff --git a/articles/compliance/gdpr/features-aiding-compliance/user-consent/index.md b/articles/compliance/gdpr/features-aiding-compliance/user-consent/index.md new file mode 100644 index 0000000000..32129280ed --- /dev/null +++ b/articles/compliance/gdpr/features-aiding-compliance/user-consent/index.md @@ -0,0 +1,356 @@ +--- +title: "GDPR: Conditions for Consent" +description: This article discusses which Auth0 features can help customers comply with the Conditions for Consent GDPR requirements +toc: true +topics: + - compliance + - gdpr +contentType: + - index + - how-to +useCase: compliance +--- +# GDPR: Conditions for Consent + +According to Article 7 of GDPR, you must ask users to consent on the processing of their personal data in a clear and easily accessible form. You must also show that the user has consented, and provide an easy way to withdraw consent at any time. + +This article explains how you can use Auth0 features to implement these requirements. + +<%= include('../_legal-warning.md') %> + +## Ask for consent + +Upon signup you have to ask your users for consent. With Auth0, you can save this information at the [user metadata](/users/concepts/overview-user-metadata). There are several available options here, depending on how you use Auth0 to authenticate your users. + +::: note +Before you design your solution using metadata make sure you are aware of the restrictions. Auth0 limits the total size of the `user_metadata` to **16 MB**. For more details review the [metadata size limits](/best-practices/metadata-best-practices#metadata-storage-and-size-limits). +::: + +### Use Lock + +You can customize the Lock UI to display links to your terms and conditions and/or privacy statement pages, and a consent checkbox that the user has to check in order to sign up. This can be done with the [mustAcceptTerms Lock option](/libraries/lock/configuration#mustacceptterms-boolean-). This property, when set to `true`, displays a checkbox alongside the terms and conditions that must be checked before signing up. The terms and conditions can be specified using the [languageDictionary option](/libraries/lock/configuration#languagedictionary-object-). Once the user accepts and signs up, save the consent information at the `user_metadata` using a [rule](/rules) that will run upon first login. + +If you want to get more information from the users during signup, and you authenticate users with a database connection, you can add custom fields to the Lock UI. This can be done with the [additionalSignUpFields Lock option](/libraries/lock/configuration#additionalsignupfields-array-). Any custom fields are automatically added to the `user_metadata`. + +If you are using social logins, adding custom fields is not an option, but you can redirect the user to another page where you ask for consent and any additional info, and then redirect back to finish the authentication transaction. This can be done with [redirect rules](/rules/redirect). Once the signup process is complete, save the consent information at the `user_metadata` by calling the [Management API's Update User endpoint](/api/management/v2#!/Users/patch_users_by_id). + +:::note +For a tutorial on how to implement any of these scenarios, see the [Track Consent with Lock](/compliance/gdpr/features-aiding-compliance/user-consent/track-consent-with-lock). +::: + +### Use your custom UI + +If you use a custom signup form with a database connection, you have to add an extra field to the signup screen in order to capture the user's consent. Afterwards, call the [Authentication API's Signup endpoint](/api/authentication#signup) in order to create the user in Auth0. At this point, you can set the consent information as part of the `user_metadata`. + +Alternatively, if you use Auth0.js from an SPA, you can use [the signup method](/libraries/auth0js#sign-up) in order to create the user in Auth0 and set the consent info as part of the `user_metadata`. + +If you use a custom signup form with social providers, you cannot set the user's consent information upon signup but you can update it as soon as the user is created. Save the consent information at the `user_metadata` by calling the [Management API's Update User endpoint](/api/management/v2#!/Users/patch_users_by_id). + +:::note +For a tutorial on how to implement any of these scenarios, see the [Track Consent with Custom UI](/compliance/gdpr/features-aiding-compliance/user-consent/track-consent-with-custom-ui). +::: + +### Re-consent and user migration + +If you need to ask for consent from existing users and you decide to migrate your users from an existing database to Auth0, you can use our [Automatic User Migration](/users/guides/configure-automatic-migration) feature. By activating this, each time a user logs in for the first time (since this was activated), they will be created in Auth0 without having to reset their password. + +Note that every time your Terms and Conditions change, you **must** ask the users for consent again. + +:::panel What else do I have to do? +- You must write up the notification users will see around how users' data is being used, how long data will be used, users' rights, etc. as well as customize the UI sign-up box +- You must determine if re-consent is required for your users, depending on your old terms and conditions and previous privacy certifications +::: + +## Track consent + +According to GDPR, you should be able to show that the user has consented to the processing of their personal data. + +With Auth0 you can save the user's consent information as part of the `user_metadata`. You can either save only a flag, showing if the user has consented or not, or a set of consent information and preferences (including for example, the day the user provided consent, the terms he consented to, etc). Afterwards, you can access and manipulate this information using our Management API. + +:::note +To access the Management API you will need an Access Token. For information on how to get one, refer to the [Access Tokens for the Management API](/api/management/v2/tokens). +::: + +The Management API offers several options when it comes to user search and endpoints to update `user_metadata` or batch export users. + +### Search for a user using their email address + +To search for a user using their email address, use [the Search user by email endpoint](/best-practices/search-best-practices#users-by-email). + +Set the **fields** request parameter to `user_metadata` in order to limit the fields returned. This way, only the user_metadata will be returned instead of the complete user profile. + +Sample request: + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/api/v2/users-by-email", + "httpVersion": "HTTP/1.1", + "headers": [{ + "name": "Authorization", + "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN" + }], + "queryString": [ + { + "name": "email", + "value": "USER_EMAIL_ADDRESS" + }, + { + "name": "fields", + "value": "user_metadata" + } + ] +} +``` + +Sample response: + +```json +[ + {}, + { + "user_metadata": { + "consent": { + "given": true, + "date": "01/23/2018", + "text_details": "some-url" + } + } + } +] +``` + +### Search for a user using their ID + +To search for a user using their ID, use [the Get a user endpoint](/best-practices/search-best-practices#users-by-id). + +Set the **fields** request parameter to `user_metadata` in order to limit the fields returned. This way, only the `user_metadata` will be returned instead of the complete user profile. + +Sample request: + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/api/v2/users/YOUR_USER_ID", + "httpVersion": "HTTP/1.1", + "headers": [{ + "name": "Authorization", + "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN" + }], + "queryString": [ + { + "name": "fields", + "value": "user_metadata" + } + ] +} +``` + +Sample response: + +```json +{ + "user_metadata": { + "consent": { + "given": true, + "date": "01/23/2018", + "text_details": "some-url" + } + } +} +``` + +### Update consent information + +To update a user's `user_metadata`, use [the Update a user endpoint](/api/management/v2#!/Users/patch_users_by_id). + +How you structure your request depends on how you have structured your metadata: as root or as inner properties. + +If your metadata are stored as root properties: + +```json +{ + "consentGiven": true, + "consentDetails": "some-url" +} +``` + +If your metadata are stored as inner properties: + +```json +{ + "consent": { + "given": true, + "text_details": "some-url" + } +} +``` + +#### Update a root property + +Updates to root-level properties are merged, so you only need to send the value for the field you want to update. For example, let's say we want to add a consent date and set it to `01/23/2018`. + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/users/USER_ID", + "httpVersion": "HTTP/1.1", + "headers": [{ + "name": "Authorization", + "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN" + }, + { + "name": "content-type", + "value": "application/json" + }], + "postData" : { + "mimeType": "application/json", + "text": "{\"user_metadata\":{\"consentDate\":\"01/24/2018\"}}" + } +} +``` + +This will add a new property to the user profile, the **user_metadata.consentDate**, which will hold the date the customer consented. The response will be the full user profile. The updated metadata will look like this: + +```json +{ + "consentGiven": true, + "consentDate": "01/23/2018", + "consentDetails": "some-url" +} +``` + +#### Update an inner property + +To update an inner property, you must send the whole metadata object, even if you are not updating more than one property. **If you do not include the entire object, Auth0 will remove your existing properties**. + +Let's add an inner property for the consent date and set it to `01/23/2018`. + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/users/USER_ID", + "httpVersion": "HTTP/1.1", + "headers": [{ + "name": "Authorization", + "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN" + }, + { + "name": "content-type", + "value": "application/json" + }], + "postData" : { + "mimeType": "application/json", + "text": "{\"user_metadata\":{\"consent\": {\"given\":true, \"date\":\"01/23/2018\", \"text_details\":\"some-url\"}}}" + } +} +``` + +This will add a new property to the user profile, the **user_metadata.consent.date**, which will hold the date the customer consented. The response will be the full user profile. The updated metadata will look like this: + +```json +{ + "consent": { + "given": true, + "date": "01/23/2018", + "text_details": "some-url" + } +} +``` + +### Export consent information + +To export a list of your users using the Management API, use [the User export endpoint](/best-practices/search-best-practices#user-export). + +This endpoint creates a job that exports all users associated with a connection. You will need the ID of the connection. To find this ID, use [the Get Connections endpoint](/api/management/v2#!/Connections/get_connections) (you can set the **name** parameter to the name of the connection to retrieve only this one). + +Once you have the connection ID and a [Access Token for the Management API](/api/management/v2/tokens), you are ready to start exporting users. For a sample request and response see [User Export](/best-practices/search-best-practices#user-export). + +:::panel What else do I have to do? +- Determine how you want to track consent. We recommend including information on not just the date the user consented, but the version of terms and conditions to which the user agreed. We also recommend including an array to hold information about users that withdraw their permission (remember that the user can consent and withdraw multiple times) +- Choose where you want to store consent: in Auth0's database or elsewhere +::: + +## Withdraw consent + +The user should have the option to withdraw consent using your app. This option should be easily accessible, and clearly distinguishable. Once the users decides to withdraw their consent, you should take action. + +First, you have to decide how you will handle withdrawal of consent: will you delete the users or flag them as deleted? + +### Delete user + +To delete a user, use the [Delete a user endpoint](/api/management/v2#!/Users/delete_users_by_id). + +```har +{ + "method": "DELETE", + "url": "https://${account.namespace}/api/v2/users/USER_ID", + "httpVersion": "HTTP/1.1", + "headers": [{ + "name": "Authorization", + "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN" + }] +} +``` + +The response body for this endpoint is empty, so if you want to confirm that the user was successfully deleted try to [retrieve the user using their email](/best-practices/search-best-practices#users-by-email). If the endpoint returns an error, then your call to delete the user was successful. + +### Flag user as deleted + +If you don't want to delete the user, flag their profile as deleted using the `app_metadata` (endpoint: [Update a user](/api/management/v2#!/Users/patch_users_by_id)). Then, add some code that will make the authentication process to fail for any user with their profile flagged as such. + +This allows you to keep a record of deleted users for future use. + +#### Step 1: Flag the profile + +To flag a user as deleted use the [app_metadata](users/concepts/overview-user-metadata). In the following example, we will show you how to add a property called **deleted** to the **app_metadata** field. This allows you to configure the authentication process to treat all uses with this property set to true as deleted. + +To update a user's metadata, use the [Update a user endpoint](/api/management/v2#!/Users/patch_users_by_id). + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/users/USER_ID", + "httpVersion": "HTTP/1.1", + "headers": [{ + "name": "Authorization", + "value": "Bearer YOUR_MGMT_API_ACCESS_TOKEN" + }, + { + "name": "content-type", + "value": "application/json" + }], + "postData" : { + "mimeType": "application/json", + "text": "{\"app_metadata\":{\"deleted\":true}}" + } +} +``` + +#### Step 2: Disable login for flagged users + +Next, we must disable login for users flagged as deleted. To do so, we will add a [rule](/rules) (that is, a JavaScript snippet that will run as part of the authentication pipeline). + +Go to [Dashboard > Rules](${manage_url}/#/rules) and create a new rule. Copy the script you see below. + +```js +function (user, context, callback) { + user.app_metadata = user.app_metadata || {}; + if (user.app_metadata.deleted){ + return callback(new UnauthorizedError('Access denied (deleted user)')); + } + callback(null, user, context); +} +``` + +The script: + +- Checks the value of the **deleted** metadata property (`user.app_metadata.deleted`) +- Returns an `Access denied (deleted user)` error to your app if `user.app_metadata.deleted = true` + +Give a name to your rule and save your changes. + +:::panel What else do I have to do? +- Ensure the consent withdrawal piece is granular enough +- Configure into the app the area where customers will withdraw consent +::: diff --git a/articles/compliance/gdpr/features-aiding-compliance/user-consent/track-consent-with-custom-ui.md b/articles/compliance/gdpr/features-aiding-compliance/user-consent/track-consent-with-custom-ui.md new file mode 100644 index 0000000000..42ec9fb97e --- /dev/null +++ b/articles/compliance/gdpr/features-aiding-compliance/user-consent/track-consent-with-custom-ui.md @@ -0,0 +1,191 @@ +--- +title: "GDPR: Track consent with your custom UI" +description: This tutorial describes how you can use either auth0.js or the Auth0 APIs to capture consent information when you use your own custom UI for logins +toc: true +topics: + - compliance + - gdpr +contentType: tutorial +useCase: compliance +--- +# Track Consent with Custom UI + +In this tutorial we will see how you can use auth0.js or the Auth0 APIs to ask for consent information and save the input at the user's [metadata](/users/concepts/overview-user-metadata). + +<%= include('../_legal-warning.md') %> + +## Overview + +We will capture consent information, under various scenarios, and save this in the user's metadata. + +All scenarios will save the following properties in the user's metadata: +- `consentGiven` (true/false) shows if the user has provided consent (true) or not (false) +- `consentTimestamp` (Unix timestamp) indicates when the user provided consent + +For example: + +```text +{ + "consentGiven": "true" + "consentTimestamp": "1525101183" +} +``` + +We will see four different implementations for this: + +1. one that displays a flag, works for database connections, and uses the [auth0.js](/libraries/auth0js) library to create the user (used by Single-Page Applications) +1. one that displays a flag, works for database connections, and uses the [Authentication API](/api/authentication#signup) to create the user (used by Regular Web Apps) +1. one that displays a flag, works for social connections, and uses the [Management API](/api/management/v2) to update the user's information (used either by SPAs or Regular Web Apps) +1. one that redirects to another page where the Terms & Conditions and/or privacy policy information can be reviewed and consent info can be provided (used either by SPAs or Regular Web Apps) + +## Option 1: Use auth0.js + +In this section, we will use a simple Single-Page Application and customize the login widget to add a flag which users can use to provide consent information. Instead of building an app from scratch, we will use [Auth0's JavaScript Quickstart sample](/quickstart/spa/vanillajs). We will also use [Auth0's Universal Login Page](/universal-login) so we can implement a [Universal Login experience](/guides/login/centralized-vs-embedded), instead of embedding the login in our app. + +This works **only** for database connections (we will use Auth0's infrastructure, instead of setting up our own database). + +1. Go to [Dashboard > Applications](${manage_url}/#/applications) and create a new [application](/applications). Choose `Single Web Page Applications` as type. Go to **Settings** and set the **Allowed Callback URLs** to `http://localhost:3000`. + + :::note + This field holds the set of URLs to which Auth0 is allowed to redirect the users after they authenticate. Our sample app will run at `http://localhost:3000` hence we set this value. + ::: + +1. Copy the **Client Id** and **Domain** values. You will need them in a while. + +1. Go to [Dashboard > Connections > Database](https://manage.auth0.com/#/connections/database) and create a new connection. Click **Create DB Connection**, set a name for the new connection, and click **Save**. Go to the connection's **Applications** tab and make sure your newly created application is enabled. + +1. Download the [JavaScript SPA Sample](/quickstart/spa/vanillajs). + +1. [Set the Client ID and Domain](https://github.com/auth0-samples/auth0-javascript-samples/tree/master/01-Login#set-the-client-id-and-domain) values. + +1. Go to [Dashboard > Universal Login](${manage_url}/#/login_settings). At the **Login** tab enable the toggle. + +1. At the **Default Templates** dropdown make sure that `Custom Login Form` is picked. The code is prepopulated for you. + +1. Set the value of the `databaseConnection` variable to the name of the database connection your app is using. + + ```js + //code reducted for simplicity + var databaseConnection = 'test-db'; + //code reducted for simplicity + ``` + +1. To add a field for the `consentGiven` metadata, add a checkbox at the form. For our example, we will configure the checkbox as checked by default and disabled so the user cannot uncheck it. You can adjust this according to your business needs. + + ```js + //code reducted for simplicity +
      + + +
      + //code reducted for simplicity + ``` + +1. Edit the signup function to set the metadata. Note that we set the value of the metadata to a string with the value `true` and not to a boolean value, and we are using `toString` to convert the number to a string. This is due to a restriction of the [Authentication API Signup endpoint](/api/authentication#signup) which only accepts strings as values. + + ```js + //code reducted for simplicity + webAuth.redirect.signupAndLogin({ + connection: databaseConnection, + email: email, + password: password, + user_metadata: { consentGiven: 'true', consentTimestamp: Date.now().toString() } + }, function(err) { + if (err) displayError(err); + }); + //code reducted for simplicity + ``` + +1. To see what the login widget will look like, click the **Preview** tab. + + ![Preview custom form with auth0.js](/media/articles/compliance/auth0js-db-consent-flag.png) + +1. To test this configuration run the application and go to [http://localhost:3000](http://localhost:3000). Sign up with a new user. Then go to [Dashboard > Users](${manage_url}/#/users) and search for your new user. Go to **User Details** and scroll down to the **Metadata** section. At the **user_metadata** text area you should see the `consentGiven` metadata set to `true`. + +## Option 2: Use the API (Database) + +If you serve your login page from your own server, then you can call the [Authentication API Signup endpoint](/api/authentication#signup) directly once the user signs up. + +For the same scenario we have been discussing so far, once you sign up a new user, you can use the following snippet to create the user at Auth0 and set the metadata. Remember to replace the value of the `consentTimestamp` request parameter with the timestamp of when the user provided consent. + +```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\": \"YOUR_USER_EMAIL\",\"password\": \"YOUR_USER_PASSWORD\",\"user_metadata\": {\"consentGiven\": \"true\", \"consentTimestamp\": \"1525101183\" }}" + } +} +``` + +Note that we set the value of the metadata to a string with the value `true` and not to a boolean value due to the API restriction that accepts strings as values, not booleans. + +If setting boolean values is a requirement for you, you can use the Management API instead. In this scenario you sign up your user as usual, and then you call the [Update User endpoint of the Management API](/api/management/v2#!/Users/patch_users_by_id) to set the required metadata after the user has been created. For details on how to do that keep reading, the next paragraph uses that endpoint. + +## Option 3: Use the API (Social) + +If you use social connections, then you cannot use the Authentication API to create the user at Auth0, since that endpoint works only for database connections. + +What you have to do instead is let your user sign up with the social provider (which will create a user record at Auth0) and then use the [Management API](/api/management/v2) to update the user's information. + +Before you call the Management API you need to get a valid token. For details see [Get Access Tokens for Production](/api/management/v2/get-access-tokens-for-production). + +:::panel Get a token from an SPA +The linked article uses the [Client Credentials Flow](/flows/concepts/client-credentials) to get a token, which you cannot use from an app running on the browser. What you can use instead is the [Implicit Flow](/flows/concepts/implicit). Set the **audience** request parameter to `https://${account.namespace}/api/v2/` and the **scope** parameter to the scope `create:current_user_metadata`. You can use the Access Token you will get at the response to call the [Update User endpoint of the Management API](/api/management/v2#!/Users/patch_users_by_id). +::: + +Once you have a valid token, use the following snippet to update the user's metadata. + +```har +{ + "method": "POST", + "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\": {\"consentGiven\":true, \"consentTimestamp\": \"1525101183\"}}" + }, + "headersSize": -1, + "bodySize": -1, + "comment": "" +} +``` + +Note that in order to make this call you need to know the unique `user_id`. You can retrieve this from the `sub` claim of the [ID Token](/tokens/concepts/id-tokens), if you got one from the response. Alternatively, if all you have is the email, you can retrieve the Id by calling another endpoint of the Management API. For more information see [Search Users by Email](/best-practices/search-best-practices#users-by-email). + +## Option 4: Redirect to another page + +If you want to display more information to your user, then upon signup you can redirect to another page where you ask for consent and any additional info, and then redirect back to finish the authentication transaction. This can be done with [redirect rules](/rules/redirect). That same rule can be used to save the consent information at the user's metadata so you can track this information and not ask for consent upon next login. + +<%= include('./_redirect.md') %> + +To test this configuration: + +1. Run the application and go to [http://localhost:3000](http://localhost:3000). +2. Sign up with a new user. You will be redirected to the consent form. +3. Check the **I agree** flag, and click **Submit**. +4. Go to [Dashboard > Users](${manage_url}/#/users), and search for your new user. +5. Go to **User Details**, and scroll down to the **Metadata** section. +6. At the **user_metadata** text area, you should see the `consentGiven` metadata set to `true` and the `consentTimestamp` set to the Unix timestamp of the moment the user consented. + +![Application Sign Up widget](/media/articles/compliance/lock-consent-form-agree.png) + +That's it, you are done! diff --git a/articles/compliance/gdpr/features-aiding-compliance/user-consent/track-consent-with-lock.md b/articles/compliance/gdpr/features-aiding-compliance/user-consent/track-consent-with-lock.md new file mode 100644 index 0000000000..713dd25c9c --- /dev/null +++ b/articles/compliance/gdpr/features-aiding-compliance/user-consent/track-consent-with-lock.md @@ -0,0 +1,210 @@ +--- +title: "GDPR: Track Consent with Lock" +description: This tutorial describes how you can customize Lock to capture consent information +toc: true +topics: + - compliance + - gdpr +contentType: tutorial +useCase: compliance +--- +# Track Consent with Lock + +In this tutorial we will see how you can use Lock to ask for consent information, and then save this input at the user's [metadata](/users/concepts/overview-user-metadata). + +<%= include('../_legal-warning.md') %> + +## Overview + +We will configure a simple JavaScript Single-Page Application and a database connection (we will use Auth0's infrastructure, instead of setting up our own database). + +Instead of building an app from scratch, we will use [Auth0's JavaScript Quickstart sample](/quickstart/spa/vanillajs). We will also use [Auth0's Universal Login Page](/universal-login) so we can implement a [Universal Login experience](/guides/login/centralized-vs-embedded), instead of embedding the login in our app. + +We will capture consent information, under various scenarios, and save this at the user's metadata. + +All scenarios will save the following properties at the [user's metadata](/users/concepts/overview-user-metadata): +- a `consentGiven` property, with true/false values, shows if the user has provided consent (true) or not (false) +- a `consentTimestamp` property, holding the Unix timestamp of when the user provided consent + +For example: + +```text +{ + "consentGiven": "true" + "consentTimestamp": "1525101183" +} +``` + +We will see three different implementations for this: +- one that displays links to other pages where the Terms & Conditions and/or privacy policy information can be reviewed +- one that adds custom fields at the signup widget and works for database connections +- one that redirects to another page where the user can provide consent, and works for social connections + +## Configure the application + +1. Go to [Dashboard > Applications](${manage_url}/#/applications) and create a new [application](/applications). Choose `Single Web Page Applications` as type. + +1. Go to **Settings** and set the **Allowed Callback URLs** to `http://localhost:3000`. + + :::note + This field holds the set of URLs to which Auth0 is allowed to redirect the users after they authenticate. Our sample app will run at `http://localhost:3000` hence we set this value. + ::: + +1. Copy the **Client Id** and **Domain** values. You will need them in a while. + +1. Go to [Dashboard > Connections > Database](${manage_url}/#/connections/database) and create a new connection. Click **Create DB Connection**, set a name for the new connection, and click **Save**. You can also [enable a social connection](/connections/identity-providers-social) at [Dashboard > Connections > Social](${manage_url}/#/connections/social) (we will [enable Google login](/connections/social/google) for the purposes of this tutorial). + +1. Go to the connection's **Applications** tab and make sure your newly created application is enabled. + +1. Download the [JavaScript SPA Sample](/quickstart/spa/vanillajs). + +1. [Set the Client ID and Domain](https://github.com/auth0-samples/auth0-javascript-samples/tree/master/01-Login#set-the-client-id-and-domain) values. + +## Option 1: Display Terms & Conditions link + +In this section, we will customize the login widget to add a flag which users must check in order to sign up. The flag's label will include links to pages that display the Terms & Conditions and privacy policy. + +This works both for database connections and social logins. + +1. Go to [Dashboard > Hosted Pages](${manage_url}/#/login_page). At the **Login** tab enable the toggle. + +1. At the **Default Templates** dropdown make sure that `Lock` is picked. The code is prepopulated for you. + +1. To add a field for the `consentGiven` metadata, use the [mustAcceptTerms](/libraries/lock/configuration#mustacceptterms-boolean-) option. To include links to your Terms & Conditions and/or privacy policy pages, use the [languageDictionary](/libraries/lock/configuration#languagedictionary-object-) option. The example below, displays next to the flag the text `I agree to the terms of service and privacy policy` (including links to both pages). + + ```js + //code reducted for simplicity + var lock = new Auth0Lock(config.clientID, config.auth0Domain, { + auth: { + //code reducted for simplicity + }, + languageDictionary: { + signUpTerms: "I agree to the terms of service and privacy policy." + }, + mustAcceptTerms: true, + //code reducted for simplicity + }); + ``` + +1. To see what this will look like, click the **Preview** tab, and when Lock loads select the **Sign Up** tab. + + ![Preview Lock with Terms & Conditions flag](/media/articles/compliance/lock-db-consent-flag-TC.png) + +1. This flag does not allow users to sign up unless they accept the terms, however it does not set any metadata. To save this information at the `consentGiven` metadata property, add a [rule](/rules). Go to [Dashboard > Rules](${manage_url}/#/rules) and click **Create Rule**. At the **Rules Templates** select **empty rule**. Change the default rule's name (`empty rule`) to something descriptive, for example `Set consent flag upon signup`. + +1. Add the following JavaScript code and save your changes. The code sets the `consentGiven` metadata to `true`, if it is not already set (which means it's the first login after a signup). + + ```js + function (user, context, callback) { + user.user_metadata = user.user_metadata || {}; + // short-circuit if the user signed up already + if (user.user_metadata.consentGiven) return callback(null, user, context); + + // first time login/signup + user.user_metadata.consentGiven = true; + user.user_metadata.consentTimestamp = Date.now(); + auth0.users.updateUserMetadata(user.user_id, user.user_metadata) + .then(function(){ + callback(null, user, context); + }) + .catch(function(err){ + callback(err); + }); + } + ``` + +## Option 2: Add custom fields for database connections + +In this section, we will customize the login widget to add a flag which users will check if they agree to the processing of their information. + +This works only for database connections (if you use social logins, see the next paragraph). + +1. Go to [Dashboard > Hosted Pages](${manage_url}/#/login_page). At the **Login** tab enable the toggle. + +1. At the **Default Templates** dropdown make sure that `Lock` is picked. The code is prepopulated for you. + +1. To add a field for the `consentGiven` metadata, use the [additionalSignUpFields](/libraries/lock/configuration#additionalsignupfields-array-) option. The example below, sets the type to `checkbox` (so we have a flag), the label to `I consent to data processing`, and the default value to checked. + + ```js + //code reducted for simplicity + var lock = new Auth0Lock(config.clientID, config.auth0Domain, { + auth: { + //code reducted for simplicity + }, + additionalSignUpFields: [{ + type: "checkbox", + name: "consentGiven", + prefill: "true", + placeholder: "I consent to data processing" + }], + //code reducted for simplicity + }); + ``` + +1. To see what this will look like, click the **Preview** tab, and when Lock loads select the **Sign Up** tab. + + ![Preview Lock with consent flag](/media/articles/compliance/lock-db-consent-flag.png) + +Note that in this option we only set the flag and not the timestamp. Displaying the current time in the login widget is not optimal, that's why we didn't add an additional signup field. What you should do is set the timestamp in the background, with a rule that will check the value of `consentGiven` and set the additional `consentTimestamp` metadata to the current timestamp. + +## Option 3: Redirect to another page + +If you are using social logins, adding custom fields is not an option, but you can redirect the user to another page where you ask for consent and any additional info, and then redirect back to finish the authentication transaction. This can be done with [redirect rules](/rules/redirect). We will use that same rule to save the consent information at the user's metadata so we can track this information and not ask for consent upon next login. + +<%= include('./_redirect.md') %> + +<%= include('../../../../_includes/_parental-consent') %> + +We are done with the configuration part, let's test! + +## Test the configuration + +1. Go to the folder where you downloaded the application and run it. + + ```bash + npm install + npm run + ``` + +1. Go to [http://localhost:3000](http://localhost:3000). Click **Login**. Once Lock is displayed, click **Sign Up**. + + :::note + The login page will be served by default at `${account.namespace}/login`. If you want to use your own domain, see [Custom Domains](/custom-domains). + ::: + +1. If you followed the [first implementation option](#option-1-display-terms-conditions-link), you should see the flag to accept the terms of service and privacy policy. Note that the **Sign up** button remains disabled until you check the flag. Follow the links to check they are working. Set an email and password and accept the terms and click **Sign Up**. Alternatively, if you use a social connection, accept the terms and choose **Sign Up with Google**. + + ![Application Sign Up widget](/media/articles/compliance/lock-signup-new-field-TC.png) + +1. If you followed the [second implementation option](#option-2-add-custom-fields-for-database-connections), you should see the new custom field we added. Set an email and password and leave the `I consent to data processing` flag checked. Click **Sign Up**. + + ![Application Sign Up widget](/media/articles/compliance/lock-signup-new-field.png) + +1. If you followed the [third implementation option](#option-3-redirect-to-another-page), choose **Sign Up with Google**. You will be navigated to the consent form. Check the **I agree** flag and click **Submit**. + + ![Application Sign Up widget](/media/articles/compliance/lock-consent-form-agree.png) + + :::panel User did not consent + If you do not check the **I agree** flag before clicking **Submit**, then you will see a popup error `Unauthorized. Check the console for details.`. At the console you will see this JSON: + ```text + { + error: "unauthorized", + errorDescription: "User did not consent!", + state: "q0GjMwzZN_q5r8XPHvfakkMYcYM2q1N3" + } + ``` + Note, that the user is created but they won't be able to log in. If they try to, they will be prompted again to provide consent. + ::: + +1. Go to [Dashboard > Users](${manage_url}/#/users) and search for the new user. + +1. Go to **User Details** and scroll down to the **Metadata** section. At the **user_metadata** text area you should see the following: + + ```text + { + "consentGiven": "true" + "consentTimestamp": "1525101183" + } + ``` + +That's it, you are done! diff --git a/articles/compliance/gdpr/features-aiding-compliance/user-consent/webtask-redirect.md b/articles/compliance/gdpr/features-aiding-compliance/user-consent/webtask-redirect.md new file mode 100644 index 0000000000..456054d2ce --- /dev/null +++ b/articles/compliance/gdpr/features-aiding-compliance/user-consent/webtask-redirect.md @@ -0,0 +1,68 @@ +--- +section: compliance +description: Learn how to host a redirect form using Webtask and redirect users to the form. +contentType: how-to +sitemap: false +public: false +--- +# Redirect Users to Consent Form Hosted Using Webtask + +:::warning +Webtask is no longer accepting new signups. We recommend hosting your consent form on another hosting service like Heroku. +::: + +For simplicity, we will use this [sample consent form](https://wt-peter-auth0_com-0.run.webtask.io/simple-redirect-rule-consent-form). This is a form we have hosted for you, but later on we will see how to host your own version of this form (with your own URL). You can find the code at [Auth0 Redirect Rules repo](https://github.com/auth0/rules/blob/master/redirect-rules/simple/webtask.js). + +:::note +If you are implementing this from a regular web app, hosting your own form, then you can also save the consent information at the `user_metadata` using the [Management API's Update User endpoint](/api/management/v2#!/Users/patch_users_by_id). +::: + +1. First, we will add the rule. Go to [Dashboard > Rules](${manage_url}/#/rules) and click **Create Rule**. At the **Rules Templates** select **empty rule**. Change the default rule's name (`empty rule`) to something descriptive, for example `Redirect to consent form`. + +2. Add the following JavaScript code and save your changes. The code redirects the user to the `CONSENT_FORM_URL` URL (we will configure this at the next step). Once the user hits **Submit** at the consent form, the rule runs again as part of the callback. At this point we persist the information at the `user_metadata`. + + ```js + function redirectToConsentForm (user, context, callback) { + var consentGiven = user.user_metadata && user.user_metadata.consentGiven; + // redirect to consent form if user has not yet consented + if (!consentGiven && context.protocol !== 'redirect-callback') { + var auth0Domain = auth0.baseUrl.match(/([^:]*:\/\/)?([^\/]+\.[^\/]+)/)[2]; + context.redirect = { + url: configuration.CONSENT_FORM_URL + + (configuration.CONSENT_FORM_URL.indexOf('?') === -1 ? '?' : '&') + + 'auth0_domain=' + encodeURIComponent(auth0Domain) + }; + } + // if user clicked 'I agree' on the consent form, persist it to their profile + // so they don't get prompted again + if (context.protocol === 'redirect-callback') { + if (context.request.body.confirm === 'yes') { + user.user_metadata = user.user_metadata || {}; + user.user_metadata.consentGiven = true; + user.user_metadata.consentTimestamp = Date.now(); + auth0.users.updateUserMetadata(user.user_id, user.user_metadata) + .then(function(){ + callback(null, user, context); + }) + .catch(function(err){ + callback(err); + }); + } else { + callback(new UnauthorizedError('User did not consent!')); + } + } + callback(null, user, context); + } + ``` + +3. Go back to [Dashboard > Rules](${manage_url}/#/rules), scroll down, and under **Settings**, create a Key/Value pair as follows: + - **Key**: `CONSENT_FORM_URL` + - **Value**: `https://wt-peter-auth0_com-0.run.webtask.io/simple-redirect-rule-consent-form` + +If you want to work with your own implementation of the consent form webtask, you can host your own version of the webtask.js script. For instructions see [Consent Form Setup](https://github.com/auth0/rules/tree/master/redirect-rules/simple#consent-form-setup). + +To learn more about redirect rules, see [Redirect Users from Rules](/rules/redirect). + +:::warning +If you plan on using this approach in a production environment, make sure to review [Trusted Callback URL's](https://github.com/auth0/rules/tree/master/redirect-rules/simple#trusted-callback-urls) and [Data Integrity](https://github.com/auth0/rules/tree/master/redirect-rules/simple#data-integrity) (both sections address some security concerns). +::: diff --git a/articles/compliance/gdpr/gdpr-summary.md b/articles/compliance/gdpr/gdpr-summary.md new file mode 100644 index 0000000000..5c03ed14e2 --- /dev/null +++ b/articles/compliance/gdpr/gdpr-summary.md @@ -0,0 +1,69 @@ +--- +title: General Data Protection Regulation (GDPR) - A Summary +description: A summary of how GDPR affects Auth0, its customers, and the end users +topics: + - compliance + - gdpr +contentType: concept +useCase: compliance +--- +# General Data Protection Regulation (GDPR) - A Summary + +In this article, we summarize the rights and responsibilities of those affected by GDPR, as well as provide a high-level overview of enforcement information. + +## Applicability + +GDPR applies to a wide scope of territory -- it includes non-EU based services/companies that possess data on EU residents. + +## Notifications and Consent + +Before you collect personal data from your end users, you must obtain their consent to do so. When requesting consent, your notifications must: + +* Be clear and easy to understand +* State the purpose of the data involved and how it will be processed + +You must also: + +* Explicitly request consent +* Make it as easy for your end-user to revoke their consent as it is to grant consent + +## Rights of Individuals + +Your end users, as individuals, have the right to: + +* See the data the company has about them +* Know how their data will be processed or used +* Be forgotten (the individual may ask the controller of their data to erase the data in question, cease disseminating the data, or halt further data processing) +* Portability (the individual can ask for their data in a standard, machine-readable format and can transit their data to another data controller) +* *Not* be subjected to automatic decision making (a process typically called **profiling**) + +## Privacy by Design and Privacy by Default + +As the data controller, you must design your app to abide by both privacy by design and privacy by default principles. + +**Privacy by design** means that each new implementation that uses personal data must take the protection of such data into consideration. + +**Privacy by default** means that the strictest privacy settings automatically apply once the end user acquires a new product or service (that is, without any manual change required on the part of the user). + +## Requirements for Data Processors and Controllers + +As the data controller, you must: + +* Do due diligence to ensure that your data processors provide adequate protection of provided data + +Auth0, as the data processor, must: + +* Comply with instructions provided by data controllers +* Maintain adequate documentation +* Implement adequate security +* Conduct data protection impact assessments +* Appoint a data protection officer or establish a privacy office +* Comply with rules on international data transfers +* Agree to and sign a written data processing agreement that meets GDPR requirements + +## Enforcement + +* GDPR mandates that data controllers release notifications regarding data breaches within 72 hours of the incident +* Fines for non-compliance are much higher and are determined using a tiered system +* Supervisory authorities in the European Union have greater investigative powers +* Organizations controlling data must appoint a Data Protection Officer, while organizations processing data should have a Data Privacy Office \ No newline at end of file diff --git a/articles/compliance/gdpr/index.md b/articles/compliance/gdpr/index.md new file mode 100644 index 0000000000..6ebbe9aa63 --- /dev/null +++ b/articles/compliance/gdpr/index.md @@ -0,0 +1,47 @@ +--- +title: Auth0 and General Data Protection Regulation +description: How Auth0 complies with the EU's General Data Protection Regulation (GDPR) +classes: topic-page +topics: + - compliance + - gdpr +contentType: + - index + - concept +useCase: compliance +--- + +
      +
      +

      General Data Protection Regulation

      +

      How GDPR affects you and your Auth0 usage

      +
      + +On 27 April 2016, the European Parliament and the European Council adopted legislation known as [General Data Protection Regulation (GDPR)](http://www.eugdpr.org/), which becomes enforceable **25 May 2018**. This legislation replaces European Privacy Directive 95/46/EC. + +GDPR is intended to unify and strengthen data privacy for individuals located in the European Union (EU). GDPR also extends the applicability of EU data privacy legislation to non-EU companies who store or process data on EU residents and increases the fines that may be levied against companies who are responsible for preventing breaches of personal data or who violate GDPR requirements. + +::: warning +The contents of these documents are not intended to be legal advice, nor should they be considered a substitute for legal assistance. The final responsibility for understanding and complying with GDPR resides with you, though Auth0 will assist you in meeting GDPR requirements where possible. +::: + + diff --git a/articles/compliance/gdpr/roles-responsibilities.md b/articles/compliance/gdpr/roles-responsibilities.md new file mode 100644 index 0000000000..2616a06e12 --- /dev/null +++ b/articles/compliance/gdpr/roles-responsibilities.md @@ -0,0 +1,56 @@ +--- +title: Roles and Responsibilities under GDPR +description: The roles and responsibilities of data controllers and processors under GDPR +topics: + - compliance + - gdpr +contentType: reference +useCase: compliance +--- +# Roles and Responsibilities under GDPR + +This document lists the types of data handled by Auth0, as well as the responsibilities of Auth0 as a data processor vs. the responsibilities of the customer as the data controllers. + +## Roles + +Auth0 customers are **data controllers**. Auth0 is a **data processor**. + +## Personal Data Handled by Auth0 + +Auth0 handles end-user data present in user profiles, including metadata. + +## Data Controller (Customer) Responsibilities + +Ultimately, you, as the data controller, are responsible for GDPR compliance, which mostly consists of operational procedures and documentation. + +More specifically, the customer is responsible for: + +* End-user notification, consent, and withdrawal of consent +* Deciding what data they expose to Auth0 +* Deciding what connections (where end user data and passwords reside) to use +* Signing up and, if necessary, creating new users +* Ensuring their users meet the age requirements and obtaining the appropriate consent if necessary (such as parental consent for children) +* Implementing the mechanisms necessary for their end users to retrieve, review, correct, or remove personal data +* Deleting user data after receiving right-to-be-forgotten requests +* Providing data in standardized formats +* Responding to their end users' privacy-related requests (DSAR) +* Responding to communications from the European Union Data Privacy Authorities +* Data breach notifications sent to supervisory authorities and end users (Auth0 will assist the customer and provide the necessary information if we are involved) +* Selecting an EU tenant when setting up their Auth0 tenants + +The customer is the party that's responsible for the security of their data. Auth0 has no knowledge of how the customer processes data, configures their applications, and so on. + +## Data Processor (Auth0) Responsibilities + +Auth0 is responsible for: + +* Following the data processor's instructions as explicated in the Subscription Agreement (SA) and Data Processing Addendum (DPA) (for enterprise customers) or Terms of Service (for self-service customers) +* Notifying the customer if it receives requests from the customer's end users exercising their GDPR rights as subjects for data access, erasure, and so on +* Notifying the customer if it receives requests from EU Data Privacy Authorities (unless prohibited by law enforcement) +* Notifying the customer if it becomes aware of a confirmed security breach +* Notifying the customer if any of its sub-processors notify Auth0 about a confirmed data breach that impacts Auth0 customer data (unless prohibited by law enforcement) +* Providing a privacy policy, terms of service, security statement, data protection agreement, and so on, to provide info on its policies and practices +* Providing information about its data processing, so that customer has info it needs to process data lawfully +* Defining its services and features, how data is processed, and the rights and obligations of customers +* Providing the means to enable customers to retrieve, review, correct, or delete customer data via the Auth0 Dashboard and the Auth0 Management API +* Providing a mechanism for customers to display consent terms and a consent agreement checkbox on the Lock widget. Customers can also design custom signup and login forms if more elaborate consent schemes are needed diff --git a/articles/compliance/gdpr/security-advice-for-customers.md b/articles/compliance/gdpr/security-advice-for-customers.md new file mode 100644 index 0000000000..686de1a708 --- /dev/null +++ b/articles/compliance/gdpr/security-advice-for-customers.md @@ -0,0 +1,25 @@ +--- +title: Security Advice for Customers +description: How to protect your end users' data +topics: + - compliance + - gdpr +contentType: reference +useCase: compliance +--- +# Security Advice for Customers + +Auth0 recommends the following practices to help ensure the security of your end users data and minimize the probability of a data breach: + +* Protect client secrets and keys +* Protect Management Dashboard credentials, and require multi-factor authentication for access to the Dashboard +* Review the list of administrators for the Dashboard on a regular basis and remove outdated entries +* Review the list of connections and applications associated with your Auth0 tenants and remove outdated entries +* Ensure that Dashboard administrators use corporate credentials that can be easily revoked if necessary, *not* personal credentials such as a personal email account +* Remove accounts for terminated employees promptly +* Ensure that administrators use devices with mandatory screen locking +* Provide regular training to all Dashboard administrators and developers on security and privacy best practices + +::: note +Make sure that you monitor any Auth0 [extensions](/extensions#export-auth0-logs-to-an-external-service) you use to send log data to logging tools with reporting capability. +::: \ No newline at end of file diff --git a/articles/compliance/index.md b/articles/compliance/index.md new file mode 100644 index 0000000000..fc73492640 --- /dev/null +++ b/articles/compliance/index.md @@ -0,0 +1,72 @@ +--- +title: Compliance +description: Information about Auth0 Compliance and Certifications +classes: topic-page +topics: + - compliance + - gdpr +contentType: + - index + - reference +useCase: compliance +--- +
      +
      +

      Compliance Frameworks and Certifications

      +

      + Auth0 maintains and meets the requirements for multiple compliance frameworks and certifications. +

      +

      + To download or request Auth0 compliance documentation, go to Auth0 Support Center: Compliance. +

      +
      + +
        +
      • + GDPR +

        Auth0 is GDPR ready. Auth0 provides information to its customers to help them understand how features and functionality of the Auth0 platform may affect their GDPR compliance obligations.

        + +
        • +
      • + Privacy Shield +

        Auth0 is certified under the Privacy Shield Program, specifically the EU-US Privacy Shield Framework and the Swiss-US Privacy Shield Framework. You can find further details on our Privacy page.

        + +
        • +
      • + HIPAA & HITECH +

        Auth0 is considered a Business Associate as defined by the US HIPAA and HITECH legislation.

        +

        For Auth0 customers who qualify as a Covered Entity under US HIPAA legislation and related legislation and regulations and who provide ePHI (electronic Protected Health Information) to Auth0 as part of the Auth0 user profile, Auth0 may qualify as a business associate. Auth0 can provide its Business Associate Agreement to such customers upon request.

        +
        • +
      • + SOC 2 +

        Auth0 undergoes a SOC 2 Type II audit by an independent auditor annually. This audit covers our product, infrastructure, and policies. The SOC 2 Type II Audit Report is available to enterprise level customers upon request with a non-disclosure agreement (NDA) signed by a corporate officer authorized to represent the company. To request the report, please contact your assigned Technical Account Manager.

        +
        • +
      • + CSA STAR +

        Auth0 is CSA STAR certified. Auth0's CSA Consensus Assessments Initiative Questionnaire (CAIQ) is available in our Support Center. You can also view our CAIQ and STAR Certificate in the CSA STAR Registry.

        +
        • +
      • + ISO 27001/27018 +

        Auth0 undergoes an ISO 27001/27018 audit by an independent auditor annually. Our ISO 27001/27018 certificate is available in our Support Center. We can also share our Statement of Applicability (SOA) upon request with a non-disclosure agreement (NDA) signed by a corporate officer authorized to represent the company. To request the SOA, please contact your assigned Technical Account Manager.

        +
        • +
      • + PCI DSS +

        PCI certification is available as an add-on for Auth0's Private Cloud deployment model. Auth0 undergoes a PCI audit by an independent auditor annually. Our Attestation of Compliance (AOC) is available upon request. To request the AOC, please contact your assigned Technical Account Manager.

        +
        • +
      + +

      Future

      + +

      Auth0 will document additional compliance frameworks and certifications on this page when available.

      + +

      Specifications

      + +

      For information on compliance with technical specifications for authentication, please see Protocols.

      diff --git a/articles/configure/index.md b/articles/configure/index.md new file mode 100644 index 0000000000..c0b668e328 --- /dev/null +++ b/articles/configure/index.md @@ -0,0 +1,21 @@ +--- +classes: topic-page +title: Configuration +description: Learn how to configure tenants, applications, APIs, and other settings in Auth0 +topics: + - configuration +contentType: index +--- +# Configuration + +Learn how to configure tenants, applications, APIs, and other settings in Auth0. + +<%= include('../_includes/_topic-links', { links: [ + 'dashboard/reference/settings-tenant', + 'dashboard/reference/settings-application', + 'dashboard/reference/settings-api', + 'sso/current', + 'anomaly-detection', + 'protocols/saml', + 'guides/ip-whitelist', +] }) %> diff --git a/articles/connections/_call-api.md b/articles/connections/_call-api.md new file mode 100644 index 0000000000..c508d4c916 --- /dev/null +++ b/articles/connections/_call-api.md @@ -0,0 +1,7 @@ +Once a user successfully authenticates, ${idp} will include an Access Token in the user profile it returns to Auth0. You can use this token to call ${idp}'s API. + +To get the ${idp} 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](/connections/calling-an-external-idp-api). + +Using the token, you can call ${idp}'s API following ${idp}'s documentation. + +Optional: Get a [Refresh Token](/tokens/guides/get-refresh-tokens) from ${idp} to refresh your Access Token once it expires. To ensure your application is secure, pay close attention to the [restrictions on using Refresh Tokens](/tokens/concepts/refresh-tokens#restrictions-and-limitations). diff --git a/articles/connections/_connections.html b/articles/connections/_connections.html index 20d7a267f2..0793f2d8f6 100644 --- a/articles/connections/_connections.html +++ b/articles/connections/_connections.html @@ -1,34 +1,24 @@ <% var terminated = false; %> +
      <% var i=0; _.forEach(connections, function(article) { %> <% if (article.connection) { %> - <% if (i === 0) { terminated = false; %> -
      + <% if (article.public !== false) { %> + + <% } else { %> +
      <% } %> -
      -
      -
      - <% if (article.public !== false) { %> -
      - - - -
      -

      <%- article.connection %>

      - <% } else { %> -
      - -
      -

      <%- article.connection %>

      - <% } %> -
      +
      +
      +
      +

      <%- article.connection %>

      - <% i++; if (i === 4) { i=0; terminated = true; %> + <% if (article.public !== false) { %> + + <% } else { %>
      <% } %> <% } %> <% }); %> -<% if (terminated === false) { terminated = true; %> -
      -<% } %> +
      <% connections = []; %> diff --git a/articles/connections/_find-auth0-domain-redirects.md b/articles/connections/_find-auth0-domain-redirects.md new file mode 100644 index 0000000000..0c1fad7485 --- /dev/null +++ b/articles/connections/_find-auth0-domain-redirects.md @@ -0,0 +1,5 @@ +::: 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, 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/articles/connections/_includes/_options-prop-pw-complexity.md b/articles/connections/_includes/_options-prop-pw-complexity.md new file mode 100644 index 0000000000..c3d3a262aa --- /dev/null +++ b/articles/connections/_includes/_options-prop-pw-complexity.md @@ -0,0 +1,5 @@ +Allows you to set password complexity options for this connection. + +Properties include: + +- `min_length` (integer): The minimum character length of a password. NIST recommends a minimum character length of 8, and suggests that length is a better indicator of strength than complexity. Maximum: 128. \ No newline at end of file diff --git a/articles/connections/_includes/_options-prop-pw-dictionary.md b/articles/connections/_includes/_options-prop-pw-dictionary.md new file mode 100644 index 0000000000..091dfd1894 --- /dev/null +++ b/articles/connections/_includes/_options-prop-pw-dictionary.md @@ -0,0 +1,6 @@ +When enabled, the system will disallow passwords that are part of the password dictionary, which includes a list of the [10,000 most common passwords](https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/10k-most-common.txt). You may also customize the dictionary with your own entries. + +Properties include: + +- `enable` (boolean): Whether or not to enable password dictionary. +- `dictionary` (array (string)): Custom entries that you would like to add to the password dictionary for this connection. Each entry may contain a maximum of 50 characters. We use case-insensitive comparison. Maximum: 200. \ No newline at end of file diff --git a/articles/connections/_includes/_options-prop-pw-expiration.md b/articles/connections/_includes/_options-prop-pw-expiration.md new file mode 100644 index 0000000000..99d8a0942a --- /dev/null +++ b/articles/connections/_includes/_options-prop-pw-expiration.md @@ -0,0 +1,7 @@ +When enabled, the system will enforce password expiration for this connection. + +Properties include: + +- `enable` (boolean): Whether or not to enable password expiration. +- `warn_after` (integer): The timeframe (in days) after which the user will be warned that their password will expire. Maximum: 365. Default: 90. +- `expire_after` (integer): The timeframe (in days) after which a password will expire. Maximum: 365. Default: 90. \ No newline at end of file diff --git a/articles/connections/_includes/_options-prop-pw-history.md b/articles/connections/_includes/_options-prop-pw-history.md new file mode 100644 index 0000000000..d3c16a7903 --- /dev/null +++ b/articles/connections/_includes/_options-prop-pw-history.md @@ -0,0 +1,6 @@ +When enabled, the system will maintain a password history for each user and prevent the reuse of passwords included in the history. Any existing users in the connection will be unaffected; the system will maintain their password history going forward. + +Properties include: + +- `enable` (boolean): Whether or not to enable password history tracking. +- `size` (integer): The number of passwords to track. Maximum: 24. \ No newline at end of file diff --git a/articles/connections/_includes/_options-prop-pw-no-pers-info.md b/articles/connections/_includes/_options-prop-pw-no-pers-info.md new file mode 100644 index 0000000000..3d513078be --- /dev/null +++ b/articles/connections/_includes/_options-prop-pw-no-pers-info.md @@ -0,0 +1,5 @@ +When enabled, the system will disallow passwords that contain any part of the user's personal data, including the user's `name`, `username`, `nickname`, `email`, local-part of `email`, `user_metadata.name`, `user_metadata.first`, and `user_metadata.last`. + +Properties include: + +- `enable` (boolean): Whether or not to enable no personal information in passwords. \ No newline at end of file diff --git a/articles/connections/_includes/_options-upstream-params.md b/articles/connections/_includes/_options-upstream-params.md new file mode 100644 index 0000000000..c68e347dd1 --- /dev/null +++ b/articles/connections/_includes/_options-upstream-params.md @@ -0,0 +1,9 @@ +Allows you to pass static provider-specific parameters to an [Identity Provider](/connections) for this connection. Not all Identity Providers support upstream parameters, so you will need to check with the Identity Provider before using this element. + +Properties include: + +- Parameter (object): The name of the parameter accepted by the Identity Provider. Will contain one of the following two properties, depening on how you are using the upstream parameters. + - `alias` (string): The existing accepted OAuth 2.0/OIDC parameter, which maps to the parameter accepted by the Identity Provider. Used when passing dynamic upstream parameters per user. Allowed values include: `acr_values`, `audience`, `client_id`, `display`, `id_token_hint`, `login_hint`, `max_age`, `prompt`, `resource`, `response_mode`, `response_type`, and `ui_locales`. + - `value` (string): The value of the parameter. Used when passing static upstream parameters per connection. + +For more information and examples of how to use upstream parameters, see [Pass Parameters to Identity Providers](/connections/pass-parameters-to-idps). \ No newline at end of file diff --git a/articles/connections/_includes/_options-validation.md b/articles/connections/_includes/_options-validation.md new file mode 100644 index 0000000000..34479ba78b --- /dev/null +++ b/articles/connections/_includes/_options-validation.md @@ -0,0 +1,7 @@ +Allows you to set validation options for this connection. + +Properties include: + +- `username` (object): + - `min` (integer): The minimum length of a user's username. + - `max` (integer): The maximum length of a user's username. diff --git a/articles/connections/_otp-limitations.md b/articles/connections/_otp-limitations.md new file mode 100644 index 0000000000..a7febd28a7 --- /dev/null +++ b/articles/connections/_otp-limitations.md @@ -0,0 +1,4 @@ +* Only the last one-time password (or link) issued will be accepted. Once the latest one is issued, any others are invalidated. Once used, the latest one is also invalidated. +* Only three failed attempts to input the one-time password are allowed. After this, a new code will need to be requested. +* The one-time password issued will be valid (by default) for three minutes before it expires. +* If you choose to extend the amount of time it takes for your one-time password to expire, you should also extend the length of the one-time password code. Otherwise, an attacker has a larger window of time to attempt to guess a short code. diff --git a/articles/connections/_quickstart-links.md b/articles/connections/_quickstart-links.md index e2c2e5d07e..a85112173d 100644 --- a/articles/connections/_quickstart-links.md +++ b/articles/connections/_quickstart-links.md @@ -1,10 +1,9 @@ ## Next Steps -Now that you have a working connection, the next step is to configure your application to use it. You can initiate login using [Lock](/libraries/lock), [Auth0.js](/libraries/auth0js), or the [Authentication API endpoint](/api/authentication#social). - -For detailed instructions and samples for a variety of technologies, refer to our [quickstarts](/quickstarts): -- Quickstarts for [Mobile / Native Apps](/quickstart/native) -- Quickstarts for [Single Page Apps](/quickstart/spa) -- Quickstarts for [Web Apps](/quickstart/webapp) - -For more background information on client authentication refer to [Client Authentication](/client-auth). +::: next-steps +* [Integrate with Auth0 using one of our libraries](/libraries) +* [Integrate with Auth0 using our Authentication API](/api/authentication) +* [Read more about the authentication flow](/application-auth) +* [Pass additional parameters to the Identity Provider](/connections/pass-parameters-to-idps) +* [Re-prompt users for permissions](/connections/social/reprompt-permissions) +::: diff --git a/articles/connections/adding-generic-oauth1-connection.md b/articles/connections/adding-generic-oauth1-connection.md new file mode 100644 index 0000000000..777e5f5471 --- /dev/null +++ b/articles/connections/adding-generic-oauth1-connection.md @@ -0,0 +1,106 @@ +--- +title: Adding a generic OAuth1 Authorization Server to Auth0 +description: How to add a generic Oauth1 Authorization Server to Auth0. +topics: + - connections + - oauth1 +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +# Adding a generic OAuth1 Authorization Server to Auth0 + +The most common [identity providers](/identityproviders) are available on Auth0's [dashboard](${manage_url}). However, you can add any __OAuth1 Authorization Server__ to Auth0 as an identity provider. + +To create an arbitrary __OAuth1__ connection, you use __[Auth0's Connections API](/api/v2#!/Connections/post_connections)__. + +This example would create a custom Twitter connection: + +```bash +curl -X POST + -H "Content-Type: application/json" + -H 'Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN' + -d @twitter.json https://${account.namespace}/api/v2/connections +``` + +:::note +Replace `YOUR_MANAGEMENT_API_TOKEN` with a valid token. For info on how to get one, see [Access Tokens for the Management API](/api/management/v2/tokens). +::: + +```json +{ + "name": "custom-twitter", + "strategy": "oauth1", + "options": { + "client_id": "YOUR_TWITTER_CLIENT_ID", + "client_secret": "YOUR_TWITTER_CLIENT_SECRET", + "requestTokenURL": "https://api.twitter.com/oauth/request_token", + "accessTokenURL": "https://api.twitter.com/oauth/access_token", + "userAuthorizationURL": "https://api.twitter.com/oauth/authenticate", + "scripts": { + "fetchUserProfile": "function (token, tokenSecret, ctx, cb) {var OAuth = new require('oauth').OAuth;var oauth = new OAuth(ctx.requestTokenURL,ctx.accessTokenURL,ctx.client_id,ctx.client_secret,'1.0',null,'HMAC-SHA1');oauth.get('https://api.twitter.com/1.1/users/show.json?user_id=' + ctx.user_id,token,tokenSecret,function(e, b, r) {if (e) return cb(e);if (r.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode));cb(null, JSON.parse(b));});}" + } + } +} +``` + +The key parameters for a connection are: + +* **name**: this is how the connection can be referenced later on in Auth0 or in your app. +* **strategy**: this must be __oauth1__. It defines the protocol implemented by the provider. + +The __options__ object: + +* **client_id** and **client_secret** must be obtained from your provider. +* **requestTokenURL**: `https://api.twitter.com/oauth/request_token` +* **accessTokenURL**: `https://api.twitter.com/oauth/access_token` +* **userAuthorizationURL**: `https://api.twitter.com/oauth/authenticate` +* **fetchUserProfile**: Auth0 allows you to define a custom script that returns a JSON object with user info. What you do in the script is up to you. For convenience, the __[OAuth](https://www.npmjs.com/package/oauth)__ module is included to simplify OAuth1 calls. + +The script will have the following signature: + +```js +function(token, tokenSecret, ctx, callback){ + + var profile = { + user_id: '123', + given_name: 'Eugenio', + family_name: 'Pace', + email: 'eugenio@mail.com' + }; + + callback(null, profile); +} +``` + +The `token` and `tokenSecret` parameters will often be used for authenticating requests to the provider's API. + +::: note +We recommend using the field names in the [normalized profile](/users/normalized). +::: + +Notice that you can manipulate the profile returned from the provider to filter/remove/add anything in it. However, we recommend you keep this script as simple as possible. More sophisticated manipulation of the user information can be achieved through [Rules](/rules). + +::: note +One advantage of using Rules is that they apply to __any__ connection. +::: + +## Using your new connection + +You can use any of the Auth0 standard mechanisms to login a user with the new connection (such as direct links, Auth0 Lock, [auth0.js](auth0js), and so on). + +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=THE_NAME_OF_THE_CONNECTION +``` + +## Keep reading + +::: next-steps +* [Custom OAuth2/OAuth1 Connections samples](/oauth2-examples) +* [Identity Providers in Auth0](/identityproviders) +* [Protocols](/protocols) +* [Custom OAuth2 Connections](/oauth2) +::: diff --git a/articles/connections/adding-scopes-for-an-external-idp.md b/articles/connections/adding-scopes-for-an-external-idp.md new file mode 100644 index 0000000000..2cb42398dc --- /dev/null +++ b/articles/connections/adding-scopes-for-an-external-idp.md @@ -0,0 +1,44 @@ +--- +description: How to add scopes to your IdP connection. +topics: + - connections + - scopes +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +# Add scopes/permissions to call Identity Provider's APIs + +Once user is logged in, you can get the user profile and then the associated `accessToken` to call the Identity Provider APIs as described in: [Call an Identity Provider API](/what-to-do-once-the-user-is-logged-in/calling-an-external-idp-api) + +However, if you are receiving `Access Denied` when calling the IdP API, you probably have not requested the correct permissions for the user during login. + +There are two ways you can use to request the correct permissions. + +## 1. Change Identity Provider Settings + +To configure the scopes/permissions needed from the user, go to [Auth0 Dashboard > Authentication > Social](${manage_url}/#/connections/social), and select an IdP. You can select the required permissions listed on the configuration screen. + +For example, if you click the **Google / Gmail** connection, you can configure Google-specific permissions: + +![Permissions for Google](/media/articles/connections/social/dashboard-connections-social-create_google.png) + +## 2. Pass Scopes to Authorize endpoint + +You can also pass the scopes/permissions you wish to request as a comma-separated list in the `connection_scope` parameter when calling the [authorize endpoint](/api/authentication#login). For example, if you want to request the `https://www.googleapis.com/auth/contacts.readonly` and `https://www.googleapis.com/auth/analytics` scopes from Google, you can pass these along with the `connection` parameter to ensure the user logs in with their Google account: + +```text +https://${account.namespace}/authorize + ?response_type=id_token + &client_id=${account.clientId} + &redirect_uri=${account.callback} + &scope=openid%20profile + &connection=google-oauth2 + &connection_scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fanalytics%2Chttps%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcontacts.readonly + &nonce=abc +``` + +::: note +Please note that in the example request above, the value of the `connection_scope` parameter is URL encoded. The decoded value that is passed to Google is `https://www.googleapis.com/auth/analytics, https://www.googleapis.com/auth/contacts.readonly` +::: diff --git a/articles/connections/apple-siwa/set-up-apple.md b/articles/connections/apple-siwa/set-up-apple.md new file mode 100644 index 0000000000..6a02e428f6 --- /dev/null +++ b/articles/connections/apple-siwa/set-up-apple.md @@ -0,0 +1,81 @@ +--- +title: Register Apps in the Apple Developer Portal +description: Learn how to set up your application with Apple before you set up your Apple connection in the Auth0 Dashboard. +topics: + - authentication + - connections + - social + - apple +contentType: how-to +useCase: + - add-login + - customize-connections + - add-idp +--- +# Register Apps in the Apple Developer Portal + +Before you configure an Apple social connection in the Auth0 Dashboard, you need to set up your application on your Apple Developer account in the Apple Developer Portal. Once that is complete, you can use the assigned credentials you receive from Apple to set up your Apple connection in the Auth0 Dashboard. + +::: note +You can test the Apple connection with Auth0's developer credentials first by navigating to [Auth0 Dashboard > Authentication > Social](${manage_url}/#/connections/social). Locate the **Apple** connection, and select the More Options menu (**...***), then select **Try Connection**. + +Prior to using the connection in production, you must provide your own credentials as shown below. +::: + +After you register your application, you will be given the following IDs and keys to use in the application connection settings in the Dashboard: + +* Services ID (Client ID) +* Apple Team ID +* Client Secret Signing Key +* Key ID + +## Prerequisites + +Before you can register your app in the Apple Developer Portal, you must have an [Apple Developer](https://developer.apple.com/programs/) account, which is a paid account with Apple. (There is no free trial available unless you are part of their [iOS Developer University Program](https://developer.apple.com/support/compare-memberships/).) + +## Obtain Team ID + +1. Sign in to your [Apple Developer Account](https://developer.apple.com/account/#/overview/), and go to the [Membership page](https://developer.apple.com/account/#/membership/): + ![Membership Page](/media/articles/connections/social/apple/apple-membership.png) +2. Make note of your Team ID. + +## Create App ID + +1. On the Apple Developer Portal, go to **Certificates, IDs, & Profiles > Identifiers** and click the **blue plus icon** next to **Identifiers** to create a new App ID. +2. Choose **App IDs** as the identifier type and click **Continue**. +3. Provide a description and a Bundle ID (reverse-domain name style, e.g., `com.example`). +4. Scroll down and check **Sign In with Apple**. +5. Click **Continue**, and then click **Register**. + +## Create Services ID + +1. Return to the **Certificates, IDs, & Profiles** section, and select the **blue plus icon** next to **Identifiers**. + ![Register Services ID](/media/articles/connections/social/apple/apple-registerservicesid.png) +2. Choose **Services IDs**, and select **Continue**. Fill in the description and identifier (`com.example.webapp`). +3. After checking **Sign In with Apple**, select **Configure**, and define your **Web Domain** (`example.com`) and your **Return URL**. Make sure that your Return URL is your Auth0 domain, such as `foo.auth0.com` (or your Auth0 custom domain if you have one) and follows this format: `https://YOUR_AUTH0_DOMAIN/login/callback`. + ![Configure URLs](/media/articles/connections/social/apple/apple-configurls2.png) +4. Click **Save**, **Continue**, and then click **Register**. + +::: note +At this time, Apple does not require validation of the redirect URL, and doing so is typically not necessary. +::: + +### Set up your Client Secret Signing Key + +1. Go to **Keys** under the **Certificates, Identifiers, & Profiles** section of your Apple developer dashboard. +2. Select the **blue plus icon** to add a new key. +3. Enter a **Key Name** and check the **Sign In with Apple** option. +4. Select **Configure** to make sure the **Choose a Primary App ID** field is filled with the correct App ID. +5. Select **Save**, **Continue**, and then **Register**. +6. On the page to which you're redirected after registering, make note of the Key ID. Then download the key; it will have a .p8 extension. + +Next, you will use these credentials on the [Auth0 Dashboard > Authentication > Social](${manage_url}/#/connections/social) page to continue to configure your application. Depending on which type of application you want to configure, choose one of the following methods: + +* [Add Sign In with Apple to Native iOS Apps](/connections/apple-siwa/add-siwa-to-native-app) +* [Add Sign In with Apple to Web or Other Apps](/connections/apple-siwa/add-siwa-to-web-app) + +## Keep reading + +* [iOS Swift - Sign In with Apple Quickstart](/quickstart/native/ios-swift-siwa) +* [Rate Limits on Native Social Logins](/policies/rate-limits#limits-on-native-social-logins) +* [Test Sign In with Apple Configuration](/connections/apple-siwa/test-siwa-connection) diff --git a/articles/connections/apple-siwa/test-siwa-connection.md b/articles/connections/apple-siwa/test-siwa-connection.md new file mode 100644 index 0000000000..61a1a36418 --- /dev/null +++ b/articles/connections/apple-siwa/test-siwa-connection.md @@ -0,0 +1,43 @@ +--- +title: Test Sign In with Apple Configuration +description: Learn how to test the Auth0 Sign In with Apple app configuration. +topics: + - authentication + - connections + - social + - apple +contentType: how-to +useCase: + - add-login + - customize-connections + - add-idp +--- + +# Test Sign In with Apple Configuration + +::: 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. +::: + +1. Go to your application login page, and you should see an option for Sign In with Apple: + + ![Apple Login Page](/media/articles/connections/social/apple/apple-login-page.png) + +2. Select **Continue with Apple**, then enter your Apple ID and password. + +3. You will be asked to verify a new device. Select **Allow**. + +4. Next, you'll be given a verification code. Make a note of this code, select **Done**, and then enter the code on the **Two-Factor Authentication** screen. + + ![Apple Two-Factor Authentication](/media/articles/connections/social/apple/apple-2FA.png) + +5. When this is done, you'll have the option to edit your name and choose whether you'd like to share or hide your email. Make your choice, then select **Continue**. + + ![Apple Email Preferences](/media/articles/connections/social/apple/apple-email-preferences.png) + + You are now signed in to your application with Apple! + +## Keep reading + +* [iOS Swift - Sign In with Apple Quickstart](/quickstart/native/ios-swift-siwa) +* [Rate Limits for Sign In with Apple](/policies/rate-limits#limits-on-sign-in-with-apple) diff --git a/articles/connections/apple-siwa/troubleshooting.md b/articles/connections/apple-siwa/troubleshooting.md new file mode 100644 index 0000000000..ad7234c93b --- /dev/null +++ b/articles/connections/apple-siwa/troubleshooting.md @@ -0,0 +1,57 @@ +--- +title: Troubleshoot Sign in With Apple +description: Describes troubleshooting steps for web and native apps using the Apple connection. +topics: + - troubleshooting + - errors + - authentication + - connections + - social + - apple +contentType: + - reference +useCase: + - troubleshooting +--- + +# Troubleshoot Sign in with Apple + +## Configuration elements + +Ensure that the correct configuration elements are in place, both in the Auth0 Management Dashboard and in the Apple Developer Settings Console. Common configuration problems include: + +- **Using the wrong identifier**: Remember that Apple App IDs (also known as App Bundle Identifiers) need to be [configured in Auth0's advanced application settings](/connections/apple-siwa/add-siwa-to-native-app). Service IDs, which are used to configure web apps, need to be [configured in connection settings](/connections/apple-siwa/add-siwa-to-native-app). Switching these identifiers will result in failures. +- **Missing return URLS for Web Apps**: When using Sign In with Apple for web apps, the Auth0 callback endpoint must be added to the list of Return URLs in the Apple Developer Settings Console. When not using custom domains, this will take the format: `https://TENANT.auth0.com/login/callback`. + +::: warning +Remember that it's not possible to test native apps from the Auth0 Management Dashboard. The **Try Connection** button in the Apple connection only tests the web app flow. This is due to the fact that real devices are required for interaction with the Apple IdP using an App ID. +::: + +## Tenant logs + +If your application successfully initiated the login flow with Auth0, the results will be reflected in the tenant logs. Native social exchanges will use the `sens` and `fens` event types to indicate success and failure (respectively), while web flows will use the standard `s` and `f` event types. All tenant logs interacting with the Apple IdP will use the connection value of `apple`. + +## Types of errors + +The following errors may be returned from the Apple IdP. Auth0 will relay both status codes and error messages from Apple should a request fail. + +| Error | Status Code | Description | +| - | - | - | +| `invalid_request` | 400 | The request parameters were incomplete or incorrect | +| `invalid_grant` | 400 | The authorization code or refresh token presented to the Apple IdP is not valid | +| `invalid_client` | 400 | Apple was unable to successfully authenticate the client with the provided credentials | +| `server_error` | 500 | Other server-side issue inhibiting its ability to issue tokens | + +## Apple nuances +Many identity providers have their own unique idiosyncrasies, and Apple is no exception. When integrating, be mindful of a few of its particular choices in implementation. + +- **Users are Unique Per Apple Development Account**: User identifiers in the Apple world are guaranteed to be both unique and persistent _per Apple Development Account_. If Apple user identifiers are sourced from more than one development account, know that the same user will be represented by different identifiers. +- **Users can Choose Which Email to Share**: When users have multiple email addresses, they may choose which one is shared. Additionally, in the case of re-authentication, users may not pick the same email address. This means that the User ID should be used exclusively as the identifier, and account linking operations should use care. + +## Keep reading +* [Register Apps in the Apple Developer Portal](/connections/apple-siwa/set-up-apple) +* [Add Sign In with Apple to Native iOS Apps](/connections/apple-siwa/add-siwa-to-native-app) +* [Add Sign In with Apple to Web or Other Apps](/connections/apple-siwa/add-siwa-to-web-app) +* [Test Sign In with Apple Configuration](/connections/apple-siwa/test-siwa-connection) +* [iOS Swift - Sign In with Apple Quickstart](/quickstart/native/ios-swift-siwa) +* [Rate Limits on Native Social Logins](/policies/rate-limits#limits-on-native-social-logins) diff --git a/articles/connections/calling-an-external-idp-api.md b/articles/connections/calling-an-external-idp-api.md new file mode 100644 index 0000000000..1aca661cec --- /dev/null +++ b/articles/connections/calling-an-external-idp-api.md @@ -0,0 +1,206 @@ +--- +title: Call an Identity Provider API +description: Learn how to call an external Identity Provider API. +toc: true +crews: crew-2 +topics: + - connections + - social + - access-tokens + - api +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +# Call an Identity Provider API + +Once you successfully authenticate a user with an external Identity Provider (IdP), such as Facebook or GitHub, the IdP often includes an Access Token in the user profile it returns to Auth0. + +You can retrieve and use this token to call the IdP's API. + +::: note +This article assumes that you have already configured the connection with the IdP of your choice. If not, go to [Identity Providers Supported by Auth0](/identityproviders), select the IdP you want, and follow the configuration steps. +::: + +The process you will follow differs depending on whether your code runs in the backend or the frontend: + +- If your code runs in the backend, then we can assume that your server is trusted to safely store secrets (as you will see, we use a secret in the backend scenario). If that's the case, proceed to the [backend section](#from-the-backend) of this article. + +- If your code runs in the frontend (for example, it's a SPA, native desktop, or mobile app), then your app cannot hold credentials securely and has to follow an alternate approach. In this case, proceed to the [frontend section](#from-the-frontend) of this article. + +## From the backend + +Once you authenticate a user, the IdP often includes an Access Token in the user profile it returns to Auth0. + +For security and compliance reasons, Auth0 does not send this token to your app as part of the user profile. To get it, you must access the Auth0 Management API and retrieve the full user's profile: + +1. Get an Access Token that allows you to call the [Auth0 Management API](/api/management/v2). + +2. Call the Auth0 Management API's [Get Users by ID endpoint](/api/management/v2#!/Users/get_users_by_id) using the Access Token obtained in step one. This endpoint returns the full user's profile, which contains the IdP Access Token. + +3. Extract the IdP Access Token from the response and use it to call the IdP's API. + +### Step 1: Get a Token + +You will need an Access Token to call the [Management API](/api/management/v2). + +#### Create a test application for the Management API + +If this is the first time you are requesting a [Management APIv2 Token](/api/management/v2/tokens), you will need to create and configure an application that can be used to call the Management API: + +1. Navigate to [Auth0 Dashboard > Applications > APIs](${manage_url}/#/apis/, and select the [Auth0 Management API](${manage_url}/#/apis/management/authorized-clients). + +2. Select the **API Explorer** view, and click **Create & Authorize a Test Application**. + +This will create a new application and grant **all scopes of the Management API**. This means that the tokens generated for this application will be able to access **all Management API endpoints**. + +::: panel Can't see the button? +If you don't see this button, it means that you already have at least one authorized application for the Management API. In this case, you can either update the scopes of the existing application and use that, or create a new one following these steps: + +1. Navigate to [Auth0 Dashboard > Applications > Applications](${manage_url}/#/applications), and click **Create Application**. +2. Select **Machine to Machine Applications**, and then **Create** +3. From the **Select an API** dropdown, select `Auth0 Management API`. +4. Enable required scopes, and select **Authorize**. +5. Select the **APIs** view, and enable the toggle for **Auth0 Management API**. +::: + +::: warning Security +For security reasons, we recommend that you assign only the required scopes to the application you will be using. For this particular case, the scopes you need are: `read:users`, `read:user_idp_tokens`. Required scopes are listed for each endpoint in the [Management API Explorer](/api/management/v2/). +::: + +To grant or remove scopes from the [registered Auth0 Management API](${manage_url}/#/apis/management/authorized-clients), select the [**Machine to Machine Applications** view](${manage_url}/#/apis/management/authorized-clients): + +![Edit the scopes granted to the Application](/media/articles/connections/dashboard-apis-edit_view-m2m_mgmt-api-permissions.png) + +#### Get the Management API Token + +You are now done with configuration and are ready to get your Management API token: + +1. From the [registered Auth0 Management API](${manage_url}/#/apis/management/authorized-clients), select the [Test view](${manage_url}/#/apis/management/test). + +2. Choose your application from the **Application** dropdown to pre-populate the ready-to-use snippets with customized variables. + +3. Choose your language of preference for the snippet, and copy and run it. + +4. Extract the `access_token` property from the response. This is what you will use to access the Management API. + +::: panel What are the snippets doing? +The snippets make a `POST` operation to the [/oauth/token endpoint of the Auth0 Authentication API](/api/authentication#client-credentials), using the **OAuth 2.0 Client Credentials grant**. This is the grant that machine-to-machine processes use to access an API. To learn more about the flow, refer to [Client Credentials Flow](/flows/concepts/client-credentials). +::: + +#### Token expiration + +By default, the token you received expires in 24 hours (86400 seconds). To change this: + +1. Navigate to [Auth0 Dashboard > Applications > APIs](${manage_url}/#/apis/, and select the [Auth0 Management API](${manage_url}/#/apis/management/authorized-clients). + +2. Select the **Settings** view, locate the **Token Expiration (Seconds)** field, enter a new value, and click **Save**. The maximum value you can set is 2592000 seconds (30 days), though we recommend that you keep the default value. + +The next token you generate will use the updated expiration time. + +::: panel-warning Security warning +These tokens **cannot be revoked**. To minimize risk, we recommend issuing short-lived tokens and granting only the necessary scopes for each application. For a production environment, you can configure a simple CLI that will fetch a new token when the old one expires. +::: + +### Step 2: Get the full User Profile + +To get a user's profile, call the [Get a User endpoint](/api/management/v2#!/Users/get_users_by_id) of the Management API using the Access Token you extracted in the previous section: + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/api/v2/users/USER_ID", + "httpVersion": "HTTP/1.1", + "cookies": [], + "headers": [{ + "name": "Authorization", + "value": "Bearer YOUR_ACCESS_TOKEN" + }] +} +``` + +Replace these values: +- `USER_ID`: ID of the user for whom you want to call the IdP's API. +- `YOUR_ACCESS_TOKEN`: Access Token you extracted in the previous section. + +::: panel Where do I find the User ID? +- For testing purposes, you can find a user ID at [Auth0 Dashboard > User Management > Users](${manage_url}/#/users/). Locate a user, and copy the value of the **user_id** field. +- For your implementation, you can either extract the user ID from the `sub` claim in the [ID Token](/tokens/concepts/id-tokens), or call the [/userinfo endpoint](/api/authentication#get-user-info) of the Authentication API and extract it from the `user_id` response property. +::: + +### Step 3: Extract the IdP Access Token + +You can find the Access Token used to call the IdP's API within the user's `identities` array: `user.identities[0].access_token`. + +::: note +For certain Identity Providers, Auth0 will also store a Refresh Token, which you can use to obtain a new Access Token for the IdP. This works for: BitBucket, Google (OAuth 2.0), OAuth 2.0, SharePoint, and Azure AD. To learn more, see [Identity Provider Access Tokens](/tokens/concepts/idp-access-tokens#renew-tokens). +::: + +In most cases, the user will only have one identity, but if the user has signed in multiple times through different connections and you have used [account linking](/users/concepts/overview-user-account-linking), there may be more. + +In this sample response, we see that our user has only one identity: `google-oauth2`. + +```json +{ + "email": "john.doe@test.com", + "email_verified": true, + "name": "John Doe", + "given_name": "John", + "family_name": "Doe", + "picture": "https://myavatar/photo.jpg", + "gender": "male", + "locale": "en", + "updated_at": "2017-03-15T07:14:32.451Z", + "user_id": "google-oauth2|111199914890750704174", + "nickname": "john.doe", + "identities": [ + { + "provider": "google-oauth2", + "access_token": "ya29.GlsPBCS6ahokDlgCYnVLnDKNE71HBXPEzNhAPoKJLAGKDSe1De3_xclahNcdZXoU-26hCpa8h6240TV86dtaEQ4ZWoeeZduHDq_yeu9QyQqUr--S9B2CR9YJrLTD", + "expires_in": 3599, + "user_id": "111199914890750704174", + "connection": "google-oauth2", + "isSocial": true + } + ], + "created_at": "2017-03-15T07:13:41.134Z", + "last_ip": "127.0.0.1", + "last_login": "2017-03-15T07:14:32.451Z", + "logins_count": 99 +} +``` + +You are now ready to call the IdP's API. Please refer to the IdP's documentation for specifics on how to do so. + +::: warning +Don't expose IdP tokens to your client-side application! If your application is public, see the [frontend section](#from-the-frontend) of this article. +::: + +::: note +To learn more about how to request specific scopes for an Identity Provider Access Token, please see [Add scopes/permissions to call Identity Provider's APIs](/connections/adding-scopes-for-an-external-idp). +::: + +## From the frontend + +If you are working with a public application (SPA, native desktop, or mobile app), then this is the place to be. + +When working with a frontend app, the process for calling IdP APIs differs from the backend process because frontend apps are public applications that **cannot hold credentials securely**. Because SPA code can be viewed and altered, and native/mobile apps can be decompiled and inspected, they cannot be trusted to hold sensitive information like secret keys or passwords. + +Specifically, they cannot securely hold the **Client Secret** for the Machine to Machine Application, which you use to call `/oauth/token` during the first step of the backend process. + +Instead, you must build a proxy for your backend and expose it to your application as an API. + +### Build a proxy + +First, you will build a process in your backend that will implement the steps included in [the backend section](#from-the-backend) of this article, and expose it to your application as an API. + +You will call the IdP's API from the same backend process, so the Access Token is never exposed to your public application. + +Then, you will call your proxy API from your public application using the [Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/flows/guides/auth-code-pkce/call-api-auth-code-pkce). + +:::panel Show me how +If you haven't implemented this before, you might find our [SPA + API](/architecture-scenarios/application/spa-api) article useful. It covers a different scenario, but it explains how to configure Auth0, how to call an API from a SPA, and how to implement API validations. It comes with a sample that uses [Angular 2](https://github.com/auth0-samples/auth0-pnp-exampleco-timesheets/tree/master/timesheets-spa/angular) and [Node.js](https://github.com/auth0-samples/auth0-pnp-exampleco-timesheets/tree/master/timesheets-api/node). + +We also offer a [Mobile + API](/architecture-scenarios/application/mobile-api) variation (the sample uses [Android](https://github.com/auth0-samples/auth0-pnp-exampleco-timesheets/tree/master/timesheets-mobile/android) and [Node.js](https://github.com/auth0-samples/auth0-pnp-exampleco-timesheets/tree/master/timesheets-api/node)). +::: diff --git a/articles/connections/criipto/bankid-no.md b/articles/connections/criipto/bankid-no.md new file mode 100644 index 0000000000..a2ed575ad4 --- /dev/null +++ b/articles/connections/criipto/bankid-no.md @@ -0,0 +1,94 @@ +--- +title: Connect Norwegian BankID with Auth0 through Criipto Verify +connection: Norwegian BankID +image: /media/articles/connections/criipto/bankid-no.png +seo_alias: bankid +description: Connecting Norwegian BankID with Auth0 through the Criipto Verify service +toc: true +crews: crew-2 +topics: + - connections + - criipto +contentType: how-to +useCase: + - customize-connections + - add-idp +--- + +# Log in with Norwegian BankID through Auth0 + +When you need to know the legal identity of your Norwegian users, your choice is BankID jointly offered by the Norwegian banks. The BankID technology by itself is rather complicated to integrate, but through the [Criipto Verify service](https://criipto.com/products/criipto-verify) +you may avoid the integration trouble. + +Below is an outline of the steps to get ready to accept Norwegian BankID logins, but you may also view [a short screen cast](https://criipto.com/easyid/auth0/2016/12/07/easyid-and-auth0/) at Criipto's website. + +::: panel Process to use Norwegian BankID in Production +While the technical integration complexity is simple, to use Norwegian BankID in production you will have to go through a formal process to +register and obtain the necessary certificate to identify yourself to your users. +More on this process can be found once you sign into the Criipto Verify service, and with the help of Criipto. +::: + +## 1. Create an account with Criipto Verify + +Go to [criipto.com/verify](https://criipto.com/products/criipto-verify) and click the sign-up button. + +Once registered you will be asked to create your tenant. + +![Create new tenant](/media/articles/connections/criipto/easyid-signup.png) + +## 2. Create an Application to point to Auth0 + +In Criipto Verify go to the **Applications** tab and create a new application by clicking the **with Auth0** button. +Give it a meaningful name, select the domain and remember to enable **NO BankID**. + +![Create application with Auth0](/media/articles/connections/criipto/auth0-app-no.png) + +Click **Save** to open the next dialog. + +## 3. Name the connection (prefix) as it will appear in Auth0 + +If you do not run off the public Auth0 service, enter the DNS name of the login tenant. Otherwise just leave the **Auth0 tenant** field as is. + +Secondly enter a name to be used as the prefix for the connections created in Auth0. + +![Auth0 connections details](/media/articles/connections/criipto/auth0-details.png) + +Click **Proceed**. + +## 4. Create new connections in Auth0 + +If you are not already logged in to Auth0 in this session, you will be prompted to do so in the popup window. + +Once logged in you must grant Criipto Verify consent to create connections and read the applications. + +::: note +If you have more than one Auth0 tenant, remember to select the right one in the dialog. +::: + +![Auth0 connections details](/media/articles/connections/criipto/auth0-consent.png) + +Click the check mark in the green area at the bottom to allow Criipto Verify to set up the connections. + +## 5. Verify the connections + +Go to [Auth0 Dashboard > Authentication > Enterprise](${manage_url}/#/connections/enterprise), and open the **ADFS** connections to see the connections for Norwegian BankID created from the previous steps. + +::: note +One connection has been created for each kind of authentication supported by Norwegian BankID: Browser based and mobile. The mobile method requires a special SIM card issued by a Norwegian provider. +::: + +![ADFS connections created](/media/articles/connections/criipto/adfs-connections-no.png) + +Remember to enable at least one application before clicking the **Try** button! For more on test users see documentation on Criipto Verify. + +## 6. Create your test users + +With the above setup you will be ready to start testing. You will find a test user's credentials in your Criipto Verify tenant to start testing the web based flow. To get your own test users and to get the special SIM cards need to test the mobile flow, work with Criipto to sign up for production use of Norwegian BankID. + +## 7. Enable production use + +To start accepting real BankID logins from real legal persons, you must first enter into a formal agreement with a Norwegian bank through Criitpo. This process requires you to be a customer of said Norwegian bank. + +Once this agreement is in place you will receive a certificate to upload to Criipto Verify. Go to the **IDENTITY SERVICES** tab and open the **NO BankID** section. This is where you will upload your organization's BankID certificate. + +![Identity Service production](/media/articles/connections/criipto/no-bankid-prod.png) diff --git a/articles/connections/criipto/bankid-se.md b/articles/connections/criipto/bankid-se.md new file mode 100644 index 0000000000..d8f6ad3466 --- /dev/null +++ b/articles/connections/criipto/bankid-se.md @@ -0,0 +1,104 @@ +--- +title: Connect Swedish BankID with Auth0 through Criipto Verify +connection: Swedish BankID +image: /media/articles/connections/criipto/bankid-se.png +seo_alias: bankid +description: Connecting Swedish BankID with Auth0 through the Criipto Verify service +toc: true +crews: crew-2 +topics: + - connections + - criipto +contentType: how-to +useCase: + - customize-connections + - add-idp +--- + +# Log in with Swedish BankID through Auth0 + +When you need to know the legal identity of your Swedish users, your choice is BankID jointly offered by the Swedish banks. +The BankID technology by itself is proprietary and takes a bit of work to understand and integrate, but through the [Criipto Verify service](https://criipto.com/products/criipto-verify) +you may avoid the integration trouble. + +Below is an outline of the steps to get ready to accept Swedish BankID logins, but you may also view +[a short screen cast](https://criipto.com/easyid/auth0/2016/12/07/easyid-and-auth0/)) at Criipto's website. + +::: panel Process to use Swedish BankID in Production +While the technical integration complexity is simple, to use Swedish BankID in production you will have to go through a formal process to register and obtain the necessary certificate to identify yourself to your users. +More on this process can be found once you sign into the Criipto Verify service, and with the help of Criipto. +::: + +## 1. Create an account with Criipto Verify + +Go to [criipto.com/verify](https://criipto.com/products/criipto-verify) and click the sign-up button. + +Once registered you will be asked to create your tenant. + +![Create new tenant](/media/articles/connections/criipto/easyid-signup.png) + +## 2. Create an Application to point to Auth0 + +In Criipto Verify go to the **APPLICATIONS** tab and create a new application by clicking the **with Auth0** button. +Give it a meaningful name, select the domain and remember to select the **SE BankID**. + +![Create application with Auth0](/media/articles/connections/criipto/auth0-app-se.png) + +Click **Save** to open the next dialog + +## 3. Name the connection (prefix) as it will appear in Auth0 + +If you do not run off the public Auth0 service, enter the DNS name of the login tenant. Otherwise just leave the **Auth0 tenant** field as is. + +Secondly enter a name to be used as the prefix for the connections created in Auth0. + +![Auth0 connections details](/media/articles/connections/criipto/auth0-details.png) + +Click **Proceed**. + +## 4. Create new connections in Auth0 + +If you are not already logged in to Auth0 in this session, you will be prompted to do so in the popup window. + +Once logged in you must grant Criipto Verify consent to create connections and read the applications. + +::: note +If you have more than one Auth0 tenant, remember to select the right one. in the dialog. +::: + +![Auth0 connections details](/media/articles/connections/criipto/auth0-consent.png) + +Click the check mark in the green area at the bottom to allow Criipto Verify to set up the connections. + +## 5. Verify the connections + +Go to [Auth0 Dashboard > Authentication > Enterprise](${manage_url}/#/connections/enterprise), and open the **ADFS** connections to see the connections for +Swedish BankID created from the previous steps. + +::: note +One connection has been created for each kind of authentication supported by Swedish BankID: +Native BankID application or mobile app. Both applications must be installed prior to BankID authentication. +::: + +![ADFS connections created](/media/articles/connections/criipto/adfs-connections-se.png) + +Remember to enable at least one application before clicking the **Try** button! For more on test users see the documentation +on Criipto Verify. + +## 6. Create your test users + +With the above setup you will be ready to start testing. But first you must create one or more test users here: [demo.bankid.com/](https://demo.bankid.com/). If you don't already have a test or real BankID, go to the section named **Log in with a personal code**. + +## 7. Enable production use + +To start accepting real BankID logins from real legal persons, you must first enter into a formal agreement with a Swedish Bank, +possibly through Criipto, or directly with your bank. + +Once this agreement is in place you will receive a certificate to upload to Criipto Verify. + +Go to the **IDENTITY SERVICES** tab +and open the **SE BankID** section. + +This is where you will upload your organization's BankID certificate. + +![Identity Service production](/media/articles/connections/criipto/se-bankid-prod.png) diff --git a/articles/connections/criipto/nemid.md b/articles/connections/criipto/nemid.md new file mode 100644 index 0000000000..31d793e530 --- /dev/null +++ b/articles/connections/criipto/nemid.md @@ -0,0 +1,105 @@ +--- +title: Connect Danish NemID with Auth0 through Criipto Verify +connection: Danish NemID +image: /media/articles/connections/criipto/nemid_black.png +seo_alias: nemid +description: Connecting Danish NemID with Auth0 through the Criipto Verify service +toc: true +crews: crew-2 +topics: + - connections + - criipto +contentType: how-to +useCase: + - customize-connections + - add-idp +--- + +# Log in with Danish NemID through Auth0 + +When you need to know the legal identity of your Danish users, your choice is NemID offered by the Danish Government. NemID exists in +both a version private citizens and one for employees of an organization. + +The NemID technology by itself is proprietary and takes quite a bit of work to understand and integrate, but through the [Criipto Verify service](https://criipto.com/products/criipto-verify) +you may avoid the integration trouble. + +Below is an outline of the steps to get ready to accept Danish NemID logins, but you may also view +[a short screen cast](https://criipto.com/easyid/auth0/2016/12/07/easyid-and-auth0/) at Criipto's website. + +::: panel Process to use Swedish BankID in Production +While the technical integration is simple, to use Danish NemID in production you will have to go through a formal process to register and obtain the necessary certificate to identify yourself to your users. This process must be completed with the Danish NemID operator, Nets. +More on this process can be found once you sign into the Criipto Verify service, and with the help of Criipto. +::: + +## 1. Create an account with Criipto Verify + +Go to [criipto.com/verify](https://criipto.com/products/criipto-verify) and click the sign-up button. + +Once registered you will be asked to create your tenant. + +![Create new tenant](/media/articles/connections/criipto/easyid-signup.png) + +## 2. Create an Application to point to Auth0 + +In Criipto Verify go to the **APPLICATIONS** tab and create a new application by clicking the **with Auth0** button. +Give it a meaningful name, select the domain and remember to select the **DK NemID**. + +![Create application with Auth0](/media/articles/connections/criipto/auth0-app-dk.png) + +Click **Save** to open the next dialog + +## 3. Name the connection (prefix) as it will appear in Auth0 + +If you do not run off the public Auth0 service, enter the DNS name of the login tenant. Otherwise just leave the **Auth0 tenant** field as is. + +Secondly enter a name to be used as the prefix for the connections created in Auth0. + +![Auth0 connections details](/media/articles/connections/criipto/auth0-details.png) + +Click **Proceed**. + +## 4. Create new connections in Auth0 + +If you are not already logged in to Auth0 in this session, you will be prompted to do so in the popup window. + +Once logged in you must grant Criipto Verify consent to create connections and read the details of your applications. + +::: note +If you have more than one Auth0 tenant, remember to select the right one. in the dialog. +::: + +![Auth0 connections details](/media/articles/connections/criipto/auth0-consent.png) + +Click the check mark in the green area at the bottom to allow Criipto Verify to set up the connections. + +## 5. Verify the connections + +Go to [Auth0 Dashboard > Authentication > Enterprise](${manage_url}/#/connections/enterprise), and open the **ADFS** connections to see the connections for +Danish NemID created from the previous steps. + +::: note +One connection has been created for each kind of authentication supported by NemID: +Personal NemID (POCES), Employee NemID (MOCES), and Employee NemID with a code file. +::: + +![ADFS connections created](/media/articles/connections/criipto/adfs-connections-dk.png) + +Remember to enable at least one application before clicking the **Try** button! For more on test users see the documentation +on Criipto Verify. + +## 6. Create your test users + +With the above setup you will be ready to start testing. But first you must create one or more test users or get some from Criipto. +See more in the documentation in your Criipto Verify tenant. + +## 7. Enable production use + +To start accepting real NemID logins from real legal persons, you must first enter into a formal agreement with Nets, +the company providing the service under contract from the Danish Government. More on this here (in Danish): +[www.nets.eu/dk-da/l%C3%B8sninger/nemid/nemid-tjenesteudbyder/Pages/bestil.aspx](https://www.nets.eu/dk-da/l%C3%B8sninger/nemid/nemid-tjenesteudbyder/Pages/bestil.aspx) + +Once this agreement is in place you will receive a certificate to upload to Criipto Verify. Go to the **IDENTITY SERVICES** tab +and open the **DK NemID** section. This is where you will upload your organization's BankID certificate and provide the rest of the +needed information. + +![Identity Service production](/media/articles/connections/criipto/dk-nemid-prod.png) diff --git a/articles/connections/database/auth0-user-store.md b/articles/connections/database/auth0-user-store.md new file mode 100644 index 0000000000..d009b0ddc1 --- /dev/null +++ b/articles/connections/database/auth0-user-store.md @@ -0,0 +1,24 @@ +--- +title: Auth0 User Store +description: Describes creating and using a database connection with the Auth0 user store. +topics: + - connections + - database + - db-connections +useCase: + - customize-connections +--- + +# Auth0 User Store + +Auth0 provides the database infrastructure to store your users by default. This scenario 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. To learn more, read [Password Strength in Auth0 Database Connections](/password-strength). + +::: note +For database connections, Auth0 limits the number of repeat login attempts per user and IP address. To learn more, read [Rate Limits on User/Password Authentication](/policies/rate-limit-policy/database-connections-rate-limits). +::: + +## Migrating to Auth0 from a custom user store + +In this scenario, you have a legacy user store and wish to switch to the Auth0 store. Auth0 provides an automatic migration feature that adds your users to the Auth0 database one-at-a-time as each logs in and avoids asking your users to reset their passwords all at the same time. To learn more, read [Configure Automatic User Migration](/users/guides/configure-automatic-migration). \ No newline at end of file diff --git a/articles/connections/database/custom-db/_includes/_bp-error-object.md b/articles/connections/database/custom-db/_includes/_bp-error-object.md new file mode 100644 index 0000000000..19e3e9c3a1 --- /dev/null +++ b/articles/connections/database/custom-db/_includes/_bp-error-object.md @@ -0,0 +1,3 @@ +::: panel Best practice +When indicating an error, we recommend using the `Error` object to provide Auth0 with a clear indication of the error condition. For example, use `callback(new Error(“an error message”))` when a problems occurs with communication to your database. See [Types of errors](/connections/database/custom-db/error-handling#types-of-errors) for more information. +::: diff --git a/articles/connections/database/custom-db/_includes/_panel-bcrypt-hash-encryption.md b/articles/connections/database/custom-db/_includes/_panel-bcrypt-hash-encryption.md new file mode 100644 index 0000000000..461e7d01a6 --- /dev/null +++ b/articles/connections/database/custom-db/_includes/_panel-bcrypt-hash-encryption.md @@ -0,0 +1,14 @@ +::: panel `bcrypt` hash encryption +The password credential for the user is passed to the login script in plain text so care must be taken regarding its use. You should refrain from logging, storing, or transporting the `password` credential anywhere in its vanilla form. Instead, use something similar to the following example, which uses the `bcrypt` algorithm to perform cryptographic hash encryption: + +```js +bcrypt.hash(password, 10, function (err, hash) { + if (err) { + return callback(err); + } else { + . + . + } +}); +``` +::: diff --git a/articles/connections/database/custom-db/_includes/_panel-feature-availability.md b/articles/connections/database/custom-db/_includes/_panel-feature-availability.md new file mode 100644 index 0000000000..94cac832e0 --- /dev/null +++ b/articles/connections/database/custom-db/_includes/_panel-feature-availability.md @@ -0,0 +1,3 @@ +::: panel Limited Access +Your Auth0 subscription plan affects the availability of some features. For more information, see [Auth0 pricing plans](https://auth0.com/pricing). +::: diff --git a/articles/connections/database/custom-db/create-db-connection.md b/articles/connections/database/custom-db/create-db-connection.md new file mode 100644 index 0000000000..9f1e1d9862 --- /dev/null +++ b/articles/connections/database/custom-db/create-db-connection.md @@ -0,0 +1,170 @@ +--- +description: Learn how to create a database connection. +toc: true +topics: + - connections + - custom-database +contentType: how-to +useCase: customize-connections +--- +# Create Custom Database Connections + +<%= include('./_includes/_panel-feature-availability') %> + +If you have your own user database, you can use it as an identity provider in Auth0 to authenticate users. In this process, you will create the custom database connection, create database action scripts, and add configuration parameters. + +::: note +Make sure that your database has the appropriate fields to store user profiles attributes, such as **id**, **nickname**, **email**, and **password**. See [Normalized User Profile](/users/normalized) for details on Auth0's user profile schema and the expected fields. Also, see [Update User Profile Using Your Database](/users/guides/update-user-profiles-using-your-database) for more information. +::: + +Auth0 allows you to create connections and scripts for most of the commonly-used databases, including: + + * ASP.NET Membership Provider + * MongoDB + * MySQL + * PostgreSQL + * SQLServer + * Windows Azure SQL Database + * Web services accessed via Basic Auth + +You can connect to any kind of database or web service with a properly-configured custom script. + +<%= include('../../../_includes/_ip_whitelist') %> + +## Create the connection in the Auth0 Dashboard + +1. Navigate to [Auth0 Dashboard > Authentication > Database](${manage_url}/#/connections/database), and select **+ Create DB Connection**. + + ![Database connections](/media/articles/connections/database/dashboard-connections-database-list.png) + +2. Configure the connection's settings, and click **Create**: + + | **Parameter** | **Definition** | + | - | - | + | **Name** | The name of the connection. The name must start and end with an alphanumeric character, contain only alphanumeric characters and dashes, and not exceed 35 characters. | + | **Requires Username** | Forces users to provide a username *and* email address during registration. | + | **Username length** | Sets the minimum and maximum length for a username. | + | **Disable Sign Ups** | Prevents sign-ups to your application. You will still be able to create users with your API credentials or via the Auth0 Dashboard. | + + Once Auth0 creates your connection, you'll have the following views (in addition to the **Settings** view): + + * Password Policy + * Custom Database + * Applications + * Try Connection + +3. Select the **Custom Database** view, and enable the **Use my own database** switch. + + ![Enable Use Own Database Option](/media/articles/connections/database/dashboard-connections-database-edit_view-custom-database_use-my-own-database.png) + +## Create database action scripts + +Toggling the **Use my own database** switch enables the **Database Action Scripts** area where you will create scripts to configure how authentication works when using your database. You can write your database action scripts, or you can select a template from the **Templates** dropdown and modifying it as necessary. + +You **must** configure a `login` script; additional scripts for user functionality are optional. + +The available database action scripts are: + +**Name** | **Description** | **Parameters** +-------|-------------|----------- +**Login**
      Required | Executes each time a user attempts to log in. | `email`, `password` +**Create** | Executes when a user signs up. | `user.email`, `user.password` +**Verify** | Executes after a user follows the verification link. | `email` +**Change Password** | Executes when a user clicks on the confirmation link after a reset password request. | `email`, `newPassword` +**Get User** | Retrieves a user profile from your database without authenticating the user. | `email` +**Delete** | Executes when a user is deleted using the API or Auth0 Dashboard. | `id` +**Change Email** | Executes when a change in the email address, or the email address status, for a user occurs. | `email`, `newEmail`, `verified`, `callback` + +See [Custom Database Action Script Templates](/connections/database/custom-db/templates) and [Custom Database Action Script Execution Best Practices](/best-practices/custom-db-connections/execution) for details on all the scripts. + +### Create a Login script + +::: panel Avoid User ID Collisions with Multiple Databases +The `id` (or alternatively `user_id`) property in the returned user profile will be used by Auth0 to identify the user. + +If you are using multiple custom database connections, then **id** value **must be unique across all the custom database connections** to avoid **user ID** collisions. Our recommendation is to prefix the value of **id** with the connection name (omitting any whitespace). See [Identify Users](/users/normalized/auth0/identify-users) for more information on user IDs. +::: + +The following steps use an example for a MySQL database login script. + +1. After toggling the **Use my own database** switch, the **Database Action Scripts** area is enabled. Make sure you are on the **Login** tab. +3. Use the **Templates** dropdown to select the MySQL database script template. + +```js +function login(email, password, callback) { + var bcrypt = require('bcrypt'); + var mysql = require('mysql'); + + var connection = mysql.createConnection({ + host: 'localhost', + user: 'me', + password: 'secret', + database: 'mydb' + }); + + connection.connect(); + + var query = "SELECT id, nickname, email, password " + + "FROM users WHERE email = ?"; + + connection.query(query, [email], function (err, results) { + if (err) return callback(err); + if (results.length === 0) return callback(new WrongUsernameOrPasswordError(email)); + var user = results[0]; + + bcrypt.compare(password, user.password, function (err, isValid) { + if (err) { + callback(err); + } else if (!isValid) { + callback(new WrongUsernameOrPasswordError(email)); + } else { + callback(null, { + // This prefix (replace with your own custom DB name) + // ensure uniqueness across different custom DBs if there's the + // possibility of collisions (e.g. if the user ID is an email address or an integer) + id: 'MyConnection1|' + user.id.toString(), + nickname: user.nickname, + email: user.email + }); + } + }); + }); +} +``` + +The above script connects to a MySQL database and executes a query to retrieve the first user with `email == user.email`. + +With the **bcrypt.compareSync** method, it then validates that the passwords match, and if successful, returns an object containing the user profile information including **id**, **nickname**, and **email**. + +This script assumes that you have a **users** table containing these columns. The **id** returned by Login script is used to construct the **user ID** attribute of the user profile. + +4. Click **Save**. +5. Click **Try** to test the script. (This step will also save your script.) + + Script templates are not used by Auth0 until you click **Save** or **Try**. This is true even if you only modify one script and haven't made changes to any others. You must click **Save** at least once for all the scripts to be in place. + +## Add configuration parameters + +You can store parameters, like the credentials required to connect to your database, in the **Settings** section below the script editor. These will be available for all of your scripts, and you can access the parameter values using the `configuration` object in your database action scripts (i.e., `configuration.MYSQL_PASSWORD`). + +![Custom database settings](/media/articles/connections/database/dashboard-connections-database-edit_view-custom-database_settings.png) + +Use the added parameters in your scripts to configure the connection. For example, you might add the following to the MySQL Login script: + +```js +function login (username, password, callback) { + var mysql = require('mysql'); + var connection = mysql.createConnection({ + host : configuration.MYSQL_HOST, + user : 'me', + password : configuration.MYSQL_PASSWORD, + database : 'mydb' + }); +} +``` + +## Keep reading + +* [Custom Database Connection and Action Script Best Practices](/best-practices/custom-db-connections) +* [Custom Database Error Handling and Troubleshooting](/connections/database/custom-db/error-handling) +* [Migrate Users to Auth0](/users/concepts/overview-user-migration) diff --git a/articles/connections/database/custom-db/error-handling.md b/articles/connections/database/custom-db/error-handling.md new file mode 100644 index 0000000000..654f9f1c4a --- /dev/null +++ b/articles/connections/database/custom-db/error-handling.md @@ -0,0 +1,51 @@ +--- +description: Describes how to handle errors and troubleshoot when using your database as an identity provider. +topics: + - connections + - custom-database + - troubleshooting +contentType: reference +useCase: + - customize-connections + - troubleshooting +--- +# Troubleshoot Custom Databases + +You can use return errors resulting from your custom database connection for troubleshooting purposes. We will also cover some basic troubleshooting steps for your scripts. + +## Types of errors + +There are three different errors you can return from a database connection: + +| Error | Login Script | Description | +| - | - | - | +| `new WrongUsernameOrPasswordError(, )` | Login | Occurs when the user's credentials are invalid | +| `new ValidationError(, )` | Create | Occurs when a user already exists in your database | +| `callback(,)` | Change Password | Occurs when the user's password was not updated| +| `callback()` | Get User | Occurs when the user is not found| +| `new Error()` | All Login Scripts | Occurs when something went wrong while trying to reach the database | + +## Return errors + +To return an error, call the **callback** function while passing **error** as the first parameter: + +```js +callback(error); +``` + +**Example:** + +```js +callback(new ValidationError('email-too-long', 'Email is too long.')); +``` + +### Returning errors when using Lock + +If you use Lock, you can [customize the error messages](libraries/lock/customizing-error-messages) that will be displayed by adding them to the dictionary. + +## Troubleshooting Errors + +Test the script using the **TRY** button. + +If you do not get the expected result or you receive an error, install the [Real-time Webtask Logs extension](/extensions/realtime-webtask-logs) and use `console.log()` statements in your script and try the connection again. The output of `console.log()` will print to the Real-time Webtask Logs window. + diff --git a/articles/connections/database/custom-db/index.md b/articles/connections/database/custom-db/index.md new file mode 100644 index 0000000000..f3b9a7e57e --- /dev/null +++ b/articles/connections/database/custom-db/index.md @@ -0,0 +1,41 @@ +--- +title: Custom Database Connections +description: Learn about authenticating users using your database as an identity provider. +classes: topic-page +topics: + - connections + - custom-database + - scripts +contentType: + - concept + - index +useCase: + - customize-connections +--- + +
      +
      +

      Custom Database Connections

      +

      + Use a custom database connection when you want to provide Auth0 with access to your own independent (legacy) identity data store primarily for authenticaton (filling the role of an identity provider) and for migrating user data to Auth0's data store. +

      +
      + +Auth0 [Extensibility](/topics/extensibility) allows you to add custom logic to build out last mile solutions for Identity and Access Management (IdAM). Auth0 extensibility comes in several forms: [Rules](/rules), [Hooks](/hooks), and [scripts](/connections/database/custom-db/templates) for both custom database connections and custom database migration. Each is implemented using [Node.js](https://nodejs.org/en/) running on the Auth0 platform in an Auth0 tenant. + +Auth0 extensibility executes at different points in the IdAM pipeline: + +* **Rules** run when artifacts for user authenticity are generated (i.e., an ID Token in OpenID Connect (OIDC)), an Access Token in OAuth 2.0, or an assertion in Security Assertion Markup Language (SAML). +* **Hooks** provide additional extensibility for when there is an exchange of non-user related artifacts, and for when user identities are created. See [pre-user registration](/hooks/extensibility-points/pre-user-registration) and [post-user registration](/hooks/extensibility-points/post-user-registration) Hooks for details. +* **Custom database action scripts** can be used to integrate with an existing user identity store, or can be used where [automatic user migration](/users/concepts/overview-user-migration#automatic-migrations) from an legacy identity store is required. + +Whatever the use case, Auth0 extensibility allows you to tailor IdAM operations to your exact requirements. However, if not used in the right way, this can open up the potential for improper or unintended use which can lead to problematic situations down the line. In an attempt to address matters ahead of time, Auth0 provides [best practice guidance](/best-practices/custom-db-connections) to both designers and implementers, and we recommend reading it in its entirety at least once, even if you've already started your journey with Auth0. + +<%= include('./_includes/_panel-feature-availability') %> + +<%= include('../../../_includes/_topic-links', { links: [ + 'connections/database/custom-db/overview-custom-db-connections', + 'connections/database/custom-db/create-db-connection', + 'connections/database/custom-db/templates', + 'connections/database/custom-db/error-handling' +] }) %> diff --git a/articles/connections/database/custom-db/overview-custom-db-connections.md b/articles/connections/database/custom-db/overview-custom-db-connections.md new file mode 100644 index 0000000000..d188cffbc1 --- /dev/null +++ b/articles/connections/database/custom-db/overview-custom-db-connections.md @@ -0,0 +1,141 @@ +--- +title: Authenticate with Your Own User Store +description: Learn about authenticating users using your database as an identity provider. +toc: true +topics: + - connections + - custom-database + - scripts +contentType: concept +useCase: + - custom-db-connections + - legacy-authentication +--- +# Authenticate with Your Own User Store + +<%= include('./_includes/_panel-feature-availability') %> + +<%= include('../../../_includes/_webtask') %> + +Use a custom database connection when you want to provide access to your own independent (legacy) identity data store for the following purposes: + +* **Authentication**: Use your database as an identity provider in Auth0 to authenticate users. (Referred to as *legacy authentication*.) +* **Import Users**: Use automatic migration (*trickle* or *lazy* migration) +* **Proxy access to an Auth0 tenant**: Use Auth0 multi-tenant architecture. + +You can create and configure a custom database connection by doing one of the following tasks: + +1. Use the [Create connections](/api/management/v2#!/Connections/post_connections) Management API endpoint with the `auth0` strategy. + +2. Navigate to [Auth0 Dashboard > Authentication > Database](${manage_url}/#/connections/database), create the connection, and enable the **Use my own database** option to allow database action script editing. + +![Enable Custom Database Use My Own Database Option](/media/articles/connections/database/dashboard-connections-database-edit_view-custom-database_use-my-own-database.png) + +## How it works + +As shown in the diagram below, you use custom database connections as part of Universal Login workflow in order to obtain user identity information from your own, legacy identity store. + +![Custom Database Connections Anatomy](/media/articles/connections/database/custom-database-connections.png) + +In addition to artifacts common for all [database connection](/connections/database) types, a custom database connection allows you to configure action scripts: custom code that’s used when interfacing with your legacy identity store. Auth0 provides [custom database action script templates](/connections/database/custom-db/templates) for configuration, and the ones you use will depend on whether you are creating a custom database connection for legacy authentication or for automatic migration. + +::: panel Best practice +Action scripts can be implemented as anonymous functions, however anonymous functions make it hard in debugging situations when it comes to interpreting the call-stack generated as a result of any exceptional error condition. For convenience, we recommend providing a function name for each action script. +::: + +### Legacy authentication scenario + +In a legacy authentication scenario, a new user record is created within Auth0 during the user's first login, but Auth0 does not store a hash of the user's password. Auth0 will always use the legacy identity store and the identity it contains when authenticating the user. + +::: note +Custom database connections are also used outside of Universal Login workflow. For example, a connection's `changePassword` action script is called when a password change operation occurs for a user that resides in a legacy identity store. +::: + +### Automatic migration scenario + +During automatic or trickle migration, Auth0 creates a new user in an identity store (database) managed by Auth0. From then on, Auth0 always uses the identity in the Auth0 managed identity store for authenticating the user. For this to occur, first Auth0 requires the user be authenticated against the legacy identity store and only if this succeeds will the new user be created. The new user will be created using the same id and password that was supplied during authentication. + +::: panel Best practice +Creation of a user in an automatic migration scenario typically occurs after the `login` action script completes. We therefore recommend that you do not attempt any deletion of a user from a legacy identity store as an inline operation (i.e., within the `login` script) but perform the deletion as an independent process. This will prevent accidental deletion of a user should an error condition occur during the migration process. +::: + +In an automatic migration scenario, users remain in the legacy identity store and can be deleted or archived if required. One side effect of this can occur if a user is deleted from Auth0 but still remains present in the legacy identity store. In this case, a login actioned by the deleted user could result in either the `login` and/or `getUser` script being executed and the user being migrated from the legacy identity store once again. + +::: panel Best practice +We recommend marking any legacy user identity as having been migrated before either `login` or `getUser` completes and prior to any eventual legacy store deletion. +::: + +## Size + +The total size of implementation for any action script should not exceed 100 kB. The larger the size the more latency is introduced due to the packaging and transport process employed by the Auth0 serverless Webtask platform, and this will have an impact on the performance of your system. + +::: note +The 100 kB limit does not include any `npm` modules that may be referenced as part of any require statements. +::: + +## Environment + +Action scripts execute as a series of called JavaScript functions in an instance of a serverless Webtask container. As part of this, a specific environment is provided, together with a number of artefacts supplied by both the Webtask container and the Auth0 authentication server (your Auth0 tenant) itself. + +### `npm` modules + +Auth0 serverless Webtask containers can make use of a [wide range of `npm` modules](https://auth0-extensions.github.io/canirequire/); `npm` modules not only reduce the overall size of action script code implementation, but also provide access to a wide range of pre-built functionality. + +Many publicly available `npm` modules are supported out-of-the-box. The list has been compiled and vetted for any potential security concerns. If you require an `npm` module that is not supported out-of-the-box, then you can make a request in the [Auth0 support portal](https://support.auth0.com/) or to your Auth0 representative. Auth0 will evaluate your request to determine suitability. There is currently no support in Auth0 for the user of `npm` modules from private repositories. + +### Variables + +Auth0 action scripts support environment variables, accessed via what is known as the globally available [`configuration` object](/connections/database/custom-db/create-db-connection#add-configuration-parameters). + +::: panel Best practice +The `configuration` object should be treated as read-only, and should be used for storing sensitive information such as credentials or API keys for accessing external identity stores. This mitigates having security sensitive values hard coded in an action script. +::: + +The configuration object can also be used to support whatever [Software Development Life Cycle (SDLC)](/dev-lifecycle/setting-up-env) strategies you employ by allowing you to define variables that have tenant specific values. This mitigates hard coded values in an action script which may change depending upon which tenant is executing it. + +### `global` object + +Auth0 serverless Webtask containers are provisioned from a pool that's associated with each Auth0 tenant. Each container instance makes available the `global` object, which can be accessed across all action scripts that execute within the container instance. The `global` object acts as a global variable that’s unique to the container, and that can be used to define information or functions used across all action scripts that run in the container instance. + +This means that the `global` object can be used to cache expensive resources as long as those resources are not user-specific. For example, you could use it to store an Access Token for a third-party (e.g., logging) API that provides non-user-specific functionality. Or, you can store an Access Token to your own non-user-specific API defined in Auth0 and obtained via the [Client Credentials](/flows/concepts/client-credentials) flow. + +::: warning +An action script may execute in any of the container instances already running, or in a newly created container instance (which may subsequently be added to the pool). There is no container affinity for action script execution in Auth0. This means that you should avoid storing any user-specific information in the `global` object, and should always ensure that any declaration made within the `global` object provides for initialization too. +::: + +Each time a Webtask container is recycled, or for each instantiation of a new Webtask container, the `global` object it defines is reset. Thus, any declaration of assignment within the `global` object associated with a container should also include provision for initialization too. + +::: panel Best practice +To provide performance flexibility, serverless Webtask containers are provisioned in Auth0 on an ad-hoc basis and are also subject to various recycle policies. In general, we recommend that you do not consider the life of a `global` object to be anything more than 20 minutes. +::: + +## Security + +### Access legacy identity storage via custom API + +Protecting legacy identity storage from general access is a recommended best practice. Exposing a database directly to the internet, for example, can be extremely problematic: database interfaces for SQL and the like are extremely open in terms of functionality, which violates the principle of least privilege when it comes to security. + +::: panel Best practice +We recommend that you implement an API to provide least privilege to your legacy identity store (database), rather than simply opening up general access via the internet. +::: + +The alternative is to create a simple (custom) API, protected via use of an access token, that each action script can call. This would act as the interface to the legacy identity store. Client credentials grant flow can then be used to obtain an access token from within a script, and this can subsequently be cached for reuse in the `global` object in order to improve performance. The API can then provide a discrete number of protected endpoints that perform only the legacy management functionality required (e.g., `read user`, `change password`, etc.) + +::: panel Best practice +By default, Auth0 will give you a token for any API if you authenticate successfully and include the appropriate audience. Restricting access to the legacy identity store API by restricting access token allocation via use of a Rule, will prevent unauthorized usage and mitigate a number of attack vector scenarios, such as where redirect to `/authorize` is intercepted and the audience to the API is added. +::: + +### Allowlist access to legacy identity storage + +Whether managing access to a legacy identity store via custom API, or using the native interface provided, restricting access to the list of IP addresses associated with your Auth0 tenant. Allowlisting constrains access to the legacy identity store ensuring that only custom database action scripts defined in Auth0 are permitted. + +::: warning +The Auth0 IP address allowlist is shared amongst all Auth0 tenants defined to a region. Never use the allowlist as the sole method of securing access to your legacy identity store; doing so could open up potential security vulnerabilities allowing unauthorized access to your users. +::: + +## Keep reading + +* [Create Custom Database Connections](/connections/database/custom-db/create-db-connection) +* [Custom Database Action Script Templates](/connections/database/custom-db/templates) +* [Handle Errors and Troubleshoot Your Custom DB Scripts](/connections/database/custom-db/error-handling) +* [Migrate Your Users to Auth0](/users/concepts/overview-user-migration) diff --git a/articles/connections/database/custom-db/templates/change-email.md b/articles/connections/database/custom-db/templates/change-email.md new file mode 100644 index 0000000000..3322d8573a --- /dev/null +++ b/articles/connections/database/custom-db/templates/change-email.md @@ -0,0 +1,46 @@ +--- +description: Custom database action script for changing a user's email. +toc: true +topics: + - connections + - custom-database +contentType: reference +useCase: + - customize-connections +--- +# Change Email Script + +The **Change Email** script implements the function executed when a change in the email address, or the email address verification status, for a user occurs. We recommend naming this function `changeEmail`. Typically the script is executed when a change in either email address and/or email address verification status is actioned via the Auth0 Dashboard or the Auth0 Management API. The script is only used in a legacy authentication scenario, and must be implemented if support is required for email address/status change via Auth0. + +The change email script is not configurable via the Auth0 Dashboard. There are no script templates available. You can use either the Auth0 [Deploy CLI Tool](/extensions/deploy-cli) or the Auth0 [Management API](/api/management/v2#!/Connections) to create or update the change email script. + +The changeEmail function should be defined as follows: + +```js +function changeEmail(email, newEmail, verified, callback) { + // TODO: implement your script + return callback(null); +} +``` + +::: warning +If you change any aspect of a connection via the Dashboard in Auth0, and that connection makes use of a **Change Email** script, then the script will be deleted. +::: + +| **Parameter** | **Description** | +| --- | --- | +| `email` | The email address for the user as the user identifying credential. | +| `newEmail` | The new email address for the user. | +| `verified` | The verified state of the new email address, passed as either a true or false value. Email verification status information is typically returned via `email_verified` as part of any user profile information returned (see `login` and `get user` for further details), so email verification state should be preserved in the legacy data store for future reference. | +| `callback` | Executed with up to two parameters. The first parameter is an indication of status: a `null` first parameter with a corresponding second parameter of `true` indicates that the operation executed successfully; a `null` first parameter with no corresponding second parameter (or one with a value of `false`) indicates that no password change was performed (possibly due to the user not being found). A non `null` first parameter value indicates that some error condition occurred. | + +<%= include('../_includes/_bp-error-object') %> + +## Keep reading + +* [Change Passwords](/connections/database/custom-db/templates/change-password) +* [Create](/connections/database/custom-db/templates/create) +* [Delete](/connections/database/custom-db/templates/delete) +* [Get User](/connections/database/custom-db/templates/get-user) +* [Login](/connections/database/custom-db/templates/login) +* [Verify](/connections/database/custom-db/templates/verify) diff --git a/articles/connections/database/custom-db/templates/change-password.md b/articles/connections/database/custom-db/templates/change-password.md new file mode 100644 index 0000000000..e39f947fea --- /dev/null +++ b/articles/connections/database/custom-db/templates/change-password.md @@ -0,0 +1,536 @@ +--- +description: Custom database action script templates for changing a user's password. +toc: true +topics: + - connections + - custom-database +contentType: reference +useCase: + - customize-connections +--- +# Change Password Script Templates + +The **Change Password** script implements the function executed to change the password associated with the user identity in the your legacy identity store. We recommend naming this function `changePassword`. The script is only used in a legacy authentication scenario. + +This script executes whenever a user tries to change their password; the user will receive the password reset email, which includes the link they need to follow to change their password. This script is **optional** however, a call to `changePassword` is typically preceded by a call to `getUser`, so if you implement the change password script you will also need to implement the [get user script](/connections/database/custom-db/templates/get-user). + +::: panel Best practice +While it’s not mandatory to implement the `changePassword` function, it is a recommended best practice. The `changePassword` function is required to for the password reset workflow recommended for [great customer experience](https://auth0.com/learn/password-reset/). +::: + +The script is executed whenever [password reset](/universal-login/password-reset) workflow is performed and also during password change workflow via the Auth0 Dashboard or the Auth0 Management API. + +The `changePassword` function implemented in the **Change Password** script should be defined as follows: + +```js +function changePassword(email, newPassword, callback) { + // TODO: implement your script + return callback(null, result); +} +``` + +| **Parameter** | **Description** | +| --- | --- | +| `email` | The email address for the user as the user identifying credential. | +| `password` | The new password credential for the user. The password credential for the user is passed to the script in plain text so care must be taken regarding its use. | +| `callback` | Executed with up to two parameters. The first parameter is an indication of status: a `null` first parameter with a corresponding second parameter of `true` indicates that the operation executed successfully; a `null` first parameter with no corresponding second parameter (or one with a value of `false`) indicates that no password change was performed (possibly due to the user not being found). A non `null` first parameter value indicates that some error condition occurred. | + +<%= include('../_includes/_bp-error-object') %> + +<%= include('../_includes/_panel-bcrypt-hash-encryption') %> + +## Language-specific script examples + +Auth0 provides sample scripts for use with the following languages/technologies: + +::: next-steps +* [JavaScript](/connections/database/custom-db/templates/change-password#javascript) +* [ASP.NET Membership Provider (MVC3 - Universal Providers)](/connections/database/custom-db/templates/change-password#asp-net-membership-provider-mvc3-universal-providers-) +* [ASP.NET Membership Provider (MVC4 - Simple Membership)](/connections/database/custom-db/templates/change-password#asp-net-membership-provider-mvc4-simple-membership-) +* [MongoDB](/connections/database/custom-db/templates/change-password#mongodb) +* [MySQL](/connections/database/custom-db/templates/change-password#mysql) +* [PostgreSQL](/connections/database/custom-db/templates/change-password#postgresql) +* [SQL Server](/connections/database/custom-db/templates/change-password#sql-server) +* [Windows Azure SQL Database](/connections/database/custom-db/templates/change-password#windows-azure-sql-database) +* [Request with Basic Auth](/connections/database/custom-db/templates/change-password#request-with-basic-auth) +::: + +### JavaScript + +``` +function changePassword(email, newPassword, callback) { + // This script should change the password stored for the current user in your + // database. It is executed when the user clicks on the confirmation link + // after a reset password request. + // The content and behavior of password confirmation emails can be customized + // here: https://manage.auth0.com/#/emails + // The `newPassword` parameter of this function is in plain text. It must be + // hashed/salted to match whatever is stored in your database. + // + // There are three ways that this script can finish: + // 1. The user's password was updated successfully: + // callback(null, true); + // 2. The user's password was not updated: + // callback(null, false); + // 3. Something went wrong while trying to reach your database: + // callback(new Error("my error message")); + // + // If an error is returned, it will be passed to the query string of the page + // to which the user is being redirected after clicking the confirmation link. + // For example, returning `callback(new Error("error"))` and redirecting to + // https://example.com would redirect to the following URL: + // https://example.com?email=alice%40example.com&message=error&success=false + + const msg = 'Please implement the Change Password script for this database ' + + 'connection at https://manage.auth0.com/#/connections/database'; + return callback(new Error(msg)); +} +``` + +### ASP.NET Membership Provider (MVC3 - Universal Providers) + +``` +function changePassword(email, newPassword, callback) { + + var crypto = require('crypto'); + var Connection = require('tedious').Connection; + var Request = require('tedious').Request; + var TYPES = require('tedious').TYPES + + var connection = new Connection({ + userName: 'the username', + password: 'the password', + server: 'the server', + options: { + database: 'the db name', + // encrypt: true for Windows Azure enable this + } + }); + + /** + * hashPassword + * + * This function creates a hashed version of the password to store in the database. + * + * @password {[string]} the password entered by the user + * @return {[string]} the hashed password + */ + function hashPassword(password, salt) { + // the default implementation uses HMACSHA256 and since Key length is 64 + // and default salt is 16 bytes, Membership will fill the buffer repeating the salt + var key = Buffer.concat([salt, salt, salt, salt]); + var hmac = crypto.createHmac('sha256', key); + hmac.update(Buffer.from(password, 'ucs2')); + var hashed = hmac.digest('base64'); + + return hashed; + } + + connection.on('debug', function(text) { + // if you have connection issues, uncomment this to get more detailed info + //console.log(text); + }).on('errorMessage', function(text) { + // this will show any errors when connecting to the SQL database or with the SQL statements + console.log(JSON.stringify(text)); + }); + + connection.on('connect', function (err) { + if (err) { + return callback(err); + } + updateMembershipUser(email, newPassword, function(err, wasUpdated) { + if (err) { + return callback(err); // this will return a 500 + } + + callback(null, wasUpdated); + }); + }); + + function updateMembershipUser(email, newPassword, callback) { + var salt = crypto.randomBytes(16); + var hashedPassword = hashPassword(newPassword, salt); + + var updateMembership = + 'UPDATE Memberships '+ + 'SET Password=@NewPassword, PasswordSalt=@NewSalt, LastPasswordChangedDate=GETDATE() '+ + 'WHERE Email=@Email'; + + var updateMembershipQuery = new Request(updateMembership, function (membershipErr, membershipCount) { + if (membershipErr) { + return callback(membershipErr); + } + callback(null, membershipCount > 0); + }); + + updateMembershipQuery.addParameter('NewPassword', TYPES.VarChar, hashedPassword); + updateMembershipQuery.addParameter('NewSalt', TYPES.VarChar, salt.toString('base64')); + updateMembershipQuery.addParameter('Email', TYPES.VarChar, email); + + connection.execSql(updateMembershipQuery); + } +} +``` + +### ASP.NET Membership Provider (MVC4 - Simple Membership) + +``` +function changePassword(email, newPassword, callback) { + + var crypto = require('crypto'); + var Connection = require('tedious').Connection; + var Request = require('tedious').Request; + var TYPES = require('tedious').TYPES + + var connection = new Connection({ + userName: 'the username', + password: 'the password', + server: 'the server', + options: { + database: 'the db name', + // encrypt: true for Windows Azure enable this + } + }); + + /** + * hashPassword + * + * This function hashes a password using HMAC SHA256 algorithm. + * + * @password {[string]} password to be hased + * @salt {[string]} salt to be used in the hashing process + * @callback {[function]} callback to be called after hashing the password + */ + function hashPassword(password, salt, callback) { + var iterations = 1000; + var passwordHashLength = 32; + + crypto.pbkdf2(password, salt, iterations, passwordHashLength, function (err, hashed) { + if (err) { + return callback(err); + } + var result = Buffer.concat([Buffer.from([0], 1), salt, Buffer.from(hashed, 'binary')]); + + var resultBase64 = result.toString('base64'); + + callback(null, resultBase64); + }); + + } + + connection.on('debug', function(text) { + // if you have connection issues, uncomment this to get more detailed info + //console.log(text); + }).on('errorMessage', function(text) { + // this will show any errors when connecting to the SQL database or with the SQL statements + console.log(JSON.stringify(text)); + }); + + connection.on('connect', function (err) { + if (err) { + return callback(err); + } + updateMembershipUser(email, newPassword, function(err, wasUpdated) { + if (err) { + return callback(err); // this will return a 500 + } + + callback(null, wasUpdated); + }); + }); + + function findUserId(email, callback) { + var findUserIdFromEmail = + 'SELECT UserProfile.UserId FROM ' + + 'UserProfile INNER JOIN webpages_Membership ' + + 'ON UserProfile.UserId = webpages_Membership.UserId ' + + 'WHERE UserName = @Email'; + + var findUserIdFromEmailQuery = new Request(findUserIdFromEmail, function (err, rowCount, rows) { + if (err) { + return callback(err); + } + + // No record found with that email + if (rowCount < 1) { + return callback(null, null); + } + + var userId = rows[0][0].value; + + callback(null, userId); + + }); + + findUserIdFromEmailQuery.addParameter('Email', TYPES.VarChar, email); + + connection.execSql(findUserIdFromEmailQuery); + } + + function updateMembershipUser(email, newPassword, callback) { + findUserId(email, function (err, userId) { + if (err) { + return callback(err); + } + + if (userId === null) { + return callback(); + } + + var salt = crypto.randomBytes(16); + + var updateMembership = + 'UPDATE webpages_Membership '+ + 'SET Password=@NewPassword, PasswordChangedDate=GETDATE() '+ + 'WHERE UserId=@UserId'; + + var updateMembershipQuery = new Request(updateMembership, function (err, rowCount) { + if (err) { + return callback(err); + } + + if (rowCount < 1) { + return callback(); + } + + callback(null, rowCount > 0); + }); + + hashPassword(newPassword, salt, function (err, hashedPassword) { + if (err) { + return callback(err); + } + + updateMembershipQuery.addParameter('NewPassword', TYPES.VarChar, hashedPassword); + updateMembershipQuery.addParameter('UserId', TYPES.VarChar, userId); + + connection.execSql(updateMembershipQuery); + }); + }); + } +} +``` + +### MongoDB + +``` +function changePassword(email, newPassword, callback) { + const bcrypt = require('bcrypt'); + const MongoClient = require('mongodb@3.1.4').MongoClient; + const client = new MongoClient('mongodb://user:pass@mymongoserver.com'); + + client.connect(function (err) { + if (err) return callback(err); + + const db = client.db('db-name'); + const users = db.collection('users'); + + bcrypt.hash(newPassword, 10, function (err, hash) { + if (err) { + client.close(); + return callback(err); + } + + users.update({ email: email }, { $set: { password: hash } }, function (err, count) { + client.close(); + if (err) return callback(err); + callback(null, count > 0); + }); + }); + }); +} +``` + +### MySQL + +``` +function changePassword(email, newPassword, callback) { + const mysql = require('mysql'); + const bcrypt = require('bcrypt'); + + const connection = mysql({ + host: 'localhost', + user: 'me', + password: 'secret', + database: 'mydb' + }); + + connection.connect(); + + const query = 'UPDATE users SET password = ? WHERE email = ?'; + + bcrypt.hash(newPassword, 10, function(err, hash) { + if (err) return callback(err); + + connection.query(query, [ hash, email ], function(err, results) { + if (err) return callback(err); + callback(null, results.length > 0); + }); + }); +} +``` + +### PostgreSQL + +``` +function changePassword (email, newPassword, callback) { + //this example uses the "pg" library + //more info here: https://github.com/brianc/node-postgres + + const bcrypt = require('bcrypt'); + const postgres = require('pg'); + + const conString = 'postgres://user:pass@localhost/mydb'; + postgres.connect(conString, function (err, client, done) { + if (err) return callback(err); + + bcrypt.hash(newPassword, 10, function (err, hash) { + if (err) return callback(err); + + const query = 'UPDATE users SET password = $1 WHERE email = $2'; + client.query(query, [hash, email], function (err, result) { + // NOTE: always call `done()` here to close + // the connection to the database + done(); + + return callback(err, result && result.rowCount > 0); + }); + }); + }); +} +``` + +### SQL Server + +``` +function changePassword (email, newPassword, callback) { + //this example uses the "tedious" library + //more info here: http://tediousjs.github.io/tedious/ + const bcrypt = require('bcrypt'); + const sqlserver = require('tedious@1.11.0'); + + const Connection = sqlserver.Connection; + const Request = sqlserver.Request; + const TYPES = sqlserver.TYPES; + + const connection = new Connection({ + userName: 'test', + password: 'test', + server: 'localhost', + options: { + database: 'mydb' + } + }); + + const query = 'UPDATE dbo.Users SET Password = @NewPassword WHERE Email = @Email'; + + connection.on('debug', function(text) { + console.log(text); + }).on('errorMessage', function(text) { + console.log(JSON.stringify(text, null, 2)); + }).on('infoMessage', function(text) { + console.log(JSON.stringify(text, null, 2)); + }); + + connection.on('connect', function (err) { + if (err) return callback(err); + + const request = new Request(query, function (err, rows) { + if (err) return callback(err); + callback(null, rows > 0); + }); + + bcrypt.hash(newPassword, 10, function (err, hash) { + if (err) return callback(err); + request.addParameter('NewPassword', TYPES.VarChar, hash); + request.addParameter('Email', TYPES.VarChar, email); + connection.execSql(request); + }); + }); +} +``` + +### Windows Azure SQL Database + +``` +function changePassword (email, newPassword, callback) { + //this example uses the "tedious" library + //more info here: http://pekim.github.io/tedious/index.html + + var Connection = require('tedious@1.11.0').Connection; + var Request = require('tedious@1.11.0').Request; + var TYPES = require('tedious@1.11.0').TYPES; + var bcrypt = require('bcrypt'); + + var connection = new Connection({ + userName: 'your-user@your-server-id.database.windows.net', + password: 'the-password', + server: 'your-server-id.database.windows.net', + options: { + database: 'mydb', + encrypt: true + } + }); + + var query = 'UPDATE dbo.Users SET Password = @NewPassword ' + + 'WHERE Email = @Email'; + + connection.on('debug', function(text) { + // Uncomment next line in order to enable debugging messages + // console.log(text); + }).on('errorMessage', function(text) { + console.log(JSON.stringify(text, null, 2)); + }).on('infoMessage', function(text) { + // Uncomment next line in order to enable information messages + // console.log(JSON.stringify(text, null, 2)); + }); + + connection.on('connect', function (err) { + if (err) { return callback(err); } + + var request = new Request(query, function (err, rows) { + if (err) { return callback(err); } + console.log('rows: ' + rows); + callback(null, rows > 0); + }); + + bcrypt.hash(newPassword, 10, function (err, hash) { + if (err) { return callback(err); } + request.addParameter('NewPassword', TYPES.VarChar, hash); + request.addParameter('Email', TYPES.VarChar, email); + connection.execSql(request); + }); + }); +} +``` + +### Request with Basic Auth + +``` +function changePassword (email, newPassword, callback) { + + var request = require('request'); + + request.put({ + url: 'https://myserviceurl.com/users', + json: { email: email, password: newPassword } + //for more options check: + //https://github.com/mikeal/request#requestoptions-callback + }, function (err, response, body) { + + if (err) return callback(err); + if (response.statusCode === 401) return callback(); + callback(null, body); + }); + +} +``` + +## Keep reading + +* [Create](/connections/database/custom-db/templates/create) +* [Delete](/connections/database/custom-db/templates/delete) +* [Get User](/connections/database/custom-db/templates/get-user) +* [Login](/connections/database/custom-db/templates/login) +* [Verify](/connections/database/custom-db/templates/verify) +* [Change Email](/connections/database/custom-db/templates/change-email) diff --git a/articles/connections/database/custom-db/templates/create.md b/articles/connections/database/custom-db/templates/create.md new file mode 100644 index 0000000000..8f8e287a03 --- /dev/null +++ b/articles/connections/database/custom-db/templates/create.md @@ -0,0 +1,594 @@ +--- +description: Custom database action script templates for user creation. +toc: true +topics: + - connections + - custom-database + - create-users +contentType: reference +useCase: + - customize-connections +--- +# Create Script Templates + +The **Create** script implements the function executed to create a user in your database. We recommend naming this function `create`. Use this script if you want new users to sign up via Auth0 so that Auth0 creates the users in your legacy data store. Not using the script doesn't prevent the creation of users by a mechanism external to Auth0. + +This script executes when a user signs up or when an administrator creates the user via the Auth0 Dashboard or Management API. When creating users, Auth0 calls the **Get User** script before the **Create** script. Be sure to implement both database action scripts if you are creating new users. When the script finishes execution, the **Login** script runs to verify that the user was created successfully. + +The `create` function implemented in the script should be defined as follows: + +```js +function create(user, callback) { + // TODO: implement your script + return callback(null); +} +``` + +| **Parameter** | **Description** | +| --- | --- | +| `user` | An object containing attributes associated with the user identity to be created. | +| `callback` | Executed with a single parameter. The parameter is an indication of status: a `null` indicates that the operation executed successfully, while a non `null` value indicates that some error condition occurred. | + +<%= include('../_includes/_bp-error-object') %> + +<%= include('../_includes/_panel-bcrypt-hash-encryption') %> + +## `user` object example + +```js +{ + client_id: "", + tenant: "", + email: "", + password: "", + username: "", + user_metadata: { + "language": "en" + }, + app_metadata: { + "plan": "full" + } +} +``` + +The `user` object can contain the following properties: + +| **Property** | **Description** | +| - | - | +| `client_id` | the client ID of the application for which the user signed up, or the API key if the user was created through the Auth0 Dashboard or Management API | +| `tenant` | the name of the Auth0 account | +| `email` | the user's email | +| `password` | the password entered by the user (in plain text) | +| `username` | required only if the custom database connection has [`Requires Username`](/connections/database/require-username) enabled +| `connection` | the name of the database connection | +| `user_metadata` | optional | +| `app_metadata` | optional | + +::: panel Best practice +If the custom database connection has [`Requires Username`](/connections/database/require-username) enabled, then `username` also needs to be used by any subsequent `login` or `getUser` execution, so you should store it in the legacy identity store. +::: + +While `user_metadata` and `app_metadata` are optional, if supplied, they do not need to be stored in the legacy identity store; Auth0 automatically stores these values as part of the [user profile](/users/concepts/overview-user-profile) record created internally. These values are (optionally) provided as a reference: their contents potentially being influential to legacy identity creation. + +::: note +Unlike with `login`, `app_metadata` is specified as-is and will not be renamed as `metadata`. +::: + +Finally, if you [create and use custom fields](/libraries/custom-signup#using-the-api) during the registration process, these properties are included in the `user` object as well. + +## Script execution results + +There are three ways a **Create** script can finish: + +| **Result** | **Description** | +| - | - | +| `callback(null);` | A user was successfully created | +| `callback(new ValidationError("user_exists", "my error message"));` | This user already exists in your database | +| `callback(new Error("my error message"));` | Something went wrong while trying to reach your database | + +## Language-specific script examples + +Auth0 provides sample scripts for use with the following languages/technologies: + +::: next-steps +* [JavaScript](/connections/database/custom-db/templates/create#javascript) +* [ASP.NET Membership Provider (MVC3 - Universal Providers)](/connections/database/custom-db/templates/create#asp-net-membership-provider-mvc3-universal-providers-) +* [ASP.NET Membership Provider (MVC4 - Simple Membership)](/connections/database/custom-db/templates/create#asp-net-membership-provider-mvc4-simple-membership-) +* [MongoDB](/connections/database/custom-db/templates/create#mongodb) +* [MySQL](/connections/database/custom-db/templates/create#mysql) +* [PostgreSQL](/connections/database/custom-db/templates/create#postgresql) +* [SQL Server](/connections/database/custom-db/templates/create#sql-server) +* [Windows Azure SQL Database](/connections/database/custom-db/templates/create#windows-azure-sql-database) +* [Request with Basic Auth](/connections/database/custom-db/templates/create#request-with-basic-auth) +::: + +### JavaScript + +``` +function create(user, callback) { + // This script should create a user entry in your existing database. It will + // be executed when a user attempts to sign up, or when a user is created + // through the Auth0 Dashboard or Management API. + // When this script has finished executing, the Login script will be + // executed immediately afterwards, to verify that the user was created + // successfully. + // + // The user object will always contain the following properties: + // * email: the user's email + // * password: the password entered by the user, in plain text + // * tenant: the name of this Auth0 account + // * client_id: the client ID of the application where the user signed up, or + // API key if created through the Management API or Auth0 Dashboard + // * connection: the name of this database connection + // + // There are three ways this script can finish: + // 1. A user was successfully created + // callback(null); + // 2. This user already exists in your database + // callback(new ValidationError("user_exists", "my error message")); + // 3. Something went wrong while trying to reach your database + // callback(new Error("my error message")); + + const msg = 'Please implement the Create script for this database connection ' + + 'at https://manage.auth0.com/#/connections/database'; + return callback(new Error(msg)); +} +``` + +### ASP.NET Membership Provider (MVC3 - Universal Providers) + +``` +function create(user, callback) { + const crypto = require('crypto'); + const sqlserver = require('tedious@1.11.0'); + + const Connection = sqlserver.Connection; + const Request = sqlserver.Request; + const TYPES = sqlserver.TYPES; + + const connection = new Connection({ + userName: 'the username', + password: 'the password', + server: 'the server', + options: { + database: 'the db name', + encrypt: true, + // Required to retrieve userId needed for Membership entity creation + rowCollectionOnRequestCompletion: true + } + }); + + const applicationId = 'your-application-id-goes-here'; + + /** + * hashPassword + * + * This function creates a hashed version of the password to store in the database. + * + * @password {[string]} the password entered by the user + * @return {[string]} the hashed password + */ + function hashPassword(password, salt) { + // the default implementation uses HMACSHA256 and since Key length is 64 + // and default salt is 16 bytes, Membership will fill the buffer repeating the salt + const key = Buffer.concat([salt, salt, salt, salt]); + const hmac = crypto.createHmac('sha256', key); + hmac.update(Buffer.from(password, 'ucs2')); + + return hmac.digest('base64'); + } + + connection.on('debug', function(text) { + // if you have connection issues, uncomment this to get more detailed info + // console.log(text); + }).on('errorMessage', function(text) { + // this will show any errors when connecting to the SQL database or with the SQL statements + console.log(JSON.stringify(text)); + }); + + connection.on('connect', function(err) { + if (err) { + return callback(err); + } + createMembershipUser(user, function(err, user) { + if (err) return callback(err); // this will return a 500 + if (!user) return callback(); // this will return a 401 + + callback(null, user); + }); + }); + + function createMembershipUser(user, callback) { + const userData = { + UserName: user.email, + ApplicationId: applicationId + }; + const createUser = + 'INSERT INTO Users (UserName, LastActivityDate, ApplicationId, UserId, IsAnonymous) ' + + 'OUTPUT Inserted.UserId ' + + 'VALUES (@UserName, GETDATE(), @ApplicationId, NEWID(), \'false\')'; + + const createUserQuery = new Request(createUser, function(err, rowCount, rows) { + if (err) return callback(err); + + // No records added + if (rowCount === 0) return callback(null); + + const userId = rows[0][0].value; + const salt = crypto.randomBytes(16); + const membershipData = { + ApplicationId: applicationId, + Email: user.email, + Password: hashPassword(user.password, salt), + PasswordSalt: salt.toString('base64'), + UserId: userId + }; + + const createMembership = + 'INSERT INTO Memberships (ApplicationId, UserId, Password, PasswordFormat, ' + + 'PasswordSalt, Email, isApproved, isLockedOut, CreateDate, LastLoginDate, ' + + 'LastPasswordChangedDate, LastLockoutDate, FailedPasswordAttemptCount, ' + + 'FailedPasswordAttemptWindowStart, FailedPasswordAnswerAttemptCount, ' + + 'FailedPasswordAnswerAttemptWindowsStart) ' + + 'VALUES ' + + '(@ApplicationId, @UserId, @Password, 1, @PasswordSalt, ' + + '@Email, \'false\', \'false\', GETDATE(), GETDATE(), GETDATE(), GETDATE(), 0, 0, 0, 0)'; + + const createMembershipQuery = new Request(createMembership, function(err, rowCount) { + if (err) return callback(err); + + if (rowCount === 0) return callback(null); + + callback(null, rowCount > 0); + }); + + createMembershipQuery.addParameter('ApplicationId', TYPES.VarChar, membershipData.ApplicationId); + createMembershipQuery.addParameter('Email', TYPES.VarChar, membershipData.Email); + createMembershipQuery.addParameter('Password', TYPES.VarChar, membershipData.Password); + createMembershipQuery.addParameter('PasswordSalt', TYPES.VarChar, membershipData.PasswordSalt); + createMembershipQuery.addParameter('UserId', TYPES.VarChar, membershipData.UserId); + + connection.execSql(createMembershipQuery); + }); + + createUserQuery.addParameter('UserName', TYPES.VarChar, userData.UserName); + createUserQuery.addParameter('ApplicationId', TYPES.VarChar, userData.ApplicationId); + + connection.execSql(createUserQuery); + } +} +``` + +### ASP.NET Membership Provider (MVC4 - Simple Membership) + +``` +function create(user, callback) { + const crypto = require('crypto'); + const sqlserver = require('tedious@1.11.0'); + + const Connection = sqlserver.Connection; + const Request = sqlserver.Request; + const TYPES = sqlserver.TYPES; + + const connection = new Connection({ + userName: 'the username', + password: 'the password', + server: 'the server', + options: { + database: 'the db name', + encrypt: true, + // Required to retrieve userId needed for Membership entity creation + rowCollectionOnRequestCompletion: true + } + }); + + /** + * hashPassword + * + * This function hashes a password using HMAC SHA256 algorithm. + * + * @password {[string]} password to be hased + * @salt {[string]} salt to be used in the hashing process + * @callback {[function]} callback to be called after hashing the password + */ + function hashPassword(password, salt, callback) { + const iterations = 1000; + const passwordHashLength = 32; + + crypto.pbkdf2(password, salt, iterations, passwordHashLength, 'sha1', function (err, hashed) { + if (err) return callback(err); + + const result = Buffer.concat([Buffer.from([0], 1), salt, Buffer.from(hashed, 'binary')]); + const resultBase64 = result.toString('base64'); + + callback(null, resultBase64); + }); + } + + connection.on('debug', function (text) { + // if you have connection issues, uncomment this to get more detailed info + // console.log(text); + }).on('errorMessage', function (text) { + // this will show any errors when connecting to the SQL database or with the SQL statements + console.log(JSON.stringify(text)); + }); + + connection.on('connect', function (err) { + if (err) return callback(err); + + const createUser = + 'INSERT INTO UserProfile (UserName) ' + + 'OUTPUT Inserted.UserId ' + + 'VALUES (@UserName)'; + + const createUserQuery = new Request(createUser, function (err, rowCount, rows) { + if (err || rowCount === 0) return callback(err); + + const userId = rows[0][0].value; + const salt = crypto.randomBytes(16); + + const createMembership = + 'INSERT INTO webpages_Membership ' + + '(UserId, CreateDate, IsConfirmed, PasswordFailuresSinceLastSuccess, Password, PasswordSalt) ' + + 'VALUES ' + + '(@UserId, GETDATE(), \'false\', 0, @Password, \'\')'; + + const createMembershipQuery = new Request(createMembership, function (err, rowCount) { + if (err || rowCount === 0) return callback(err); + + callback(null, rowCount > 0); + }); + + hashPassword(user.password, salt, function (err, hashedPassword) { + if (err) return callback(err); + createMembershipQuery.addParameter('Password', TYPES.VarChar, hashedPassword); + createMembershipQuery.addParameter('PasswordSalt', TYPES.VarChar, salt.toString('base64')); + createMembershipQuery.addParameter('UserId', TYPES.VarChar, userId); + + connection.execSql(createMembershipQuery); + }); + }); + + createUserQuery.addParameter('UserName', TYPES.VarChar, user.email); + + connection.execSql(createUserQuery); + }); +} +``` + +### MongoDB + +``` +function create(user, callback) { + const bcrypt = require('bcrypt'); + const MongoClient = require('mongodb@3.1.4').MongoClient; + const client = new MongoClient('mongodb://user:pass@mymongoserver.com'); + + client.connect(function (err) { + if (err) return callback(err); + + const db = client.db('db-name'); + const users = db.collection('users'); + + users.findOne({ email: user.email }, function (err, withSameMail) { + if (err || withSameMail) { + client.close(); + return callback(err || new Error('the user already exists')); + } + + bcrypt.hash(user.password, 10, function (err, hash) { + if (err) { + client.close(); + return callback(err); + } + + user.password = hash; + users.insert(user, function (err, inserted) { + client.close(); + + if (err) return callback(err); + callback(null); + }); + }); + }); + }); +} +``` + +### MySQL + +``` +function create(user, callback) { + const mysql = require('mysql'); + const bcrypt = require('bcrypt'); + + const connection = mysql({ + host: 'localhost', + user: 'me', + password: 'secret', + database: 'mydb' + }); + + connection.connect(); + + const query = 'INSERT INTO users SET ?'; + + bcrypt.hash(user.password, 10, function(err, hash) { + if (err) return callback(err); + + const insert = { + password: hash, + email: user.email + }; + + connection.query(query, insert, function(err, results) { + if (err) return callback(err); + if (results.length === 0) return callback(); + callback(null); + }); + }); +} +``` + +### PostgreSQL + +``` +function create(user, callback) { + //this example uses the "pg" library + //more info here: https://github.com/brianc/node-postgres + + const bcrypt = require('bcrypt'); + const postgres = require('pg'); + + const conString = 'postgres://user:pass@localhost/mydb'; + postgres.connect(conString, function (err, client, done) { + if (err) return callback(err); + + bcrypt.hash(user.password, 10, function (err, hashedPassword) { + if (err) return callback(err); + + const query = 'INSERT INTO users(email, password) VALUES ($1, $2)'; + client.query(query, [user.email, hashedPassword], function (err, result) { + // NOTE: always call `done()` here to close + // the connection to the database + done(); + + return callback(err); + }); + }); + }); +} +``` + +### SQL Server + +``` + +function create(user, callback) { + //this example uses the "tedious" library + //more info here: http://pekim.github.io/tedious/index.html + const bcrypt = require('bcrypt'); + const sqlserver = require('tedious@1.11.0'); + + const Connection = sqlserver.Connection; + const Request = sqlserver.Request; + const TYPES = sqlserver.TYPES; + + const connection = new Connection({ + userName: 'test', + password: 'test', + server: 'localhost', + options: { + database: 'mydb' + } + }); + + const query = 'INSERT INTO dbo.Users SET Email = @Email, Password = @Password'; + + connection.on('debug', function(text) { + console.log(text); + }).on('errorMessage', function(text) { + console.log(JSON.stringify(text, null, 2)); + }).on('infoMessage', function(text) { + console.log(JSON.stringify(text, null, 2)); + }); + + connection.on('connect', function (err) { + if (err) return callback(err); + + const request = new Request(query, function (err, rows) { + if (err) return callback(err); + callback(null); + }); + + bcrypt.hash(user.password, 10, function(err, hash) { + if (err) return callback(err); + request.addParameter('Email', TYPES.VarChar, user.email); + request.addParameter('Password', TYPES.VarChar, hash); + connection.execSql(request); + }); + }); +} +``` + +### Windows Azure SQL Database + +``` +function create (user, callback) { + //this example uses the "tedious" library + //more info here: http://pekim.github.io/tedious/index.html + + var Connection = require('tedious@1.11.0').Connection; + var Request = require('tedious@1.11.0').Request; + var TYPES = require('tedious@1.11.0').TYPES; + var bcrypt = require('bcrypt'); + + var connection = new Connection({ + userName: 'your-user@your-server-id.database.windows.net', + password: 'the-password', + server: 'your-server-id.database.windows.net', + options: { + database: 'mydb', + encrypt: true + } + }); + + var query = "INSERT INTO users (Email, Password) VALUES (@Email, @Password)"; + + connection.on('debug', function(text) { + // Uncomment next line in order to enable debugging messages + // console.log(text); + }).on('errorMessage', function(text) { + console.log(JSON.stringify(text, null, 2)); + }).on('infoMessage', function(text) { + // Uncomment next line in order to enable information messages + // console.log(JSON.stringify(text, null, 2)); + }); + + connection.on('connect', function (err) { + if (err) { return callback(err); } + + var request = new Request(query, function (err, rows) { + if (err) { return callback(err); } + console.log('rows: ' + rows); + callback(null); + }); + + bcrypt.hash(user.password, 10, function (err, hashedPassword) { + if (err) { return callback(err); } + request.addParameter('Email', TYPES.VarChar, user.email); + request.addParameter('Password', TYPES.VarChar, hashedPassword); + connection.execSql(request); + }); + + }); +} +``` + +### Request with Basic Auth + +``` +function create(user, callback) { + const request = require('request'); + + request.post({ + url: 'https://myserviceurl.com/users', + json: user + //for more options check: + //https://github.com/mikeal/request#requestoptions-callback + }, function(err, response, body) { + if (err) return callback(err); + + callback(null); + }); +} +``` + +## Keep reading + +* [Change Passwords](/connections/database/custom-db/templates/change-password) +* [Delete](/connections/database/custom-db/templates/delete) +* [Get User](/connections/database/custom-db/templates/get-user) +* [Login](/connections/database/custom-db/templates/login) +* [Verify](/connections/database/custom-db/templates/verify) +* [Change Email](/connections/database/custom-db/templates/change-email) diff --git a/articles/connections/database/custom-db/templates/delete.md b/articles/connections/database/custom-db/templates/delete.md new file mode 100644 index 0000000000..ba548b495c --- /dev/null +++ b/articles/connections/database/custom-db/templates/delete.md @@ -0,0 +1,366 @@ +--- +description: Custom database action script templates for user deletion. +toc: true +topics: + - connections + - custom-database +contentType: reference +useCase: + - customize-connections +--- +# Delete Script Templates + +The **Delete** script implements the function executed in order to delete the specified user identity from the legacy identity store. We recommend naming this function `deleteUser` (which will also mitigate clashes with the JavaScript `delete` keyword). The script is only used in a legacy authentication scenario if you want use Auth0 to delete users from your legacy data store. + +::: warning +Deleting a user using the Auth0 Dashboard or the Auth0 Management API performs deletion of both the user profile and the user identity. If you do not implement this script correctly then this will not be done as an atomic operation, which may leave a user identity still in existence even after the user’s profile has been removed. Conversely, deleting a user identity outside of Auth0 will typically leave a disconnected (orphaned) profile in Auth0 that has no associated user identity. This may cause unpredictable issues. +::: + +The `deleteUser` function should be defined as follows: + +```js +function deleteUser(id, callback) { + // TODO: implement your script + return callback(null); +} +``` + +| **Parameter** | **Description** | +| --- | --- | +| `id` | The identifier of the user. This is the connection specific identifier returned as the user_id value from either the `login` or `getUser` function. | +| `callback` | Executed with a single parameter. The one and only parameter is an indication of status: a `null` value indicates successful operation, whereas a non `null` value indicates that some error condition occurred. | + +<%= include('../_includes/_bp-error-object') %> + +<%= include('../_includes/_panel-bcrypt-hash-encryption') %> + +## Sample Scripts + +Auth0 provides sample scripts for use with the following languages/technologies: + +::: next-steps +* [JavaScript](/connections/database/custom-db/templates/delete#javascript) +* [ASP.NET Membership Provider (MVC3 - Universal Providers)](/connections/database/custom-db/templates/delete#asp-net-membership-provider-mvc3-universal-providers-) +* [ASP.NET Membership Provider (MVC4 - Simple Membership)](/connections/database/custom-db/templates/delete#asp-net-membership-provider-mvc4-simple-membership-) +* [MongoDB](/connections/database/custom-db/templates/delete#mongodb) +* [MySQL](/connections/database/custom-db/templates/delete#mysql) +* [PostgreSQL](/connections/database/custom-db/templates/delete#postgresql) +* [SQL Server](/connections/database/custom-db/templates/delete#sql-server) +* [Windows Azure SQL Database](/connections/database/custom-db/templates/delete#windows-azure-sql-database) +* [Request with Basic Auth](/connections/database/custom-db/templates/delete#request-with-basic-auth) +::: + +### JavaScript + +``` +function remove (id, callback) { + // This script remove a user from your existing database. + // It is executed whenever a user is deleted from the Management API or Auth0 dashboard. + // + // There are two ways that this script can finish: + // 1. The user was removed successfully: + // callback(null); + // 2. Something went wrong while trying to reach your database: + // callback(new Error("my error message")); + + var msg = "Please implement the Delete script for this database " + + "connection at https://manage.auth0.com/#/connections/database"; + return callback(new Error(msg)); +} +``` + +### ASP.NET Membership Provider (MVC3 - Universal Providers) + +``` +function remove(id, callback) { + const sqlserver = require('tedious@1.11.0'); + + const Connection = sqlserver.Connection; + const Request = sqlserver.Request; + const TYPES = sqlserver.TYPES; + + const connection = new Connection({ + userName: 'the username', + password: 'the password', + server: 'the server', + options: { + database: 'the db name', + encrypt: true, + // Required to retrieve userId needed for Membership entity creation + rowCollectionOnRequestCompletion: true + } + }); + + connection.on('debug', function(text) { + // if you have connection issues, uncomment this to get more detailed info + // console.log(text); + }).on('errorMessage', function(text) { + // this will show any errors when connecting to the SQL database or with the SQL statements + console.log(JSON.stringify(text)); + }); + + connection.on('connect', function(err) { + if (err) return callback(err); + + executeDelete(['Memberships', 'Users'], function(err) { + if (err) return callback(err); + + callback(null); + }); + }); + + function executeDelete(tables, callback) { + const query = tables.map(function(table) { + return 'DELETE FROM ' + table + ' WHERE UserId = @UserId'; + }).join(';'); + const request = new Request(query, function(err) { + if (err) return callback(err); + + callback(null); + }); + request.addParameter('UserId', TYPES.VarChar, id); + connection.execSql(request); + } +} +``` + +### ASP.NET Membership Provider (MVC4 - Simple Membership) + +``` +function remove(id, callback) { + const sqlserver = require('tedious@1.11.0'); + + const Connection = sqlserver.Connection; + const Request = sqlserver.Request; + const TYPES = sqlserver.TYPES; + + const connection = new Connection({ + userName: 'the username', + password: 'the password', + server: 'the server', + options: { + database: 'the db name', + encrypt: true, + // Required to retrieve userId needed for Membership entity creation + rowCollectionOnRequestCompletion: true + } + }); + + connection.on('debug', function (text) { + // if you have connection issues, uncomment this to get more detailed info + // console.log(text); + }).on('errorMessage', function (text) { + // this will show any errors when connecting to the SQL database or with the SQL statements + console.log(JSON.stringify(text)); + }); + + connection.on('connect', function (err) { + if (err) return callback(err); + executeDelete(['webpages_Membership', 'UserProfile'], function (err) { + if (err) return callback(err); + callback(null); + }); + }); + + function executeDelete(tables, callback) { + const query = tables.map(function (table) { + return 'DELETE FROM ' + table + ' WHERE UserId = @UserId'; + }).join(';'); + const request = new Request(query, function (err) { + if (err) return callback(err); + callback(null); + }); + request.addParameter('UserId', TYPES.VarChar, id); + connection.execSql(request); + } +} +``` + +### MongoDB + +``` +function remove(id, callback) { + const MongoClient = require('mongodb@3.1.4').MongoClient; + const client = new MongoClient('mongodb://user:pass@mymongoserver.com'); + + client.connect(function (err) { + if (err) return callback(err); + + const db = client.db('db-name'); + const users = db.collection('users'); + + users.remove({ _id: id }, function (err) { + client.close(); + + if (err) return callback(err); + callback(null); + }); + }); + +} +``` + +### MySQL + +``` +function remove(id, callback) { + const mysql = require('mysql'); + + const connection = mysql({ + host: 'localhost', + user: 'me', + password: 'secret', + database: 'mydb' + }); + + connection.connect(); + + const query = 'DELETE FROM users WHERE id = ?'; + + connection.query(query, [ id ], function(err) { + if (err) return callback(err); + callback(null); + }); +} +``` + +### PostgreSQL + +``` +function remove(id, callback) { + //this example uses the "pg" library + //more info here: https://github.com/brianc/node-postgres + + const postgres = require('pg'); + + const conString = 'postgres://user:pass@localhost/mydb'; + postgres.connect(conString, function (err, client, done) { + if (err) return callback(err); + + const query = 'DELETE FROM users WHERE id = $1'; + client.query(query, [id], function (err) { + // NOTE: always call `done()` here to close + // the connection to the database + done(); + + return callback(err); + }); + }); +} +``` + +### SQL Server + +``` +function remove(id, callback) { + // this example uses the "tedious" library + // more info here: http://pekim.github.io/tedious/index.html + const sqlserver = require('tedious@1.11.0'); + + const Connection = sqlserver.Connection; + const Request = sqlserver.Request; + const TYPES = sqlserver.TYPES; + + const connection = new Connection({ + userName: 'test', + password: 'test', + server: 'localhost', + options: { + database: 'mydb' + } + }); + + const query = 'DELETE FROM dbo.Users WHERE id = @UserId'; + + connection.on('debug', function (text) { + console.log(text); + }).on('errorMessage', function (text) { + console.log(JSON.stringify(text, null, 2)); + }).on('infoMessage', function (text) { + console.log(JSON.stringify(text, null, 2)); + }); + + connection.on('connect', function (err) { + if (err) return callback(err); + + const request = new Request(query, function (err) { + if (err) return callback(err); + callback(null); + }); + + request.addParameter('UserId', TYPES.VarChar, id); + + connection.execSql(request); + }); +} +``` + +### Windows Azure SQL Database + +``` +function remove (id, callback) { + // this example uses the "tedious" library + // more info here: http://pekim.github.io/tedious/index.html + + var Connection = require('tedious@1.11.0').Connection; + var Request = require('tedious@1.11.0').Request; + var TYPES = require('tedious@1.11.0').TYPES; + + var connection = new Connection({ + userName: 'your-user@your-server-id.database.windows.net', + password: 'the-password', + server: 'your-server-id.database.windows.net', + options: { + database: 'mydb', + encrypt: true + } + }); + + connection.on('debug', function (text) { + console.log(text); + }).on('errorMessage', function (text) { + console.log(JSON.stringify(text, null, 2)); + }).on('infoMessage', function (text) { + console.log(JSON.stringify(text, null, 2)); + }); + + connection.on('connect', function (err) { + if (err) { return callback(err); } + var query = 'DELETE FROM users WHERE id = @UserId'; + + var request = new Request(query, function (err) { + if (err) { return callback(err); } + callback(null); + }); + + request.addParameter('UserId', TYPES.VarChar, id); + + connection.execSql(request); + }); +} +``` + +### Request with Basic Auth + +``` +function remove (id, callback) { + + request.del({ + url: 'https://myserviceurl.com/users/' + id + // for more options check: + // https://github.com/mikeal/request#requestoptions-callback + }, function (err, response, body) { + if (err) { return callback(err); } + callback(null); + }); +} +``` + +## Keep reading + +* [Change Passwords](/connections/database/custom-db/templates/change-password) +* [Create](/connections/database/custom-db/templates/create) +* [Get User](/connections/database/custom-db/templates/get-user) +* [Login](/connections/database/custom-db/templates/login) +* [Verify](/connections/database/custom-db/templates/verify) +* [Change Email](/connections/database/custom-db/templates/change-email) diff --git a/articles/connections/database/custom-db/templates/get-user.md b/articles/connections/database/custom-db/templates/get-user.md new file mode 100644 index 0000000000..0046674c26 --- /dev/null +++ b/articles/connections/database/custom-db/templates/get-user.md @@ -0,0 +1,427 @@ +--- +description: Custom database action script templates for user search. +toc: true +topics: + - connections + - custom-database + - get-users +contentType: reference +useCase: + - customize-connections +--- +# Get User Script Templates + +The **Get User** script implements the function executed to determine the current state of existence of a user. We recommend naming this function `getUser`. For automatic migration, the script is mandatory. + +For automatic migration, the script is executed during the password reset workflow (e.g., with a forgotten password in Universal Login). For legacy authentication, it is executed whenever the following operations occur: create user, change email, change password, and password reset. + +The `getUser` function should be defined as follows: + +```js +function getUser(email, callback) { + // TODO: implement your script + return callback(null, profile); +} +``` + +| **Parameter** | **Description** | +| --- | --- | +| `email` | The email address for the user as the user identifying credential. If **Requires Username** is enabled for your connection, the **Get User** script may run multiple times for some transactions (ex. Creating a user, or requesting a password reset link). In these cases the value of the parameter will sometimes be a username instead of an email. Your code should be able to handle either value and always return the same profile for a given user regardless of whether they were looked up by email or username. | +| `callback` | Executed with up to two parameters. The first parameter is an indication of status: a `null` first parameter with a corresponding second parameter indicates that the operation executed successfully; a `null` first parameter with no corresponding second parameter indicates that no user was found, while a non `null` first parameter value indicates that some error condition occurred. If the first parameter is `null` then the second parameter should be the profile for the user in JSON format (if a user was found). If the first parameter is `null` and no user was found, or if the first parameter is non `null`, then the second parameter can be omitted. The second parameter is the `profile` for the user. This should be supplied as a JSON object in normalized user profile form. See the [**Login**](/connections/database/custom-db/templates/login#callback-profile-example) script for details. | + +<%= include('../_includes/_bp-error-object') %> + +::: warning +When creating users, Auth0 calls the **Get User** script before the **Create** script. Be sure to implement both database action scripts if you are creating new users. +::: + +## Language-specific script examples + +Auth0 provides sample scripts for use with the following languages/technologies: + +::: next-steps +* [JavaScript](/connections/database/custom-db/templates/get-user#javascript) +* [ASP.NET Membership Provider (MVC3 - Universal Providers)](/connections/database/custom-db/templates/get-user#asp-net-membership-provider-mvc3-universal-providers-) +* [ASP.NET Membership Provider (MVC4 - Simple Membership)](/connections/database/custom-db/templates/get-user#asp-net-membership-provider-mvc4-simple-membership-) +* [MongoDB](/connections/database/custom-db/templates/get-user#mongodb) +* [MySQL](/connections/database/custom-db/templates/get-user#mysql) +* [PostgreSQL](/connections/database/custom-db/templates/get-user#postgresql) +* [SQL Server](/connections/database/custom-db/templates/get-user#sql-server) +* [Windows Azure SQL Database](/connections/database/custom-db/templates/get-user#windows-azure-sql-database) +* [Request with Basic Auth](/connections/database/custom-db/templates/get-user#request-with-basic-auth) +* [Stormpath](/connections/database/custom-db/templates/get-user#stormpath) +::: + +### JavaScript + +``` +function getByEmail(email, callback) { + // This script should retrieve a user profile from your existing database, + // without authenticating the user. + // It is used to check if a user exists before executing flows that do not + // require authentication (signup and password reset). + // + // There are three ways this script can finish: + // 1. A user was successfully found. The profile should be in the following + // format: https://auth0.com/docs/users/normalized/auth0/normalized-user-profile-schema. + // callback(null, profile); + // 2. A user was not found + // callback(null); + // 3. Something went wrong while trying to reach your database: + // callback(new Error("my error message")); + + const msg = 'Please implement the Get User script for this database connection ' + + 'at https://manage.auth0.com/#/connections/database'; + return callback(new Error(msg)); +} +``` + +### ASP.NET Membership Provider (MVC3 - Universal Providers) + +``` +function getByEmail(email, callback) { + const sqlserver = require('tedious@1.11.0'); + + const Connection = sqlserver.Connection; + const Request = sqlserver.Request; + const TYPES = sqlserver.TYPES; + + const connection = new Connection({ + userName: 'the username', + password: 'the password', + server: 'the server', + options: { + database: 'the db name', + encrypt: true // for Windows Azure + } + }); + + connection.on('debug', function(text) { + // if you have connection issues, uncomment this to get more detailed info + //console.log(text); + }).on('errorMessage', function(text) { + // this will show any errors when connecting to the SQL database or with the SQL statements + console.log(JSON.stringify(text)); + }); + + connection.on('connect', function(err) { + if (err) return callback(err); + + var user = {}; + const query = + 'SELECT Memberships.UserId, Email, Users.UserName ' + + 'FROM Memberships INNER JOIN Users ' + + 'ON Users.UserId = Memberships.UserId ' + + 'WHERE Memberships.Email = @Username OR Users.UserName = @Username'; + + const getMembershipQuery = new Request(query, function(err, rowCount) { + if (err) return callback(err); + if (rowCount < 1) return callback(); + + callback(null, user); + }); + + getMembershipQuery.addParameter('Username', TYPES.VarChar, email); + + getMembershipQuery.on('row', function(fields) { + user = { + user_id: fields.UserId.value, + nickname: fields.UserName.value, + email: fields.Email.value + }; + }); + + connection.execSql(getMembershipQuery); + }); +} +``` + +### ASP.NET Membership Provider (MVC4 - Simple Membership) + +``` +function getByEmail(email, callback) { + const sqlserver = require('tedious@1.11.0'); + + const Connection = sqlserver.Connection; + const Request = sqlserver.Request; + const TYPES = sqlserver.TYPES; + + const connection = new Connection({ + userName: 'the username', + password: 'the password', + server: 'the server', + options: { + database: 'the db name', + encrypt: true // for Windows Azure + } + }); + + connection.on('debug', function(text) { + // if you have connection issues, uncomment this to get more detailed info + //console.log(text); + }).on('errorMessage', function(text) { + // this will show any errors when connecting to the SQL database or with the SQL statements + console.log(JSON.stringify(text)); + }); + + connection.on('connect', function(err) { + if (err) return callback(err); + + var user = {}; + const query = + 'SELECT webpages_Membership.UserId, UserName, UserProfile.UserName from webpages_Membership ' + + 'INNER JOIN UserProfile ON UserProfile.UserId = webpages_Membership.UserId ' + + 'WHERE UserProfile.UserName = @Username'; + + const getMembershipQuery = new Request(query, function (err, rowCount) { + if (err) return callback(err); + if (rowCount < 1) return callback(); + + callback(null, user); + }); + + getMembershipQuery.addParameter('Username', TYPES.VarChar, email); + + getMembershipQuery.on('row', function (fields) { + user = { + user_id: fields.UserId.value, + nickname: fields.UserName.value, + email: fields.UserName.value + }; + }); + + connection.execSql(getMembershipQuery); + }); +} +``` + +### MongoDB + +``` +function getByEmail(email, callback) { + const MongoClient = require('mongodb@3.1.4').MongoClient; + const client = new MongoClient('mongodb://user:pass@mymongoserver.com'); + + client.connect(function (err) { + if (err) return callback(err); + + const db = client.db('db-name'); + const users = db.collection('users'); + + users.findOne({ email: email }, function (err, user) { + client.close(); + + if (err) return callback(err); + if (!user) return callback(null, null); + + return callback(null, { + user_id: user._id.toString(), + nickname: user.nickname, + email: user.email + }); + }); + }); +} +``` + +### MySQL + +``` +function getByEmail(email, callback) { + const mysql = require('mysql'); + + const connection = mysql({ + host: 'localhost', + user: 'me', + password: 'secret', + database: 'mydb' + }); + + connection.connect(); + + const query = 'SELECT id, nickname, email FROM users WHERE email = ?'; + + connection.query(query, [ email ], function(err, results) { + if (err || results.length === 0) return callback(err || null); + + const user = results[0]; + callback(null, { + user_id: user.id.toString(), + nickname: user.nickname, + email: user.email + }); + }); +} +``` + +### PostgreSQL + +``` +function loginByEmail(email, callback) { + //this example uses the "pg" library + //more info here: https://github.com/brianc/node-postgres + + const postgres = require('pg'); + + const conString = 'postgres://user:pass@localhost/mydb'; + postgres.connect(conString, function (err, client, done) { + if (err) return callback(err); + + const query = 'SELECT id, nickname, email FROM users WHERE email = $1'; + client.query(query, [email], function (err, result) { + // NOTE: always call `done()` here to close + // the connection to the database + done(); + + if (err || result.rows.length === 0) return callback(err); + + const user = result.rows[0]; + + return callback(null, { + user_id: user.id, + nickname: user.nickname, + email: user.email + }); + }); + }); +} +``` + +### SQL Server + +``` +function getByEmail(email, callback) { + //this example uses the "tedious" library + //more info here: http://pekim.github.io/tedious/index.html + const sqlserver = require('tedious@1.11.0'); + + const Connection = sqlserver.Connection; + const Request = sqlserver.Request; + const TYPES = sqlserver.TYPES; + + const connection = new Connection({ + userName: 'test', + password: 'test', + server: 'localhost', + options: { + database: 'mydb' + } + }); + + const query = 'SELECT Id, Nickname, Email FROM dbo.Users WHERE Email = @Email'; + + connection.on('debug', function (text) { + console.log(text); + }).on('errorMessage', function (text) { + console.log(JSON.stringify(text, null, 2)); + }).on('infoMessage', function (text) { + console.log(JSON.stringify(text, null, 2)); + }); + + connection.on('connect', function (err) { + if (err) return callback(err); + + const request = new Request(query, function (err, rowCount, rows) { + if (err) return callback(err); + + callback(null, { + user_id: rows[0][0].value, + nickname: rows[0][1].value, + email: rows[0][2].value + }); + }); + + request.addParameter('Email', TYPES.VarChar, email); + connection.execSql(request); + }); +} +``` + +### Windows Azure SQL Database + +``` +function getByEmail (name, callback) { + var profile = { + user_id: "103547991597142817347", + nickname: "johnfoo", + email: "johnfoo@gmail.com", + name: "John Foo", + given_name: "John", + family_name: "Foo" + }; + + callback(null, profile); +} +``` + +### Request with Basic Auth + +``` +function loginByEmail(email, callback) { + const request = require('request'); + + request.get({ + url: 'https://myserviceurl.com/users-by-email/' + email + //for more options check: + //https://github.com/mikeal/request#requestoptions-callback + }, function(err, response, body) { + if (err) return callback(err); + + const user = JSON.parse(body); + + callback(null, { + user_id: user.user_id.toString(), + nickname: user.nickname, + email: user.email + }); + }); +} +``` + +### Stormpath + +``` +function getByEmail(email, callback) { + // Replace the YOUR-STORMPATH-CLIENT-ID with your Stormpath ID + var url = 'https://api.stormpath.com/v1/applications/{YOUR-STORMPATH-CLIENT-ID}/accounts'; + // Add your Stormpath API Client ID and Secret + var apiCredentials = { + user : 'YOUR-STORMPATH-API-ID', + password: 'YOUR-STORMPATH-API-SECRET' + }; + + // Make a GET request to find a user by email + request({ + url: url, + method: 'GET', + auth: apiCredentials, + qs: { q: email }, + json: true + }, function (error, response, body) { + if (response.statusCode !== 200) return callback(); + + var user = body.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 + }); + }); +} +``` + +## Keep reading + +* [Change Passwords](/connections/database/custom-db/templates/change-password) +* [Create](/connections/database/custom-db/templates/create) +* [Delete](/connections/database/custom-db/templates/delete) +* [Login](/connections/database/custom-db/templates/login) +* [Verify](/connections/database/custom-db/templates/verify) +* [Change Email](/connections/database/custom-db/templates/change-email) diff --git a/articles/connections/database/custom-db/templates/index.md b/articles/connections/database/custom-db/templates/index.md new file mode 100644 index 0000000000..66a1318d9f --- /dev/null +++ b/articles/connections/database/custom-db/templates/index.md @@ -0,0 +1,68 @@ +--- +description: Learn about custom database action script templates. +topics: + - connections + - custom-database + - templates +contentType: + - index + - concept +useCase: + - customize-connections + - script-templates +--- +# Custom Database Action Script Templates + +<%= include('../_includes/_panel-feature-availability') %> + +If you have your own database (known as a legacy data store in Auth0) containing user identity data, you can use it as an identity provider to authenticate users. +You create and configure the connection to your legacy data store as a custom database in Auth0. You can choose to migrate data to Auth0's data store from your legacy database incrementally over time, or you can continue to use it without migrating data. We provide script templates to perform functions on the custom database that you can use and customize. + +There are two different types of custom database scripts: + +* **Automatic Migration**: Whenever a user logs into Auth0, if the user is not yet in Auth0, the script will check the legacy database to see if the user exists there. If found and the **Import users to Auth0** flag is turned on, the user data migrates the user to Auth0 data store. This capability is sometimes called **trickle migration** or **lazy migration**. + +* **Legacy Database**: Auth0 will always query the underlying database when a user tries to log in, is created, changes their password, verifies their email, or is deleted. If found and the **Import users to Auth0** flag is **not** turned on, user data stays in the legacy database and does **not** migrate to Auth0. + +Auth0 provides the following custom database action scripts: + +* [Change Passwords](/connections/database/custom-db/templates/change-password) +* [Create](/connections/database/custom-db/templates/create) +* [Delete](/connections/database/custom-db/templates/delete) +* [Get User](/connections/database/custom-db/templates/get-user) +* [Login](/connections/database/custom-db/templates/login) +* [Verify](/connections/database/custom-db/templates/verify) +* [Change Email](/connections/database/custom-db/templates/change-email) + +<%= include('../../../../_includes/_ip_whitelist') %> + +## Script execution + +As described in the [Custom Database Connections Overview](/connections/database/custom-db/custom-db-connection-overview#how-it-works), a custom database connection type allows you to configure action scripts: custom code that is used when interfacing with your legacy identity store. Each action script is essentially a named JavaScript function that is passed a number of parameters, with the name of the function and the parameters passed depending on the script. + +### Limits + +Action script execution supports the asynchronous nature of JavaScript, and constructs such as [Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) objects can be used. Asynchronous processing effectively results in suspension pending completion of an operation, and an Auth0 serverless Webtask container typically has a 20-second execution limit, after which the container may be recycled. Recycling a container due to this limit will prematurely terminate operation, ultimately resulting in an error condition being returned (as well as resulting in a potential reset of the `global` object). + +### Completion and the `callback` function + +The `callback` function supplied to each action script effectively acts as a signal to indicate completion of operation. An action script should complete immediately following a call to the `callback` function (either implicitly or by explicitly executing a JavaScript return statement) and should refrain from any other operation. + +::: warning +The Auth0 supplied `callback` function must be called exactly **once**; calling the function more than once within an action script will lead to unpredictable results and/or errors. +::: + +::: note +Where `callback` is executed with no parameters, as in `callback()`, the implication is that function has been called as though `callback(null)` had been executed. +::: + +If an action script uses asynchronous processing, then a call to the `callback` function must be deferred to the point where asynchronous processing completes, and must be the final thing called. Asynchronous execution will result in a JavaScript `callback` being executed after the asynchronous operation is complete; this callback is typically fired at some point after the main (synchronous) body of a JavaScript function completes. + +::: warning +Failure to execute the `callback` function will result in a stall of execution, and ultimately in an error condition being returned. The action script must call the `callback` function exactly once: the `callback` function must be called at least once in order to prevent stall of execution, however it must not be called more than once otherwise unpredictable results and/or errors will occur. +::: + +## Keep reading + +* [Custom Database Action Script Execution Best Practices](/best-practices/custom-db-connections/execution) +* [Handle Errors and Troubleshoot Your Custom DB Scripts](/connections/database/custom-db/error-handling) diff --git a/articles/connections/database/custom-db/templates/login.md b/articles/connections/database/custom-db/templates/login.md new file mode 100644 index 0000000000..f20948b312 --- /dev/null +++ b/articles/connections/database/custom-db/templates/login.md @@ -0,0 +1,709 @@ +--- +description: Custom database action script templates for user login. +toc: true +topics: + - connections + - custom-database +contentType: reference +useCase: + - customize-connections +--- +# Login Script Templates + +The **Login** script implements the function executed each time a user is required to authenticate. We recommend naming this function `login`. The `login` function is typically used during the Universal Login workflow, but is also applicable in other authentication flow scenarios (such as [Resource Owner Password Grant](/api-auth/tutorials/password-grant)). The script is required for both legacy authentication and for automatic migration. + +The `login` function should be defined as follows: + +```js +function login(userNameOrEmail, password, callback) { + // TODO: implement your script + return callback(null, profile); +} +``` + +| **Parameter** | **Description** | +| --- | --- | +| `userNameOrEmail` | The identification credential for the user typically either the email address for the user or the name associated with the user. With default out-of-box Universal Login, support for the use of `username` during login is available only if the **Requires Username** setting is enabled for the database connection. | +| `password` | Passed to the `login` script in plain text. Do not store it or transport it anywhere in its vanilla form. Use `bcrypt` as described below. | +| `callback` | Executed with up to two parameters. The first parameter is an indication of status: a `null` first parameter with a corresponding second parameter indicates that the operation executed successfully, while a non `null` first parameter value indicates that some error condition occurred. If the first parameter is `null` then the second parameter is the profile for the user in JSON format. If the first parameter is non `null` then the second parameter can be omitted. The second parameter is the `profile` for the user. This should be supplied as a JSON object in normalized user profile form. See the example below. | + +<%= include('../_includes/_bp-error-object') %> + +<%= include('../_includes/_panel-bcrypt-hash-encryption') %> + +## `callback` `profile` parameter example + +The second parameter provided to the `callback` function should be the profile for the user. This should be supplied as a JSON object in normalized user profile form. + +::: warning +The profile returned by the `login` script for a user should be consistent with the profile returned in the `getUser` script, and vice-versa. +::: + +Additionally, you can also provide metadata for a user as part of the user profile returned. The following is an example of the profile object that can be returned for a user. + +```js +{ + "username": "", + "user_id": "", + "email": "jane.doe@example.com", + "email_verified": false, + "user_metadata": { + "language": "en" + }, + "app_metadata": { + "plan": "full" + }, + "mfa_factors": [ + { + "phone": { + "value": "+15551234567" + } + }, + ] +} +``` + +| **Parameter** | Description | +| --- | --- | +| `username` | If a custom database connection type has **Requires Username** as an enabled setting then the profile returned for the user must include a `username`. If the setting is not enabled then `username` is optional and can be omitted. | +| `user_id` | The `user_id` value must be specified and provides the unique identifier for a user. For the `auth0` strategy, the strategy used to define a custom database connection, Auth0 automatically decorates whatever `user_id` value is supplied by prefixing the text `auth0|` in order to create the `user_id` in the root of the normalized user profile. The `user_id` value supplied will appear in it’s undecorated form in the identities array associated with the user profile in Auth0. The `user_id` value specified must be unique across all database connections defined in an Auth0 tenant. Failure to observe this will result in user identifier collision which will lead to unpredictable operation. One way to avoid this is to explicitly prefix the supplied `user_id` with the name of, or pseudonym for, the connection (omitting any whitespace). The `user_id` value must also be consistent for any given user; the value returned by the **Login** script must also be consistent with the value returned by the **Get User** script, and vice-versa. Failure to observe this requirement can lead to duplicate Auth0 user profiles for a user, duplicate identities for any user migrated via automatic migration, and/or unpredictable results when it comes to user operations. | +| `email` | An `email` value should also be specified. While an email address is not mandatory for a user, much of Auth0 out-of-box functionality such as password reset, requires that a user has a valid and verified email address. Email addresses should be returned consistently for all scripts and should also be unique within the context of a single custom database connection (for automatic migration scenarios). Failure to observe either of these requirements will typically lead to unpredictable results when it comes to user operation. | +| `mfa_factors` | (Optional) A list of [MFA enrollments](/mfa) for the imported user, which prevents the need for users to re-enroll in MFA. This field currently supports [SMS](/mfa/concepts/mfa-factors#sms-notifications), [Voice](/mfa/concepts/mfa-factors#voice-notifications), [OTP](/mfa/concepts/mfa-factors#one-time-passwords), and [email](/mfa/concepts/mfa-factors#email-notifications) based factors.| + +::: panel Best Practice +While a user does not need to use an email address to login, it’s recommended best practice that they have an email address defined against their user profile. This ensures that Auth0 out-of-box functionality works as designed. +::: + +For a legacy authentication scenario, you can also enable the `Sync user profile at each login` option in the settings for a custom database connection. This allows attribute updates in the Auth0 user profile each time a login for the user occurs for attributes that would otherwise not be available for update via the Auth0 Management API. For legacy authentication scenarios there are a number of root profile attributes which cannot be updated directly via the Management API. + +::: note +In order to update `name`, `nickname`, `given_name`, `family_name`, and/or `picture` attributes associated with the root of the normalized user profile, you must configure user profile sync so that user attributes will be updated from the identity provider. Auth0 does not support update of these attributes for a custom database connection used for legacy authentication. +::: + +## Language-specific script examples + +Auth0 provides sample scripts for use with the following languages/technologies: + +::: next-steps +* [JavaScript](/connections/database/custom-db/templates/login#javascript) +* [ASP.NET Membership Provider (MVC3 - Universal Providers)](/connections/database/custom-db/templates/login#asp-net-membership-provider-mvc3-universal-providers-) +* [ASP.NET Membership Provider (MVC4 - Simple Membership)](/connections/database/custom-db/templates/login#asp-net-membership-provider-mvc4-simple-membership-) +* [MongoDB](/connections/database/custom-db/templates/login#mongodb) +* [MySQL](/connections/database/custom-db/templates/login#mysql) +* [PostgreSQL](/connections/database/custom-db/templates/login#postgresql) +* [SQL Server](/connections/database/custom-db/templates/login#sql-server) +* [Windows Azure SQL Database](/connections/database/custom-db/templates/login#windows-azure-sql-database) +* [Request with Basic Auth](/connections/database/custom-db/templates/login#request-with-basic-auth) +* [Stormpath](/connections/database/custom-db/templates/login#stormpath) +::: + +### JavaScript + +``` +function login(email, password, callback) { + // This script should authenticate a user against the credentials stored in + // your database. + // It is executed when a user attempts to log in or immediately after signing + // up (as a verification that the user was successfully signed up). + // + // Everything returned by this script will be set as part of the user profile + // and will be visible by any of the tenant admins. Avoid adding attributes + // with values such as passwords, keys, secrets, etc. + // + // The `password` parameter of this function is in plain text. It must be + // hashed/salted to match whatever is stored in your database. For example: + // + // var bcrypt = require('bcrypt@0.8.5'); + // bcrypt.compare(password, dbPasswordHash, function(err, res)) { ... } + // + // There are three ways this script can finish: + // 1. The user's credentials are valid. The returned user profile should be in + // the following format: https://auth0.com/docs/users/normalized/auth0/normalized-user-profile-schema + // var profile = { + // user_id: ..., // user_id is mandatory + // email: ..., + // [...] + // }; + // callback(null, profile); + // 2. The user's credentials are invalid + // callback(new WrongUsernameOrPasswordError(email, "my error message")); + // 3. Something went wrong while trying to reach your database + // callback(new Error("my error message")); + // + // A list of Node.js modules which can be referenced is available here: + // + // https://tehsis.github.io/webtaskio-canirequire/ + + const msg = 'Please implement the Login script for this database connection ' + + 'at https://manage.auth0.com/#/connections/database'; + return callback(new Error(msg)); +} +``` + +### ASP.NET Membership Provider (MVC3 - Universal Providers) + +``` +function login(email, password, callback) { + const crypto = require('crypto'); + const sqlserver = require('tedious@1.11.0'); + + const Connection = sqlserver.Connection; + const Request = sqlserver.Request; + const TYPES = sqlserver.TYPES; + + const connection = new Connection({ + userName: 'the username', + password: 'the password', + server: 'the server', + options: { + database: 'the db name', + encrypt: true // for Windows Azure + } + }); + + /** + * hashPassword + * + * This function creates a hashed version of the password to store in the database. + * + * @password {[string]} the password entered by the user + * @return {[string]} the hashed password + */ + function hashPassword(password, salt) { + // the default implementation uses HMACSHA256 and since Key length is 64 + // and default salt is 16 bytes, Membership will fill the buffer repeating the salt + const key = Buffer.concat([salt, salt, salt, salt]); + const hmac = crypto.createHmac('sha256', key); + hmac.update(Buffer.from(password, 'ucs2')); + + return hmac.digest('base64'); + } + + connection.on('debug', function(text) { + // if you have connection issues, uncomment this to get more detailed info + //console.log(text); + }).on('errorMessage', function(text) { + // this will show any errors when connecting to the SQL database or with the SQL statements + console.log(JSON.stringify(text)); + }); + + connection.on('connect', function(err) { + if (err) return callback(err); + + getMembershipUser(email, function(err, user) { + if (err || !user || !user.profile || !user.password) return callback(err || new WrongUsernameOrPasswordError(email)); + + const salt = Buffer.from(user.password.salt, 'base64'); + + if (hashPassword(password, salt).toString('base64') !== user.password.password) { + return callback(new WrongUsernameOrPasswordError(email)); + } + + callback(null, user.profile); + }); + }); + + + // Membership Provider implementation used on Microsoft.AspNet.Providers NuGet + + /** + * getMembershipUser + * + * This function gets a username or email and returns a the user membership provider + * info, password hashes and salt + * + * @usernameOrEmail {[string]} the username or email, the method will do a + * query on both with an OR + * + * @callback {[Function]} first argument will be the Error if any, + * and second argument will be a user object + */ + function getMembershipUser(usernameOrEmail, done) { + var user = null; + const query = + 'SELECT Memberships.UserId, Email, Users.UserName, Password ' + + 'FROM Memberships INNER JOIN Users ' + + 'ON Users.UserId = Memberships.UserId ' + + 'WHERE Memberships.Email = @Username OR Users.UserName = @Username'; + + const getMembershipQuery = new Request(query, function(err, rowCount) { + if (err || rowCount < 1) return done(err); + + done(err, user); + }); + + getMembershipQuery.addParameter('Username', TYPES.VarChar, usernameOrEmail); + + getMembershipQuery.on('row', function(fields) { + user = { + profile: { + user_id: fields.UserId.value, + nickname: fields.UserName.value, + email: fields.Email.value, + }, + password: { + password: fields.Password.value, + salt: fields.PasswordSalt.value + } + }; + }); + + connection.execSql(getMembershipQuery); + } +} +``` + +### ASP.NET Membership Provider (MVC4 - Simple Membership) + +``` +function login(email, password, callback) { + const crypto = require('crypto'); + const sqlserver = require('tedious@1.11.0'); + + const Connection = sqlserver.Connection; + const Request = sqlserver.Request; + const TYPES = sqlserver.TYPES; + + const connection = new Connection({ + userName: 'the username', + password: 'the password', + server: 'the server', + options: { + database: 'the db name', + encrypt: true // for Windows Azure + } + }); + + function fixedTimeComparison(a, b) { + var mismatch = (a.length === b.length ? 0 : 1); + if (mismatch) { + b = a; + } + + for (var i = 0, il = a.length; i < il; ++i) { + const ac = a.charCodeAt(i); + const bc = b.charCodeAt(i); + mismatch += (ac === bc ? 0 : 1); + } + + return (mismatch === 0); + } + + + /** + * validatePassword + * + * This function gets the password entered by the user, and the original password + * hash and salt from database and performs an HMAC SHA256 hash. + * + * @password {[string]} the password entered by the user + * @originalHash {[string]} the original password hashed from the database + * (including the salt). + * @return {[bool]} true if password validates + */ + function validatePassword(password, originalHash, callback) { + const iterations = 1000; + const hashBytes = Buffer.from(originalHash, 'base64'); + const salt = hashBytes.slice(1, 17); + const hash = hashBytes.slice(17, 49); + crypto.pbkdf2(password, salt, iterations, hash.length, 'sha1', function(err, hashed) { + if (err) return callback(err); + + const hashedBase64 = Buffer.from(hashed, 'binary').toString('base64'); + const isValid = fixedTimeComparison(hash.toString('base64'), hashedBase64); + + return callback(null, isValid); + }); + } + + + connection.on('debug', function(text) { + // if you have connection issues, uncomment this to get more detailed info + //console.log(text); + }).on('errorMessage', function(text) { + // this will show any errors when connecting to the SQL database or with the SQL statements + console.log(JSON.stringify(text)); + }); + + connection.on('connect', function(err) { + if (err) return callback(err); + getMembershipUser(email, function(err, user) { + if (err || !user || !user.profile) return callback(err || new WrongUsernameOrPasswordError(email)); + + validatePassword(password, user.password, function(err, isValid) { + if (err || !isValid) return callback(err || new WrongUsernameOrPasswordError(email)); + + callback(null, user.profile); + }); + }); + }); + + + // Membership Provider implementation used on Microsoft.AspNet.Providers NuGet + + /** + * getMembershipUser + * + * This function gets a username or email and returns a user info, password hashes and salt + * + * @usernameOrEamil {[string]} the username or email, the method will do a query + * on both with an OR + * @callback {[Function]} first argument will be the Error if any, and second + * argument will be a user object + */ + function getMembershipUser(usernameOrEmail, done) { + var user = null; + const query = + 'SELECT webpages_Membership.UserId, UserName, UserProfile.UserName, Password from webpages_Membership ' + + 'INNER JOIN UserProfile ON UserProfile.UserId = webpages_Membership.UserId ' + + 'WHERE UserProfile.UserName = @Username'; + + const getMembershipQuery = new Request(query, function(err, rowCount) { + if (err || rowCount < 1) return done(err); + + done(err, user); + }); + + getMembershipQuery.addParameter('Username', TYPES.VarChar, usernameOrEmail); + + getMembershipQuery.on('row', function(fields) { + user = { + profile: { + user_id: fields.UserId.value, + nickname: fields.UserName.value, + email: fields.UserName.value, + }, + password: fields.Password.value + }; + }); + + connection.execSql(getMembershipQuery); + } +} +``` + +### MongoDB + +``` +function login(email, password, callback) { + const bcrypt = require('bcrypt'); + const MongoClient = require('mongodb@3.1.4').MongoClient; + const client = new MongoClient('mongodb://user:pass@mymongoserver.com'); + + client.connect(function (err) { + if (err) return callback(err); + + const db = client.db('db-name'); + const users = db.collection('users'); + + users.findOne({ email: email }, function (err, user) { + if (err || !user) { + client.close(); + return callback(err || new WrongUsernameOrPasswordError(email)); + } + + bcrypt.compare(password, user.password, function (err, isValid) { + client.close(); + + if (err || !isValid) return callback(err || new WrongUsernameOrPasswordError(email)); + + return callback(null, { + user_id: user._id.toString(), + nickname: user.nickname, + email: user.email + }); + }); + }); + }); +} +``` + +### MySQL + +``` +function login(email, password, callback) { + const mysql = require('mysql'); + const bcrypt = require('bcrypt'); + + const connection = mysql({ + host: 'localhost', + user: 'me', + password: 'secret', + database: 'mydb' + }); + + connection.connect(); + + const query = 'SELECT id, nickname, email, password FROM users WHERE email = ?'; + + connection.query(query, [ email ], function(err, results) { + if (err) return callback(err); + if (results.length === 0) return callback(new WrongUsernameOrPasswordError(email)); + const user = results[0]; + + bcrypt.compare(password, user.password, function(err, isValid) { + if (err || !isValid) return callback(err || new WrongUsernameOrPasswordError(email)); + + callback(null, { + user_id: user.id.toString(), + nickname: user.nickname, + email: user.email + }); + }); + }); +} +``` + +### PostgreSQL + +``` +function login(email, password, callback) { + //this example uses the "pg" library + //more info here: https://github.com/brianc/node-postgres + + const bcrypt = require('bcrypt'); + const postgres = require('pg'); + + const conString = 'postgres://user:pass@localhost/mydb'; + postgres.connect(conString, function (err, client, done) { + if (err) return callback(err); + + const query = 'SELECT id, nickname, email, password FROM users WHERE email = $1'; + client.query(query, [email], function (err, result) { + // NOTE: always call `done()` here to close + // the connection to the database + done(); + + if (err || result.rows.length === 0) return callback(err || new WrongUsernameOrPasswordError(email)); + + const user = result.rows[0]; + + bcrypt.compare(password, user.password, function (err, isValid) { + if (err || !isValid) return callback(err || new WrongUsernameOrPasswordError(email)); + + return callback(null, { + user_id: user.id, + nickname: user.nickname, + email: user.email + }); + }); + }); + }); +} +``` + +### SQL Server + +``` +function login(email, password, callback) { + //this example uses the "tedious" library + //more info here: http://pekim.github.io/tedious/index.html + const bcrypt = require('bcrypt'); + const sqlserver = require('tedious@1.11.0'); + + const Connection = sqlserver.Connection; + const Request = sqlserver.Request; + const TYPES = sqlserver.TYPES; + + const connection = new Connection({ + userName: 'test', + password: 'test', + server: 'localhost', + options: { + database: 'mydb' + } + }); + + const query = 'SELECT Id, Nickname, Email, Password FROM dbo.Users WHERE Email = @Email'; + + connection.on('debug', function (text) { + console.log(text); + }).on('errorMessage', function (text) { + console.log(JSON.stringify(text, null, 2)); + }).on('infoMessage', function (text) { + console.log(JSON.stringify(text, null, 2)); + }); + + connection.on('connect', function (err) { + if (err) return callback(err); + + const request = new Request(query, function (err, rowCount, rows) { + if (err || rowCount < 1) return callback(err || new WrongUsernameOrPasswordError(email)); + + bcrypt.compare(password, rows[0][3].value, function (err, isValid) { + if (err || !isValid) return callback(err || new WrongUsernameOrPasswordError(email)); + + callback(null, { + user_id: rows[0][0].value, + nickname: rows[0][1].value, + email: rows[0][2].value + }); + }); + }); + + request.addParameter('Email', TYPES.VarChar, email); + connection.execSql(request); + }); +} +``` + +### Windows Azure SQL Database + +``` +function login(email, password, callback) { + //this example uses the "tedious" library + //more info here: http://pekim.github.io/tedious/index.html + var Connection = require('tedious@1.11.0').Connection; + var Request = require('tedious@1.11.0').Request; + var TYPES = require('tedious@1.11.0').TYPES; + var bcrypt = require('bcrypt'); + + var connection = new Connection({ + userName: 'your-user@your-server-id.database.windows.net', + password: 'the-password', + server: 'your-server-id.database.windows.net', + options: { + database: 'mydb', + encrypt: true, + rowCollectionOnRequestCompletion: true + } + }); + + var query = "SELECT Id, Email, Password " + + "FROM dbo.Users WHERE Email = @Email"; + + connection.on('debug', function (text) { + // Uncomment next line in order to enable debugging messages + // console.log(text); + }).on('errorMessage', function (text) { + console.log(JSON.stringify(text, null, 2)); + return callback(text); + }).on('infoMessage', function (text) { + // Uncomment next line in order to enable information messages + // console.log(JSON.stringify(text, null, 2)); + }); + + connection.on('connect', function (err) { + if (err) { return callback(err); } + + var request = new Request(query, function (err, rowCount, rows) { + if (err) { + callback(new Error(err)); + } else if (rowCount < 1) { + callback(new WrongUsernameOrPasswordError(email)); + } else { + bcrypt.compare(password, rows[0][2].value, function (err, isValid) { + if (err) { callback(new Error(err)); } + else if (!isValid) { callback(new WrongUsernameOrPasswordError(email)); } + else { + callback(null, { + user_id: rows[0][0].value, + email: rows[0][1].value + }); + } + }); + } + }); + + request.addParameter('Email', TYPES.VarChar, email); + connection.execSql(request); + }); +} +``` + +### Request with Basic Auth + +``` +function login(email, password, callback) { + const request = require('request'); + + request.get({ + url: 'https://myserviceurl.com/profile', + auth: { + username: email, + password: password + } + //for more options check: + //https://github.com/mikeal/request#requestoptions-callback + }, function(err, response, body) { + if (err) return callback(err); + if (response.statusCode === 401) return callback(); + const user = JSON.parse(body); + + callback(null, { + user_id: user.user_id.toString(), + nickname: user.nickname, + email: user.email + }); + }); +} +``` + +### Stormpath + +``` +function login(username, password, callback) { + // Replace the YOUR-STORMPATH-CLIENT-ID with your Stormpath ID + var url = 'https://api.stormpath.com/v1/applications/{YOUR-STORMPATH-CLIENT-ID}/loginAttempts'; + // Add your Stormpath API Client ID and Secret + var apiCredentials = { + user : 'YOUR-STORMPATH-API-ID', + password: 'YOUR-STORMPATH-API-SECRET' + }; + + // Stormpath requires the user credentials be passed in as a base64 encoded message + var credentials = Buffer.from(username + ':' + password).toString('base64'); + + // Make a POST request to authenticate a user + request({ + url: url, + method: 'POST', + auth: apiCredentials, + json: { + type: 'basic', + // Passing in the base64 encoded credentials + value: credentials + } + }, 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; + + // Make a second request to get the user info. + request({ + url: accountUrl, + auth: apiCredentials, + json: true + }, function (errorUserInfo, responseUserInfo, bodyUserInfo) { + // If we get a successful response, we'll process it + if (responseUserInfo.statusCode !== 200) return callback(); + + // To get the user identifier, we'll strip out the Stormpath API + var id = bodyUserInfo.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: bodyUserInfo.username, + email: bodyUserInfo.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. You can decide how to handle this for your use case + email_verified: true + // Add any additional fields you would like to carry over from Stormpath + }); + }); + }); +} +``` + +## Keep reading + +* [Change Passwords](/connections/database/custom-db/templates/change-password) +* [Create](/connections/database/custom-db/templates/create) +* [Delete](/connections/database/custom-db/templates/delete) +* [Get User](/connections/database/custom-db/templates/get-user) +* [Verify](/connections/database/custom-db/templates/verify) +* [Change Email](/connections/database/custom-db/templates/change-email) diff --git a/articles/connections/database/custom-db/templates/verify.md b/articles/connections/database/custom-db/templates/verify.md new file mode 100644 index 0000000000..0fe7bca960 --- /dev/null +++ b/articles/connections/database/custom-db/templates/verify.md @@ -0,0 +1,433 @@ +--- +description: Custom database action script templates for user verification. +toc: true +topics: + - connections + - custom-database +contentType: reference +useCase: + - customize-connections +--- +# Verify Users Script Templates + +The **Verify** script implements the function executed to mark the verification status of a user’s email address in the legacy identity store. Email verification status information is typically returned via `email_verified` as part of any user profile information returned (see [Login](/connections/database/custom-db/templates/login) and [Get User](/connections/database/custom-db/templates/get-user) for further details). The script is executed when a user clicks on the link in the verification email sent by Auth0. We recommend naming this function `verify`. The script is only used in a legacy authentication scenario, and must be implemented if support is required for Auth0 email verification functionality. + +While it’s not mandatory to implement the `verify` function, it is a recommended best practice. The function is required to support user email address verification, and a verified email address for a user is critical to a number of the workflow scenarios in Auth0. Implementing the script will provide support for these workflows out-of-box. + +::: note +The `verify` function is called when a user clicks on the link in the verification email sent by Auth0. Change in email verification status influenced by other operations, such as via user profile modification in the Auth0 Dashboard, is performed via the [Change Email](/connections/database/custom-db/templates/change-email) script. +::: + +The `verify` function should be defined as follows: + +```js +function verify(email, callback) { + // TODO: implement your script + return callback(null, JSON Object); +} +``` + +| **Parameter** | **Description** | +| --- | --- | +| `email` | The email address for the user as the user identifying credential. | +| `callback` | Executed with up to two parameters. The first parameter is an indication of status: a `null` first parameter with a corresponding second parameter indicates that the operation executed successfully, while a non `null` first parameter value indicates that some error condition occurred. | + +## `callback` example + +If the first parameter is `null` then the second parameter should be a JSON object in a format similar to the following: + +```js +{ + "user_id": "", + "email": "jane.doe@example.com", + "email_verified": true +} +``` + +<%= include('../_includes/_bp-error-object') %> + +## Language-specific script examples + +Auth0 provides sample scripts for use with the following languages/technologies: + +* [JavaScript](#javascript) +* [ASP.NET Membership Provider (MVC3 - Universal Providers)](#asp-net-membership-provider-mvc3-universal-providers-) +* [ASP.NET Membership Provider (MVC4 - Simple Membership)](#asp-net-membership-provider-mvc4-simple-membership-) +* [MongoDB](#mongodb) +* [MySQL](#mysql) +* [PostgreSQL](#postgresql) +* [SQL Server](#sql-server) +* [Windows Azure SQL Database](#windows-azure-sql-database) +* [Request with Basic Auth](#request-with-basic-auth) + +### JavaScript + +``` +function verify(email, callback) { + // This script should mark the current user's email address as verified in + // your database. + // It is executed whenever a user clicks the verification link sent by email. + // These emails can be customized at https://manage.auth0.com/#/emails. + // It is safe to assume that the user's email already exists in your database, + // because verification emails, if enabled, are sent immediately after a + // successful signup. + // + // There are two ways that this script can finish: + // 1. The user's email was verified successfully + // callback(null, true); + // 2. Something went wrong while trying to reach your database: + // callback(new Error("my error message")); + // + // If an error is returned, it will be passed to the query string of the page + // where the user is being redirected to after clicking the verification link. + // For example, returning `callback(new Error("error"))` and redirecting to + // https://example.com would redirect to the following URL: + // https://example.com?email=alice%40example.com&message=error&success=false + + const msg = 'Please implement the Verify script for this database connection ' + + 'at https://manage.auth0.com/#/connections/database'; + return callback(new Error(msg)); +} +``` + +### ASP.NET Membership Provider (MVC3 - Universal Providers) + +``` +function verify(email, callback) { + const sqlserver = require('tedious@1.11.0'); + + const Connection = sqlserver.Connection; + const Request = sqlserver.Request; + const TYPES = sqlserver.TYPES; + + const connection = new Connection({ + userName: 'the username', + password: 'the password', + server: 'the server', + options: { + database: 'the db name', + encrypt: true, + // Required to retrieve userId needed for Membership entity creation + rowCollectionOnRequestCompletion: true + } + }); + + connection.on('debug', function(text) { + // if you have connection issues, uncomment this to get more detailed info + //console.log(text); + }).on('errorMessage', function(text) { + // this will show any errors when connecting to the SQL database or with the SQL statements + console.log(JSON.stringify(text)); + }); + + connection.on('connect', function(err) { + if (err) return callback(err); + + verifyMembershipUser(email, function(err, wasUpdated) { + if (err) return callback(err); // this will return a 500 + + callback(null, wasUpdated); + }); + }); + + function verifyMembershipUser(email, callback) { + // isApproved field is the email verification flag + const updateMembership = + 'UPDATE Memberships SET isApproved = \'true\' ' + + 'WHERE isApproved = \'false\' AND Email = @Email'; + + const updateMembershipQuery = new Request(updateMembership, function(err, rowCount) { + if (err) { + return callback(err); + } + callback(null, rowCount > 0); + }); + + updateMembershipQuery.addParameter('Email', TYPES.VarChar, email); + + connection.execSql(updateMembershipQuery); + } +} +``` + +### ASP.NET Membership Provider (MVC4 - Simple Membership) + +``` +function verify (email, callback) { + const sqlserver = require('tedious@1.11.0'); + + const Connection = sqlserver.Connection; + const Request = sqlserver.Request; + const TYPES = sqlserver.TYPES; + + const connection = new Connection({ + userName: 'the username', + password: 'the password', + server: 'the server', + options: { + database: 'the db name', + encrypt: true, + // Required to retrieve userId needed for Membership entity creation + rowCollectionOnRequestCompletion: true + } + }); + + connection.on('debug', function(text) { + // if you have connection issues, uncomment this to get more detailed info + //console.log(text); + }).on('errorMessage', function(text) { + // this will show any errors when connecting to the SQL database or with the SQL statements + console.log(JSON.stringify(text)); + }); + + connection.on('connect', function (err) { + if (err) return callback(err); + verifyMembershipUser(email, function(err, wasUpdated) { + if (err) return callback(err); // this will return a 500 + + callback(null, wasUpdated); + }); + }); + + function findUserId(email, callback) { + const findUserIdFromEmail = + 'SELECT UserProfile.UserId FROM ' + + 'UserProfile INNER JOIN webpages_Membership ' + + 'ON UserProfile.UserId = webpages_Membership.UserId ' + + 'WHERE UserName = @Username'; + + const findUserIdFromEmailQuery = new Request(findUserIdFromEmail, function (err, rowCount, rows) { + if (err || rowCount < 1) return callback(err); + + const userId = rows[0][0].value; + + callback(null, userId); + }); + + findUserIdFromEmailQuery.addParameter('Username', TYPES.VarChar, email); + + connection.execSql(findUserIdFromEmailQuery); + } + + function verifyMembershipUser(email, callback) { + findUserId(email, function (err, userId) { + if (err || !userId) return callback(err); + + // isConfirmed field is the email verification flag + const updateMembership = + 'UPDATE webpages_Membership SET isConfirmed = \'true\' ' + + 'WHERE isConfirmed = \'false\' AND UserId = @UserId'; + + const updateMembershipQuery = new Request(updateMembership, function (err, rowCount) { + return callback(err, rowCount > 0); + }); + + updateMembershipQuery.addParameter('UserId', TYPES.VarChar, userId); + + connection.execSql(updateMembershipQuery); + }); + } +} +``` + +### MongoDB + +``` +function verify (email, callback) { + const MongoClient = require('mongodb@3.1.4').MongoClient; + const client = new MongoClient('mongodb://user:pass@mymongoserver.com'); + + client.connect(function (err) { + if (err) return callback(err); + + const db = client.db('db-name'); + const users = db.collection('users'); + const query = { email: email, email_verified: false }; + + users.update(query, { $set: { email_verified: true } }, function (err, count) { + client.close(); + + if (err) return callback(err); + callback(null, count > 0); + }); + }); +} +``` + +### MySQL + +``` +function verify(email, callback) { + const mysql = require('mysql'); + + const connection = mysql({ + host: 'localhost', + user: 'me', + password: 'secret', + database: 'mydb' + }); + + connection.connect(); + + const query = 'UPDATE users SET email_Verified = true WHERE email_Verified = false AND email = ?'; + + connection.query(query, [ email ], function(err, results) { + if (err) return callback(err); + + callback(null, results.length > 0); + }); + +} +``` + +### PostgreSQL + +``` +function verify (email, callback) { + //this example uses the "pg" library + //more info here: https://github.com/brianc/node-postgres + + const postgres = require('pg'); + + const conString = 'postgres://user:pass@localhost/mydb'; + postgres.connect(conString, function (err, client, done) { + if (err) return callback(err); + + const query = 'UPDATE users SET email_Verified = true WHERE email_Verified = false AND email = $1'; + client.query(query, [email], function (err, result) { + // NOTE: always call `done()` here to close + // the connection to the database + done(); + + return callback(err, result && result.rowCount > 0); + }); + }); +} +``` + +### SQL Server + +``` +function verify (email, callback) { + //this example uses the "tedious" library + //more info here: http://pekim.github.io/tedious/index.html + const sqlserver = require('tedious@1.11.0'); + + const Connection = sqlserver.Connection; + const Request = sqlserver.Request; + const TYPES = sqlserver.TYPES; + + const connection = new Connection({ + userName: 'test', + password: 'test', + server: 'localhost', + options: { + database: 'mydb' + } + }); + + const query = 'UPDATE dbo.Users SET Email_Verified = true WHERE Email_Verified = false AND Email = @Email'; + + connection.on('debug', function(text) { + console.log(text); + }).on('errorMessage', function(text) { + console.log(JSON.stringify(text, null, 2)); + }).on('infoMessage', function(text) { + console.log(JSON.stringify(text, null, 2)); + }); + + connection.on('connect', function (err) { + if (err) return callback(err); + + const request = new Request(query, function (err, rows) { + if (err) return callback(err); + callback(null, rows > 0); + }); + + request.addParameter('Email', TYPES.VarChar, email); + + connection.execSql(request); + }); +} +``` + +### Windows Azure SQL Database + +``` +function verify (email, callback) { + //this example uses the "tedious" library + //more info here: http://pekim.github.io/tedious/index.html + + var Connection = require('tedious@1.11.0').Connection; + var Request = require('tedious@1.11.0').Request; + var TYPES = require('tedious@1.11.0').TYPES; + + var connection = new Connection({ + userName: 'your-user@your-server-id.database.windows.net', + password: 'the-password', + server: 'your-server-id.database.windows.net', + options: { + database: 'mydb', + encrypt: true + } + }); + + var query = + 'UPDATE Users SET Email_Verified=\'TRUE\' ' + + 'WHERE Email_Verified=\'FALSE\' AND Email=@Email'; + + connection.on('debug', function(text) { + // Uncomment next line in order to enable debugging messages + // console.log(text); + }).on('errorMessage', function(text) { + console.log(JSON.stringify(text, null, 2)); + }).on('infoMessage', function(text) { + // Uncomment next line in order to enable information messages + // console.log(JSON.stringify(text, null, 2)); + }); + + connection.on('connect', function (err) { + if (err) { return callback(err); } + + var request = new Request(query, function (err, rows) { + if (err) { return callback(err); } + console.log('rows: ' + rows); + callback(null, rows > 0); + }); + + request.addParameter('Email', TYPES.VarChar, email); + + connection.execSql(request); + }); +} + +``` + +### Request with Basic Auth + +``` +function verify(email, callback) { + const request = require('request'); + + request.put({ + url: 'https://myserviceurl.com/users', + json: { email: email } + //for more options check: + //https://github.com/mikeal/request#requestoptions-callback + }, function(err, response, body) { + if (err) return callback(err); + if (response.statusCode === 401) return callback(); + + callback(null, body); + }); +} +``` + +## Keep reading + +* [Change Passwords](/connections/database/custom-db/templates/change-password) +* [Create](/connections/database/custom-db/templates/create) +* [Delete](/connections/database/custom-db/templates/delete) +* [Get User](/connections/database/custom-db/templates/get-user) +* [Login](/connections/database/custom-db/templates/login) +* [Change Email](/connections/database/custom-db/templates/change-email) diff --git a/articles/connections/database/db2-script.md b/articles/connections/database/db2-script.md new file mode 100644 index 0000000000..17fb5c54c2 --- /dev/null +++ b/articles/connections/database/db2-script.md @@ -0,0 +1,55 @@ +--- +title: Login Script for IBM DB2 +description: A custom callback script for those integrating with IBM DB2 +topics: + - connections + - custom-database + - ibm-db2 +contentType: reference +useCase: + - customize-connections +--- + +# Login Script for IBM DB2 + +If you are integrating Auth0 with [IBM DB2](https://www.ibm.com/analytics/us/en/technology/db2/), you can use the following script for your login process. + +```js +function login (email, password, callback) { + var ibmdb = require("ibm_db"); + var bcrypt = require('bcrypt'); + + var credentials = ""; + credentials += "DRIVER={DB2};"; + credentials += "DATABASE=SAMPLE;"; + credentials += "HOSTNAME=;"; + credentials += "UID=;"; + credentials += "PWD=;"; + credentials += "PORT=50001;"; + credentials += "PROTOCOL=TCPIP"; + + ibmdb.open(credentials, function(err, conn) { + if (err) callback(new Error("Error while trying to connect to auth source")); + conn.query("select * from =.USERS where email='" + email + "'", function(err, data) { + if (err) callback(new Error(err)); + else { + if (!bcrypt.compareSync(password, data[0].PASSWORDHASH)) return; + + //map attributes to profile – sample below + var profile = { + user_id: data[0].ID, + nickname: data[0].EMAIL, + email: data[0].EMAIL, + given_name : data[0].FIRSTNAME, + family_name : data[0].LASTNAME + }; + + callback(null,profile); + } + conn.close(function() { + + }); + }); + }); +} +``` diff --git a/articles/connections/database/index.md b/articles/connections/database/index.md index 8150734931..b83c31045f 100644 --- a/articles/connections/database/index.md +++ b/articles/connections/database/index.md @@ -1,22 +1,32 @@ --- -description: How to create and use a database connection using either the Auth0 user store or a custom database connection. +description: How to create and use a database connection using either the Auth0 user store or your own user store. +crews: crew-2 url: /connections/database +topics: + - connections + - database + - db-connections +contentType: + - index + - concept +useCase: + - customize-connections --- -# Database Identity Providers +# Database Connections -Auth0 provides database connections to authenticate users with an email or username and a password and securely store these credentials in the Auth0 user store, or in your own database. +Auth0 provides database connections to authenticate users with an email/username and password. These credentials are securely stored in the Auth0 user store or in your own database. -You can create a new database connection or manage existing ones in the [Dashboard](${manage_url}/#/connections/database): +You can create a new database connection and manage existing ones at [Auth0 Dashboard > Authentication > Database](${manage_url}/#/connections/database): -![](/media/articles/connections/database/database-connections.png) +![](/media/articles/connections/database/dashboard-connections-database-list.png) ## Scenarios Typical database connection scenarios include: * [Using the Auth0 user store](#using-the-auth0-user-store) -* [Using a custom user store](#using-a-custom-user-store) +* [Using your own user store](#using-your-own-user-store) * [Migrating to Auth0 from a custom user store](#migrating-to-auth0-from-a-custom-user-store) * [Requiring a username for users](/connections/database/require-username) @@ -26,26 +36,22 @@ Auth0 provides the database infrastructure to store your users by default. This 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 (see: [Password Strength in Auth0 Database Connections](/password-strength)). -**NOTE:** For database connections, Auth0 limits the number of repeat login attempts per user and IP address. For more information, see: [Rate Limits on User/Password Authentication](/connections/database/rate-limits). +::: note +For database connections, Auth0 limits the number of repeat login attempts per user and IP address. For more information, see: [Rate Limits on User/Password Authentication](/policies/rate-limit-policy/database-connections-rate-limits). +::: -### Using a custom user store +### Using your own user store -If you have an existing user store, or wish to store user credentials on your own server, Auth0 enables you to easily connect to a custom repository and use it as the identity provider. +If you have an existing user store, or wish to store user credentials on your own server, Auth0 enables you to connect to a [custom database](/connections/database/custom-db) or repository and use it as the identity provider. -![](/media/articles/connections/database/custom-database.png) +![Custom Database Configuration](/media/articles/connections/database/dashboard-connections-database-edit_view-custom-database.png) -In this scenario, you provide the login script to authenticate the user that will execute each time a user attempts to log in. Optionally, you can create scripts for sign-up, email verification, password reset and delete user functionality. +In this scenario, you provide the login script to authenticate the user that will execute each time a user attempts to log in. Optionally, you can create [scripts](/connections/database/custom-db/templates) for sign-up, email verification, password reset, and delete user functionality. -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**, **SQL Server**, **Windows Azure SQL Database**, and for a web service accessed by **Basic Auth**. Essentially, you can connect to any kind of database or web service with a custom script. +The scripts are Node.js code. Auth0 provides [templates](/connections/database/custom-db/templates) for most common databases, such as: **ASP.NET Membership Provider**, **MongoDB**, **MySQL**, **PostgreSQL**, **SQL Server**, **Windows Azure SQL Database**, and for a web service accessed by **Basic Auth**. Essentially, you can connect to almost any kind of database or web service with a custom script. -Some specifics to keep in mind: - -* Latency will be greater compared to Auth0-hosted user stores -* The database or service must be reachable from the Auth0 servers. You will need to configure inbound connections if your store is behind a firewall. -* Database scripts run in the same [Webtask](https://webtask.io) container, which is shared with all other extensibility points (i.e. rules, webtasks or other databases) belonging to the same Auth0 domain. Therefore, you must carefully code for error handling and throttling. - -**NOTE:** See the custom database connection tutorial at [Authenticate Users with Username and Password using a Custom Database](/connections/database/mysql) for detailed steps on how to setup and configure a custom user store. +<%= include('../../_includes/_webtask') %> ### Migrating to Auth0 from a custom user store -In this scenario, you have a legacy user store and wish to switch to the Auth0 store. Auth0 provides an automatic migration feature that adds your users to the Auth0 database one-at-a-time as each logs in and avoids asking your users to reset their passwords all at the same time. For a detailed guide to this feature see [Importing users to Auth0](/connections/database/migrating). +In this scenario, you have a legacy user store and wish to switch to the Auth0 store. Auth0 provides an automatic migration feature that adds your users to the Auth0 database one-at-a-time as each logs in and avoids asking your users to reset their passwords all at the same time. For more information, see [Configure Automatic User Migration](/users/guides/configure-automatic-migration). diff --git a/articles/connections/database/migrating.md b/articles/connections/database/migrating.md deleted file mode 100644 index c117af8a29..0000000000 --- a/articles/connections/database/migrating.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: Migrating Users to Auth0 -description: Auth0 supports the automatic migration of users to Auth0 from a custom database connection. This feature adds your users to the Auth0 database one-at-a-time as each logs in and avoids asking your users to reset their passwords all at the same time. ---- -# Migrate Users to Auth0 - -At Auth0, the focus has always been not only on greenfield projects but also on existing applications that would benefit from an extension to their authentication capabilities. For these added features, you may wish to migrate your existing users to Auth0 from a legacy user store. - -Auth0 supports the automatic migration of users to Auth0 from a custom database connection. This feature adds your users to the Auth0 database one-at-a-time as each logs in and avoids asking your users to reset their passwords all at the same time. - -You can read more about database connections and the several user store options at [Database Identity Providers](/connections/database). - -## The migration process - -When a user authenticates using a custom database connection marked for **import to Auth0**, the following process takes place: - -![](/media/articles/connections/database/migrating-diagram.png) - -If a user has already been migrated to Auth0, they are authenticated against the Auth0 database; if not, your custom login script is executed. When the login is successful, the user is automatically added to the Auth0 database. - -The next time that user attempts to log in, their credentials and profile are retrieved from Auth0 and not from your custom database. - -New users are registered to Auth0 directly. - -**NOTE:** The password reset procedure is only available for users stored in the Auth0 database. - -## Enable automatic migration - -### 1. Create a new custom database - -You can create a new database connection or configure an existing one in the [Connections > Database](${manage_url}/#/connections/database) section of the Dashboard. - -On the **Custom Database** page, enable the **Use my own database** option: - -![](/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: - -![](/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 that you will need to complete. - -![](/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**, **PostgreSQL**, **SQLServer**, **Windows Azure SQL Database**, and for a web service accessed by **Basic Auth**. For more information on implementing these scripts, see the tutorial at: [Authenticate Users with Username and Password using a Custom Database](/connections/database/mysql). - -The **Login** script to authenticate the user will execute each time a user that is not found in Auth0 database attempts to log in. - -The **Get User** script will execute when any of the following actions are performed: - -* A user attempts to *sign-up*. -* A user clicks on a valid [password change confirmation](/libraries/lock/customization#rememberlastlogin-boolean-) link. -* A Management API call is made to [update a user's email or username](/api/v2#!/Users/patch_users_by_id). - -This script is needed because none of these actions require authentication on the user's behalf. The **Get User** script must provide a way of verifying that a user exists in the legacy database without requiring their password. - -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. - -### 4. Complete the migration - -After importing users for a time, many of your users will have been migrated to the Auth0 database. You can verify this with the [List or search users](/api/v2#!/Users/get_users) Management API endpoint or by reviewing the [Users](${manage_url}/#/users) list on the Dashboard. - -![](/media/articles/connections/database/migrated-users.png) - -Once all your users are in the Auth0 database, you are ready to turn off the import users feature and convert the database to Auth0. - -Go to your custom database connection on the [Dashboard](${manage_url}/#/connections/database) and: - -* Disable the **Import Users to Auth0** option under **Settings** page. -* Disable the **Use my own database** option on the **Custom Database** page. diff --git a/articles/connections/database/mysql.md b/articles/connections/database/mysql.md deleted file mode 100644 index bd10113a44..0000000000 --- a/articles/connections/database/mysql.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -title: Authenticate Users with Username and Password using a Custom Database -connection: MySQL -image: /media/connections/mysql.svg -seo_alias: mysql -description: How to authenticate users with username and password using a Custom Database. -toc: true ---- - -# Authenticate Users with Username and Password using a Custom Database - -Applications often rely on user databases for authentication. Auth0 enables you to easily connect to these repositories and use them as identity providers while preserving user credentials and providing many additional features. You can read more about database connections and the different user store options at [Database Identity Providers](/connections/database). - -In this tutorial, you will be guided through a series of steps to connect your custom user store to Auth0. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Create a database connection - -Log into Auth0, and select the [Connections > Database](${manage_url}/#/connections/database) menu option. Click the **New Database Connection** button and provide a name for the database, or select a database you have created previously. - -![](/media/articles/connections/database/database-connections.png) - -## 2. Customize the database connection - -Click **Custom Database** and turn on the **Use my own database** switch. - -![](/media/articles/connections/database/custom-database.png) - -## 3. Provide action scripts - -You have to provide a login script to authenticate the user that will execute each time a user attempts to log in. Optionally, you can create scripts for sign-up, email verification, password reset and delete user functionality. - -::: panel-info Note -When creating users, the `get_user` script is called before the `create` script. Be sure that you have implemented both. -::: - -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**. Essentially, you can connect to any kind of database or web service with a custom script. - -This tutorial uses **MySQL** as an example. In the **Templates** drop-down, select **MySQL**: - -![](/media/articles/connections/database/mysql/db-connection-login-script.png) - -The following code is generated for you in the connection editor: - -```js -function login (email, password, callback) { - var connection = mysql({ - host : 'localhost', - user : 'me', - password : 'secret', - database : 'mydb' - }); - - connection.connect(); - - var query = "SELECT id, nickname, email, password " + - "FROM users WHERE email = ?"; - - connection.query(query, [email], function (err, results) { - if (err) return callback(err); - if (results.length === 0) return callback(); - var user = results[0]; - - if (!bcrypt.compareSync(password, user.password)) { - return callback(); - } - - callback(null, { - id: user.id.toString(), - nickname: user.nickname, - email: user.email - }); - - }); - -} -``` - -This script connects to a **MySQL** database and executes a query to retrieve the first user with `email == user.email`. With the `bcrypt.compareSync` method, it then validates that the passwords match, and if successful, returns an object containing the user profile information including `id`, `nickname`, and `email`. This script assumes that you have a `users` table containing these columns. You can tweak this script in the editor to adjust it to your own requirements. - -### Database Field Requirements - -Of course, your custom database will need to have fields in it that will provide the information to populate user profiles. In the above example, the script is checking for an `id`, `nickname`, `email`, and `password`. - -For more information on Auth0 user profile schema and the fields that are expected, as well as additional ones that are available, take a look at the [Auth0 Normalized User Profile](/user-profile/normalized) documentation. - - -## 4. Add configuration parameters - -You can securely store the credentials needed to connect to your database in the **Settings** section at the bottom of the page. - -![](/media/articles/connections/database/mysql/db-connection-configurate.png) - -In the connection script, refer to these parameters as: `configuration.PARAMETER_NAME`. For example, you could enter: - -```js -function login (username, password, callback) { - var connection = mysql({ - host : 'localhost', - user : 'me', - password : configuration.MYSQL_PASSWORD, - database : 'mydb' - }); -} -``` - -## 5. Error handling - -To return an error, call the callback with an error as the first parameter: - -```js -callback(error); -``` - -There are three different errors you can return from a DB Connection: - -* `new WrongUsernameOrPasswordError(, )`: when you know who the user is and want to keep track of a wrong password. -* `new ValidationError(, )`: a generic error with an error code. -* `new Error()`: simple errors (no error code). - -For example: - -```js -callback(new ValidationError('email-too-long', 'Email is too long.')); -``` - -## 6. Debug and troubleshoot - -Test the script using the **TRY** button. If your settings are correct you should see the resulting profile: - -![](/media/articles/connections/database/mysql/db-connection-try-ok.png) - -If you add a `console.log` statement to the script you will be able to see the output here. - - -## The script container - -The script runs in a JavaScript sandbox where you can use the full power of the JavaScript language and selected Node.js libraries. [You can `require` any library listed here](https://tehsis.github.io/webtaskio-canirequire/). - -## Auth0 Login widget - -After you have enabled the database connection, the Auth0 Login widget will automatically change its appearance to allow users to enter their `username` and `password`. Once entered, this data is passed to your scripts. - -![](/media/articles/connections/database/mysql/db-connection-widget.png) - -<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/database/password-change.md b/articles/connections/database/password-change.md index 446f4eb5d3..875101bd33 100644 --- a/articles/connections/database/password-change.md +++ b/articles/connections/database/password-change.md @@ -1,35 +1,52 @@ --- -description: This document explains the ways you can reset the passwords for users of your Auth0 clients. +description: Describes the different ways to reset the users' passwords for your Auth0 applications. +toc: true +topics: + - connections + - database + - db-connections + - passwords +contentType: how-to +useCase: customize-connections --- +# Change Users' Passwords -# Changing a User's Password +This topic describes different ways to reset the password for a user in your database. You can change passwords for users in your [database connections](/connections/database) only. Users signing in with [social](/connections/social) or [enterprise](/connections/enterprise) connections must reset their passwords with the identity provider (such as Google or Facebook). -:::panel-warning Notice -This information applies to those using *Change Password flow v2*. If you are using the old *Change Password flow* or Lock v. 8, check the notice panels (like this one) for information on differences between the two flows. +There are two basic methods for changing a user's password: -To determine the flow version you are using, navigate to [Dashboard > Account Settings > Advanced](${manage_url}/#/account/advanced) to check if the *Change Password flow v2* toggle is enabled. If it is, use Lock version 9/10. If not, use an older version of Lock to trigger the old Change Password flow. +- [Trigger an interactive password reset flow](#trigger-an-interactive-password-reset-flow) that sends the user a link through email. The link opens the Auth0 password reset page where the user can enter a new password. +- [Directly set the new password](#directly-set-the-new-password) using the Auth0 Management API or the Auth0 Dashboard. -We strongly encourage you to enable *Change Password flow v2* and upgrade to Lock version 9 and above. To learn more about the vulnerability and migration, please see [Vulnerable Password Flow.](/migrations#vulnerable-password-flow). To learn more about migrating to Lock 10, please take a look at the [Lock 10 Migration Guide](/libraries/lock/v10/migration-guide). +::: note +Resetting a user's password makes their session expire. ::: +:::panel Not what you're looking for? +- To configure the custom Password Reset page, read [Customize Hosted Password Reset Page](/universal-login/password-reset). +- To implement custom behavior after a successful password change, read [Post Change Password Hook](/hooks/extensibility-points/post-change-password). +- To reset the password to your personal Auth0 user account, read [Reset Your Auth0 Account Password](/support/reset-account-password). +::: + + +## Trigger an interactive password reset flow -You can change your users' passwords using one of the following methods: -+ [**Authentication API**](#using-the-authentication-api): Send a `POST` call to the Authentication API to send a password reset email to the user. -+ [**Management API**](#using-the-management-api): Send a `PATCH` call to the Management API to update the user's password manually. -+ [**Lock**](#using-lock): Use the Lock login screen to trigger a password reset email to the user. -+ [**Dashboard**](#manually-setting-a-user-s-password): Use the [Users](${manage_url}/#/users) section of the Dashboard to manually change the user's password. +There are two ways to trigger an interactive password reset flow, depending on your use case: through the Universal Login page or the Authentication API. -**NOTE:** You can only change passwords for users signing in using Database connections. Users signing in using Social or Enterprise connections need to reset their passwords with the appropriate system. +### Universal Login Page +If your application uses Universal Login, the user can use the Lock widget on the Login screen to trigger a password reset email. With the New Universal Login Experience, the user can click the **Don't remember your password?** link and then enter their email address. This fires off a POST request to Auth0 that triggers the password reset process. The user [receives a password reset email](#password-reset-emails). +### Authentication API +If your application uses an interactive password reset flow through the Authentication API, make a `POST` call. In the `email` field, provide the email address of the user who needs to change their password. If the call is successful, the user [receives a password reset email](#password-reset-emails). -## Using the Authentication API +If you call the API from the browser, be sure the origin URL is allowed: Go to [Auth0 Dashboard > Applications > Applications](${manage_url}/#/applications/${account.clientId}/settings) and add the URL to the `Allowed Origins (CORS)` list. -To reset a user's password using the Authentication API, make a `POST` call specifying the email address of the user account whose password you would like to reset in the `email` field. If the call is successful, the user will receive an email prompting them to change their password. +If your connection a custom database, check to see if the user exists in the database before you invoke the Authentication API for `changePassword`. ```har { "method": "POST", - "url": "https://YOURACCOUNT.auth0.com/dbconnections/change_password", + "url": "https://${account.namespace}/dbconnections/change_password", "headers": [ { "name": "Content-Type", "value": "application/json" } ], @@ -40,34 +57,46 @@ To reset a user's password using the Authentication API, make a `POST` call spec } ``` -:::panel-warning Custom Database -If you have a custom database set up for your Connection and the user exists in the database, invoke the Authentication API for `changePassword`. -::: +### Password reset email -If the `POST` call is successful, the user will receive an email containing a link to reset their password. +Regardless of how the password reset process was triggered, the user receives email containing a link to reset their password. -![](/media/articles/connections/database/reset-password-email.png) +![](/media/articles/connections/database/password-reset-email.png) -Clicking the link will send the user to a password reset page. +Clicking the link sends the user to the [password reset page](/universal-login/password-reset). -![](/media/articles/connections/database/reset-password.png) +After submitting the new password, the user sees confirmation that they can now log in with their new credentials. -**NOTE**: The reset password link in the email is valid for one use only, and it must be used before the time specified in the `URL Lifetime` field elapses. The `URL Lifetime` field can be modified in the Dashboard where you customize the Change Password email. +Notes on password resets: +- The reset password link in the email is valid for one use only. +- If the user receives multiple password reset emails, only the password link in the most recent email is valid. +- The `URL Lifetime` field determines how long the link is valid. From the Auth0 dashboard, you can [customize the Change Password email](/email/templates) and modify the link's [lifetime](/api/authentication/reference#change-password). -Please see the [Change User Password for DB Connections](/api/authentication/reference#change-password) Authentication API endpoint for more information. +In the [Classic Universal Login Experience](/universal-login/classic) you can [configure a url](/email/templates#configuring-the-redirect-to-url) to redirect users after completing the password reset. The URL receives a success indicator and a message. -## Using the Management API +The [New Experience](/universal-login/new) redirects the user to the [default login route](/universal-login/default-login-url) when it succeeds, and handles the error cases as part of the Universal Login flow. This experience ignores the Redirect URL in the email template. -To reset a user's password using the Management API, make a `PATCH` call to the [Update a User endpoint](/api/management/v2#!/Users/patch_users_by_id). +::: panel Generate Password Reset Tickets -::: panel-danger Notice -Users will not receive notification that their password has been manually changed. +The Management API v2 provides an additional endpoint, [Generate a password reset ticket]( /api/management/v2#!/Tickets/post_password_change), that generates a URL like the one in the password reset email. You can use the generated URL when the email delivery method is not appropriate. Keep in mind that in the default flow, the email delivery verifies the identity of the user. (An impostor wouldn't have access to the email inbox.) If you use the ticket URL, your application is responsible for verifying the identity of the user in some other way. ::: +## Directly set the new password + +To set a new password directly for the user without sending a password reset email, use either the [**Management API**](#using-the-management-api) or the [**Auth0 Dashboard**](#manually-set-users-passwords-using-the-dashboard). + +::: note +Users do not receive notification when you change their password. +::: + +### Use the Management API + +If you want to implement your own password reset flow, you can directly change a user's password from a server request to the Management API: make a `PATCH` call to the [Update a User endpoint](/api/management/v2#!/Users/patch_users_by_id). + ```har { "method": "PATCH", - "url": "https://${manage_url}/api/v2/users/{id}", + "url": "https://${account.namespace}/api/v2/users/USER_ID", "headers": [{ "name": "Content-Type", "value": "application/json" @@ -79,55 +108,12 @@ Users will not receive notification that their password has been manually change } ``` -## Using Lock - -Users can change their passwords using the Lock screen. - -To begin the password change process, the user would click on the **Don't remember your password?** link on the Lock screen: - -![](/media/articles/connections/database/lock_v9/lock_login_page.png) - -They would then enter their email address: - -![](/media/articles/connections/database/lock_v9/lock_request_reset.png) - -:::panel-warning Notice -If you are using Lock version 8, the user will be asked, immediately after clicking the **Don't remember your password?** link on the Lock screen, to provide their email address *and* their new password. The user would then confirm this action via email. - -However, this flow is not considered safe. We recommend that you upgrade to Lock 9 or later to utilize a more secure flow. To learn more about migrating Lock, see [Vulnerable Password Flow](/migrations#vulnerable-password-flow). -::: - -The user will then receive an email containing a link to reset the password: - -![](/media/articles/connections/database/lock_v9/lock_reset_pass_email.png) - -Clicking the link will send the user to a password reset page where they can enter their new password: - -![](/media/articles/connections/database/lock_v9/lock_set_new_pass.png) - -After submitting the new password, the user will be able to login with their new credentials: - -![](/media/articles/connections/database/lock_v9/lock_pass_changed.png) - -## Manually Setting a User's Password - -::: panel-danger Notice -Users will not receive notification that their password has been manually changed. -::: - -You, or anyone with sufficient administrative privledges to your Auth0 account, can manually change a user's password in the [Users](${manage_url}/#/users) section of the Dashboard. - -Click on the name of the user for whom you want to change the password. Then, click on the **Actions** button on the right side of the page, and select **Change Password**. - -![](/media/articles/connections/database/manual-password-change.png) - -Enter the new password and click **Save**. - - -## Customizing the Change Password Email - -You can change the content of the Change Password emails in the [Emails > Templates](${manage_url}/#/emails) section of the Dashboard. Select the **Change Password Confirmation** tab to edit the email fields: +### Manually set users' passwords using the Auth0 Dashboard -![](/media/articles/connections/database/change-password-email.png) +Anyone with administrative privileges to your Auth0 tenant can manually change a user's password at [Auth0 Dashboard > User Management > Users](${manage_url}/#/users). -**NOTE**: Email templates can only be changed for those *not* using Auth0's built-in email provider. For more information, please see: [Customizing Your Emails](/email/templates). +1. Select the name of the user whose password you want to change. +2. Locate the **Danger Zone** at the bottom of the page. +3. In the red **Change Password** box, click **CHANGE**. + ![](/media/articles/connections/database/dashboard-users-edit_view-details_danger-zone.png) +3. Enter the new password and click **Save**. diff --git a/articles/connections/database/password-options.md b/articles/connections/database/password-options.md index 7d14164e0e..645302fc79 100644 --- a/articles/connections/database/password-options.md +++ b/articles/connections/database/password-options.md @@ -1,38 +1,44 @@ --- +title: Password Options in Auth0 Database Connections description: Auth0's Password Options allow you to disallow users from repeating prior passwords, to customize a password dictionary of passwords to disallow, and to disallow passwords related to the user's personal data. +crews: crew-2 +topics: + - connections + - database + - db-connections + - passwords +contentType: concept +useCase: customize-connections --- - # Password Options in Auth0 Database Connections -:::panel-warning Notice -The **Password Options** feature is only available for Database connections. The password limitations in Social and Enterprise connections are enforced by each provider. +::: warning +**Password History**, **Password Dictionary**, and **Personal Data** password options are available for Database connections using the Auth0 data store and for Custom Database connections that have import mode enabled. Password limitations in Social and Enterprise connections are enforced by each provider. ::: -An important concern when using passwords for authentication is the creation of unique passwords. A strong password policy will make it difficult, if not improbable, for someone to guess a password through either manual or automated means. +When using passwords for authentication, you should enforce the creation of unique passwords. A strong password policy will make it difficult, if not improbable, for a bad actor to guess a password through either manual or automated means. -One facet of strong passwords is their uniqueness and difficulty to guess. Auth0's password options for database connections are designed to allow you to force your users to make better decisions when choosing their passwords. +Important facets of strong passwords are their uniqueness and difficulty to guess. Auth0's password options for database connections allow you to force your users to make better decisions when choosing their passwords. -![Password Options](/media/articles/connections/database/password-options.png) +![Password Options](/media/articles/connections/database/dashboard-connections-database-edit_view-password-policy_password-options.png) -The Password Options area is located in your [Auth0 Dashboard](${manage_url}). Go to Connections -> Database, choose a database connection, and then open its settings, and click _Password Policy_. The Password Policy settings page contains the ability to configure the [Password Strength Policy](/connections/database/password-strength) as well as the Password Options below. +The Password Options area is located at [Auth0 Dashboard > Authentication > Database](${manage_url}/#/connections/database). Choose a database connection, then select the **Password Policy** view. The Password Policy settings page contains the ability to configure the [Password Strength Policy](/connections/database/password-strength) as well as the following Password Options. ## Password History -When your users are creating passwords, you often don't want them to repeat the usage of passwords that they've used in the recent past. That, of course, would defeat the purpose of having them change their password! Even if you do not have a required password change policy (for example, forcing users to change passwords every six months), you still might have a reason to disallow the use of previous passwords. For example, if a security breach in your organization causes you to want users to change their passwords everywhere, you want to ensure that they aren't just re-using one that might be compromised! - -Auth0 can retain a password history for each user in order to prevent their re-use. You can choose an amount of prior password entries to keep, up to 24 maximum. +Enabling this option disallows users from setting passwords that repeat passwords they've used in the recent past. Auth0 can retain a password history for each user, up to a maximum of 24 entries per user. Note that when this option is enabled, only password changes going forward will be affected because the history will not have been kept prior to that point. -Note that upon enabling this option, only password changes going forward will be affected, as the history will not have been kept until that point. +Even if you do not have a required password change policy (for example, forcing users to change passwords every six months), you still may want to disallow the use of previous passwords. For example, if a security breach in your organization causes you to force users to change their passwords everywhere, you will want to ensure they aren't just re-using passwords that might be compromised. ## Password Dictionary -The Password Dictionary option, when enabled, allows the use of a password dictionary to stop users from choosing common passwords. The [default dictionary list](https://github.com/danielmiessler/SecLists/blob/master/Passwords/10k_most_common.txt) that Auth0 uses can be enabled just by toggling this option on. It will not allow users to use a password that is present on that list. +Enabling this option disallows users from setting passwords to common options included in a [default dictionary list](https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/10k-most-common.txt). You may also include your own prohibited passwords by entering them in the text field in this section. -Additionally, you can use the text area here and add your own prohibited passwords, one per line. These can be items that are specific to your company, or passwords that your own research has shown you are commonly used in general or at your company in specific. +Note that Auth0 uses case-insensitive comparison with the Password Dictionary feature. ## Personal Data -Enabling this option will force a user that is setting their password to not set passwords that contain any part of the user's personal data. This includes: +Enabling this option disallows users from setting passwords that contain any part of their personal data. This includes: * `name` * `username` @@ -42,4 +48,43 @@ Enabling this option will force a user that is setting their password to not set * `user_metadata.last` * The first part of the user's email will also be checked - `firstpart`@example.com -For example, if the user's name is "John", including "John" in the user's password `John1234` would not be allowed, if this option is enabled. +For example, if the user's name were "John", the user would not be allowed to include "John" in their password; `John1234` would not be allowed. + +## API Access + +Because password options are associated with a Database connection, you can access them using the [Connections endpoints of the Management API](/api/management/v2#!/Connections). Password-related fields are stored in the `options` object. Because these fields are not used for non-database connections, they are not required, so if they are not enabled for a connection, they may not appear. + +For example, after setting a password policy, a MySQL database connection will look like this: + +```json +{ + "id": "con_9dKKcib71UMRiHHW", + "options": { + "password_history": { + "enable": true, + "size": 5 + }, + "password_dictionary": { + "enable": true, + "dictionary": [ + "entry1", + "entry2" + ] + }, + "password_no_personal_info": { + "enable": true + }, + "passwordPolicy": "fair" + }, + "strategy": "auth0", + "name": "MySQL", + "enabled_clients": [ + "smTzlgPEdqGV0i070t6kPhmG98787987", + "ztIyxRuiK7Pr2VTzEGvRqxfuh7DgePbF" + ] +} +``` + +In this example, we can see from the `options` object that all three password options are enabled, password history will store the 5 most recent passwords, and each password will be cross-checked against two dictionaries: `entry1` and `entry2`. + +If you are [creating a connection](/api/management/v2#!/Connections/post_connections) or [updating an existing connection](/api/management/v2#!/Connections/patch_connections_by_id) using the Management API, you can update the password policy for the connection using these fields. diff --git a/articles/connections/database/password-strength.md b/articles/connections/database/password-strength.md index 744cb81bc9..fe9d4a414b 100644 --- a/articles/connections/database/password-strength.md +++ b/articles/connections/database/password-strength.md @@ -1,10 +1,17 @@ --- +title: Password Strength in Auth0 Database Connections description: Auth0's Password Strength feature allows you to customize the level of enforced complexity for passwords entered during user sign-up. Auth0 offers 5 levels of security to match OWASP password recommendations. +topics: + - connections + - database + - db-connections + - passwords +contentType: concept +useCase: customize-connections --- - # Password Strength in Auth0 Database Connections -:::panel-warning Notice +::: warning The **Password Strength** feature is only available for Database connections. The password complexity in Social and Enterprise connections is enforced by each provider. ::: @@ -18,30 +25,109 @@ The following characteristics define a strong password: ## Password policies -Auth0's Password Strength feature allows you to customize the level of enforced complexity for passwords entered during user sign-up. Auth0 offers 5 levels of security to match [OWASP password recommendations](https://www.owasp.org/index.php/Authentication_Cheat_Sheet#Implement_Proper_Password_Strength_Controls). +Auth0's Password Strength feature allows you to customize the level of enforced complexity for passwords entered during user sign-up. Auth0 offers 5 levels of security to match [OWASP password recommendations](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md). At each level, new passwords must meet the following criteria: - * **None** (default): at least 1 character of any type. - * **Low**: at least 6 characters. - * **Fair**: at least 8 characters including a lower-case letter, an upper-case letter, and a number. - * **Good**: at least 8 characters including at least 3 of the following 4 types of characters: a lower-case letter, an upper-case letter, a number, a special character (e.g. !@#$%^&*). - * **Excellent**: at least 10 characters including at least 3 of the following 4 types of characters: a lower-case letter, an upper-case letter, a number, a special character (e.g. `!@#$%^&*`). Not more than 2 identical characters in a row (e.g. `111` is not allowed). +* **None** (default): at least 1 character of any type. +* **Low**: at least 6 characters. +* **Fair**: at least 8 characters including a lower-case letter, an upper-case letter, and a number. +* **Good**: at least 8 characters including at least 3 of the following 4 types of characters: a lower-case letter, an upper-case letter, a number, a special character (such as !@#$%^&*). +* **Excellent**: at least 10 characters including at least 3 of the following 4 types of characters: a lower-case letter, an upper-case letter, a number, a special character (such as `!@#$%^&*`). Not more than 2 identical characters in a row (such as `111` is not allowed). + +::: note +The password policy for Auth0 Dashboard Admins will mirror the criteria set for the **Fair** level. +::: + +## Minimum password length + +You can set a minimum length requirement for passwords that is independent of the policy strength requirements described in the [section immediately above](#password-policies). + +The minimum password length you can set is **1 byte**, while the maximum is **72 bytes**. +::: note +The maximum limit may vary depending on the password hashing algorithm you use. +::: + +If you opt for a higher-level password policy, but you do not specify a minimum length value, the minimum password length for the policy level will automatically be used: +| Password Policy Level | Minimum Password Length | +| - | - | +| None | 1 | +| Low | 6 | +| Fair | 8 | +| Good | 8 | +| Excellent | 10 | -## Change your policy +If you provide a minimum password length, this value supercedes that indicated by the password policy. -To change the password strength policy, go to [Database connections](${manage_url}/#/connections/database). Select the database connection you want to change and click on the **Password Strength** tab: +### Minimum password length when using Universal Login Pages -![Password Strength Panel in Auth0](/media/articles/connections/database/password-strength/jH0kabJPoi.png) +If you are using either the [Universal Login Page](/universal-login) or the [Universal Login Password Reset Page](/universal-login/password-reset), and you want to set the minimum password length value, you will need to complete a few additional configuration steps using the [Auth0 Dashboard](${manage_url}). + +#### Set minimum password length when using Hosted Password Reset Pages + +If you're using a customized [Password Reset Page](/universal-login/password-reset) and you want to set the password length parameter, you must: + +1. Update your templates to include library version 1.5.1 or later +2. Add `password_complexity_options` to leverage the new parameter + +If you do not [update the Password Reset Page](/universal-login/password-reset#edit-the-password-reset-page), Auth0 ignores any attempt to set the minimum password length. + +##### Step 1: Update the change password library version + +To use the new minimum password length feature, you should update the change password library used to version 1.5.1 (or later): + +```text + +``` + +##### Step 2: Add `password_complexity_options` to leverage the new parameter + +You'll need to add `password_complexity_options` to leverage the new parameter. Add this option to the page's script as follows: + +```text + +``` + +Scroll to the bottom and click **Save**. + +#### Set minimum password length when using Universal Login Pages + +If you're using a customized [Login Page](/universal-login) and you want to set the password length parameter, you must [update the page to use Lock version 11.9 or later](/universal-login/classic). + +```text + +``` + +Scroll to the bottom and click **Save**. + +## Change Your Policy + +To change the password strength policy, navigate to [Auth0 Dashboard > Authentication > Database](${manage_url}/#/connections/database). Select the database connection you want to change, select the **Password Policy** view, and locate the **Password Strength** section: +![Auth0 Database Authentication - Password Policy - Password Strength](/media/articles/connections/database/password-strength/dashboard-connections-database-edit_view-password-policy_password-strength.png) The new policy will be enforced on all subsequent user sign-ups and password changes. If the user enters a password that does not match the required criteria, the password will be rejected by Auth0 and the user will be asked to create one that complies with these requirements. -**NOTE**: Existing passwords that were created prior to the change in policy will continue to validate. +::: note +Existing passwords that were created prior to the change in policy will continue to validate. +::: ### Lock -After password policies have been enabled, users will be notified on sign-up and reset password Lock modes if their password does not meet the required criteria. +After password policies have been enabled, users will be notified on sign-up and reset password Lock modes if their password does not meet the required criteria. This is how Lock will appear on the desktop: @@ -51,17 +137,24 @@ and on mobile: ![Auth0 Lock Password Strength checks on Mobile](/media/articles/connections/database/password-strength/moUbn4XXxR.png) -## Custom Signup Errors + +::: note +If Auth0 rejects a provided password, the notification will display in English. If you would like to display notifications in another language, you will need to do so via client-side translation. +::: + +## Custom signup errors Sign-up errors will return a 400 HTTP status code. The JSON response will contain `code: invalid_password` when the password does not meet the selected password policy criteria. The response will also contain additional information that can be used to guide the user to what is incorrect in the selected password: -* A `message` is ready to be formated using the `printf` function (or Node.js `util.format`). +* A `message` is ready to be formatted using the `printf` function (or Node.js `util.format`). * `format` is an array with values to be used in the `message`. (`message` is separate from the `format` to allow easier i18n of error messages in custom UIs.) * `verified` can be either `true` or `false`. Returns `false` if the rule has been violated. -**NOTE**: Some rules are composites. A rule may contain an `items` field that specifies which sub-rules have failed. Each sub-rule will have a `message` and may have a `format`, if required. +::: note +Some rules are composites. A rule may contain an `items` field that specifies which sub-rules have failed. Each sub-rule will have a `message` and may have a `format`, if required. +::: ### Examples @@ -75,8 +168,8 @@ This is a sample `description` error report from a `good` policy with `hello` as "items":[ {"message":"lower case letters (a-z)","verified":true}, {"message":"upper case letters (A-Z)","verified":false}, - {"message":"numbers (i.e. 0-9)","verified":false}, - {"message":"special characters (e.g. !@#$%^&*)","verified":false} + {"message":"numbers (such as 0-9)","verified":false}, + {"message":"special characters (such as !@#$%^&*)","verified":false} ],"verified":false} ]," verified":false @@ -93,14 +186,14 @@ This is a sample `description` error report from a `good` policy with `hello1234 "items":[ {"message":"lower case letters (a-z)","verified":true}, {"message":"upper case letters (A-Z)","verified":false}, - {"message":"numbers (i.e. 0-9)","verified":true}, - {"message":"special characters (e.g. !@#$%^&*)","verified":false} + {"message":"numbers (such as 0-9)","verified":true}, + {"message":"special characters (such as !@#$%^&*)","verified":false} ],"verified":false} ]," verified":false } ``` -## Password Options +## Password options In addition to the Password Strength feature explained here, the Password Policy settings for a database connection also include various Password Options that can further enhance your connection's password policy and ensure that your users have more secure passwords. Take a look at the [Password Options](/connections/database/password-options) documentation for more information. diff --git a/articles/connections/database/rate-limits.md b/articles/connections/database/rate-limits.md deleted file mode 100644 index 073f1900f6..0000000000 --- a/articles/connections/database/rate-limits.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -description: Explains the Auth0 limits the number of repeat login attempts per user and IP address on database connections. ---- - -# Rate Limits on User/Password Authentication - -For database connections Auth0 limits certain types of repeat login attempts depending on the user account and IP address, some of these limits are set as part of [Anomaly Detection](/anomaly-detection): - - - If a user enters their password incorrectly more than 10 times from a single IP address, they will be blocked from logging into that account from that IP address. Auth0 will send an email containing a link to unblock the user to the owner of the database account. This the [Brute Force Protection](/anomaly-detection#brute-force-protection) shield as part of Auth0's Anomaly Detection. - - - Depending on if the [2nd Level Brute Force Protection](/anomaly-detection#2nd-level-brute-force-protection) shield is enabled, users may also be blocked they attempt 100 failed login attempts from a single IP address using different usernames and incorrect passwords in 24 hours. This shield also blocks 50 sign up attempts per minute from the same IP address. - - - A user cannot login more than 10 times-per-minute as the same user from the same location, regardless of having the correct credentials. This limit does not apply if the frequent requests are from different users. - - - For the users of a free account, there is a limit of two logins per second per IP address. - - ## Unblocking a User - - The user account can be unblocked for a given IP address by the database owner following the unblock-user link or by the user properly completing a password reset procedure. - - [Click here to learn more about Blocking and Unblocking a User](/user-profile#blocking-and-unblocking-a-user) - - ## Why are some successful login attempts blocked? - -To protect the health of the system overall, putting these restrictions in place help mitigate the load on our systems. Due to the high amount of customization Auth0 provides, we risk degradation of service from users that may perform high load stress or benchmark tests, as well as the possibility of bad code causing users to login multiple times. - -[Click here to learn more about API Rate Limits](/rate-limits) - - - diff --git a/articles/connections/database/require-username.md b/articles/connections/database/require-username.md index b6d389d408..853dd26a08 100644 --- a/articles/connections/database/require-username.md +++ b/articles/connections/database/require-username.md @@ -1,36 +1,57 @@ --- +title: Adding Username for Database Connections description: How to add a username field for login to database connections. +crews: crew-2 +topics: + - connections + - database + - db-connections +contentType: how-to +useCase: customize-connections --- # Adding Username for Database Connections For database connections, you can have your users sign in with a username instead of their email address. -### To add a required username: +## Require username -1. Go to the [Connections -> Database](${manage_url}/#/connections/database) section of the dashboard. +1. Go to the [Auth0 Dashboard > Authentication > Database](${manage_url}/#/connections/database), and select the name of the connection you want to edit. -1. Select the connection you wish to edit by clicking on the connection name or the Settings gear icon. -![](/media/articles/connections/database/db-connections-page.png) +![Require a username](/media/articles/connections/database/dashboard-connections-database-list.png) -1. Under **Settings**, you will see **Requires Username**, use the toggle here to enable/disable requiring a username. -![](/media/articles/connections/database/requires-username-toggle.png) +2. Locate **Requires Username**, and use the toggle to enable or disable requiring a username. -You can see how the this will affect the login screen by clicking on **Try Connection**. You can see that once **Requires Username** is enabled, new users will have to enter a username and their email address to sign up. +![](/media/articles/connections/database/dashboard-connections-database-settings.png) - +To see how this will affect the login screen, select the **Try Connection** view. Notice that once **Requires Username** is enabled, new users must enter a username and their email address to sign up. -Users can then login with either their username or their email address. For users who registered while **Requires Username** was disabled, there will be no Username field stored for them and they will have to login with their email. +![Login form with username](/media/articles/connections/database/dashboard-connections-database-edit_view-try-connection-requires-username.png) -### Username Limitations +Users can then login with either their username or their email address. Users who registered while **Requires Username** was disabled will not have a Username field stored and will have to log in with their email address. -### Length +### Username length -The default allowed length for usernames is between 1 and 15 characters. However, using the dashboard or via API v2, you can modify the length minimum and maximum (up to a maximum length of 128 characters). +The default allowed length for usernames is between 1 and 15 characters. However, using the Auth0 Dashboard or via the Management API v2, you can modify the length minimum and maximum (up to a maximum length of 128 characters). -![](/media/articles/connections/database/username-length.png) +![Username length](/media/articles/connections/database/dashboard-connections-database-settings_requires-username.png) -### Allowed Characters +### Allowed characters -The username field only allows letters (upper and lowercase A through Z, letters with accent marks not accepted), numbers, and the underscore (`_`) symbol. All other symbols (`@`, `.`, `,`, etc.) are not allowed. +The username field accepts the following characters: +* Alphanumeric characters (without accent marks, automatically converted to lowercase); +* The at sign (@) character (but email addresses are not allowed); +* The caret (^) character; +* The dollar sign ($) character; +* The dot (.) character; +* The exclamation (!) character; +* The grave accent (\`) character; +* The minus (-) character; +* The number sign (#) character; +* The plus (+) character; +* The single quote (') character; +* The tilde (~) character; +* The underscore (_) character; + +No other characters/symbols are allowed. diff --git a/articles/connections/enterprise/_login-experience-tab.md b/articles/connections/enterprise/_login-experience-tab.md new file mode 100644 index 0000000000..3158282d4d --- /dev/null +++ b/articles/connections/enterprise/_login-experience-tab.md @@ -0,0 +1,9 @@ +| Field | Description| +| -- | -- | +| **Identity Provider domains** | A comma-separated list of the domains that can be authenticated in the Identify Provider. This is only applicable when using [Identifier First](/universal-login/identifier-first) authentication in the Universal Login Experience. | +| **Add button** (Optional) | Display a button for this connection in the login page. | +| **Button display name** (Optional) | Text used to customize the login button for new Universal Login. When set the button reads: "Continue with {Button display name}". | +| **Button logo URL** (Optional) | URL of image used to customize the login button for new Universal Login. When set, the Universal Login login button displays the image as a 20px by 20px square. | +::: note +Optional fields are available with the New Login Experience only. Customers using the Classic experience will not see the Add button, Button display name, or Button logo URL. +::: diff --git a/articles/connections/enterprise/active-directory-ldap.md b/articles/connections/enterprise/active-directory-ldap.md new file mode 100644 index 0000000000..c6cdc69026 --- /dev/null +++ b/articles/connections/enterprise/active-directory-ldap.md @@ -0,0 +1,103 @@ +--- +title: Connect Your App to Active Directory using LDAP +connection: Active Directory / LDAP +image: /media/connections/ad.png +public: true +alias: + - ad + - ldap +seo_alias: active-directory +description: Learn how to connect your app to Active Directory (AD) using Lightweight Directory Access Protocol (LDAP) through an enterprise connection. +crews: crew-2 +topics: + - connections + - enterprise + - azure + - active-directory + - microsoft + - ldap +contentType: how-to +useCase: + - customize-connections + - add-idp +--- + +# Connect Your App to Active Directory using LDAP + +Auth0 integrates with Active Directory (AD) using Lightweight Directory Access Protocol (LDAP) through an **Active Directory/LDAP Connector** that you install on your network. + +The **AD/LDAP Connector** (1), is a bridge between your **Active Directory/LDAP** (2) and the **Auth0 Service** (3). This bridge is necessary because AD/LDAP is typically restricted to your internal network, and Auth0 is a cloud service running in a completely different context. + +![Overview Diagram of AD/LDAP Connector](/media/articles/connections/enterprise/active-directory/ldap-connect.png) + +For [high availability and load balancing](/connector/high-availability), you can install multiple instances of the connector. All connections are outbound from the connector to the Auth0 Server, so changes to your firewall are generally unnecessary. + +::: warning +The AD/LDAP Connector is designed for scenarios where your company controls the AD/LDAP server. The connector should not be installed on your customer's servers. + +For B2B scenarios where you want to allow your customer's users to access your applications using their enterprise credentials, connect to your customer's federation service (for example, their own Auth0 service, ADFS, or any SAML identity provider) using one of the available enterprise connections. + +If you install an AD/LDAP connector on your customer's servers and it is connected directly to your Auth0 domain, you will have to handle the passwords of your customer's users directly. Auth0 strongly recommends against these types of deployments and does not support them. +::: + +## Prerequisites + +**Before beginning:** + +* [Register your Application with Auth0](/getting-started/set-up-app). + * Select an appropriate **Application Type**. + * Add an **Allowed Callback URL** of **`${account.callback}`**. + * Make sure your Application's **[Grant Types](/dashboard/guides/applications/update-grant-types)** include the appropriate flows. + +## Steps + +To connect your application to Active Directory/LDAP, you must: + +1. [Create an enterprise connection in Auth0](#create-an-enterprise-connection-in-auth0) and download the installer. +2. [Install the connector on your network](#install-the-connector-on-your-network). +3. [Enable the enterprise connection for your Auth0 Application](#enable-the-enterprise-connection-for-your-auth0-application). +4. [Test the connection](#test-the-connection). + +## Create an enterprise connection in Auth0 + +1. Navigate to [Auth0 Dashboard > Authentication > Enterprise](${manage_url}/#/connections/enterprise), locate **Active Directory / LDAP**, and select its `+`. + + ![Create AD / LDAP Connection](/media/articles/connections/dashboard-connections-enterprise-list.png) + +2. Enter details for your connection, and select **Create**: + +| Field | Description | +| ----- | ----------- | +| **Connection name** | Logical identifier for your connection; it must be unique for your tenant. Once set, this name can't be changed. | +| **Display name** (optional) | Text used to customize the login button for Universal Login. When set, the Universal Login login button reads: "Continue with {Display name}". | +| **Logo URL** (optional) | URL of image used to customize the login button for Universal Login. When set, the Universal Login login button displays the image as a 20px by 20px square. | +| **IdP Domains** (optional) | Comma-separated list of valid email domains that will be allowed to log in using this connection. Only needed if using the Lock login widget. | +| **Disable cache** | When enabled, disables caching. | +| **Use client SSL certificate authentication** | When enabled, uses client SSL certificate authentication. | +| **Use Windows Integrated Auth (Kerberos)** | When enabled, you will be asked to enter a range of IP addresses. When users log in through these IP addresses, Kerberos will be used; otherwise, AD/LDAP username/password will be requested. Typically, the IP range entered represent intranet addresses. | +| **Sync user profile attributes at each login** | When enabled, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. | + +![Enter AD / LDAP Connection Details](/media/articles/connections/dashboard-connections-enterprise-create_ad-ldap_default-empty.png) + +3. Download the provided installer and make note of the provided **Provisioning Ticket URL**. + +::: note +We ship different versions of the connector to install on Windows or Linux platforms. +::: + +## Install the connector on your network + +Set up the [AD/LDAP Connector](/connector) by following the instructions for your platform: + +- [Install the AD/LDAP Connector on Windows](/connector/install) +- [Install the AD/LDAP Connector on Non-Microsoft Platforms](/connector/install-other-platforms) + +## Enable the enterprise connection for your Auth0 application + +To use your new AD connection, you must first [enable the connection](/dashboard/guides/connections/enable-connections-enterprise) for your Auth0 Applications. + +## Test the connection + +Now you're ready to [test your connection](/dashboard/guides/connections/test-connections-enterprise). + +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/enterprise/active-directory.md b/articles/connections/enterprise/active-directory.md deleted file mode 100644 index 90d7dad473..0000000000 --- a/articles/connections/enterprise/active-directory.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Connect Active Directory with Auth0 -connection: Active Directory -image: /media/connections/ms.png -alias: - - ad -seo_alias: active-directory -description: How to connect to Active Directory with Auth0. ---- - - -# Connect Active Directory with Auth0 - -Auth0 integrates with Active Directory/LDAP through the **Active Directory/LDAP Connector** that you install on your network. - -The **AD/LDAP Connector** (1), is a bridge between your **Active Directory** (2) and the **Auth0 Service** (3). This bridge is necessary because AD is typically restricted to your internal network, and Auth0 is a cloud service running in a completely different context. - -![](/media/articles/connections/enterprise/active-directory/ldap-connect.png) - -For [high availability and load balancing](/connector/high-availability), you can install multiple instances of the connector. All connections are out-bound from the connector to the Auth0 Server, so changes to your firewall are generally unnecessary. - -Configuring an AD/LDAP connection in Auth0 requires two steps: - -1. Create an AD/LDAP Connection in Auth0 and download the installer. -2. Install the connector on your network. - -### Create an AD/LDAP Connection in Auth0 - -Select **Connections > Enterprise > AD/LDAP** from the Auth0 dashboard menu. Click the **+ CREATE NEW CONNECTION** button and name the connection. - -![](/media/articles/connections/enterprise/active-directory/ldap-create.png) - -In the *Email domains* field, list the user email domains that will be allowed to login to this particular AD/LDAP connection. - -If you want to use **Kerberos** with this connection, enter a range of IP addresses where **Kerberos** authentication will be enabled from. Typically, these would be intranet addresses. - -If you would like to disable caching, enable the appropriate slider. - -![](/media/articles/connections/enterprise/active-directory/ldap-create-2.png) - -Click **Save**. You are done on the Auth0 side. Click the button on the next page to download the **AD/LDAP Connector** installer to your machine. - -![](/media/articles/connections/enterprise/active-directory/ldap-create-3.png) - -**Note:** We ship different versions of the connector to install on Windows or Linux platforms. - -Keep the **TICKET URL** on hand as you will need it later. - -### Install the connector on your network - -Continue to the instructions on how to [Install the Connector](/connector). diff --git a/articles/connections/enterprise/adfs.md b/articles/connections/enterprise/adfs.md index e6813c9c3d..10b273635a 100644 --- a/articles/connections/enterprise/adfs.md +++ b/articles/connections/enterprise/adfs.md @@ -1,126 +1,159 @@ --- -title: Connect ADFS with Auth0 +title: Connect Your App to ADFS connection: ADFS -image: /media/connections/ms.png +image: /media/connections/adfs.png +public: true alias: - - active-directory-federation-services - - adfs-2 + - active-directory-federation-services + - adfs-2 seo_alias: adfs -description: How to connect ADFS with Auth0. +description: Learn how to connect your application to Active Directory Federation Services (ADFS) using enterprise connections. +crews: crew-2 +topics: + - connections + - enterprise + - azure + - active-directory + - microsoft + - ad-fs +contentType: how-to +toc: true +useCase: + - customize-connections + - add-idp + --- +# Connect Your App to ADFS -# Connect ADFS with Auth0 - -Provide this information to your ADFS administrator: +To connect your application to Microsoft's Active Directory Federation Services (ADFS), you will need to provide the following information to your ADFS administrator: * Realm Identifier: `urn:auth0:${account.tenant}` -* Endpoint: `https://${account.namespace}/login/callback` +* Endpoint: `https://${account.namespace}/login/callback` or `https:///login/callback`, if you are using a [custom domain](/custom-domains). -**Note:** If you want to use the [/oauth/ro](/api/authentication/reference#resource-owner) endpoint you must enable `/adfs/services/trust/13/usernamemixed`. +::: panel Federated Metadata +The Federation Metadata file contains information about the ADFS server's certificates. If the Federation Metadata endpoint (`/FederationMetadata/2007-06/FederationMetadata.xml`) is enabled in ADFS, Auth0 can periodically (once a day) look for changes in the configuration, like a new signing certificate added to prepare 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**: The Federation Metadata file contains information about the ADFS server's certificates. If the Federation Metadata endpoint (`/FederationMetadata/2007-06/FederationMetadata.xml`) is enabled in ADFS, Auth0 can periodically (once a day) look for changes in the configuration, like a new signing certificate added to prepare 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. +You can use a script to to setup the connection or set it up manually. ## Scripted setup -For automated integration, this script uses the [ADFS PowerShell SnapIn](http://technet.microsoft.com/en-us/library/adfs2-powershell-basics.aspx) to create and configure a **Relying Party** that will issue, for the authenticated user, the following claims: **email**, **upn**, **given name** and **surname**. - - (new-object Net.WebClient -property @{Encoding = [Text.Encoding]::UTF8}).DownloadString("https://raw.github.com/auth0/adfs-auth0/master/adfs.ps1") | iex - AddRelyingParty "urn:auth0:${account.tenant}" "https://${account.namespace}/login/callback" +Run the following two commands in the Windows PowerShell window. -Copy and paste the script above into the Windows PowerShell window. +::: note +You must run this script as an administrator of your system. +::: -![](/media/articles/connections/enterprise/adfs/adfs-script.png) +```powershell +(new-object Net.WebClient -property @{Encoding = [Text.Encoding]::UTF8}).DownloadString("https://raw.github.com/auth0/adfs-auth0/master/adfs.ps1") | iex +``` -**Note:** You must run this script as an administrator of your system. +```powershell +AddRelyingParty "urn:auth0:${account.tenant}" "https://${account.namespace}/login/callback" +``` -### What the script does +For automated integration, this script uses the [ADFS PowerShell SnapIn](http://technet.microsoft.com/en-us/library/adfs2-powershell-basics.aspx) to create and configure a **Relying Party** that will issue, for the authenticated user, the following claims: **email**, **upn**, **given name** and **surname**. -#### 1. Creates the *Relying Party* on ADFS +::: note +If you are using the [custom domains](/custom-domains) feature, you will need to replace the `$webAppEndpoint` value with `https:///login/callback`. +::: - $realm = "urn:auth0:${account.tenant}"; - $webAppEndpoint = "https://${account.namespace}/login/callback"; +The script creates the Relying Party Trust on ADFS, as follows: - Add-PSSnapin Microsoft.Adfs.Powershell - Add-ADFSRelyingPartyTrust -Name $realm -Identifier $realm -WSFedEndpoint $webAppEndpoint - $rp = Get-ADFSRelyingPartyTrust -Name $realm +```powershell +$realm = "urn:auth0:${account.tenant}"; +$webAppEndpoint = "https://${account.namespace}/login/callback"; -#### 2. Creates rules to output the most common Active Directory attributes (email, UPN, given name, surname) +Add-PSSnapin Microsoft.Adfs.Powershell +Add-ADFSRelyingPartyTrust -Name $realm -Identifier $realm -WSFedEndpoint $webAppEndpoint +$rp = Get-ADFSRelyingPartyTrust -Name $realm +``` - $rules = @' - @RuleName = "Store: ActiveDirectory -> Mail (ldap attribute: mail), Name (ldap attribute: displayName), Name ID (ldap attribute: userPrincipalName), GivenName (ldap attribute: givenName), Surname (ldap attribute: sn)" - c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] - => issue(store = "Active Directory", - types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", - "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", - "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", - "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname", - "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"), query = ";mail,displayName,userPrincipalName,givenName,sn;{0}", param = c.Value); - '@ +The script also creates rules to output the most common attributes, such as email, UPN, given name, or surname: - Set-ADFSRelyingPartyTrust –TargetName $realm -IssuanceTransformRules $rules +```powershell +$rules = @' +@RuleName = "Store: ActiveDirectory -> Mail (ldap attribute: mail), Name (ldap attribute: displayName), Name ID (ldap attribute: userPrincipalName), GivenName (ldap attribute: givenName), Surname (ldap attribute: sn)" +c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] +=> issue(store = "Active Directory", + types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname", + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"), query = ";mail,displayName,userPrincipalName,givenName,sn;{0}", param = c.Value); +'@ - $rSet = New-ADFSClaimRuleSet –ClaimRule '=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");' - Set-ADFSRelyingPartyTrust –TargetName $realm –IssuanceAuthorizationRules $rSet.ClaimRulesString +Set-ADFSRelyingPartyTrust –TargetName $realm -IssuanceTransformRules $rules -## Manual setup +$rSet = New-ADFSClaimRuleSet –ClaimRule '=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");' +Set-ADFSRelyingPartyTrust –TargetName $realm –IssuanceAuthorizationRules $rSet.ClaimRulesString +``` -If you don't feel comfortable executing the script, you can follow these steps: +## Manual setup part 1: Add a Relying Party Trust 1. Open the ADFS Management Console. -2. Click on **Add Relying Party Trust**. -3. Click **Start** on the first step. -4. Select **Enter data about the relying party manually** and click **Next**. +1. On the right side of the console, click **Add Relying Party Trust**. +1. Click **Start**. +1. Select **Enter data about the relying party manually** and click **Next**. +1. Type a name (such as `${account.appName}`) and click **Next**. +1. Use the default (`ADFS 2.0 profile`) and click **Next**. +1. Use the default (`no encryption certificate`) and click **Next**. +1. Check **Enable support for the WS-Federation...** and type this value in the textbox: - ![](/media/articles/connections/enterprise/adfs/adfs-importmanual.png) -5. Enter an arbitrary name (e.g. "${account.appName}") and click **Next**. -6. Leave the default selection (*ADFS 2.0 profile*) and click **Next**. -7. Leave the default (*no encryption certificate*) and click **Next**. -8. Check **Enable support for the WS-Federation...**, enter the following value in the textbox and click **Next**. + `https://${account.namespace}/login/callback` or if you are using a [custom domain](/custom-domains), use `https:///login/callback` - `https://${account.namespace}/login/callback` - - ![](/media/articles/connections/enterprise/adfs/adfs-url.png) - -9. Add a *Relying party trust identifier* with the following value and click **Add** and then **Next**. +1. Click **Next**. +1. Add a Relying Party Trust identifier with this value: `urn:auth0:${account.tenant}` - ![](/media/articles/connections/enterprise/adfs/adfs-identifier.png) -10. Leave the default option (*Permit all users...*) and click **Next**. -11. Click **Next** and then **Close**. The UI will show a new window to edit the **Claim Rules**. -12. Click on **Add Rule...**. -13. Leave the default option (*Send LDAP Attributes as Claims*). - - ![](/media/articles/connections/enterprise/adfs/adfs-sendldap.png) - -14. Give the rule an arbitrary name that describes what it does. For example: +1. Click **Add** and then **Next**. +1. Leave the default `Permit all users...` and click **Next**. +1. Click **Next** and then **Close**. - `Map ActiveDirectory attributes (mail -> Mail, displayName -> Name, userPrincipalName -> NameID, givenName -> GiveName, sn -> Surname)` +## Manual setup part 2: Add a claim issuance policy rule -15. Select the mappings as shown in this image and click **Finish**. +1. If you're using Windows Server 2019, the Edit Claim Issuance Polcy dialog box automatically opens when you finish the Add Relying Party Trust wizard. If you're using Windows 2012 or 2016, follow these steps: + | In Windows Server 2012 | In Windows Server 2016 | + | --- | --- | + | In the Actions panel on the right side of the console, find the Relying Party Trust you just created. Beneath it, click **Edit Claim Issuance Policy**. | In the console tree, under ADFS, click **Relying Party Trusts**. On the right side of the console, find the Relying Party Trust you just created. Right-click it and click **Edit Claim Issuance Policy**. | - ![](/media/articles/connections/enterprise/adfs/adfs-claimrules.png) +2. In the Edit Claim Issuance Policy Window, under Issuance Transform Rules, click **Add Rule...**. +3. Leave the default `Send LDAP Attributes as Claims`. +4. Give the rule a name that describes what it does. +5. Under Attribute Store, select **Active Directory**. +6. Select these mappings under `Mapping of LDAP attributes to outgoing claim types` and click **Finish**. -16. (Optional) Adding additional LDAP attributes + | LDAP Attribute | Outgoing Claim Type | + | --- | --- | + | E-Mail-Addresses | E-Mail Address | + | Display-Name | Name | + | User-Principal-Name | Name ID | + | Given-Name | Given Name | + | Surname | Surname | - The mappings created on step **15** are the most commonly used, but if you need additional LDAP attributes with information about the user, you can add more claim mappings. +### Add additional LDAP attributes - > If you already closed the window on the previous step, select **Edit Claim Rules** on the context menu for the Relying Party Trust you created, and edit the rule from step **14**). +The mappings in the previous steps are the most commonly used, but if you need additional LDAP attributes with information about the user, you can add more claim mappings. - Create a row for every additional LDAP attribute you need, choosing the attribute name on the left column and desired claim type on the right column. - If the claim type you are looking for doesn't exist, you have two options: +1. If you closed the window on the previous step, select **Edit Claim Rules** on the context menu for the Relying Party Trust you created, and edit the rule. - - Type a namespace-qualified name for the new claim (i.e. `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/department`). - - Register a new claim type (under **AD FS | Services | Claim Descriptions**) on the ADFS admin console), and use the claim name in the mapping. +2. Create an additional row for every LDAP attribute you need, choosing the attribute name in the left column and desired claim type in the right column. - Auth0 will use the name part of the claim type (i.e. `department` in `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/department`) as the attribute name for the user profile. +3. If the claim type you are looking for doesn't exist, you have two options: -Yes, running the script is definitely easier. + * Type a [namespace-qualified name](/tokens/guides/create-namespaced-custom-claims) for the new claim (for example `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/department`). + * Register a new claim type (under **ADFS > Services > Claim Descriptions**) on the ADFS admin console), and use the claim name in the mapping. -## Next steps + Auth0 uses the name part of the claim type (for example `department` in `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/department`) as the attribute name for the user profile. -After you configure the connection, you have to configure your application to use it. You can initiate login using [Lock](/libraries/lock), [Auth0.js](/libraries/auth0js), or use the [Authentication API endpoint](/api/authentication?http#enterprise-saml-and-others-). +## Next Steps -For detailed instructions and samples for a variety of technologies, refer to our [Quickstarts](/quickstarts). +Now that you have a working connection, the next step is to configure your application to use it. You can follow our step-by-step quickstarts or use our libraries and API. -We also have a blog post that shows how to [Authenticate PHP with ADFS using Auth0](https://auth0.com/authenticate/php/adfs). +::: next-steps +* [Get started with our Quickstarts](/quickstarts) +* [Configure your application using our Lock login form](/libraries/lock) +* [Configure your application using our Auth0.js library and your own UI](/libraries/auth0js) +* [Use our Authentication API to authenticate](/api/authentication) +::: diff --git a/articles/connections/enterprise/azure-active-directory-classic.md b/articles/connections/enterprise/azure-active-directory-classic.md deleted file mode 100644 index e658f1a0e2..0000000000 --- a/articles/connections/enterprise/azure-active-directory-classic.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: Connect Azure Active Directory with Auth0 (Classic Portal) -description: How to obtain a ClientId and Client Secret for a Microsoft Azure Active Directory with the Classic Portal. ---- - -# Obtain a *ClientId* and *Client Secret* for a Microsoft Azure Active Directory- Classic Portal - -::: panel-info Notice -This page uses the Azure Active Directory Classic Portal, for information on using the current portal, [click here.](/connections/enterprise/azure-active-directory) -::: - -To allow users to login using a Microsoft Azure Active Directory account, you must register your application through the Microsoft Azure portal. If you don't have a Microsoft Azure account, you can [signup](http://www.windowsazure.com/en-us/pricing/free-trial) for free. - -**NOTE:** There is no way to create an application that integrates with Microsoft Azure AD without having **your own** Microsoft Azure AD instance. - -## 1. Create a new Microsoft Azure Active Directory instance - -Login to Microsoft Azure and click on **Active Directory** on the Dashboard. - -![](/media/articles/connections/enterprise/azure-active-directory/waad-0.png) - -Click on **ADD+** at the bottom of the screen. - -![](/media/articles/connections/enterprise/azure-active-directory/waad-1.png) - -Enter a *subdomain*, e.g.: **${account.tenant}**. This can be any text. (It does not have to match the Auth0 subdomain and it will be used in the next step.) Also enter your country and a friendly name for your organization. - -![](/media/articles/connections/enterprise/azure-active-directory/waad-2.png) - -## 2. Create a new application - -Once the Microsoft Azure AD instance has been created, you need to create an application. Go to **APPLICATIONS** and click on **ADD AN APPLICATION**. - -![](/media/articles/connections/enterprise/azure-active-directory/waad-3.png) - -Select **Add an application my organization is developing**. - -![](/media/articles/connections/enterprise/azure-active-directory/waad-3b.png) - -Enter a friendly name for the application and select **WEB APPLICATION AND/OR WEB API**. - -![](/media/articles/connections/enterprise/azure-active-directory/waad-4.png) - -Proceed to the next screen and enter the following: - -* **SIGN-ON URL**: your application URL (completely arbitrary) -* **APP ID URI**: https://**${account.tenant}**.onmicrosoft.com/yourapp - -**NOTE:** The **APP ID URI** is just a logical identifier, not a real URL. It is important to use the value as specified above in the **APP ID URI** field. For example, if the Microsoft Azure AD you've just created is **myorg.onmicrosoft.com**, you would enter https://**myorg.onmicrosoft.com***/yourapp* here. - -![](/media/articles/connections/enterprise/azure-active-directory/waad-5.png) - -## 3. Configure the application - -Once the application has been created, you have to configure it. Click **CONFIGURE** to continue. On this screen you can customize the logo and the application URL that you entered before, if needed. - -Enter the following values on **KEYS** and **REPLY URL**, and click **Save**. - -* **KEYS**: Select 1 or 2 years (the key will be displayed when these settings are saved) -* **REPLY URL**: https://${account.namespace}/login/callback - -![](/media/articles/connections/enterprise/azure-active-directory/waad-8.png) - -The next step is to modify permissions so your app can read the directory. Select the *Read Directory Data* and *Enable sign-on and read users' profiles* delegated permissions. - -![](/media/articles/connections/enterprise/azure-active-directory/waad-8b.png) - -**NOTE:** If you want to enable extended attributes (like *Extended Profile* or *Security Groups*) you will also need to enable the following permissions: **Application Permissions:** *Read directory data*, **Delegated Permissions:** *Access your organization's directory*. - -Click **SAVE** at the bottom of the screen and the key will be displayed. Make sure to copy the value of this key before leaving this screen. - -![](/media/articles/connections/enterprise/azure-active-directory/waad-9.png) - -## 4. Copy the Client ID and Secret to Auth0 - -Login to your [Auth0 Dashboard](${manage_url}), and select the **Connections > Enterprise** menu option. Select **Windows Azure AD**. - -Copy the Client ID and the Key generated by Microsoft Azure in the [previous step](#configure-the-application) into the *Client ID* and *Client Secret* fields in Auth0. - -![](/media/articles/connections/enterprise/azure-active-directory/waad-10.png) - -**Congratulations!** You are now ready to accept Microsoft Azure AD users. - -## Troubleshooting - -* When granting access, make sure to use an *Incognito/InPrivate* window and a Global Administrator user. - -* If you get *Access cannot be granted to this service because the service listing is not properly configured by the publisher*, try selecting the **Application is Multi Tenant** option in the Windows Azure AD application on the Azure dashboard. - -## Signing Key Rollover in Azure Active Directory - -Signing keys are used by the identity provider to sign the authentication token it issues, and by the consumer application (Auth0 in this case) to validate the authenticity of the generated token. - -For security purposes, Azure AD’s signing key [rolls on a periodic basis](https://azure.microsoft.com/en-us/documentation/articles/active-directory-signing-key-rollover/). If this happens, **you do not need to take any action**. Auth0 will use the new key automatically. diff --git a/articles/connections/enterprise/azure-active-directory-native.md b/articles/connections/enterprise/azure-active-directory-native.md index a882e598d3..142f690faa 100644 --- a/articles/connections/enterprise/azure-active-directory-native.md +++ b/articles/connections/enterprise/azure-active-directory-native.md @@ -1,7 +1,8 @@ --- -title: Native Azure Active Directory applications with Auth0 +title: Connect Your Native App to Microsoft Azure Active Directory Using Resource Owner Flow connection: Azure Active Directory Native image: /media/connections/azure.png +public: true alias: - azure-ad-native-resource-owner - waad-native-resource-owner @@ -10,62 +11,175 @@ alias: - microsoft-azure-ad-native-resource-owner - microsoft-azure-active-directory-native-resource-owner seo_alias: azure-active-directory-native -description: How to setup native Azure Active Directory applications with Auth0 for a Resource Owner. +description: Learn how to connect your app to Microsoft Azure Active Directory using an enterprise connection with the Resource Owner flow. +crews: crew-2 +topics: + - connections + - enterprise + - azure + - active-directory + - microsoft + - native-apps +contentType: how-to +useCase: + - customize-connections + - add-idp --- +# Connect Your Native App to Microsoft Azure Active Directory Using Resource Owner Flow -# Native Azure Active Directory applications with Auth0 (Resource Owner flow) +In addition to the **WS-Federation** and **OpenID Connect** flows, it's also possible to use the **Resource Owner** flow with Azure AD. This flow allows you to capture and validate a user's credentials (email and password) instead of showing the Azure AD login page. For security and Single Sign-on (SSO) reasons, this is not the recommended approach; still, **Resource Owner** flow can be useful in Native mobile scenarios or to batch-process authentication with Azure AD. -In addition to the **WS-Federation** and **OpenID Connect** flows, it's also possible to use the **Resource Owner** flow with Azure AD. This flow allows you to capture and validate a user's credentials (email and password) instead of showing the Azure AD login page. While this is not the recommended approach for security and SSO reasons, **Resource Owner** flow could be used in Native mobile scenarios or to batch process authentication with Azure AD. +This configuration requires two applications: a *Web Application and/or Web API* and a *Native Client Application*. From Azure AD's point of view, users will be authenticated using the *Native Client Application* to gain access to the *Web Application and/or Web API*. -This setup will require two applications, a *Web Application and/or Web API* and a *Native Client Application*. From Azure AD's point of view, users will be authenticated using the *Native Client Application* to gain access to the *Web Application and/or Web API*. +![Overview Diagram of Azure AD Apps using Resource Owner flow](/media/articles/connections/enterprise/azure-active-directory/azure-ad-native-app.png) -![](/media/articles/connections/enterprise/azure-active-directory/azure-ad-native-app.png) +## Prerequisites -## 1. Define a *Web Application and/or Web API* in Azure Active Directory +**Before beginning:** -The first step is to define the "Web Application and/or Web API". +* [Register your Application with Auth0](/getting-started/set-up-app). + * Select an **Application Type** of **Native**. + * Add an **Allowed Callback URL**. Your callback URL format will vary depending on your platform. For details about the format for your platform, see our [Native Quickstarts](/quickstart/native). + * Make sure your Application's **[Grant Types](/dashboard/guides/applications/update-grant-types)** include the appropriate flows. -![](/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-new-api.png) +## Steps -During setup, you'll need to specify the `App ID Uri` which will be needed later to configure the connection in Auth0. +To connect your application using Resource Owner flow, you must: -![](/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-new-api-properties.png) +1. [Set up your applications in the Microsoft Azure portal](#set-up-your-applications-in-the-microsoft-azure-portal). +2. [Create an enterprise connection in Auth0](#create-an-enterprise-connection-in-auth0). +3. [Enable the enterprise connection for your Auth0 Application](#enable-the-enterprise-connection-for-your-auth0-application). +4. [Test the connection](#test-the-connection). -## 2. Define a *Native Client Application* in Azure Active Directory +::: panel Microsoft Azure Account +Before proceeding, you will need a valid Microsoft Azure account and must have **your own** Microsoft Azure AD directory for which you are a Global administrator. -After creating the first application, you'll need to define a *Native Client Application*. +If you don't have a Microsoft Azure account, you can [sign up](https://azure.microsoft.com/en-us/free) for free; then, if necessary, set up an Azure AD directory by following Microsoft's [Quickstart: Create a new tenant in Azure Active Directory - Create a new tenant for your organization](https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-access-create-new-tenant#create-a-new-tenant-for-your-organization). -![](/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-new-native-app.png) +Alternatively, if you have an Office 365 account, you can use the account's Azure AD instance instead of creating a new one. To access your Office 365 account's Azure AD instance: -In this application, you'll need to configure the following permissions to other applications: +1. [Sign in to Office 365](https://portal.office.com), and navigate to the [Office 365 Admin Center](https://portal.office.com/adminportal/home#/homepage). +2. Open the **Admin centers** menu drawer located in the left menu, and click on **Azure AD**. +::: - - **Windows Azure Active Directory**: *Read directory data* and *Enable sign-on and read users' profiles* - - Your **Web Application and/or Web API**: *Access your API* +## Set up your applications in the Microsoft Azure portal -![](/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-native-app-permissions.png) +::: warning +Before proceeding, you must have already set up **your own** Microsoft Azure AD directory for which you are a Global administrator. To learn how, follow Microsoft's [Quickstart: Create a new tenant in Azure Active Directory - Create a new tenant for your organization](https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-access-create-new-tenant#create-a-new-tenant-for-your-organization). +::: -## 3. Configure the connection in Auth0 +### Register a new web application -After creating both applications in Azure Active Directory, the Auth0 connection can be configured. The `App ID Uri` must be set to the Uri which was configured previously in the *Web Application and/or Web API* and the `Client ID` must be set to the `Client ID` of the *Native Client Application*. In this setup, the `Client Secret` does not matter and can be set to any value. +To learn how to register your application with Azure AD, follow Microsoft's [Quickstart: Register an application with the Microsoft identity platform](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app) doc. -![](/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-create-native-connection.png) +::: warning +If you have more than one Azure AD directory, make sure you are in the correct directory when you register your app. +::: -## 4. Test the connection +While setting up your app, make sure you use the following settings: -To test the complete setup, you can use the [Resource Owner endpoint](/api/authentication/reference#resource-owner). Enter the username and password of a user and choose the connection. Click **Try Me!** to sign in as that user. +* If you want to allow users from external organizations (like other Azure AD directories), then when asked to choose **Supported account types**, choose the appropriate multitenant option. Multitenant options include the following: **Accounts in any organizational directory (Any Azure AD directory - Multitenant)**. +* When asked to set a **Redirect URI**, make sure `Web` is selected and enter your callback URL: `https://${account.namespace}/login/callback`. -![](/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-login.png) +<%= include('../_find-auth0-domain-redirects.md') %> + +During this process, Microsoft will generate an **Application (client) ID** for your application; you can find this on the app's **Overview** screen. Make note of this value. + +### Configure your web application to expose an API + +To learn how to configure your **Web** application to expose an API with Azure AD, follow Microsoft's [Quickstart: Configure an application to expose web APIs](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-configure-app-expose-web-apis). + +While configuring your app, make sure you use the following settings: + +* When asked to set a **Scope name**, enter `API.Access`. + +During this process, Microsoft will generate an **Application ID URI**. Make note of this value. + +### Register a new native application + +Again, follow Microsoft's [Quickstart: Register an application with the Microsoft identity platform](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app) doc. + +::: warning +If you have more than one Azure AD directory, make sure you are in the correct directory when you register your app. +::: + +While setting up your app, make sure you use the following settings: + +* If you want to allow users from external organizations (like other Azure AD directories), then when asked to choose **Supported account types**, choose the appropriate multitenant option. Multitenant options include the following: **Accounts in any organizational directory (Any Azure AD directory - Multitenant)**. +* When asked to set a **Redirect URI**, make sure `Public client/native (mobile & desktop)` is selected and enter your callback URL. Your callback URL format will vary depending on your platform. For details about the format for your platform, see our [Native Quickstarts](/quickstart/native). + +During this process, Microsoft will generate an **Application (client) ID** for your application; you can find this on the app's **Overview** screen. Make note of this value. + +### Create a client secret for your native application + +To learn how to create a client secret, follow Microsoft's [Quickstart: Configure a client application to access web APIs - Add Credentials to your web application](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-configure-app-access-web-apis#add-credentials-to-your-web-application). You want to generate a **Client secret**. Once generated, make note of this value. + +::: note +If you configure an expiring secret, make sure to record the expiration date; you will need to renew the key before that day to avoid a service interruption. +::: + +### Add permissions for your native application + +To learn how to add permissions for your **Native** application, follow Microsoft's [Quickstart: Configure a client application to access web APIs - Add permissions to access web APIs](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-configure-app-access-web-apis#add-permissions-to-access-web-apis). You want to configure permissions for the **Microsoft Graph API** and for the **Web** application you configured to expose an API. + +While setting up your permissions, make sure you use the following settings for **Microsoft Graph API**: + +* When asked for a permission type, choose **Delegated permissions**. Under **User**, select **User.Read** so your app can sign in users and read the signed-in user's profile. Under **Directory**, select **Directory.Read.All** so your app can read directory data on the signed-in user's behalf. + +For your **Web** app that you configured to expose an API, make sure you use the following settings: + +* When asked for a permission type, choose **Delegated permissions**. Under **API**, select **API.Access** so your app can access your API on the user's behalf. + +## Configure the connection in Auth0 + +After creating both applications in Azure AD, you can configure the Auth0 connection. + +1. Navigate to the [Auth0 Dashboard > Authentication > Enterprise](${manage_url}/#/connections/enterprise), locate **Microsoft Azure AD**, and click its `+`. + +![Create Connection Type](/media/articles/connections/dashboard-connections-enterprise-list.png) + +2. Enter details for your connection, and select **Create**: + +| Field | Description | +| ----- | ----------- | +| **Connection name** | Logical identifier for your connection; it must be unique for your tenant. Once set, this name can't be changed. | +| **Microsoft Azure AD Domain** | Your Azure AD domain name. You can find this on your Azure AD directory's overview page in the Microsoft Azure portal. | +| **Client ID** | Unique identifier for your registered Azure AD application. Enter the saved value of the **Application (client) ID** for the **Native** application you registered in Azure AD. | +| **Client Secret** | String used to gain access to your registered Azure AD application. Enter the saved value of the **Client secret** for the **Native** app you registered in Azure AD. | +| **Use common endpoint** (optional) | When enabled, your application will dynamically accept users from new directories. Typically enabled if you selected a multitenant option for **Supported account types** for the application you registered in Azure AD. When enabled, Auth0 will redirect users to Azure's common login endpoint, and Azure will perform *Home Realm Discovery* based on the domain of the user's email address. | +| **Identity API** | API used by Auth0 to interact with Azure AD endpoints. Learn about the differences in behavior in Microsoft's [Why update to Microsoft identity platform (v2.0)](https://docs.microsoft.com/en-us/azure/active-directory/develop/azure-ad-endpoint-comparison) doc. Select `Azure Active Directory (v1)`, and for **App ID URI**, enter the saved value of the **Application ID URI** that was created when you configured your **Web** application to expose an API. | +| **Attributes** | Basic attributes for the signed-in user that your app can access. Indicates how much information you want stored in the Auth0 User Profile. | +| **Extended Attributes** (optional) | Extended attributes for the signed-in user that your app can access. | +| **Auth0 APIs** (optional) | When selected, indicates that you require the ability to make calls to the Azure AD Users API. | +| **Sync user profile attributes at each login** | When enabled, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. | +| **Email Verification** | Choose how Auth0 sets the `email_verified` field in the user profile. To learn more, see [Email Verification for Azure AD and ADFS](/connections/azuread-adfs-email-verification). | + +![Configure Microsoft Azure AD Settings](/media/articles/connections/dashboard-connections-enterprise-create_azure-ad_default-empty.png) + +## Enable the enterprise connection for your Auth0 application + +To use your new Azure AD enterprise connection, you must first [enable the connection](/dashboard/guides/connections/enable-connections-enterprise) for your Auth0 Applications. + +## Test the connection + +Now you're ready to [test your connection](/dashboard/guides/connections/test-connections-enterprise). ## Group Memberships and Advanced Profile Information -In this native flow Auth0 will receive an access token from Azure AD which has been issued for your **Web Application and/or Web API**. Because of that features like loading group memberships and advanced profile information will no longer work. This is because the access token received by Azure AD can no longer be used to query the Azure AD Graph API for this additional information. +In this native flow, Auth0 will receive an Access Token from Azure AD which has been issued for your Azure AD **Web** application. As a result, features like loading group memberships and advanced profile information will no longer work because the Access Token received by Azure AD can no longer be used to query the Azure AD Graph API for this additional information. + +However, if you depend on group memberships and advanced profile information, you can change your configuration to accommodate your needs. -If you depend on group memberships and advanced profile information you can however change your configure. First you will need to configure the **Native** application with additional read permissions for Azure AD: +1. Configure your **Native** application with additional permissions for the **Microsoft Graph API**: -![](/media/articles/connections/enterprise/azure-active-directory/azure-ad-native-permissions.png) + * When asked for a permission type, choose **Delegated permissions**. Under **Directory**, select **Directory.AccessAsUser.All**, so your app can access the directory as the signed-in user. -Then in Auth0 instead of specifying the `App ID Uri` of your "Web Application and/or Web API" you will need to use the Azure AD Graph API instead: +2. In Auth0, modify your Azure AD enterprise connection as follows, then **Save Changes**: + + * In **Identity API**, select `Azure Active Directory (v1)`, and for **App ID URI**, enter the URI of the Azure AD Graph API: ``` https://graph.windows.net ``` + +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/enterprise/azure-active-directory.md b/articles/connections/enterprise/azure-active-directory.md deleted file mode 100644 index 6182738d3c..0000000000 --- a/articles/connections/enterprise/azure-active-directory.md +++ /dev/null @@ -1,102 +0,0 @@ ---- -title: Connect Azure Active Directory with Auth0 -connection: Azure Active Directory -image: /media/connections/azure.png -alias: - - azure-ad - - waad - - windows-azure-ad - - windows-azure-active-directory - - microsoft-azure-ad - - microsoft-azure-active-directory -seo_alias: azure-active-directory -description: How to obtain a ClientId and Client Secret for Microsoft Azure Active Directory. ---- - -# Obtain a *ClientId* and *Client Secret* for Microsoft Azure Active Directory - -::: panel-info Notice -This page uses the current portal of the Azure Active Directory, for information on using the classic portal, [click here.](/connections/enterprise/azure-active-directory-classic) -::: - -To allow users to login using a Microsoft Azure Active Directory account, you must register your application through the Microsoft Azure portal. If you don't have a Microsoft Azure account, you can [signup](https://azure.microsoft.com/en-us/free) for free. You can access the Azure management portal from your Microsoft service, or visit [https://manage.windowsazure.com](https://manage.windowsazure.com) and sign in to Azure using the global administrator account that was used to create the Office 365 organization. - -**NOTE:** There is no way to create an application that integrates with Microsoft Azure AD without having **your own** Microsoft Azure AD instance. - -## 1. Create a new application - -Login to Microsoft Azure and choose **Azure Active Directory** from the sidebar. - -![Select Active Directory](/media/articles/connections/enterprise/azure-active-directory/azure-ad-1-1.png) - -Then under **MANAGE**, select **App registrations**. - -![Select App registrations](/media/articles/connections/enterprise/azure-active-directory/azure-ad-1-2.png) - -Then click on the **+ ADD** button to add a new application. - -Enter a name for the application, select **Web app/API** as the **Application Type**, and for **Sign-on URL** enter your application URL (completely arbitrary). - -![Create application form](/media/articles/connections/enterprise/azure-active-directory/azure-ad-1-3.png) - -## 2. Configuring the permissions - -Once the application has been created, you will have to configure the permissions. Click on the name of the application to open the **Settings** section, then click **Required permissions**. - -![Choose Required Permissions](/media/articles/connections/enterprise/azure-active-directory/azure-ad-3-1.png) - -Then click on **Windows Azure Active Directory** to change the access levels. - -![Required Permissions](/media/articles/connections/enterprise/azure-active-directory/azure-ad-3-2.png) - -The next step is to modify permissions so your app can read the directory. Under **DELEGATED PERMISSIONS** check next to **Sign in and read user profile** and **Read directory data**. - -![Check access levels](/media/articles/connections/enterprise/azure-active-directory/azure-ad-3-3.png) - -**NOTE:** If you want to enable extended attributes (like *Extended Profile* or *Security Groups*) you will also need to enable the following permissions: **Application Permissions:** *Read directory data*, **Delegated Permissions:** *Access the directory as the signed-in user*. - -Click the **SAVE** button at the top to save these changes. - -### 3. Creating the key - -Next you will need to create a key which will be used as the **Client Secret** in the Auth0 connection. Click on **Keys** from the **Settings** menu. - -![Select Keys](/media/articles/connections/enterprise/azure-active-directory/azure-ad-4-1.png) - -Enter a name for the key and for the duration of the key select 1 or 2 years. - -![Creating a Key](/media/articles/connections/enterprise/azure-active-directory/azure-ad-4-2.png) - -Click on **Save** and the key will be displayed. Make sure to copy the value of this key before leaving this screen, this is your **Client Secret** used in the next step. - -## 4. Copy the Client ID and Client Secret to Auth0 - -Login to your [Auth0 Dashboard](${manage_url}), and select the **Connections > Enterprise** menu option. Select **Windows Azure AD**. - -For the **Client ID**, this value is stored as the **Application ID** in Azure AD. - -![Application ID](/media/articles/connections/enterprise/azure-active-directory/azure-ad-5-1.png) - -For the **Client Secret** use the value that was shown for the key when you created it in the previous step. - -![Create Azure AD Connection](/media/articles/connections/enterprise/azure-active-directory/add-azure-connection.png) - -Click **SAVE** when you have finished. - -**Congratulations!** You are now ready to accept Microsoft Azure AD users. - -## Troubleshooting - -* Make sure you are in the desired directory to add you application. If you do not have an existing directory you will need to create one. - -* When granting access, make sure to use an *Incognito/InPrivate* window and a Global Administrator user. - -* If you get *Access cannot be granted to this service because the service listing is not properly configured by the publisher*, try enabling **Multi Tenanted** in the Windows Azure AD application under **Settings** -> **Properties**. - -## Signing Key Rollover in Azure Active Directory - -Signing keys are used by the identity provider to sign the authentication token it issues, and by the consumer application (Auth0 in this case) to validate the authenticity of the generated token. - -For security purposes, Azure AD’s signing key [rolls on a periodic basis](https://azure.microsoft.com/en-us/documentation/articles/active-directory-signing-key-rollover/). If this happens, **you do not need to take any action**. Auth0 will use the new key automatically. - - diff --git a/articles/connections/enterprise/azure-active-directory/index.yml b/articles/connections/enterprise/azure-active-directory/index.yml new file mode 100644 index 0000000000..77c7ae73c3 --- /dev/null +++ b/articles/connections/enterprise/azure-active-directory/index.yml @@ -0,0 +1,8 @@ +versioning: + baseUrl: connections/enterprise/azure-active-directory + current: v2 + versions: + - v1 + - v2 + defaultArticles: + v2: index diff --git a/articles/connections/enterprise/azure-active-directory/v1/index.md b/articles/connections/enterprise/azure-active-directory/v1/index.md new file mode 100644 index 0000000000..ec54bfa753 --- /dev/null +++ b/articles/connections/enterprise/azure-active-directory/v1/index.md @@ -0,0 +1,116 @@ +--- +title: Connect your app to Azure Active Directory (Classic Portal) +description: How to obtain a ClientId and Client Secret for a Microsoft Azure Active Directory with the Classic Portal. +crews: crew-2 +toc: true +topics: + - connections + - enterprise + - azure + - active-directory + - microsoft +contentType: + - index + - how-to +useCase: + - customize-connections + - add-idp +--- + +# Connect your app to Azure Active Directory (Classic Portal) + +::: version-warning +This document covers the Azure Active Directory Classic Portal. +::: + +To allow users to login using a Microsoft Azure Active Directory account, you must register your application through the Microsoft Azure portal. If you don't have a Microsoft Azure account, you can [signup](http://www.windowsazure.com/en-us/pricing/free-trial) for free. + +::: note +There is no way to create an application that integrates with Microsoft Azure AD without having **your own** Microsoft Azure AD instance. +::: + +## 1. Create a new Microsoft Azure Active Directory instance + +Log in to Microsoft Azure, and select **Active Directory** from the Dashboard. + +![](/media/articles/connections/enterprise/azure-active-directory/waad-0.png) + +Click on **ADD+** at the bottom of the screen. + +![](/media/articles/connections/enterprise/azure-active-directory/waad-1.png) + +Enter a *subdomain*, such as: **${account.tenant}**. This can be any text. (It does not have to match the Auth0 subdomain and it will be used in the next step.) Also enter your country and a friendly name for your organization. + +![](/media/articles/connections/enterprise/azure-active-directory/waad-2.png) + +## 2. Create a new application + +Once the Microsoft Azure AD instance has been created, you need to create an application. Go to **APPLICATIONS** and click on **ADD AN APPLICATION**. + +![](/media/articles/connections/enterprise/azure-active-directory/waad-3.png) + +Select **Add an application my organization is developing**. + +![](/media/articles/connections/enterprise/azure-active-directory/waad-3b.png) + +Enter a friendly name for the application and select **WEB APPLICATION AND/OR WEB API**. + +![](/media/articles/connections/enterprise/azure-active-directory/waad-4.png) + +Proceed to the next screen and enter the following: + +* **SIGN-ON URL**: your application URL +* **APP ID URI**: https://**${account.tenant}**.onmicrosoft.com/yourapp + +::: note +The **APP ID URI** is just a logical identifier, not a real URL. It is important to use the value as specified above in the **APP ID URI** field. For example, if the Microsoft Azure AD you've just created is **myorg.onmicrosoft.com**, you would enter https://**myorg.onmicrosoft.com***/yourapp* here. +::: + +![](/media/articles/connections/enterprise/azure-active-directory/waad-5.png) + +## 3. Configure the application + +Once the application has been created, you have to configure it. Click **CONFIGURE** to continue. On this screen you can customize the logo and the application URL that you entered before, if needed. + +Enter the following values on **KEYS** and **REPLY URL**, and click **Save**. + +* **KEYS**: Select 1 or 2 years (the key will be displayed when these settings are saved) +* **REPLY URL**: https://${account.namespace}/login/callback + +![](/media/articles/connections/enterprise/azure-active-directory/waad-8.png) + +The next step is to modify permissions so your app can read the directory. Select the *Read Directory Data* and *Enable sign-on and read users' profiles* delegated permissions. + +![](/media/articles/connections/enterprise/azure-active-directory/waad-8b.png) + +::: note +If you want to enable extended attributes (like *Extended Profile* or *Security Groups*) you will also need to enable the following permissions: **Application Permissions:** *Read directory data*, **Delegated Permissions:** *Access your organization's directory*. +::: + +Click **Save** at the bottom of the screen and the key will be displayed. Make sure to copy the value of this key before leaving this screen. + +![](/media/articles/connections/enterprise/azure-active-directory/waad-9.png) + +## 4. Copy the Client ID and Secret to Auth0 + +Go to [Auth0 Dashboard > Authentication > Enterprise](${manage_url}/#/connections/enterprise), and select **Microsoft Azure AD**. + +Copy the Client ID and the Key generated by Microsoft Azure in the [previous step](#configure-the-application) into the *Client ID* and *Client Secret* fields in Auth0. + +![](/media/articles/connections/enterprise/azure-active-directory/waad-10.png) + +**Congratulations!** You are now ready to accept Microsoft Azure AD users. + +## Troubleshooting + +* When granting access, make sure to use an *Incognito/InPrivate* window and a Global Administrator user. + +* If you get *Access cannot be granted to this service because the service listing is not properly configured by the publisher*, try selecting the **Application is Multi Tenant** option in the Windows Azure AD application in the Azure Dashboard. + +## Signing Key Rollover in Azure Active Directory + +Signing keys are used by the identity provider to sign the authentication token it issues, and by the consumer application (Auth0 in this case) to validate the authenticity of the generated token. + +For security purposes, Azure AD’s signing key [rolls on a periodic basis](https://azure.microsoft.com/en-us/documentation/articles/active-directory-signing-key-rollover/). If this happens, **you do not need to take any action**. Auth0 will use the new key automatically. + +<%= include('../../../_quickstart-links.md') %> diff --git a/articles/connections/enterprise/azure-active-directory/v2/index.md b/articles/connections/enterprise/azure-active-directory/v2/index.md new file mode 100644 index 0000000000..ce2f6ac9cd --- /dev/null +++ b/articles/connections/enterprise/azure-active-directory/v2/index.md @@ -0,0 +1,180 @@ +--- +title: Connect Your App to Microsoft Azure Active Directory +connection: Azure Active Directory +image: /media/connections/azure.png +public: true +alias: + - azure-ad + - waad + - windows-azure-ad + - windows-azure-active-directory + - microsoft-azure-ad + - microsoft-azure-active-directory +seo_alias: azure-active-directory +description: Learn how to connect your app to Microsoft Azure Active Directory using an enterprise connection. +crews: crew-2 +toc: true +topics: + - connections + - enterprise + - azure + - active-directory + - microsoft +contentType: + - how-to +useCase: + - customize-connections + - add-idp +--- +# Connect Your App to Microsoft Azure Active Directory + +You can integrate with Microsoft Azure Active Directory (AD) if you want to let users: + +* From within your company use your application from an Azure AD controlled by you or your organization. +* From other companies' Azure ADs use your application. (We recommend that you configure external directories as different connections.) + +::: note +Claims returned from the Azure AD enterprise connection are static; custom or optional claims will not appear in user profiles. If you need to include custom or optional claims in user profiles, use a SAML or OIDC connection instead. +::: + +## Prerequisites + +* [Register your app with Auth0](/getting-started/set-up-app) + * Select an appropriate **Application Type**. + * Add an **Allowed Callback URL** of **`${account.callback}`**. + * Make sure your Application's **[Grant Types](/dashboard/guides/applications/update-grant-types)** include the appropriate flows. +* Have an Azure account. If you don't, you can [sign up for free](https://azure.microsoft.com/en-us/free). +* Have an Azure AD directory. If you don't, you can create one by following Microsoft's [Quickstart: Create a new tenant in Azure Active Directory - Create a new tenant for your organization](https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-access-create-new-tenant#create-a-new-tenant-for-your-organization). + +## Steps + +To connect your application to Azure AD, you must: + +1. [Register your app with Azure AD](#register-your-app-with-azure-ad). +2. [Create an enterprise connection in Auth0](#create-an-enterprise-connection-in-auth0). +3. [Enable the enterprise connection for your Auth0 Application](#enable-the-enterprise-connection-for-your-auth0-application). +4. [Test the connection](#test-the-connection). + +### Register your app with Azure AD + +To register your app with Azure AD, see Microsoft's [Quickstart: Register an application with the Microsoft identity platform](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app). + +::: warning +If you have more than one Azure AD directory, make sure you are in the correct directory when you register the app you want to use with Auth0. +::: + +During registration, configure the following settings: + +| Option | Setting | +| -- | -- | +| **Supported account types** | To allow users from external organizations (like other Azure AD directories) choose the appropriate multitenant option. Multitenant options include the following: **Accounts in any organizational directory (Any Azure AD directory - Multitenant)**. | +| **Redirect URI** | Select a Redirect URI type of **Web**, and enter your callback URL: `https://${account.namespace}/login/callback`. | + +<%= include('../../../_find-auth0-domain-redirects.md') %> + +During this process, Microsoft generates an **Application (client) ID** for your application; you can find this on the app's **Overview** screen. **Make note of this value.** + +#### Create a client secret + +To create a client secret, see Microsoft's [Quickstart: Configure a client application to access web APIs - Add Credentials to your web application](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-register-app#add-credentials). + +Once generated, **make note of this value**. + +::: note +If you configure an expiring secret, make sure to **record the expiration date**; you will need to renew the key before that day to avoid a service interruption. +::: + +#### Add permissions + +To add permissions, see Microsoft's [Quickstart: Configure a client application to access web APIs - Add permissions to access web APIs](https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-configure-app-access-web-apis#add-permissions-to-access-web-apis). + +You will need to configure permissions for the **Microsoft Graph API**. + +While setting up your permissions, configure the following settings: + +| Field | Description | +| -- | -- | +| **Delegated permissions** | Required. | +| **Users > User.Read** | So your app can sign in users and read the signed-in users' profiles. | +| **Directory > Directory.Read.All** | So your app can read directory data on the signed-in user's behalf. | + +If you want to enable extended attributes (such as *Extended Profile* or *Security Groups*), then you also must configure the following settings: + +| Field | Description | +| -- | -- | +| **Delegated permissions** | Under **Directory**, select **Directory.AccessAsUser.All** so your app can access the directory as the signed-in user. | +| **Application Permissions** | Under **Directory**, select **Directory.Read.All** so your app can read directory data. | + +### Create an enterprise connection in Auth0 + +Create and configure an Azure AD Enterprise Connection in Auth0. Make sure you have the **Application (client) ID** and the **Client secret** generated when you set up your app in the Microsoft Azure portal. + +1. Navigate to [Auth0 Dashboard > Authentication > Enterprise](${manage_url}/#/connections/enterprise), locate **Microsoft Azure AD**, and select its `+`. + +![Create Connection Type](/media/articles/connections/dashboard-connections-enterprise-list.png) + +2. Enter details for your connection, and select **Create**: + +| Field | Description | +| ----- | ----------- | +| **Connection name** | Logical identifier for your connection; it must be unique for your tenant. Once set, this name can't be changed. | +| **Microsoft Azure AD Domain** | Your Azure AD domain name. You can find this on your Azure AD directory's overview page in the Microsoft Azure portal. | +| **Client ID** | Unique identifier for your registered Azure AD application. Enter the saved value of the **Application (client) ID** for the app you just registered in Azure AD. | +| **Client Secret** | String used to gain access to your registered Azure AD application. Enter the saved value of the **Client secret** for the app you just registered in Azure AD. | +| **Use common endpoint** | (Optional) When enabled, your application will dynamically accept users from new directories. Typically enabled if you selected a multitenant option for **Supported account types** for the application you just registered in Azure AD. When enabled, Auth0 will redirect users to Azure's common login endpoint, and Azure will perform *Home Realm Discovery* based on the domain of the user's email address. | +| **Identity API** | API used by Auth0 to interact with Azure AD endpoints. Learn about the differences in behavior in Microsoft's [Why update to Microsoft identity platform (v2.0)](https://docs.microsoft.com/en-us/azure/active-directory/develop/azure-ad-endpoint-comparison) doc. | +| **Attributes** | Basic attributes for the signed-in user that your app can access. Indicates how much information you want stored in the Auth0 User Profile. | +| **Extended Attributes** (optional) | Extended attributes for the signed-in user that your app can access. | +| **Auth0 APIs** (optional) | When selected, indicates that we require the ability to make calls to the Azure AD API, which allows us to search for users in the Azure AD Graph even if they never logged in to Auth0. | +| **Sync user profile attributes at each login** | When enabled, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. | +| **Email Verification** | Choose how Auth0 sets the `email_verified` field in the user profile. To learn more, see [Email Verification for Azure AD and ADFS](/connections/azuread-adfs-email-verification). | + +![Configure General Microsoft Azure AD Settings](/media/articles/connections/dashboard-connections-enterprise-create_azure-ad_default-empty.png) + +3. In the **Login Experience** view, you can configure how users log in with this connection. + +<%= include('../../_login-experience-tab.md') %> + +4. If you have appropriate Azure AD administrative permissions to *give consent* to the application so users can log in, then click **Continue**. + + You will be asked to [log in to your Azure AD account](https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#requesting-consent-for-an-entire-tenant) and give consent. Otherwise, provide the given URL to your administrator so that they can give consent. + +### Enable the enterprise connection for your Auth0 application + +To use your new Azure AD enterprise connection, you must first [enable the connection](/dashboard/guides/connections/enable-connections-enterprise) for your Auth0 Applications. + +### Test the connection + +Now you're ready to [test your connection](/dashboard/guides/connections/test-connections-enterprise). + +## Troubleshooting + +Here are some troubleshooting tips: + +**I registered my application with Azure AD, but when I go back to my Azure Active Directory App registrations, I can't see my application.** + +You may have accidentally registered your app in the wrong Azure AD directory (or not have created an Azure AD directory at all before registering your app). It's likely easiest to re-register your app in Azure AD. Make sure you are in the correct directory when you register the app. If you need to create an Azure AD directory, follow Microsoft's [Quickstart: Create a new tenant in Azure Active Directory - Create a new tenant for your organization](https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-access-create-new-tenant#create-a-new-tenant-for-your-organization). + +**I receive the following error message: "Access cannot be granted to this service because the service listing is not properly configured by the publisher".** + +To resolve this, try changing the **Supported account types** for your registered Azure AD app. Make sure you have chosen an appropriate multitenant option in the Azure AD app's Authentication settings. Multitenant options include the following: **Accounts in any organizational directory (Any Azure AD directory - Multitenant)**. + +**When users try to log in, we receive the following error message: "invalid_request; failed to obtain access token".** + +The most likely reason for this error is an invalid or expired Azure AD **Client secret**. To resolve this, generate a new **Client secret** for your app in Azure AD, then update the **Client Secret** in the enterprise connection configured with Auth0. + +## Signing Key Rollover in Azure AD + +Signing keys are used by the identity provider to sign the authentication token it issues, and by the consumer application (Auth0 in this case) to validate the authenticity of the generated token. + +For security purposes, Azure AD’s signing key [rolls on a periodic basis](https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-signing-key-rollover). If this happens, **you do not need to take any action**. Auth0 will use the new key automatically. + +<%= include('../../../_quickstart-links.md') %> + +## Remove unverified label + +If you're using a custom domain, the application consent prompt for Azure AD login may label your domain as "unverified". To remove the unverified label: + +1. Verify the domain for the Auth0 application: [Add your custom domain name using the Azure Active Directory portal](https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/add-custom-domain#add-your-custom-domain-name-to-azure-ad) +2. Assign the verified domain to the Auth0 application: [How to: Configure an application's publisher domain](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-configure-publisher-domain#configure-publisher-domain-using-the-azure-portal) + diff --git a/articles/connections/enterprise/azuread-adfs-email-verification.md b/articles/connections/enterprise/azuread-adfs-email-verification.md new file mode 100644 index 0000000000..19816db46a --- /dev/null +++ b/articles/connections/enterprise/azuread-adfs-email-verification.md @@ -0,0 +1,63 @@ +--- +title: Email Verification for Azure AD and ADFS +description: Learn how to control how the `email_verified` field is set for Azure AD and ADFS. +toc: true +topics: + - connections +contentType: how-to +--- +# Email Verification for Azure AD and ADFS connections + +Auth0 user's profile has an `email_verified` field, which can be set in different ways depending on the connection type. For database connections, users must go through an email validation flow to get the email verified. For federated connections, identity providers can return the `email_verified` field based on their own criteria. + +Azure AD and ADFS cannot guarantee that the emails they return have been verified: + +- In ADFS, the ADFS administrator can configure any email they want. + +- In Azure AD, depending on how the Azure AD tenant is configured, email addresses returned by Azure AD may or may not correspond to Office mailboxes. Auth0 can't know whether they do or not. + +However, if you know how an Azure AD or ADFS is configured and managed, you can decide to trust that the emails from those accounts are verified. + +To accommodate both needs, Azure AD and ADFS connections have an **Email Verification** property with two values: + +- Always set `email_verified` to `true` +- Always set `email_verified` to `false` + +The Azure AD connection also has a **Use Common Endpoint** property. When it's enabled, the user can authenticate with any Azure AD tenant. Given it's not possible to trust that any Azure AD tenant will return verified emails, the **Email Verification** property will need to be set to **Always set `email_verified` to `false`**. + +When the property is set to **Always set `email_verified` to `false`**, users will get `email_verified` set to `false` the next time they log in, unless the [Sync user profile attributes at each login](/dashboard/guides/connections/configure-connection-sync) is disabled. + +## Azure AD/ADFS Email Verification Migration Setting + +In previous versions, Auth0 always set the `email_verified` field to true in Azure AD and ADFS connections. If you were using Azure AD and ADFS connections in the past, you will have a tenant setting that will override the Connection Setting for **Email Verification** and keep the previous behavior. + +You can find the new tenant setting in the [Auth0 Dashboard > Settings > Advanced](${manage_url}/#/tenant/advanced). Locate the **Migrations** section, then find **Default to 'Email Verification' setting for Azure AD/ADFS connections**. + +::: note +This setting is only available if: + +* the tenant is older than the date the migration was introduced +* the tenant has one or more active ADFS or Azure AD connection +::: + +![Dashboard - Advanced Tenant Settings - Migrations](/media/connections/dashboard-tenant-edit_view-advanced_migrations_azure-adfs.png) + +When this setting is disabled, `email_verified` will always be `true` for Azure AD/ADFS connections. When enabled, it will use the 'Email Verification' setting at the connection level. + +## Email Verification Flow for Azure AD/ADFS connections + +If your application requires that the emails from an Azure AD/ADFS connection's users are always verified, you can enable the **Enable email verification flow during login for Azure AD and ADFS connections** option in the tenant's **Advanced Settings** section. + +After the user authenticates for the first time with a non-verified email, Auth0 will ask the user to verify their email by entering a one-time-use code that will be sent to their email account: + +![Auth0 - Email Verification Prompt - One-Time Code](/media/articles/connections/azuread-adfs-email-verification.png) + +If the user completes this step, the `email_verified` field will be set to `true`, and users will not be prompted again for email verification, unless Azure AD or ADFS return a different email for the user. + +This new screen is rendered using the New Universal Login Experience, even if you have Universal Login configured to use the Classic Experience. To learn how to customize it, read the [Universal Login Customization documentation](/universal-login/customization-new). + +To learn how to customize the email that is sent to users, check the [Verification Email template documentation](/users/verify-emails/) + +:::warning +When Azure AD does not return an `email` claim, Auth0 maps the [Azure UserPrincipalName](https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-userprincipalname) as the email. There is no guarantee that the UserPrincipalName value is a mailbox, so Auth0 will **NOT** display the email verification prompt and the user will have the field `email_verified` set to `false`. +::: diff --git a/articles/connections/enterprise/google-apps.md b/articles/connections/enterprise/google-apps.md index 4cd8ac0253..19bfde226b 100644 --- a/articles/connections/enterprise/google-apps.md +++ b/articles/connections/enterprise/google-apps.md @@ -1,8 +1,120 @@ --- -title: Connecting Google Apps with Auth0 -connection: Google Apps -image: /media/connections/googleapps.png -public: false -seo_alias: google-apps -description: Connecting Google Apps with Auth0. +title: Connect Your App to Google Workspace +connection: Google Workspace +image: /media/connections/gsuite.png +public: true +seo_alias: g-suite +description: Learn how to connect your app to Google Workspace using an enterprise connection. +crews: crew-2 +toc: true +topics: + - connections + - enterprise + - google + - workspace +contentType: how-to +useCase: + - customize-connections + - add-idp --- +# Connect Your App to Google Workspace + +::: panel Using Google Social and Enterprise Connections +If you have an existing [Google Social Connection](/connections/social/google) for your application and you create a new Google Workspace connection for the same domain, users affiliated with the social connection with now be logged in with the new enterprise connection. This will occur regardless of whether you enable the Google Workspace enterprise connection. +::: + +## Prerequisites + + * [Register your Application with Auth0](/getting-started/set-up-app). + * Select an appropriate **Application Type**. + * Add an **Allowed Callback URL** of **`${account.callback}`**. + * Make sure your Application's **[Grant Types](/dashboard/guides/applications/update-grant-types)** include the appropriate flows. + +## Steps + +To connect your application to Google Workspace, you must: + +1. [Set up your app in Google](#set-up-your-app-in-google) +2. [Create an enterprise connection in Auth0](#create-an-enterprise-connection-in-auth0). +3. [Enable the enterprise connection for your Auth0 Application](#enable-the-enterprise-connection-for-your-auth0-application). +4. [Test the connection](#test-the-connection). + +::: panel Google Workspace Account +Before proceeding, you will need a valid Google Workspace account and must have **your own** Google Workspace Organization for which you are an administrator. +::: + +## Set up your app in Google + +To allow users to log in using Google Workspace, you must register your application in the Google developer console. + +::: warning +Before proceeding, you must have already set up **your own** Google Workspace Organization for which you are an administrator. +::: + +### Register a new application + +To learn how to register a new application with Google, follow Google's [Setting up OAuth 2.0](https://support.google.com/googleapi/answer/6158849) doc. During this process, Google will generate a **Client ID** and **Client Secret** for your application; make note of these. + +While setting up your app, be sure to use these settings: + +* On the **OAuth consent screen**, under **Authorized domains**, add `auth0.com`. +* When asked to select an application type, choose **Web application** and set the following parameters: + +| Field | Description | +| ----- | ----------- | +| Name | The name of your application. | +| Authorized JavaScript origins | `https://${account.namespace}` | +| Authorized redirect URIs | `https://${account.namespace}/login/callback` | + +<%= include('../_find-auth0-domain-redirects') %> + +::: warning +If your application requests sensitive OAuth scopes, it may be [subject to review by Google](https://developers.google.com/apps-script/guides/client-verification). +::: + +### Enable the Admin SDK Service + +If you plan to connect to Google Workspace enterprise domains, you need to enable the **Admin SDK Service**. To learn how, follow Google's [Enable and disable APIs](https://support.google.com/googleapi/answer/6158841) doc. + +## Create an enterprise connection in Auth0 + +Next, you will need to create and configure a Google Workspace Enterprise Connection in Auth0. Make sure you have the **Client ID** and **Client Secret** generated when you set up your app in the Google developer console. + +1. Navigate to [Auth0 Dashboard > Authentication > Enterprise](${manage_url}/#/connections/enterprise), locate **Google Workspace**, and click its `+`. + +![Create Connection Type](/media/articles/connections/dashboard-connections-enterprise-list.png) + +2. Enter details for your connection, and select **Create**: + +| Field | Description | +| ----- | ----------- | +| **Connection name** | Logical identifier for your connection; it must be unique for your tenant. Once set, this name can't be changed. | +| **Google Workspace Domain** | Google Workspace domain name for your organization. | +| **Client ID** | Unique identifier for your registered Google application. Enter the saved value of the **Client ID** for the app you just registered in the Google developer console. | +| **Client Secret** | String used to gain access to your registered Google application. Enter the saved value of the **Client Secret** for the app you just registered in the Google developer console. | +| **Attributes** | Basic attributes for the signed-in user that your app can access. Indicates how much information you want stored in the Auth0 User Profile. Options include: **Basic Profile** (`email`, `email verified` flag) and **Extended Profile** (name, public profile URL, photo, gender, birthdate, country, language, and timezone). | +| **Extended Attributes** | Extended attributes for the signed-in user that your app can access. Options include: **Groups** (distribution list(s) to which the user belongs), **Is Domain Administrator** (indicates whether the user is a domain administrator), **Is Account Suspended** (indicates whether the user's account is suspended), and **Agreed to Terms** (indicates whether the user has agreed to the terms of service). | +| **Auth0 APIs** | When **Enable Users API** is selected, indicates that you require the ability to make calls to the Google Directory API. | +| **Sync user profile attributes at each login** | When enabled, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. | + +![Create Connection Type](/media/articles/connections/dashboard-connections-enterprise-create_google-workspace_default-empty.png) + +3. If you have appropriate administrative permissions to configure your Google Workspace settings so you can use Google's Admin APIs, then click **Continue**. Otherwise, provide the given URL to your administrator so that they can adjust the required settings. + +4. On the **Login Experience** tab you can configure how users log in with this connection. + +<%= include('./_login-experience-tab.md') %> + +## Enable the enterprise connection for your Auth0 application + +To use your new AD connection, you must first [enable the connection](/dashboard/guides/connections/enable-connections-enterprise) for your Auth0 Applications. + +## Test the connection + +Now you're ready to [test your connection](/dashboard/guides/connections/test-connections-enterprise). + +## Requesting Refresh Tokens from Google + +Google always returns an Access Token, which is stored in the user profile. If you add `access_type=offline&approval_prompt=force` to the authorization request, Auth0 will forward these parameters to Google. Google will then return a Refresh Token, which will also be stored in the user profile. + +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/enterprise/index.md b/articles/connections/enterprise/index.md new file mode 100644 index 0000000000..b3bb2c147a --- /dev/null +++ b/articles/connections/enterprise/index.md @@ -0,0 +1,18 @@ +--- +title: Enterprise Identity Providers +description: Learn about enterprise identity providers supported by Auth0. +topics: + - connections + - identity-providers +contentType: + - reference +useCase: + - customize-connections + - add-idp +--- +# Enterprise Identity Providers + +Auth0 supports the following enterprise providers out of the box. You can also explore partner-supported enterprise connections through the [Auth0 Marketplace](https://marketplace.auth0.com/features/enterprise-connections). + +<% var enterpriseConnections = cache.find('articles/connections/enterprise', {sort: 'index'}); %> +<%= include('../_connections', { connections: enterpriseConnections }) %> \ No newline at end of file diff --git a/articles/connections/enterprise/ip-address.md b/articles/connections/enterprise/ip-address.md index ed0756b00a..34374e2760 100644 --- a/articles/connections/enterprise/ip-address.md +++ b/articles/connections/enterprise/ip-address.md @@ -1,18 +1,68 @@ --- -title: Using IP Address Authentication with Auth0 +title: Connect Your App using IP Address Authentication [DEPRECATED] connection: IP Address Authentication -image: /media/connections/open-id.png +image: /media/connections/ipaddress.png public: false alias: - ip-based-auth - ip - address-authentication -seo_alias: ip-address -description: How to use IP Address Authentication with Auth0. +description: Learn how to connect your app using IP Address Authentication with an enterprise connection. This feature has been deprecated. +topics: + - connections + - enterprise + - ip-addresses +useCase: + - customize-connections + - add-idp --- +# Connect Your App using IP Address Authentication [DEPRECATED] -In this type of connection Auth0 will simply check that the request is coming from an IP address that is within the range specified in the configuration. An optional `username` can be assigned to a given range. +::: warning + IP Address Authentication has been deprecated and will not be enabled for new customers. Existing customers who currently have IP Address Authentication enabled may continue to use this feature. If IP Address Authentication 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. +::: -![](/media/articles/connections/enterprise/ip-address/ip.png) +When users connect to your app using IP Address Authentication, Auth0 checks whether the request is coming from within a specified range of IP addresses. -Notice that ranges are specified in the [CIDR-notation](http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing). Multiple ranges can be added by separating them with a comma. +## Prerequisites + +**Before beginning:** + +* [Register your Application with Auth0](/getting-started/set-up-app). + * Select an appropriate **Application Type**. + * Add an **Allowed Callback URL** of **`${account.callback}`**. + * Make sure your Application's **[Grant Types](/dashboard/guides/applications/update-grant-types)** include the appropriate flows. + +## Steps + +To connect your application using IP Address Authentication, you must: + +1. [Create an enterprise connection in Auth0](#create-an-enterprise-connection-in-auth0). +2. [Enable the enterprise connection for your Auth0 Application](#enable-the-enterprise-connection-for-your-auth0-application). +3. [Test the connection](#test-the-connection). + +## Create an enterprise connection in Auth0 + +1. Navigate to [Auth0 Dashboard > Authentication > Enterprise](${manage_url}/#/connections/enterprise), locate **IP Address Authentication**, and click its `+`. + +![Create Connection Type](/media/articles/connections/dashboard-connections-enterprise-list.png) + +2. Enter details for your connection, and click **Create**: + +| Field | Description | +| ----- | ----------- | +| **Connection name** | Logical identifier for your connection; it must be unique for your tenant. Once set, this name can't be changed. | +| **Display name** (optional) | Text used to customize the login button for Universal Login. When set, the Universal Login login button reads: "Continue with {Display name}". | +| **Logo URL** (optional) | URL of image used to customize the login button for Universal Login. When set, the Universal Login login button displays the image as a 20px by 20px square. | +| **IP Range** | Comma-separated list of IP Addresses and/or CIDR blocks, as specified in the [CIDR-notation](http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing). (For example, `192.168.100.14/24`). | +| **Display username** | Generic username assigned to anyone connecting from this range of IP addresses. | + +![Configure IP Address Authentication Settings](/media/articles/dashboard/connections/enterprise/conn-enterprise-ip-addr-auth-settings.png) + +## Enable the enterprise connection for your Auth0 application + +To use your new IP Address Authentication connection, you must first [enable the connection](/dashboard/guides/connections/enable-connections-enterprise) for your Auth0 Applications. + +## Test the connection + +Now you're ready to [test your connection](/dashboard/guides/connections/test-connections-enterprise). diff --git a/articles/connections/enterprise/ldap.md b/articles/connections/enterprise/ldap.md deleted file mode 100644 index eaed02ef7b..0000000000 --- a/articles/connections/enterprise/ldap.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: Using LDAP Authentication with Auth0 -connection: LDAP -image: /media/connections/ldap.png -public: false -seo_alias: ldap -description: Using LDAP Authentication with Auth0. ---- diff --git a/articles/connections/enterprise/o365-deprecated.md b/articles/connections/enterprise/o365-deprecated.md index bb667c0f04..a4db6cf5e7 100644 --- a/articles/connections/enterprise/o365-deprecated.md +++ b/articles/connections/enterprise/o365-deprecated.md @@ -1,24 +1,33 @@ --- -title: Connecting Office 365 with Auth0 (Deprecated) +title: Connect your app to Microsoft Office 365 (Deprecated) connection: Office 365 (Deprecated) image: /media/connections/office-365.png +public: false alias: - office365 seo_alias: o365-deprecated description: How to obtain a ClientId and Client Secret for an Office 365 connection. +toc: true +topics: + - connections + - enterprise + - microsoft + - o365 +useCase: + - customize-connections + - add-idp --- +# Connect your app to Microsoft Office 365 -::: warning-banner -__Warning:__ The Office 365 connection is deprecated, you should use Windows Azure AD instead.
      +::: warning +The Office 365 connection is deprecated, you should use Windows Azure AD instead. See [here](/office365-deprecated) for more details. ::: -# Obtain a *ClientId* and *Client Secret* for an Office 365 connection - To configure Microsoft Office 365 connections, you need to a register an application in the Seller Dashboard. -## 1. Log into the Seller Dashboard -Log into the [Seller Dashboard](https://sellerdashboard.microsoft.com), then select **client ids**. +## 1. Log in to the Seller Dashboard +Log in to the [Seller Dashboard](https://sellerdashboard.microsoft.com), then select **client ids**. ![](/media/articles/connections/enterprise/o365-deprecated/o365-portal-1.png) @@ -44,6 +53,6 @@ This is your only opportunity in Office 365 to copy the `ClientSecret`, it is no ![](/media/articles/connections/enterprise/o365-deprecated/o365-portal-4.png) -In your Auth0 dashboard, select **Connections > Enterprise**, then select **Office 365**. +Navigate to [Auth0 Dashboard > Marketplace](${manage_url}/#/marketplace/office-365-sso), then select **SSO Integrations**, and locate **Office 365**, then[Configure the Office 365 connection](/integrations/sso/office-365). -Copy the `ClientId` and `ClientSecret` from the Seller Dashboard into your Office 365 connection settings on this page. +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/enterprise/oidc.md b/articles/connections/enterprise/oidc.md new file mode 100644 index 0000000000..eba713572c --- /dev/null +++ b/articles/connections/enterprise/oidc.md @@ -0,0 +1,207 @@ +--- +connection: OpenID Connect +image: /media/connections/oidc.png +public: true +seo_alias: oidc +description: Learn how to connect to OpenID Connect (OIDC) Identity Providers using an enterprise connection. +crews: crew-2 +toc: true +topics: + - connections + - enterprise + - oidc +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +# Connect to OpenID Connect Identity Provider + +::: warning +If you are using the Lock login widget with an OpenID Connect (OIDC) connection, you must use Lock version 11.16 or higher. +::: + +## Prerequisites + +* [Register your Application with Auth0](/getting-started/set-up-app). + * Select an appropriate **Application Type**. + * Add an **Allowed Callback URL** of **`${account.callback}`**. + * Make sure your Application's **[Grant Types](/dashboard/guides/applications/update-grant-types)** include the appropriate flows. + +## Steps + +To connect your application to an OIDC Identity Provider, you must: + +1. [Set up your app in the OpenID Connect Identity Provider](#set-up-your-app-in-the-openid-connect-identity-provider). +2. [Create an enterprise connection in Auth0](#create-an-enterprise-connection-in-auth0). +3. [Enable the enterprise connection for your Auth0 Application](#enable-the-enterprise-connection-for-your-auth0-application). +4. [Test the connection](#test-the-connection). + +## Set up your app in the OpenID Connect Identity Provider + +To allow users to log in using an OIDC Identity Provider, you must register your application with the IdP. The process of doing this varies depending on the OIDC Identity Provider, so you will need to follow your IdP's documentation to complete this task. + +Generally, you will want to make sure that at some point you enter your callback URL: `https://${account.namespace}/login/callback`. + +<%= include('../_find-auth0-domain-redirects.md') %> + +During this process, your OIDC Identity Provider will generate a unique identifier for the registered API, usually called a **Client ID** or an **Application ID**. Make note of this value; you will need it later. + +## Create an enterprise connection in Auth0 + +Next, you will need to create and configure a OIDC Enterprise Connection in Auth0. Make sure you have the **Application (client) ID** and the **Client secret** generated when you set up your app in the OIDC provider. + +### Create an enterprise connection using the Dashboard + +::: warning +To be configurable through the Auth0 Dashboard, the OpenID Connect (OIDC) Identity Provider (IdP) needs to support [OIDC Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html). Otherwise, you can configure the connection using the [Management API](#configure-the-connection-using-the-management-api). +::: + +1. Navigate to [Auth0 Dashboard > Authentication > Enterprise](${manage_url}/#/connections/enterprise), locate **Open ID Connect**, and click its `+`. + +![Create Connection Type](/media/articles/connections/dashboard-connections-enterprise-list.png) + +2. Enter details for your connection, and select **Create**: + +| Field | Description | +| ----- | ----------- | +| **Connection name** | Logical identifier for your connection; it must be unique for your tenant. Once set, this name can't be changed. | +| **Issuer URL** | URL where Auth0 can find the **OpenID Provider Configuration Document**, which should be available in the `/.well-known/openid-configuration` endpoint. You can enter the base URL or the full URL. You will see a green checkmark if it can be found at that location, a red mark if it cannot be found, or an error message if the file is found but the required information is not present in the configuration file. | +| **Client ID** | Unique identifier for your registered application. Enter the saved value of the **Client ID** for the app you registered with the OIDC Identity Provider. | +| **Callback URL** | URL to which Auth0 redirects users after they authenticate. Ensure that this value is configured for the app you registered with the OIDC Identity Provider. +| **Sync user profile attributes at each login** | When enabled, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. | + +<%= include('../_find-auth0-domain-redirects.md') %> + +![Enter OIDC Connection Details](/media/articles/connections/dashboard-connections-enterprise-create_oidc_default-empty.png) + +3. In the **Settings** view, make additional configuration adjustments, if necessary. + +| Field | Description| +| -- | -- | +| **Issuer URL** | Click **Show Issuer Details** to view the Issuer URL **Advanced Settings** and make adjustments. | +| **Type** | Set to **Front Channel** or **Back Channel**. Front Channel uses the OIDC protocol with `response_mode=form_post` and `response_type=id_token`. Back Channel uses `response_type=code`. | +| **Scopes** | A comma-separated list of Auth0 scopes to request when connecting to the Identify Provider. This will affect the data stored in the user profile. You are required to include at least the `openid` scope. Note that the connection does not call `/userinfo` endpoint and expects the user claims to be present in the `id_token`. | + +4. In the **Login Experience** view, configure how users log in with this connection. + +<%= include('./_login-experience-tab.md') %> + +5. Select **Save Changes**. + +### Create an enterprise connection using the Management API + +These examples will show you the variety of ways you can create the [connection](/connections) using Auth0's Management API. You ca configure the connection by either providing a metadata URI or by setting the OIDC URLs explicitly. + +**Use Front Channel with discovery endpoint** + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/api/v2/connections", + "httpVersion": "HTTP/1.1", + "cookies": [], + "headers": [{ + "name": "Authorization", + "value": "Bearer MGMT_API_ACCESS_TOKEN" + }], + "queryString": [], + "postData": { + "mimeType": "application/json", + "text": "{ \"strategy\": \"oidc\", \"name\": \"CONNECTION_NAME\", \"options\": { \"type\": \"front_channel\", \"discovery_url\": \"https://IDP_DOMAIN/.well-known/openid-configuration\", \"client_id\" : \"IDP_CLIENT_ID\", \"scopes\": \"openid profile\" } }" + }, + "headersSize": -1, + "bodySize": -1, + "comment": "" +} +``` + +**Use Back Channel with discovery endpoint** + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/api/v2/connections", + "httpVersion": "HTTP/1.1", + "cookies": [], + "headers": [{ + "name": "Authorization", + "value": "Bearer MGMT_API_ACCESS_TOKEN" + }], + "queryString": [], + "postData": { + "mimeType": "application/json", + "text": "{ \"strategy\": \"oidc\", \"name\": \"CONNECTION_NAME\", \"options\": { \"type\": \"back_channel\", \"discovery_url\": \"https://IDP_DOMAIN/.well-known/openid-configuration\", \"client_id\" : \"IDP_CLIENT_ID\", \"client_secret\" : \"IDP_CLIENT_SECRET\", \"scopes\": \"openid profile\" } }" + + }, + "headersSize": -1, + "bodySize": -1, + "comment": "" +} +``` + +**Use Back Channel specifying issuer settings** + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/api/v2/connections", + "httpVersion": "HTTP/1.1", + "cookies": [], + "headers": [{ + "name": "Authorization", + "value": "Bearer MGMT_API_ACCESS_TOKEN" + }], + "queryString": [], + "postData": { + "mimeType": "application/json", + "text": "{ \"strategy\": \"oidc\", \"name\": \"CONNECTION_NAME\", \"options\": { \"type\": \"back_channel\", \"issuer\": \"https://IDP_DOMAIN\", \"authorization_endpoint\": \"https://IDP_DOMAIN/authorize\", \"jwks_uri\": \"https://IDP_DOMAIN/.well-known/jwks.json\", \"client_id\" : \"IDP_CLIENT_ID\", \"scopes\": \"openid profile\" } }" + }, + "headersSize": -1, + "bodySize": -1, + "comment": "" +} +``` + +**Use Front Channel specifying issuer settings** + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/api/v2/connections", + "httpVersion": "HTTP/1.1", + "cookies": [], + "headers": [{ + "name": "Authorization", + "value": "Bearer MGMT_API_ACCESS_TOKEN" + }], + "queryString": [], + "postData": { + "mimeType": "application/json", + "text": "{ \"strategy\": \"oidc\", \"name\": \"CONNECTION_NAME\", \"options\": { \"type\": \"front_channel\", \"issuer\": \"https://IDP_DOMAIN\", \"authorization_endpoint\": \"https://IDP_DOMAIN/authorize\", \"token_endpoint\": \"https://IDP_DOMAIN/oauth/token\", \"jwks_uri\": \"https://IDP_DOMAIN/.well-known/jwks.json\", \"client_id\" : \"IDP_CLIENT_ID\", \"client_secret\" : \"IDP_CLIENT_SECRET\", \"scopes\": \"openid profile\" } }" + }, + "headersSize": -1, + "bodySize": -1, + "comment": "" +} +``` + +## Enable the enterprise connection for your Auth0 application + +To use your new enterprise connection, you must first [enable the connection](/dashboard/guides/connections/enable-connections-enterprise) for your Auth0 Applications. + +## Test the connection + +Now you're ready to [test your connection](/dashboard/guides/connections/test-connections-enterprise). + +## Manually configure Issuer metadata + +If you click `Show Issuer Details` on the Issuer URL endpoint, you can see the data and adjust it if you need to. + +## Federate with Auth0 + +The OpenID Connect enterprise connection is extremely useful when federating to another Auth0 tenant. Just enter your Auth0 tenant URL (for example, `https://.us.auth0.com`) in the **Issuer** field, and enter the Client ID for any application in the tenant to which you want to federate in the **Client ID** field. + +::: note +New tenants will have `us` as part of the URL. Tenants created before the regional domain addition will continue to work. For example, `https://{YOUR ACCOUNT}.auth0.com`. +::: diff --git a/articles/connections/enterprise/okta.md b/articles/connections/enterprise/okta.md new file mode 100644 index 0000000000..24f4fc0078 --- /dev/null +++ b/articles/connections/enterprise/okta.md @@ -0,0 +1,116 @@ +--- +connection: Okta +image: /media/connections/okta.png +public: true +seo_alias: okta +description: Learn how to connect to Okta as an OpenID Connect (OIDC) Identity Provider using an enterprise connection. +crews: crew-2 +toc: true +topics: + - okta + - connections + - enterprise + - oidc +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +# Connect to Okta as an OpenID Connect Identity Provider + +::: warning +If you are using the Lock login widget with an OpenID Connect (OIDC) connection, you must use Lock version 11.16 or higher. +::: + +## Prerequisites + +* [Register your Application with Auth0](/getting-started/set-up-app). + * Select an appropriate **Application Type**. + * Add an **Allowed Callback URL** of **`${account.callback}`**. + * Make sure your Application's **[Grant Types](/dashboard/guides/applications/update-grant-types)** include the appropriate flows. + +## Steps + +To connect your application to an OIDC Identity Provider, you must: + +1. [Register your app with Okta](#register-your-app-with-okta). +2. [Create an enterprise connection in Auth0](#create-an-enterprise-connection-in-auth0). +3. [Enable the enterprise connection for your Auth0 Application](#enable-the-enterprise-connection-for-your-auth0-application). +4. [Test the connection](#test-the-connection). + +## Register your app with Okta + +To allow users to log in using Okta, you'll need to register your application. See [Register your app (Okta Documentation)](https://developer.okta.com/docs/guides/quickstart/website/register-app/) for full instructions. + +During registration you'll be prompted for **Sign-in redirect URIs**. Add your callback URL as a sign-in redirect URI: + +```text +https://${account.namespace}/login/callback +``` + +<%= include('../_find-auth0-domain-redirects.md') %> + +Once you finish registering your application with Okta, save the **Client ID** and **Client secret** to use in the next step. + +## Create an enterprise connection in Auth0 + +Next, you will need to create and configure a OIDC Enterprise Connection in Auth0. Make sure you have the **Application (client) ID** and the **Client secret** generated when you set up your app in the OIDC provider. + +### Create an enterprise connection using the Dashboard + +1. Navigate to [Auth0 Dashboard > Authentication > Enterprise](${manage_url}/#/connections/enterprise), locate **Open ID Connect**, and click its `+`. + +![Create Connection Type](/media/articles/connections/dashboard-connections-enterprise-list.png) + +2. Enter details for your connection, and select **Create**: + +| Field | Description | +| ----- | ----------- | +| **Connection name** | Logical identifier for your connection; it must be unique for your tenant. Once set, this name can't be changed. | +| **Issuer URL** | URL where Auth0 can find the **OpenID Provider Configuration Document**. For Okta this should be either of the following: + +* `https:///.well-known/openid-configuration` +* `https:///oauth2//.well-known/` + +You can enter the base URL or the full URL. You will see a green checkmark if it can be found at that location, a red mark if it cannot be found, or an error message if the file is found but the required information is not present in the configuration file. | +| **Client ID** | Unique identifier for your registered Okta application. Enter the saved value of the **Client ID** for the app you registered with the OIDC Identity Provider. | +| **Callback URL** | URL to which Auth0 redirects users after they authenticate. Ensure that this value is configured for the app you registered with the OIDC Identity Provider. +| **Sync user profile attributes at each login** | When enabled, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. | + +<%= include('../_find-auth0-domain-redirects.md') %> + +![Enter OIDC Connection Details](/media/articles/connections/dashboard-connections-enterprise-create_oidc_default-empty.png) + +3. In the **Settings** view, make additional configuration adjustments, if necessary. + +| Field | Description| +| -- | -- | +| **Issuer URL** | Click **Show Issuer Details** to view the Issuer URL **Advanced Settings** and make adjustments. | +| **Type** | Set to **Front Channel** or **Back Channel**. Front Channel uses the OIDC protocol with `response_mode=form_post` and `response_type=id_token`. Back Channel uses `response_type=code`. | +| **Scopes** | A comma-separated list of Auth0 scopes to request when connecting to the Identify Provider. This will affect the data stored in the user profile. You are required to include at least the `openid` scope. Note that the connection does not call `/userinfo` endpoint and expects the user claims to be present in the `id_token`. | + +4. In the **Login Experience** view, configure how users log in with this connection. + +<%= include('./_login-experience-tab.md') %> + +5. Select **Save Changes**. + +::: note +For instructions on creating an enterprise connection using the Management API, see [Connect to OpenID Connect Identity Provider](/connections/enterprise/oidc#create-an-enterprise-connection-using-the-management-api) +::: + +## Enable the enterprise connection for your Auth0 application + +To use your new enterprise connection, you must first [enable the connection](/dashboard/guides/connections/enable-connections-enterprise) for your Auth0 Applications. + +## Test the connection + +Now you're ready to [test your connection](/dashboard/guides/connections/test-connections-enterprise). + +## Federate with Auth0 + +The OpenID Connect enterprise connection is extremely useful when federating to another Auth0 tenant. Just enter your Auth0 tenant URL (for example, `https://.us.auth0.com`) in the **Issuer** field, and enter the Client ID for any application in the tenant to which you want to federate in the **Client ID** field. + +::: note +New tenants will have `us` as part of the URL. Tenants created before the regional domain addition will continue to work. For example, `https://{YOUR ACCOUNT}.auth0.com`. +::: diff --git a/articles/connections/enterprise/ping-federate.md b/articles/connections/enterprise/ping-federate.md index ddda4606fe..6d5703f670 100644 --- a/articles/connections/enterprise/ping-federate.md +++ b/articles/connections/enterprise/ping-federate.md @@ -1,10 +1,90 @@ --- -title: Connecting PingFederate with Auth0 +title: Connect Your PingFederate Server to Auth0 connection: PingFederate image: /media/connections/pingfederate.png -public: false +public: true alias: - pingfederate seo_alias: ping-federate -description: Connecting PingFederate with Auth0. +description: Learn how to create an enterprise connection between a PingFederate Server and Auth0. +topics: + - connections + - enterprise + - pingfederate +contentType: how-to +useCase: + - customize-connections + - add-idp --- + +# Connect Your PingFederate Server to Auth0 + +Auth0 lets you create [PingFederate Server](https://documentation.pingidentity.com/pingfederate/pf84/#gettingStartedGuide/concept/gettingStarted.html) connections. + +## Prerequisites + +**Before beginning:** + +* [Register your Application with Auth0](/getting-started/set-up-app). + * Select an appropriate **Application Type**. + * Add an **Allowed Callback URL** of **`${account.callback}`**. + * Make sure your Application's **[Grant Types](/dashboard/guides/applications/update-grant-types)** include the appropriate flows. + +## Steps + +As long as your server is configured in the standard way, to connect your PingFederate server to Auth0 you must: + +1. [Get the signing certificate from the IdP](#get-the-signing-certificate-from-the-idp) and [convert it to Base64](#convert-signing-certificate-to-base64). +2. [Create an enterprise connection in Auth0](#create-an-enterprise-connection-in-auth0). +3. [Enable the enterprise connection for your Auth0 Application](#enable-the-enterprise-connection-for-your-auth0-application). +4. [Test the connection](#test-the-connection). + +::: warning +If additional setup is required for your server (such as attribute mapping), then you must [create a new SAML enterprise connection](/connections/enterprise/saml) instead. +::: + +## Get the signing certificate from the IdP + +With PingFederate Server, Auth0 acts as the service provider, so you will need to retrieve an X.509 signing certificate from the IdP (in PEM or CER format); later, you will upload this to Auth0. The methods for retrieving this certificate vary, so please see the [PingFederate documentation](https://documentation.pingidentity.com/pingfederate/pf84/index.shtml#concept_digitalSignatureSettings.html) for instructions on managing your server's certificates. + +### Convert signing certificate to Base64 + +Before you upload the X.509 signing certificate to Auth0, you must convert the file to Base64. To do this, either use a [simple online tool](https://www.base64decode.org/) or run the following command in Bash: `cat signing-cert.crt | base64`. + +## Create an enterprise connection in Auth0 + +Next, if your server is configured in the standard way, you will need to create and configure a PingFederate Enterprise Connection in Auth0 and upload your X.509 signing certificate. This task can be performed using Auth0's Dashboard. + +::: warning +If additional setup is required for your server (such as attribute mapping), then you must [create a new SAML enterprise connection](/connections/enterprise/saml) instead. +::: + +1. Navigate to [Auth0 Dashboard > Authentication > Enterprise](${manage_url}/#/connections/enterprise), locate **Ping Federate**, and select its `+`. + +![Create Connection Type](/media/articles/dashboard/connections/enterprise/conn-enterprise-list.png) + +2. Enter details for your connection, and select **Create**: + +| Field | Description | +| ----- | ----------- | +| **Connection name** | Logical identifier for your connection; it must be unique for your tenant. Once set, this name can't be changed. | +| **PingFederate Server URL** | URL for your PingFederate Server. | +| **X.509 Signing Certificate** | PingFederate Server public key (encoded in PEM or CER) you retrieved from the IdP earlier in this process. | +| **Sign Request** | When enabled, the SAML authentication request will be signed. (Be sure to download and provide the PingFederate server with your [tenant's certificate](https://${account.namespace}/pem).) | +| **Sign Request Algorithm** | Algorithm Auth0 will use to sign the SAML assertions. Ensure this matches your PingFederate Server's configuration. | +| **Sign Request Digest Algorithm** | Algorithm Auth0 will use for the sign request digest. Ensure this matches your PingFederate Server's configuration. | +| **Sync user profile attributes at each login** | When enabled, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. | + +![Configure Ping Federate Settings](/media/articles/connections/dashboard-connections-enterprise-create_ping-federate_default-empty.png) + +3. In the **Login Experience** view, configure how users log in with this connection. + +<%= include('./_login-experience-tab.md') %> + +## Enable the enterprise connection for your Auth0 application + +To use your new PingFederate enterprise connection, you must first [enable the connection](/dashboard/guides/connections/enable-connections-enterprise) for your Auth0 Applications. + +## Test the connection + +Now you're ready to [test your connection](/dashboard/guides/connections/test-connections-enterprise). diff --git a/articles/connections/enterprise/saml.md b/articles/connections/enterprise/saml.md new file mode 100644 index 0000000000..f639dc52cc --- /dev/null +++ b/articles/connections/enterprise/saml.md @@ -0,0 +1,281 @@ +--- +title: Connect Your App to SAML Identity Providers +connection: SAML +image: /media/connections/saml.png +public: true +alias: + - saml +seo_alias: saml +description: Learn how to connect to SAML Identity Providers using an enterprise connection. +topics: + - connections + - enterprise + - saml + - saml-p +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +# Connect Your App to SAML Identity Providers + +Auth0 lets you create SAML Identity Provider (IdP) connections. + +## Prerequisites + +**Before beginning:** + +* [Register your Application with Auth0](/getting-started/set-up-app). + * Select an appropriate **Application Type**. + * Add an **Allowed Callback URL** of **`${account.callback}`**. + * Make sure your Application's **[Grant Types](/dashboard/guides/applications/update-grant-types)** include the appropriate flows. +* Decide on the name of this enterprise connection + * The Post-back URL (also called Assertion Consumer Service URL) becomes: `https://YOUR_DOMAIN/login/callback?connection=YOUR_CONNECTION_NAME` + * The Entity ID becomes: `urn:auth0:YOUR_TENANT:YOUR_CONNECTION_NAME` + +## Steps + +To connect your application to a SAML Identity Provider, you must: + +1. Enter the Post-back URL and Entity ID at the IdP (read the separate article here: https://auth0.com/docs/protocols/saml-configuration-options/saml-identity-provider-configuration-settings) +2. [Get the signing certificate from the IdP](#get-the-signing-certificate-from-the-idp) and [convert it to Base64](#convert-signing-certificate-to-base64). +3. [Create an enterprise connection in Auth0](#create-an-enterprise-connection-in-auth0). +4. [Enable the enterprise connection for your Auth0 Application](#enable-the-enterprise-connection-for-your-auth0-application). +5. [Set up mappings](#set-up-mappings) (unnecessary for most cases). +6. [Test the connection](#test-the-connection). + +## Get the signing certificate from the IdP + +With SAML Login, Auth0 acts as the service provider, so you will need to retrieve an X.509 signing certificate from the SAML IdP (in PEM or CER format); later, you will upload this to Auth0. The methods for retrieving this certificate vary, so please see your IdP's documentation if you need additional assistance. + +### Convert signing certificate to Base64 + +Before you upload the X.509 signing certificate to Auth0, you must convert the file to Base64. To do this, either use a [simple online tool](https://www.base64decode.org/) or run the following command in Bash: `cat signing-cert.crt | base64`. + +## Create an enterprise connection in Auth0 + +Next, you will need to create and configure a SAML Enterprise Connection in Auth0 and upload your X.509 signing certificate. This task can be performed using either Auth0's Dashboard or Management API. + +### Create an enterprise connection using the Dashboard + +1. Navigate to [Auth0 Dashboard > Authentication > Enterprise](${manage_url}/#/connections/enterprise), locate **SAML**, and select its `+`. + +![Create Connection Type](/media/articles/connections/dashboard-connections-enterprise-list.png) + +2. Enter details for your connection, and select **Create**: + +| Field | Description | +| ----- | ----------- | +| **Connection name** | Logical identifier for your connection; it must be unique for your tenant and the same name used when setting the Post-back URL and Entity ID at the IdP. Once set, this name can't be changed. | +| **Sign In URL** | SAML single login URL. | +| **X.509 Signing Certificate** | Signing certificate (encoded in PEM or CER) you retrieved from the IdP earlier in this process. | +| **Sign Out URL** (optional) | SAML single logout URL. | +| **User ID Attribute** (optional) | Attribute in the SAML token that will be mapped to the `user_id` property in Auth0. | +| **Debug Mode** | When enabled, more verbose logging will be performed during the authentication process. | +| **Sign Request** | When enabled, the SAML authentication request will be signed. (Be sure to download and provide the accompanying certificate so the SAML IdP can validate the assertions' signature.) | +| **Sign Request Algorithm** | Algorithm Auth0 will use to sign the SAML assertions. | +| **Sign Request Digest Algorithm** | Algorithm Auth0 will use for the sign request digest. | +| **Protocol Binding** | HTTP binding supported by the IdP. | +| **Request Template** (optional) | Template that formats the SAML request. | +| **Sync user profile attributes at each login** | When enabled, Auth0 automatically syncs user profile data with each user login, thereby ensuring that changes made in the connection source are automatically updated in Auth0. | + +![Configure SAML Settings](/media/articles/connections/dashboard-connections-enterprise-create_saml_default-empty.png) + +3. In the **Login Experience** view, configure how users log in with this connection. + +<%= include('./_login-experience-tab.md') %> + +4. If you have appropriate administrative permissions to complete the integration, click **Continue** to learn about the custom parameters needed to configure your IdP. Otherwise, provide the given URL to your administrator so that they can adjust the required settings. + +### Create an enterprise connection using the Management API + +You can also use the [Management API](/api/management/v2#!) to create your SAML Connection. When doing so, you may choose to specify each SAML configuration field manually or else specify a SAML metadata document that contains the configuration values. + +#### Create a connection using specified values + +1. Make a `POST` call to the [Create a Connection endpoint](/api/management/v2#!/Connections/patch_connections_by_id). Be sure to replace `MGMT_API_ACCESS_TOKEN`, `CONNECTION_NAME`, `SIGN_IN_ENDPOINT_URL`, `SIGN_OUT_ENDPOINT_URL`, and `BASE64_SIGNING_CERT` placeholder values with your Management API Access Token, connection name, sign in URL, sign out URL, and Base64-encoded signing certificate (in PEM or CER format), 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": "{ \"strategy\": \"samlp\", \"name\": \"CONNECTION_NAME\", \"options\": { \"signInEndpoint\": \"SIGN_IN_ENDPOINT_URL\", \"signOutEndpoint\": \"SIGN_OUT_ENDPOINT_URL\", \"signatureAlgorithm\": \"rsa-sha256\", \"digestAlgorithm\": \"sha256\", \"fieldsMap\": {}, \"signingCert\": \"BASE64_SIGNING_CERT\" } }" + } +} +``` + +| Value | Description | +| - | - | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `create:connections`. | +| `CONNECTION_NAME` | Τhe name of the connection to be created. | +| `SIGN_IN_ENDPONT_URL` | SAML single login URL for the connection to be created. | +| `SIGN_OUT_ENDPOINT_URL` | SAML single logout URL for the connection to be created. | +| `BASE64_SIGNING_CERT` | X.509 signing certificate (encoded in PEM or CER) you retrieved from the IdP.| + +Or, in JSON: + +```json +{ + "strategy": "samlp", + "name": "CONNECTION_NAME", + "options": { + "signInEndpoint": "SIGN_IN_ENDPOINT_URL", + "signOutEndpoint": "SIGN_OUT_ENDPOINT_URL", + "signatureAlgorithm": "rsa-sha256", + "digestAlgorithm": "sha256", + "fieldsMap": { + ... + }, + "signingCert": "BASE64_SIGNING_CERT" + } +} +``` + +#### Create a connection using SAML metadata + +Rather than specifying each SAML configuration field, you can specify a SAML metadata document that contains the configuration values. When specifying a SAML metadata document, you may provide either the XML content of the document (`metadataXml`) or the URL of the document (`metadataUrl`). When providing the URL, content is downloaded only once; the connection will not automatically reconfigure if the content of the URL changes in the future. + +##### Provide metadata document content + +Use the `metadataXml` option to provide content of the document: + +```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": "{ \"strategy\": \"samlp\", \"name\": \"CONNECTION_NAME\", \"options\": { \"metadataXml\": \"...\" } }" + }, + "headersSize": -1, + "bodySize": -1, + "comment": "" +} +``` + +##### Provide a metadata document URL + +Use the `metadataUrl` option to provide the URL of the document: + +```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": "{ \"strategy\": \"samlp\", \"name\": \"CONNECTION_NAME\", \"options\": { \"metadataUrl\": \"https://saml-idp/samlp/metadata/uarlU13n63e0feZNJxOCNZ1To3a9H7jX\" } }" + } +} +``` + +When providing the URL, content is downloaded only once; the connection will not automatically reconfigure if the content of the URL changes in the future. + +##### Refresh existing connection information with metadata URL + +::: note +This process will only work if the connection was created with `metadataUrl` manually. +::: + +If you have a B2B implementation and federate to Auth0 with your own SAML identity provider, you may need to refresh connection information stored in Auth0, such as signing certificate changes, endpoint URL changes, or new assertion fields. Auth0 does this automatically for ADFS connections, but not for SAML connections. + +You can create a batch process (cron job) to do a periodic refresh. The process can run every few weeks and perform a PATCH call to `/api/v2/connections/CONNECTION_ID` endpoint, passing a body containing `{options: {metadataUrl: '$URL'}}` where `$URL` is the same metadata URL with which you created the connection. You use the metadata URL to create a new temporary connection, then compare the properties of the old and new connections. If anything is different, update the new connection and then delete the temporary connection. + +1. Create SAML connection with `options.metadataUrl`. The connection object will be populated with information from the metadata. + +2. Update metadata content in the URL. + +3. Send a PATCH to the `/api/v2/connections/CONNECTION_ID` endpoint with `{options: {metadataUrl: '$URL'}}`. Now the connection object is updated with the new metadata content. + +## Specify a custom Entity ID + +To specify a custom Entity ID, use the Management API to override the default `urn:auth0:YOUR_TENANT:YOUR_CONNECTION_NAME.` Set the `connection.options.entityID` property when the connection is first created or by updating an existing connection. + +The JSON example below can be used to create a new SAML connection using the SAML IdP’s metadata URL while also specifying a custom Entity ID. The Entity ID is still unique since it is created using the name of the connection. + +```json +{ + "strategy": "samlp", + "name": "CONNECTION_NAME", + "options": { + "metadataUrl": "https://saml-idp/samlp/metadata/uarlU13n63e0feZNJxOCNZ1To3a9H7jX", + "entityId": "urn:your-custom-sp-name:YOUR_CONNECTION_NAME" + } +} +``` + +## Enable the enterprise connection for your Auth0 application + +To use your new SAML enterprise connection, you must first [enable the connection](/dashboard/guides/connections/enable-connections-enterprise) for your Auth0 Applications. + +## Set up mappings + +::: warning +If you're configuring a SAML enterprise connection for a non-standard PingFederate Server, you **must** update the attribute mappings. +::: + +Select the **Mappings** view, enter mappings between the `{}`, and select **Save**. + +![Configure SAML Mappings](/media/articles/dashboard/connections/enterprise/dashboard-connections-enterprise-edit_view-mappings_saml.png) + +**Mappings for non-standard PingFederate Servers:** + +```json +{ + "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", + "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" +} +``` + +**Mappings for SSO Circle** + +```json +{ + "email": "EmailAddress", + "given_name": "FirstName", + "family_name": "LastName" +} +``` + +**Map either of two claims to one user attribute** + +```json +{ + "given_name": [ + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname", + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" + ] +} +```` + +**How to map name identifier to a user attribute** + +```json +{ + "user_id": [ + "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" + ] +} +``` + +## Test the connection + +Now you're ready to [test your connection](/dashboard/guides/connections/test-connections-enterprise). diff --git a/articles/connections/enterprise/samlp.md b/articles/connections/enterprise/samlp.md deleted file mode 100644 index c3ce3027fb..0000000000 --- a/articles/connections/enterprise/samlp.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: Connecting SAML Providers with Auth0 -connection: SAML-P -image: /media/connections/saml.png -public: false -alias: - - saml -seo_alias: samlp -description: Connecting SAML Providers with Auth0 ---- diff --git a/articles/connections/enterprise/sharepoint-apps.md b/articles/connections/enterprise/sharepoint-apps.md index 53e39bd064..439966e375 100644 --- a/articles/connections/enterprise/sharepoint-apps.md +++ b/articles/connections/enterprise/sharepoint-apps.md @@ -1,14 +1,23 @@ --- -title: Connecting SharePoint Apps with Auth0 +title: Connect Your App to SharePoint Apps connection: SharePoint Apps image: /media/connections/sharepoint.png +public: false alias: - sharepoint-online - sharepoint seo_alias: sharepoint-apps -description: About connecting SharePoint Apps with Auth0. +description: Learn how to connect your app to SharePoint Apps with Auth0. +topics: + - connections + - enterprise + - sharepoint +contentType: how-to +useCase: + - customize-connections + - add-idp --- -# Obtaining a App Id and App Secret for SharePoint +# Connect your app to SharePoint Apps Sharepoint Online Apps integration is in __experimental mode__. Please [contact us](${env.DOMAIN_URL_SUPPORT}) if you are interested in this integration. diff --git a/articles/connections/enterprise/ws-fed.md b/articles/connections/enterprise/ws-fed.md index 2cf5603b45..efbad677e5 100644 --- a/articles/connections/enterprise/ws-fed.md +++ b/articles/connections/enterprise/ws-fed.md @@ -5,4 +5,37 @@ image: /media/connections/wsfed.png public: false seo_alias: ws-fed description: Connecting WS-Federation Providers with Auth0 +topics: + - connections + - enterprise + - ws-fed +contentType: how-to +useCase: + - customize-connections + - add-idp --- + +# Connecting WS-Federation Providers with Auth0 + +To create a connection for a WS-Federation Identity Provider (such as Azure ACS/AD or IdentityServer) use the [ADFS connection](/connections/enterprise/adfs) type when creating your new connection. + +To configure this connection, navigate to [Auth0 Dashboard > Authentication > Enterprise](${manage_url}/#/connections/enterprise), and select __ADFS__. + +![Enterprise Connections](/media/articles/connections/enterprise/ws-fed/connections-enterprise.png) + +Click __Create New Connection__ and enter 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. + +Next, either provide the URL for your WS-Federation server in the __ADFS URL__ field or upload a Federation Metadata file. + +If you configure the connection with 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) + +Click __Save__. + +Next you will see a list of your registered [applications](${manage_url}/#/applications) with the option to enable the new connection for any of them. + +That's it! You are now ready to test and start using your connection. diff --git a/articles/connections/generic-oauth2-connection-examples.md b/articles/connections/generic-oauth2-connection-examples.md new file mode 100644 index 0000000000..33aa05f5d9 --- /dev/null +++ b/articles/connections/generic-oauth2-connection-examples.md @@ -0,0 +1,296 @@ +--- +description: This document covers generic OAuth 1.0/2.0 examples. +toc: true +topics: + - connections + - oauth2 +contentType: concept +useCase: + - customize-connections + - add-idp +--- + +# Generic OAuth 1.0 and 2.0 Examples + +Adding [OAuth 1.0](/oauth1) and [OAuth 2.0](/oauth2) providers as Connections allow you to support providers that are not currently built-in to the [Auth0 Dashboard](${manage_url}), like [DigitalOcean](#digitalocean), [Tumblr](#tumblr), and more. + +This document covers examples of OAuth 1.0/2.0 Connections that you can create by making the appropriate `POST` call to the [Auth0 APIv2's Connections endpoint](/api/v2#!/Connections/post_connections). Please note that doing so requires an [APIv2 token](/api/v2/tokens) with `create:connections` scope. + +## DigitalOcean + +1. Navigate to [Digital Ocean](https://cloud.digitalocean.com/login). +2. If you have not already registered a Digital Ocean application, you will need to do so prior to continuing. +3. Once available, copy the `Client ID` and `Client Secret` for use with your cURL `POST`. + +```har +{ + "method": "POST", + "url": "https://YOURACCOUNT.auth0.com/api/v2/connections", + "httpVersion": "HTTP/1.1", + "cookies": [], + "headers": [{ + "name": "Authorization", + "value": "Bearer ABCD" + }], + "queryString": [], + "postData": { + "mimeType": "application/json", + "text": "{ \"name\": \"digitalocean\", \"strategy\": \"oauth2\", \"options\": { \"client_id\", \"YOUR-DIGITAL-OCEAN-CLIENT-ID\", \"client_secret\": \"YOUR-DIGITAL-OCEAN-CLIENT-SECRET\", \"authorizationURL\": \"https://cloud.digitalocean.com/v1/oauth/authorize\", \"tokenURL\": \"https://cloud.digitalocean.com/v1/oauth/token\", \"scope\": [\"read\"], \"scripts\": { \"fetchUserProfile\": \"function(accessToken, ctx, cb) { request.get('https://api.digitalocean.com/v2/account', { headers: { 'Authorization': 'Bearer ' + accessToken } }, function(e, r, b) { if (e) return cb(e); if (r.statusCode !== 200 ) return cb(new Error('StatusCode: ' + r.statusCode)); var profile = JSON.parse(b).account; profile.user_id = profile.uuid; cb(null, profile); });}" + }, + "headersSize": -1, + "bodySize": -1, + "comment": "" +} +``` + +## Dribbble + +1. Navigate to [Dribble](https://dribbble.com/account/applications/new). +2. If you have not already registered a new Dribble consumer, you will need to do so prior to continuing. If you have, set the `Redirect URI` of your application to `https://${account.namespace}/login/callback`. +3. Copy the `Client ID` and `Client Secret` for use with your cURL `POST`. + +```har +{ + "method": "POST", + "url": "https://YOURACCOUNT.auth0.com/api/v2/connections", + "httpVersion": "HTTP/1.1", + "cookies": [], + "headers": [{ + "name": "Authorization", + "value": "Bearer ABCD" + }], + "queryString": [], + "postData": { + "mimeType": "application/json", + "text": "{ \"name\": \"dribbble\", \"strategy\": \"oauth2\", \"options\": { \"client_id\", \"YOUR_DRIBBLE_CLIENT_ID\", \"client_secret\": \"YOUR_DRIBBLE_CLIENT_SECRET\", \"authorizationURL\": \"https://dribbble.com/oauth/authorize\", \"tokenURL\": \"https://dribbble.com/oauth/token\", \"scope\": [\"public\"], \"scripts\": { \"fetchUserProfile\": \"function(accessToken, ctx, cb) { request.get('https://api.dribbble.com/v1/user', { headers: { 'Authorization': 'Bearer ' + accessToken } }, function(e, r, b) { if (e) return cb(e); if (r.statusCode !== 200 ) return cb(new Error('StatusCode: ' + r.statusCode)); var profile = JSON.parse(b); profile.user_id = profile.id; profile.picture = profile.avatar_url; cb(null, profile); });}" + }, + "headersSize": -1, + "bodySize": -1, + "comment": "" +} +``` + +## Imgur + +1. Navigate to [Imgur](https://api.imgur.com/oauth2/addclient). +2. If you have not already registered an Imgur application, you will need to do so prior to continuing. +3. Once available, copy the `Client ID` and `Client Secret` for use with your cURL `POST`. + +```har +{ + "method": "POST", + "url": "https://YOURACCOUNT.auth0.com/api/v2/connections", + "httpVersion": "HTTP/1.1", + "cookies": [], + "headers": [{ + "name": "Authorization", + "value": "Bearer ABCD" + }], + "queryString": [], + "postData": { + "mimeType": "application/json", + "text": "{ \"name\": \"imgur\", \"strategy\": \"oauth2\", \"options\": { \"client_id\", \"YOUR-IMGUR-CLIENT-ID\", \"client_secret\": \"YOUR-IMGUR-CLIENT-SECRET\", \"authorizationURL\": \"https://api.imgur.com/oauth2/authorize\", \"tokenURL\": \"https://api.imgur.com/oauth2/token\", \"scripts\": { \"fetchUserProfile\": \"function(accessToken, ctx, cb) { request.get('https://api.imgur.com/3/account/me', { headers: { 'Authorization': 'Bearer ' + accessToken } }, function(e, r, b) { if (e) return cb(e); if (r.statusCode !== 200 ) return cb(new Error('StatusCode: ' + r.statusCode)); var profile = JSON.parse(b).data; profile.user_id = profile.id; cb(null, profile); });}" + }, + "headersSize": -1, + "bodySize": -1, + "comment": "" +} +``` + +## JIRA + +### Step 1: Generate an RSA Keypair + +Generate an RSA keypair with the following command (or any equivalent method): + +```bash +openssl genrsa -out EXAMPLE.key 2048 && openssl rsa -pubout -in EXAMPLE.key -out EXAMPLE.pub +``` + +### Step 2: Create a JIRA Application Link + + +From JIRA, go to **Administration** > **Application** > **Application Links**, and [create an Application Link](https://confluence.atlassian.com/display/APPLINKS-050/Application+Links+Documentation) with the following settings: + +* **Application URL**: Any arbitrary URL (you can ignore the `No response was received from the URL` warnings); +* **Application Name**: Any arbitrary name; +* **Application Type**: Generic Application; +* **Create incoming link**: *checked*. + +Leave all other options left blank. + +To create the incoming link, use the following settings: + + * **Consumer Key**: Any arbitrary URL-friendly name (for example, `auth0-jira`) + * **Consumer Name**: Any arbitrary name + * **Public Key**: The RSA keypair previously generated in step 1 (copy and paste the entire `.pub` file) + * **Consumer Callback URL**: `https://${account.namespace}/login/callback` + +:::panel Updating Settings +If you need to modify these settings after you've created the application link, you can do so via the **Incoming Authentication** section of the link's settings. +::: + +In the JSON below, replace all instances of the following placeholders: + * `JIRA_URL`: The root URL of your JIRA instance (for example, `https://foo.atlassian.net`) + * `CONSUMER_KEY`: The chosen Consumer Key for your application link + * `CONSUMER_SECRET`: The previously generated private key (as a JSON string). You can convert `EXAMPLE.key` to a valid JSON string using the following command: + +```bash +node -p -e 'JSON.stringify(require("fs").readFileSync("EXAMPLE.key").toString("ascii"));' +``` + +```har +{ + "method": "POST", + "url": "https://YOURACCOUNT.auth0.com/api/v2/connections", + "httpVersion": "HTTP/1.1", + "cookies": [], + "headers": [{ + "name": "Authorization", + "value": "Bearer ABCD" + }], + "queryString": [], + "postData": { + "mimeType": "application/json", + "text": "{ \"name\": \"jira\", \"strategy\": \"oauth1\", \"options\": { \"consumerKey\", \"CONSUMER_KEY\", \"consumerSecret\": \"CONSUMER_SECRET\", \"requestTokenURL\": \"JIRA_URL/plugins/servlet/oauth/request-token\", \"accessTokenURL\": \"JIRA_URL/plugins/servlet/oauth/access-token\", \"userAuthorizationURL\": \"JIRA_URL/plugins/servlet/oauth/authorize\", \"signatureMethod\": \"RSA-SHA1\", \"scripts\": { \"fetchUserProfile\": \"function(token, tokenSecret, ctx, cb) {\n // Based on passport-atlassian-oauth\n // https://github.com/tjsail33/passport-atlassian-oauth/blob/a2e444b0c3969dfd7caf4524ce4a4c379656ba2e/lib/passport-atlassian-oauth/strategy.js\n var jiraUrl = 'JIRA_URL';\n var OAuth = new require('oauth').OAuth;\n var oauth = new OAuth(ctx.requestTokenURL, ctx.accessTokenURL, ctx.client_id, ctx.client_secret, '1.0', null, 'RSA-SHA1');\n function oauthRequest(url, cb) {\n return oauth._performSecureRequest(token, tokenSecret, 'GET', url, null, '', 'application/json', cb);\n }\n oauthRequest(jiraUrl + '/rest/auth/1/session', function(err, body, res) {\n if (err) return cb(err);\n if (res.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode));\n var json;\n try {\n json = JSON.parse(body);\n } catch(ex) {\n return cb(new Error('Invalid JSON returned from JIRA', ex));\n }\n var profileUrl = jiraUrl + '/rest/api/2/user?expand=groups&username=' + encodeURIComponent(json.name);\n oauthRequest(profileUrl, function(err, body, res) {\n if (err) return cb(err);\n if (res.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode));\n try {\n json = JSON.parse(body);\n } catch(ex) {\n return cb(new Error('Invalid JSON returned from JIRA', ex));\n }\n // Auth0-specific mappings, customize as n:qeeded\n // https:///users/normalized\n return cb(null, {\n user_id: json.name,\n username: json.name,\n email: json.emailAddress,\n name: json.displayName,\n groups: json.groups,\n picture: json.avatarUrls['48x48'],\n active: json.active,\n self: json.self,\n timezone: json.timeZone,\n locale: json.locale\n });\n });\n });\n}\n" + }, + "headersSize": -1, + "bodySize": -1, + "comment": "" +} +``` + +## Tumblr + +1. Navigate to [Tumblr](https://www.tumblr.com/oauth/apps). +2. If you have not already registered a new Tumblr application, you will need to do so prior to continuing. +3. Copy the `OAuth Consumer Key` and `Secret Key` for use with your cURL `POST`. + +```har +{ + "method": "POST", + "url": "https://YOURACCOUNT.auth0.com/api/v2/connections", + "httpVersion": "HTTP/1.1", + "cookies": [], + "headers": [{ + "name": "Authorization", + "value": "Bearer ABCD" + }], + "queryString": [], + "postData": { + "mimeType": "application/json", + "text": "{ \"name\": \"tumblr\", \"strategy\": \"oauth1\", \"options\": { \"client_id\", \"YOUR-TUMBLR-CONSUMER-KEY\", \"client_secret\": \"YOUR-TUMBLR-SECRET-KEY\", \"requestTokenURL\": \"https://www.tumblr.com/oauth/request_token\", \"accessTokenURL\": \"https://www.tumblr.com/oauth/access_token\", \"userAuthorizationURL\": \"https://www.tumblr.com/oauth/authorize\", \"scripts\": { \"fetchUserProfile\": \"function (token, tokenSecret, ctx, cb) {var OAuth = new require('oauth').OAuth;var oauth = new OAuth(ctx.requestTokenURL,ctx.accessTokenURL,ctx.client_id,ctx.client_secret,'1.0',null,'HMAC-SHA1');oauth.get('https://api.tumblr.com/v2/user/info',token,tokenSecret,function(e, b, r) {if (e) return cb(e);if (r.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode));var user = JSON.parse(b).response.user; user.user_id = user.name; cb(null, user);});}" + }, + "headersSize": -1, + "bodySize": -1, + "comment": "" +} +``` + +## Twitch + +1. Navigate to [Twitch](http://www.twitch.tv/kraken/oauth2/clients/new). +2. If you have not already registered a Twitch application, you will need to do so prior to continuing. +3. Once available, copy the `Client ID` and `Client Secret` for use with your cURL `POST`. + +```har +{ + "method": "POST", + "url": "https://YOURACCOUNT.auth0.com/api/v2/connections", + "httpVersion": "HTTP/1.1", + "cookies": [], + "headers": [{ + "name": "Authorization", + "value": "Bearer ABCD" + }], + "queryString": [], + "postData": { + "mimeType": "application/json", + "text": "{ \"name\": \"twitch\", \"strategy\": \"oauth2\", \"options\": { \"client_id\", \"YOUR-TWITCH-CLIENT-ID\", \"client_secret\": \"YOUR-TWITCH-CLIENT-SECRET\", \"authorizationURL\": \"https://api.twitch.tv/kraken/oauth2/authorize\", \"tokenURL\": \"https://api.twitch.tv/kraken/oauth2/token\", \"scope\": [\"user_read\"], \"scripts\": { \"fetchUserProfile\": \"function(accessToken, ctx, cb){ request.get('https://api.twitch.tv/kraken/user', { headers: { 'Authorization': 'OAuth ' + accessToken, 'Accept': 'application/vnd.twitchtv.v3+json' } }, function(e, r, b) { if (e) return cb(e); if (r.statusCode !== 200 ) return cb(new Error('StatusCode: ' + r.statusCode)); var profile = JSON.parse(b); profile.id = profile._id; delete profile._id; profile.links=profile._links; delete profile._links; return cb(null, profile);});}" + }, + "headersSize": -1, + "bodySize": -1, + "comment": "" +} +``` + +## Uber + +1. Navigate to [Uber Developers](https://developer.uber.com/). +2. If you have not already [registered an Uber application](https://developer.uber.com/dashboard/create), you will need to do so prior to continuing. If you have, set the `Redirect URI` of your application to 'https://${account.namespace}/login/callback'. +3. Copy the `Client ID` and `Client Secret` for use with your cURL `POST`. + +```har +{ + "method": "POST", + "url": "https://YOURACCOUNT.auth0.com/api/v2/connections", + "httpVersion": "HTTP/1.1", + "cookies": [], + "headers": [{ + "name": "Authorization", + "value": "Bearer ABCD" + }], + "queryString": [], + "postData": { + "mimeType": "application/json", + "text": "{ \"name\": \"uber\", \"strategy\": \"oauth2\", \"options\": { \"client_id\", \"YOUR_UBER_APP_KEY\", \"client_secret\": \"YOUR_UBER_APP_SECRET\", \"authorizationURL\": \"https://login.uber.com/oauth/authorize\", \"tokenURL\": \"https://login.uber.com/oauth/token\", \"scope\": [\"profile\"], \"scripts\": { \"fetchUserProfile\": \"function(accessToken, ctx, cb) { request.get('https://api.uber.com/v1/me', { headers: { 'Authorization': 'Bearer ' + accessToken } }, function(e, r, b) { if (e) return cb(e); if (r.statusCode !== 200 ) return cb(new Error('StatusCode: ' + r.statusCode)); var profile = JSON.parse(b); profile.user_id = profile.uuid; cb(null, profile); });}\" } }, \"enabled_clients\": [\"\"] }" + }, + "headersSize": -1, + "bodySize": -1, + "comment": "" +} +``` + +## Vimeo + +1. Navigate to [Vimeo](https://dribbble.com/account/applications/new). +2. If you have not already registered a new Vimeo application, you will need to do so prior to continuing. +3. Copy the `Client ID` and `Client Secret` for use with your cURL `POST`. + +```har +{ + "method": "POST", + "url": "https://YOURACCOUNT.auth0.com/api/v2/connections", + "httpVersion": "HTTP/1.1", + "cookies": [], + "headers": [{ + "name": "Authorization", + "value": "Bearer ABCD" + }], + "queryString": [], + "postData": { + "mimeType": "application/json", + "text": "{ \"name\": \"vimeo\", \"strategy\": \"oauth2\", \"options\": { \"client_id\", \"YOUR_VIMEO_CLIENT_ID\", \"client_secret\": \"YOUR_VIMEO_CLIENT_SECRET\", \"authorizationURL\": \"https://api.vimeo.com/oauth/authorize\", \"tokenURL\": \"https://api.vimeo.com/oauth/access_token\", \"scope\": [\"public\"], \"scripts\": { \"fetchUserProfile\": \"function(accessToken, ctx, cb) { request.get('https://api.vimeo.com/me', { headers: { 'Authorization': 'Bearer ' + accessToken } }, function(e, r, b) { if (e) return cb(e); if (r.statusCode !== 200 ) return cb(new Error('StatusCode: ' + r.statusCode)); var profile = JSON.parse(b); profile.user_id = profile.uri; cb(null, profile); });}" + }, + "headersSize": -1, + "bodySize": -1, + "comment": "" +} +``` + +## Xing + +1. Navigate to [Xing](https://developer.xing.com/). +2. If you have not already registered a Xing application, you will need to do so prior to continuing. +3. Once available, copy the `Client ID` and `Client Secret` for use with your cURL `POST`. + +```har +{ + "method": "POST", + "url": "https://YOURACCOUNT.auth0.com/api/v2/connections", + "httpVersion": "HTTP/1.1", + "cookies": [], + "headers": [{ + "name": "Authorization", + "value": "Bearer ABCD" + }], + "queryString": [], + "postData": { + "mimeType": "application/json", + "text": "{ \"name\": \"xing\", \"strategy\": \"oauth1\", \"options\": { \"client_id\", \"YOUR-XING-CLIENT-ID\", \"client_secret\": \"YOUR-XING-CLIENT-SECRET\", \"requestTokenURL\": \"https://api.xing.com/v1/request_token\", \"accessTokenURL\": \"https://api.xing.com/v1/access_token\", \"userAuthorizationURL\": \"https://api.xing.com/v1/authorize\", \"scripts\": { \"fetchUserProfile\": \"function (token, tokenSecret, ctx, cb) {var OAuth = new require('oauth').OAuth;var oauth = new OAuth(ctx.requestTokenURL,ctx.accessTokenURL,ctx.client_id,ctx.client_secret,'1.0',null,'HMAC-SHA1');oauth.get('https://api.xing.com/v1/users/me.json',token,tokenSecret,function(e, b, r) {if (e) return cb(e);if (r.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode)); var p = JSON.parse(b); var profile = p.users[0]; cb(null, profile); });}" + }, + "headersSize": -1, + "bodySize": -1, + "comment": "" +} +``` diff --git a/articles/connections/grean/bankid-no.md b/articles/connections/grean/bankid-no.md deleted file mode 100644 index 643411ed8e..0000000000 --- a/articles/connections/grean/bankid-no.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: Connect Norwegian BankID with Auth0 through Grean easyID -connection: Norwegian BankID -image: /media/articles/connections/grean/bankid-no.png -seo_alias: bankid -description: Connecting Norwegian BankID with Auth0 through Grean's easyID service ---- - -# Log in with Norwegian BankID through Auth0 - -When you need to know the legal identity of your Norwegian users, your choice is BankID jointly offered by the Norwegian banks. The BankID technology by itself is rather complicated to integrate, but through [Grean's easyID service](https://grean.com/easyid) -you may avoid the integration trouble. - -Below is an outline of the steps to get ready to accept Norwegian BankID logins, but you may also view [a short screen cast](https://grean.com/easyid/auth0/2016/12/07/easyid-and-auth0.html) at Grean's website. - -**NOTE:** While the technical integration complexity is simple, to use Norwegian BankID in production you will have to go through a formal process to register and obtain the necessary certificate to identify yourself to your users. More on this process can be found once you sign into the easyID service, and with the help of Grean. - -## 1. Create an account with Grean easyID - -Go to [grean.com/easyid](https://grean.com/easyid) and click the sign-up button. - -Once registered you will be asked to create your tenant. - -![Create new tenant](/media/articles/connections/grean/easyid-signup.png) - -## 2. Create an Application to point to Auth0 - -In easyID go to the **Applications** tab and create a new application, a client, by clicking the **with Auth0** button. -Give it a meaningful name, select the domain and remember to select the **NO BankID**. - -![Create application with Auth0](/media/articles/connections/grean/auth0-app-no.png) - -Click **Save** to open the next dialog. - -## 3. Name the connection (prefix) as it will appear in Auth0 - -If you do not run off the public Auth0 service, enter the DNS name of the login tenant. Otherwise just leave the **Auth0 tenant** field as is. - -Secondly enter a name to be used as the prefix for the connections created in Auth0. - -![Auth0 connections details](/media/articles/connections/grean/auth0-details.png) - -Click **Proceed**. - -## 4. Create new connections in Auth0 - -If you are not already logged in to Auth0 in this session, you will be prompted to do so in the popup window. - -Once logged in you must grant Grean easyID consent to create connections and read the clients. - -**Note:** If you have more than one Auth0 tenant, remember to select the right one in the dialog. - -![Auth0 connections details](/media/articles/connections/grean/auth0-consent.png) - -Click the check mark in the green area at the bottom to allow Grean easyID to set up the connections. - -## 5. Verify the connections - -Go to the **Connections > Enterprise** section and open the **ADFS** connections to see the connections for Norwegian BankID created from the previous steps. - -**Note:** One connection has been created for each kind of authentication supported by Norwegian BankID: -Browser based and mobile. The mobile method requires a special SIM card issued by a Norwegian provider. - -![ADFS connections created](/media/articles/connections/grean/adfs-connections-no.png) - -Remember to enable at least one client before clicking the **Try** button! For more on test users see documentation on easyID. - -## 6. Create your test users - -With the above setup you will be ready to start testing. You will find a test user's credentials in your easyID tenant to start testing the web based flow. To get your own test users and to get the special SIM cards need to test the mobile flow, work with Grean to sign up for production use of Norwegian BankID. - -## 7. Enable production use - -To start accepting real BankID logins from real legal persons, you must first enter into a formal agreement with a Norwegian Bank, possibly through Grean, or directly with you bank. - -Once this agreement is in place you will receive a certificate to upload to Grean easyID. Go to the **IDENTITY SERVICES** tab and open the **NO BankID** section. This is where you will upload your organization's BankID certificate. - -![Identity Service production](/media/articles/connections/grean/no-bankid-prod.png) - - - - - - diff --git a/articles/connections/grean/bankid-se.md b/articles/connections/grean/bankid-se.md deleted file mode 100644 index fddb79f9c0..0000000000 --- a/articles/connections/grean/bankid-se.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: Connect Swedish BankID with Auth0 through Grean easyID -connection: Swedish BankID -image: /media/articles/connections/grean/bankid-se.png -seo_alias: bankid -description: Connecting Swedish BankID with Auth0 through Grean's easyID service ---- - -# Log in with Swedish BankID through Auth0 - -When you need to know the legal identity of your Swedish users, your choice is BankID jointly offered by the Swedish banks. -The BankID technology by itself is proprietary and takes a bit of work to understand and integrate, but through [Grean's easyID service](https://grean.com/easyid) -you may avoid the integration trouble. - -Below is an outline of the steps to get ready to accept Swedish BankID logins, but you may also view -[a short screen cast](https://grean.com/easyid/auth0/2016/12/07/easyid-and-auth0.html) at Grean's website. - -**NOTE:** While the technical integration complexity is simple, to use Swedish BankID in production you will have to go through a formal process to -register and obtain the necessary certificate to identify yourself to your users. -More on this proceess can be found once you sign into the easyID service, and with the help of Grean. - -## 1. Create an account with Grean easyID - -Go to [grean.com/easyid](https://grean.com/easyid) and click the sign-up button. - -Once registered you will be asked to create your tenant. - -![Create new tenant](/media/articles/connections/grean/easyid-signup.png) - -## 2. Create an Application to point to Auth0 - -In easyID go to the **APPLICATIONS** tab and create a new application, a client, by clikcing the **with Auth0** button. -Give it a meaningful name, select the domain and remember to select the **SE BankID**. - -![Create application with Auth0](/media/articles/connections/grean/auth0-app-se.png) - -Click **Save** to open the next dialog - -## 3. Name the connection (prefix) as it will appear in Auth0 - -If you do not run off the public Auth0 service, enter the DNS name of the login tenant. Otherwise just leave the **Auth0 tenant** field as is. - -Secondly enter a name to be used as the prefix for the connections created in Auth0. - -![Auth0 connections details](/media/articles/connections/grean/auth0-details.png) - -Click **Proceed**. - -## 4. Create new connections in Auth0 - -If you are not already logged in to Auth0 in this session, you will be prompted to do so in the popup window. - -Once logged in you must grant Grean easyID consent to create connections and read the clients. - -**Note:** If you have more than one Auth0 tenant, remember to select the right one. in the dialog. - -![Auth0 connections details](/media/articles/connections/grean/auth0-consent.png) - -Click the check mark in the green area at the bottom to allow Grean easyID to set up the connections. - -## 5. Verify the connections - -Go to the **Connections > Enterprise** section and open the **ADFS** connections to see the connections for -Swedish BankID created from the previous steps. - -**Note:** One connection has been created for each kind of authentication supported by Swedish BankID: -Native BankID application or mobile app. Both applications must be installed prior to BankID authentication. - -![ADFS connections created](/media/articles/connections/grean/adfs-connections-se.png) - -Remember to enable at least one client before clicking the **Try** button! For more on test users see documentation -on easyID. - -## 6. Create your test users - -With the above setup you will be ready to start testing. But first you must create one or more test users here: -[demo.bankid.com/](https://demo.bankid.com/). If you don't already have a test or real BankID, go to the section -namd **Log in with a personal code**. - -## 7. Enable production use - -To start accepting real BankID logins from real legal persons, you must first enter into a formal agreement with a Swedish Bank, -possibly through Grean, or directly with you bank. - -Once this agreement is in place you will receive a certificate to upload to Grean easyID. Go to the **IDENTITY SERVICES** tab -and open the **SE BankID** section. This is where you will upload your organization's BankID certificate. - -![Identity Service production](/media/articles/connections/grean/se-bankid-prod.png) - - - - - - - diff --git a/articles/connections/grean/nemid.md b/articles/connections/grean/nemid.md deleted file mode 100644 index eea21f5302..0000000000 --- a/articles/connections/grean/nemid.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: Connect Danish NemID with Auth0 through Grean easyID -connection: Danish NemID -image: /media/articles/connections/grean/nemid_black.png -seo_alias: nemid -description: Connecting Danish NemID with Auth0 through Grean's easyID service ---- - -# Log in with Danish NemID through Auth0 - -When you need to know the legal identity of your Danish users, your choice is NemID offered by the Danish Government. NemID exists in -both a version private citizens and one for employees of an organization. - -The NemID technology by itself is proprietary and takes quite a bit of work to understand and integrate, but through [Grean's easyID service](https://grean.com/easyid) -you may avoid the integration trouble. - -Below is an outline of the steps to get ready to accept Danish NemID logins, but you may also view -[a short screen cast](https://grean.com/easyid/auth0/2016/12/07/easyid-and-auth0.html) at Grean's website. - -**NOTE:** While the technical integration complexity is simple, to use Danish BankID in production you will have to go through a formal process to -register and obtain the necessary certificate to identify yourself to your users. -More on this proceess can be found once you sign into the easyID service, and with the help of Grean. - -## 1. Create an account with Grean easyID - -Go to [grean.com/easyid](https://grean.com/easyid) and click the sign-up button. - -Once registered you will be asked to create your tenant. - -![Create new tenant](/media/articles/connections/grean/easyid-signup.png) - -## 2. Create an Application to point to Auth0 - -In easyID go to the **APPLICATIONS** tab and create a new application, a client, by clikcing the **with Auth0** button. -Give it a meaningful name, select the domain and remember to select the **DK NemID**. - -![Create application with Auth0](/media/articles/connections/grean/auth0-app-dk.png) - -Click **Save** to open the next dialog - -## 3. Name the connection (prefix) as it will appear in Auth0 - -If you do not run off the public Auth0 service, enter the DNS name of the login tenant. Otherwise just leave the **Auth0 tenant** field as is. - -Secondly enter a name to be used as the prefix for the connections created in Auth0. - -![Auth0 connections details](/media/articles/connections/grean/auth0-details.png) - -Click **Proceed**. - -## 4. Create new connections in Auth0 - -If you are not already logged in to Auth0 in this session, you will be prompted to do so in the popup window. - -Once logged in you must grant Grean easyID consent to create connections and read the details of your clients. - -**Note:** If you have more than one Auth0 tenant, remember to select the right one. in the dialog. - -![Auth0 connections details](/media/articles/connections/grean/auth0-consent.png) - -Click the check mark in the green area at the bottom to allow Grean easyID to set up the connections. - -## 5. Verify the connections - -Go to the **Connections > Enterprise** section and open the **ADFS** connections to see the connections for -Danish NemID created from the previous steps. - -**Note:** One connection has been created for each kind of authentication supported by NemID: -Personal NemID (POCES), Employee NemID (MOCES), and Employee NemID with a code file. - -![ADFS connections created](/media/articles/connections/grean/adfs-connections-dk.png) - -Remember to enable at least one client before clicking the **Try** button! For more on test users see the documentation -on easyID. - -## 6. Create your test users - -With the above setup you will be ready to start testing. But first you must create one or more test users or get some from Grean. -See more in the documentation in your easyID tenant. - -## 7. Enable production use - -To start accepting real NemID logins from real legal persons, you must first enter into a formal agreement with Nets, -the company providing the service under contract from the Danish Government. More on this here (in Danish): -[https://www.nets.eu/dk-da/l%C3%B8sninger/nemid/nemid-tjenesteudbyder/Pages/bestil.aspx](https://www.nets.eu/dk-da/l%C3%B8sninger/nemid/nemid-tjenesteudbyder/Pages/bestil.aspx) - -Once this agreement is in place you will receive a certificate to upload to Grean easyID. Go to the **IDENTITY SERVICES** tab -and open the **DK NemID** section. This is where you will upload your organization's BankID certificate and provide the rest of the -needed information. - -![Identity Service production](/media/articles/connections/grean/dk-nemid-prod.png) \ No newline at end of file diff --git a/articles/connections/how-to-test-partner-connection.md b/articles/connections/how-to-test-partner-connection.md new file mode 100644 index 0000000000..21359c8e7c --- /dev/null +++ b/articles/connections/how-to-test-partner-connection.md @@ -0,0 +1,48 @@ +--- +description: Learn how to test a partner connection. +topics: + - connections + - troubleshooting +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +# Test Partner Connections + +1. Click on the __Try__ button on each connection. +1. Login with the identity provider. +1. Wait for the __It Works!__ page that displays the result. + +Auth0 simulates the authentication flow as if it was an application, displaying the __User Profile__ resulting from a successful authentication. + +There's a caveat though: for this to work you have to be logged in to the Auth0 Dashboard. + +This is often not possible if you are testing a connection that belongs to someone else, and you don't have test credentials with them. This is common when connecting to __Enterprise connections__ such as __SAML IdPs__ or __Active Directory__. + +Your partners can test the new connection. + +1. Register a test app. + + - Navigate to [Auth0 Dashboard > Applications > Applications](${manage_url}/#/applications), and click **Create Application**. You can give it any name, for example, `Test App`. + + - In the settings of the newly-created app, configure __Allowed Callback Urls__ to `http://jwt.io`. + + - Select __Save Changes__. + +2. Send your partner the link to log in. + + ```text + https://${account.namespace}/authorize?response_type=token&scope=openid%20profile&client_id=${account.clientId}&redirect_uri=http://jwt.io&connection=THE_CONNECTION_YOU_WANT_TO_TEST + ``` + + Replace these two parameters: + + * __client_id__: the app client_id created in __Step 1__. + * __connection__: the name of the connection you want to test. + +3. Test the connection. When your partner follows the link, they will be redirected to their configured Identity Provider (the __connection__). After successful authentication, they will be sent back to [JWT.io](http://jwt.io) where all user properties will be decoded from the token. + +::: note +The test app is not a _real_ app. [JWT.io](http://jwt.io) is a testing website that decodes tokens sent on a URL fragment. +::: \ No newline at end of file diff --git a/articles/connections/index.md b/articles/connections/index.md index 380f53051d..6efe88df28 100644 --- a/articles/connections/index.md +++ b/articles/connections/index.md @@ -1,91 +1,31 @@ --- -url: /identityproviders -description: Auth0 is an identity hub that supports the many authentication providers listed here. +section: articles +classes: topic-page +title: Connections +description: Describes the various sources of users supported by Auth0, including identity providers, databases, and passwordless authentication methods. +topics: + - connections +contentType: + - index +useCase: + - customize-connections + - add-idp --- +# Connections - +A connection is the relationship between Auth0 and a source of users, which may include external Identity Providers (such as Google or LinkedIn), databases, or passwordless authentication methods. Auth0 sits between your application and its sources of users, which adds a level of abstraction, so your application is isolated from any changes to and idiosyncrasies of each source's implementation. -# Identity Providers Supported by Auth0 +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. You can disable synchronization to allow for updating profile attributes from your application. -Auth0 is an identity hub that supports many authentication providers using various protocols: **OAuth2**, **WS-Federation**, etc. Auth0 supports [Social](#social), [Enterprise](#enterprise), [Database](#database-and-custom-connections) and [Passwordless](#passwordless) connections. +You can configure any number of connections for your applications. -## Social - -Auth0 supports the following social providers out of the box. You can also use any [OAuth2 Authorization Server](/connections/social/oauth2). - -<% var socialConnections = cache.find('articles/connections/social', {sort: 'index'}); %> -<%= include('./_connections', { connections: socialConnections }) %> - -## Enterprise - -<% var enterpriseConnections = cache.find('articles/connections/enterprise', {sort: 'index'}); %> -<%= include('./_connections', { connections: enterpriseConnections }) %> - -## Legal identities - -Through our partner Grean we offer a growing range of government and bank identities tied to -legal persons. -<% var greanConnections = cache.find('articles/connections/grean', {sort: 'index'}); %> -<%= include('./_connections', { connections: greanConnections }) %> - -If the one you need isn't found here we suggest getting in touch with [Grean](https://grean.com). - -## Database and Custom Connections - -If you want to create your own user store, instead of using external identity providers like Google or Facebook, you can use a Database Connection. This way you can can authenticate users with an email or username and a password. The credentials can be securely stored either in the Auth0 user store, or in your own database. - -You can create any number of custom fields and store this information as part of the `user_metadata`. You can easily import users from a legacy user store, enable or disable sign ups, configure your password policy or enable Multifactor Authentication. - -For more details refer to the [Database Connections](/connections/database) documentation. - -## Passwordless -Full documentation on Passwordless authentication can be found at the links below: - -
        -
      • Passwordless Authentication Overview
        • -<% cache.find('articles/connections/passwordless', {sort: 'connection'}).forEach(article => { %> - <% if (article.connection) { %> -
      • - <% if (article.public === false) { %> - <%- article.connection %> - <% } else { %> - <%- article.connection %> - <% } %> -
        • - <% } %> -<% }); %> -
      - - -## Additional Information - -Auth0 sits between your app and the identity provider that authenticates your users. Through this level of abstraction, Auth0 keeps your app isolated from any changes to and idiosyncrasies of each provider's implementation. In addition, Auth0's [normalized user profile](/user-profile) simplifies user management. - -**Note:** The relationship between Auth0 and any of these authentication providers is referred to as a 'connection'. - -Auth0 is a multi-tenant service. When you register with Auth0, you get your own namespace (${account.namespace}). Many of these identity providers require registration and you will need to provide a `return url`. This will always be: - -`https://${account.namespace}/login/callback` +| Read... | To learn... | +|---------|-------------| +| [Social Identity Providers](/connections/identity-providers-social) | About the external social Identity Providers supported by Auth0. | +| [Enterprise Identity Providers](/connections/identity-providers-enterprise) | About the external enterprise Identity Providers supported by Auth0. | +| [Legal Identity Providers](/connections/identity-providers-legal) | About the external legal Identity Providers supported by Auth0. | +| [Database Connections](/connections/database) | How to create your own user store, which allows you to authenticate users with an email address or username and a password. The credentials can be stored securely in either the Auth0 user store or your own database. | +| [Passwordless Connections](/connections/passwordless) | How to allow users to log in without needing to remember a password. Users enter their mobile phone number or email address, and receive a one-time code or link, which they can use to log in. | +| [View Connections](/dashboard/guides/connections/view-connections) | How to view the configure connections for your application using the Auth0 Dashboard. | +| [Disable Connection Sync](/dashboard/guides/connections/configure-connection-sync) | How to disable the synchronization between user profile data and the connection source, which allows you to update profile attributes from your application instead. | +| [Pass Parameters to Identity Providers](/connections/pass-parameters-to-idps) | How to pass provider-specific parameters to an Identity Provider during authentication. | \ No newline at end of file diff --git a/articles/connections/legal.md b/articles/connections/legal.md new file mode 100644 index 0000000000..cb14347513 --- /dev/null +++ b/articles/connections/legal.md @@ -0,0 +1,18 @@ +--- +title: Legal Identity Providers +description: Learn about legal identity providers supported by Auth0. +topics: + - connections + - identity-providers +contentType: + - reference +useCase: + - customize-connections + - add-idp +--- +# Legal Identity Providers + +Through our partner, Criipto, we offer a growing range of government and bank identities tied to legal persons. If what you need isn't found here, please contact [Criipto](https://criipto.com). + +<% var criiptoConnections = cache.find('articles/connections/criipto', {sort: 'index'}); %> +<%= include('./_connections', { connections: criiptoConnections }) %> \ No newline at end of file diff --git a/articles/connections/options-mgmt-api.md b/articles/connections/options-mgmt-api.md new file mode 100644 index 0000000000..15a15a88ae --- /dev/null +++ b/articles/connections/options-mgmt-api.md @@ -0,0 +1,33 @@ +--- +title: Connection Options in the Management API +description: Describes the options attributes used when creating or updating a connection using the Management API. +topics: + - connections + - mgmt-api +contentType: reference +useCase: add-login +--- +# Connection Options in the Management API + +When creating or updating a connection in the Management API, you can include a variety of custom options in the `options` attribute, such as a password strength for the connection or provider-specific parameters to pass to an Identity Provider. + +The following elements are available for the `options` attribute. These are optional when calling the [Create a Connection endpoint](/api/management/v2#!/Connections/post_connections) or [Update a Connection endpoint](/api/management/v2#!/Connections/patch_connections_by_id). + +| Element | Type | Description | +|-|-|-| +| `validation` | object | <%= include('./_includes/_options-validation.md') %> Used with [database connections](/connections/database). | +| `passwordPolicy` | string | The strength level of the password. Allowed values include `none`, `low`, `fair`, `good`, and `excellent`. Used with [database connections](/connections/database). | +| `password_complexity_options` | object | <%= include('./_includes/_options-prop-pw-complexity.md') %> Used with [database connections](/connections/database). | +| `password_history` | object | <%= include('./_includes/_options-prop-pw-history.md') %> Used with [database connections](/connections/database). | +| `password_no_personal_info` | object | <%= include('./_includes/_options-prop-pw-no-pers-info.md') %> Used with [database connections](/connections/database). | +| `password_dictionary` | object | <%= include('./_includes/_options-prop-pw-dictionary.md') %> Used with [database connections](/connections/database). | +| `basic_profile` | boolean | Indicates that you want basic profile information (email address and email verified flag) stored in the Auth0 User Profile. Used with social and enterprise connections. | +| `ext_profile` | boolean | Indicates that you want extended profile information (name, public profile URL, photo, gender, birthdate, country, language, and timezone) stored in the Auth0 User Profile. Used with social and enterprise connections. | +| `ext_admin` | boolean | Indicates that you want to store whether or not the user is a domain administrator. Used with enterprise connections. | +| `ext_is_suspended` | boolean | Indicates that you want to store whether or not a user's account is suspended. Used with enterprise connections. | +| `ext_agreed_terms` | boolean | Indicates that you want to store whether or not a user has agreed to the terms of service. Used with enterprise connections. | +| `ext_groups` | boolean | Indicates that you want to store the distribution list(s) to which a user belongs. Used with enterprise connections. | +| `ext_assigned_plans` | boolean | Indicates that you want to store a list of the Office 365 assigned plans for the user. Used with the Office 365 enterprise connection, which is deprecated; these connections should be [migrated to Azure AD connections](/integrations/office365-connection-deprecation-guide). | +| `api_enable_users` | boolean | When enabled, allows users to make calls to the Google Directory API. Used with enterprise connections. | +| `upstream_params` | object | <%= include('./_includes/_options-upstream-params.md') %> Used with connections that use [Identity Providers](/connections). | +| `requires_username` | boolean | Indicates whether or not a user must provide a username in addition to their email address. | diff --git a/articles/connections/pass-parameters-to-idps.md b/articles/connections/pass-parameters-to-idps.md new file mode 100644 index 0000000000..e967f8d79d --- /dev/null +++ b/articles/connections/pass-parameters-to-idps.md @@ -0,0 +1,165 @@ +--- +title: Pass Parameters to Identity Providers +description: How to pass parameters to an Identity Provider API +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +# Pass Parameters to Identity Providers + +You can pass provider-specific parameters to an Identity Provider during authentication. The values can either be static per connection or dynamic per user. Note the following restrictions: + +- Only [valid OAuth 2.0/OIDC parameters](http://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint) are accepted. +- Not all Identity Providers support upstream parameters. Check with the specific Identity Provider before you proceed with your implementation. +- SAML identity providers, in particular, do not support upstream parameters. + +## Static parameters + +You can configure static parameters per connection with the Connections endpoints of our [Management API](/api/management/v2). Each time your connection is used, the specified parameters will be sent to the Identity Provider. + +When you [create](/api/management/v2#!/Connections/post_connections) or [update](/api/management/v2#!/Connections/patch_connections_by_id) a connection, use the `upstream_params` element of the `options` attribute. + +### Example: WordPress +As an example, let's use WordPress, which allows you to pass an optional `blog` parameter to its OAuth 2.0 authorization endpoint (for more information, see [WordPress's OAuth 2.0 documentation](https://developer.wordpress.com/docs/oauth2/)). + +Let's assume that you have a working WordPress connection and you want to always request that users have access to the `myblog.wordpress.com` blog when logging in with it. To do this, assign WordPress's `blog` parameter a default value of `myblog.wordpress.com`. + +First, we will use the [Get Connection](/api/management/v2#!/Connections/get_connections_by_id) endpoint, to retrieve the existing values of the `options` object. This is mandatory since the [Update Connection](/api/management/v2#!/Connections/patch_connections_by_id) endpoint, which we will use next, overrides this object will be overridden, so if parameters are missing they will be lost after the update. + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/api/v2/connections/YOUR-WORDPRESS-CONNECTION-ID", + "headers": [ + { + "name": "Authorization", + "value": "Bearer YOUR_ACCESS_TOKEN" + }, + { + "name": "Content-Type", + "value": "application/json" + } + ] +} +``` + +Let's say that the `options` contents for our wordpress connection are the following: + +```text +{ + "options": { + "client_id": "", + "profile": true, + "scope": ["profile"] + } +} +``` + +Now we can send the update request, copying the existing `options` contents and adding also the `blog` parameter. + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/connections/YOUR-WORDPRESS-CONNECTION-ID", + "headers": [ + { + "name": "Authorization", + "value": "Bearer YOUR_ACCESS_TOKEN" + }, + { + "name": "Content-Type", + "value": "application/json" + } + ], + "postData": { + "mimeType": "application/json", + "text": "{\"options\":{\"client_id\":\"\",\"profile\":true,\"scope\":[\"profile\"],\"upstream_params\":{\"blog\":{\"value\":\"myblog.wordpress.com\"}}}}" + } +} +``` + +Now every time a user authenticates with this connection the request to Wordpress will include the query parameter `blog=myblog.wordpress.com`. + +## Dynamic parameters + +You can configure upstream parameters per user. This way when a user authenticates, the parameters will be dynamically added to the authorization query. + +To do this, use the `upstream_params` element of the `options` attribute to specify a mapping between one of the existing accepted parameters to the parameter accepted by the Identity Provider. + +### Field list + +Here are fields available for the `enum` parameter: + +* `acr_values` +* `audience` +* `client_id` +* `display` +* `id_token_hint` +* `login_hint` +* `max_age` +* `prompt` +* `resource` +* `response_mode` +* `response_type` +* `ui_locales` + +### Example: Twitter + +As an example, let's use Twitter, which allows you to pass an optional `screen_name` parameter to its OAuth authorization endpoint (for more information, see [Twitter's API reference](https://developer.twitter.com/en/docs/basics/authentication/api-reference/authorize)). + +To continue, you should already have a working Twitter connection; to learn how to configure one, see [Connect Your App to Twitter](/connections/social/twitter). + +Twitter's `screen_name` parameter pre-fills the username input box of the login screen with the given value, so we want to map it to the existing accepted parameter of `login_hint`. + +Let's assume that you already retrieved the contents of the `options` object (like we did in the previous paragraph) and they are the following: + +```text +"options": { + "client_id": "thisismyid", + "client_secret": "thisismysecret", + "profile": true +} +``` + +Send the update request, copying the existing `options` contents and adding also the `screen_name` parameter. + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/connections/YOUR-TWITTER-CONNECTION-ID", + "headers": [ + { + "name": "Authorization", + "value": "Bearer YOUR_ACCESS_TOKEN" + }, + { + "name": "Content-Type", + "value": "application/json" + } + ], + "postData": { + "mimeType": "application/json", + "text": "{\"options\": {\"client_id\": \"thisismyid\", \"client_secret\": \"thisismysecret\", \"profile\": true, \"upstream_params\": {\"screen_name\": {\"alias\": \"login_hint\"}}}}" + } +} +``` + +Now, when you call the [Authorize endpoint](/api/authentication#authorize-application) for a specific user, you can pass their email address in the `login_hint` parameter. + +```text +https://${account.namespace}/authorize + ?client_id=${account.clientId} + &response_type=token + &redirect_uri=${account.callback} + &scope=openid%20name%20email + &login_hint=john@gmail.com +``` + +And that value will in turn be passed along to the Twitter authorization endpoint in the `screen_name` parameter. + +```text +https://api.twitter.com/oauth/authorize + ?oauth_token=YOUR_TOKEN + &screen_name=john@gmail.com +``` diff --git a/articles/connections/passwordless/_includes/_introduction-email-magic-link.md b/articles/connections/passwordless/_includes/_introduction-email-magic-link.md new file mode 100644 index 0000000000..88b93e7aad --- /dev/null +++ b/articles/connections/passwordless/_includes/_introduction-email-magic-link.md @@ -0,0 +1,10 @@ + +With an email connection, the user is asked to enter their email address, to which Auth0 usually sends a one-time-use code. Instead, you can configure Auth0 to send a magic link. If you are using Universal Login, make sure you [configure Universal Login with Passwordless](/dashboard/guides/universal-login/configure-login-page-passwordless). + +![Send Magic Link Flow](/media/articles/connections/passwordless/passwordless-email-magic-link-start-flow.png) + +![Sample Magic Link Email](/media/articles/connections/passwordless/passwordless-email-receive-link.png) + +The user then clicks the button or link in the email and is automatically signed in to your application. + +![Magic Link User Flow](/media/articles/connections/passwordless/passwordless-authenticated-magic-flow.png) diff --git a/articles/connections/passwordless/_includes/_introduction-email.md b/articles/connections/passwordless/_includes/_introduction-email.md new file mode 100644 index 0000000000..45009e0d1e --- /dev/null +++ b/articles/connections/passwordless/_includes/_introduction-email.md @@ -0,0 +1,10 @@ +When Passwordless is configured to use Email. the user is asked to enter their email address, to which Auth0 sends a one-time-use code. The user then enters the code into your application. If you are using Universal Login, make sure you [configure Universal Login with Passwordless](/dashboard/guides/universal-login/configure-login-page-passwordless). + +If the email address attached to the code matches an existing user, Auth0 authenticates the user: + +![Existing User Flow](/media/articles/connections/passwordless/passwordless-authenticated-flow.png) + +If the user is new, their user profile is created for the `email` connection before they are authenticated by Auth0. + +![New User Flow](/media/articles/connections/passwordless/passwordless-create-user-flow.png) + diff --git a/articles/connections/passwordless/_includes/_introduction-sms.md b/articles/connections/passwordless/_includes/_introduction-sms.md new file mode 100644 index 0000000000..c9fc26970c --- /dev/null +++ b/articles/connections/passwordless/_includes/_introduction-sms.md @@ -0,0 +1,11 @@ +With an SMS connection, the user is asked to enter a phone number. By default, Auth0 uses [Twilio](https://www.twilio.com) to send a one-time-use code to that phone number. (If you have a custom SMS gateway, you can [modify your connection to use that instead of Twilio](/connections/passwordless/use-sms-gateway-passwordless).) + +The user then enters the code into your application. If you are using Universal Login, make sure you [configure Universal Login with Passwordless](/dashboard/guides/universal-login/configure-login-page-passwordless). + +If the phone number attached to the code matches an existing user, Auth0 authenticates the user: + +![Existing User Flow](/media/articles/connections/passwordless/passwordless-authenticated-flow.png) + +If the user is new, their user profile is created for the `sms` connection before they are authenticated by Auth0. + +![New User Flow](/media/articles/connections/passwordless/passwordless-create-user-flow.png) diff --git a/articles/connections/passwordless/_includes/_rate_limit_server_side.md b/articles/connections/passwordless/_includes/_rate_limit_server_side.md new file mode 100644 index 0000000000..29a8815a31 --- /dev/null +++ b/articles/connections/passwordless/_includes/_rate_limit_server_side.md @@ -0,0 +1,4 @@ + +## Setting the `auth0-forwarded-for` header for rate-limit purposes + +The `/passwordless/start` endpoint has a [rate limit](/policies/rate-limits#authentication-api) of 50 requests per hour per IP. If you call the API from the server-side, your backend's IP may easily hit these rate limits. To address this issue read more here about [rate limiting in passwordless endpoints](/connections/passwordless/relevant-api-endpoints#rate-limiting-in-passwordless-endpoints). diff --git a/articles/connections/passwordless/_includes/_setup-cors.md b/articles/connections/passwordless/_includes/_setup-cors.md new file mode 100644 index 0000000000..a2d3a95518 --- /dev/null +++ b/articles/connections/passwordless/_includes/_setup-cors.md @@ -0,0 +1,7 @@ +### Configure Cross-Origin Resource Sharing (CORS) + +For security purposes, your app's origin URL must be listed as an approved URL. If you have not already added it to the **Allowed Callback URLS** for your application, you will need to add it to the list of **Allowed Origins (CORS)**. + +1. Navigate to [Auth0 Dashboard > Applications > Applications](${manage_url}/#/applications), and select the name of your application to see its settings. + +2. Locate **Allowed Origins (CORS)**, enter your application's [origin URL](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin), and select **Save Changes**. diff --git a/articles/connections/passwordless/_includes/_setup-email.md b/articles/connections/passwordless/_includes/_setup-email.md new file mode 100644 index 0000000000..705f028170 --- /dev/null +++ b/articles/connections/passwordless/_includes/_setup-email.md @@ -0,0 +1,80 @@ + +## Configure the connection + +1. Navigate to [Auth0 Dashboard > Authentication > Passwordless](${manage_url}/#/connections/passwordless), and enable the **Email** switch. + +![Enable Email Passwordless](/media/articles/connections/passwordless/connections-passwordless-list.png) + +2. Select your **Email Syntax**, and enter your email's **From**, **Subject**, and **Message** text. + +![Configure Email Passwordless](/media/articles/connections/passwordless/connections-passwordless-email.png) + +::: note +You must change the **From** value to a non **@auth0.com** address for your custom email to be sent. Otherwise the default email template will be sent. +::: + +3. Enter any **Authentication Parameters** you would like to include in the generated sign-in link. + +4. Adjust settings for your **OTP Expiry** and **OTP Length** + +<%= include('../../_otp-limitations') %> + +5. Decide if you want to **Disable Signups**. You can enable passwordless access just for existing users by enabling this setting. + +### Multi-language support + +The **Message** area supports multiple languages. + +To choose the language, call the [/passwordless/start authentication endpoint](/api/authentication/reference#get-code-or-link) and set the value of the 'x-request-language' header. When this header is not set, the language is extracted from the 'accept-language' header, which is automatically set by the browser. + +### Message syntax + +The **Message** area accepts Liquid syntax. You can use this syntax, combined with exposed parameter values, to programmatically construct elements of the message. For example, you can reference the `request_language` parameter to change the language of the message: + +```text +{% if request_language contains 'dutch' %} + Hier is uw verificatie code: {{ code }} +{% endif %} + +{% if request_language contains 'fr-FR' %} + Ceci est votre code: {{ code }} +{% endif %} +``` + +The following parameters are available when defining the message template: + +| Exposed Parameter | Description | +|:------------------|:---------| +| `code` | The password to use | +| `link` | The generated sign-in link | +| `application.name` | The name of the application with which the user is signing up | +| `request_language` | The requested language for message content | +| `operation` | Indicates when the template has been triggered by an update to a user's email via the API. Equals `change_email` when triggered; otherwise, null.| + +## Enable your apps + +Select the **Applications** view, and enable the applications for which you would like to use Passwordless Email. + +## Email Providers + +By default, Auth0 sends the email from its own SMTP provider. Auth0's built-in email infrastructure should be used for testing-level emails only. You can [configure your own email provider](/email/providers) to better monitor and troubleshoot the email service as well as be able to fully customize the emails. + +::: note +You will need to use your own email provider to be able to modify the `From`, `Subject`, and `Body` of Passwordless emails. +::: + +You may configure Auth0 to send users one-time codes using: + +* [Mandrill](/email/providers#configure-mandrill) +* [AWS](/email/providers#configure-amazon-ses) +* [Twilio SendGrid](/email/providers#configure-sendgrid) +* [SparkPost](/email/providers#configure-sparkpost) +* [Mailgun](/email/providers#configure-mailgun) +* [your own custom SMTP email provider](/email/providers#configure-a-custom-smtp-server) + +::: note +To use a custom SMTP email provider, the SMTP server must: +* support LOGIN authentication +* support TLS 1.0 or higher +* use a certificate signed by a public certificate authority (CA) +::: diff --git a/articles/connections/passwordless/_includes/_setup-sms-twilio.md b/articles/connections/passwordless/_includes/_setup-sms-twilio.md new file mode 100644 index 0000000000..cd5bc9e769 --- /dev/null +++ b/articles/connections/passwordless/_includes/_setup-sms-twilio.md @@ -0,0 +1,77 @@ + +Navigate to [Auth0 Dashboard > Authentication > Passwordless](${manage_url}/#/connections/passwordless), and enable the **SMS** switch. + +![Enable SMS Passwordless](/media/articles/connections/passwordless/connections-passwordless-list.png) + +To send the SMS, you can either use Twilio, or a Custom SMS Gateway. + +### Configure Twilio settings + +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. + +1. Enter your **Twilio Account SID** and **Twilio Auth Token**. + +::: note +To learn how to find your Twilio SID and Auth Token, see Twilio docs: [How to create an Application SID](https://www.twilio.com/help/faq/twilio-basics/what-is-an-application-sid) and [Auth Tokens and how to change them](https://www.twilio.com/help/faq/twilio-basics/what-is-the-auth-token-and-how-can-i-change-it). +::: + +![Configure SMS Passwordless](/media/articles/connections/passwordless/connections-passwordless-sms.png) + +2. Select your **SMS Source** and depending on your selection, enter either your **Twilio Messaging Service SID** or a **From** phone number. Users will see what you enter as the sender of the SMS. + +::: note +To learn about using Twilio Messaging Services, see Twilio docs: [Sending Messages with Messaging Services](https://www.twilio.com/docs/sms/services/services-send-messages). +::: + +### Configure a custom SMS gateway + +If you would like to use your own SMS gateway, you will need to create the passwordless connection and then modify it using our Management API. To learn how to modify the connection to use your own SMS gateway, see [Configure SMS Gateway for Passwordless Connections](/connections/passwordless/use-sms-gateway-passwordless). + +### Configure passwordless SMS settings + +1. In **Message**, enter the body text of the SMS. + +::: note +The `@@password@@` placeholder will automatically be replaced with the one-time password that is sent to the user. +::: + +2. Adjust settings for your **OTP Expiry** and **OTP Length**. + +<%= include('../../_otp-limitations') %> + +3. Decide if you want to **Disable Signups**. You can enable passwordless access just for existing users by enabling this setting. + +4. Click **Save**. + +#### Multi-language support + +The **Message** area supports multiple languages. + +To choose the language, call the [/passwordless/start authentication endpoint](/api/authentication/reference#get-code-or-link) and set the value of the 'x-request-language' header. When this header is not set, the language is extracted from the 'accept-language' header, which is automatically set by the browser. + +#### Message syntax + +The **Message** area accepts Liquid syntax. You can use this syntax, combined with exposed parameter values, to programmatically construct elements of the message. For example, you can reference the `request_language` parameter to change the language of the message: + +```text +{% if request_language contains 'dutch' %} + Hier is uw verificatie code: {{ password }} +{% endif %} + +{% if request_language contains 'fr-FR' %} + Ceci est votre code: {{ password }} +{% endif %} +``` + +The following parameters are available when defining the message template: + +| Exposed Parameter | Description | +|:------------------|:---------| +| `password` or `code` | The password to use | +| `phone_number` | The user's phone number | +| `application.name` | The name of the application with which the user is signing up | +| `request_language` | The requested language for message content | + +### Enable your apps + +Select the **Applications** view, and enable the applications for which you would like to use Passwordless SMS. diff --git a/articles/connections/passwordless/_init-passwordless-lock.md b/articles/connections/passwordless/_init-passwordless-lock.md deleted file mode 100644 index cc5e9fc84d..0000000000 --- a/articles/connections/passwordless/_init-passwordless-lock.md +++ /dev/null @@ -1,3 +0,0 @@ -Auth0 Lock Passwordless is a professional-looking dialog that allows users to log in after receiving a one-time password via email or text message. - -After installing [Lock Passwordless](https://github.com/auth0/lock-passwordless), you must initialize it with your `Client Id` and `domain`. You can find this information on your [application settings](${manage_url}/#/applications/${account.clientId}/settings) page. diff --git a/articles/connections/passwordless/_introduction-email-magic-link.md b/articles/connections/passwordless/_introduction-email-magic-link.md deleted file mode 100644 index cd442cf0b5..0000000000 --- a/articles/connections/passwordless/_introduction-email-magic-link.md +++ /dev/null @@ -1,11 +0,0 @@ -Instead of sending the user a one time code, you can configure Auth0 to send a magic link: - -![](/media/articles/connections/passwordless/passwordless-email-magic-link-start-flow.png) - -Auth0 will send an email containing a clickable button or link: - -![](/media/articles/connections/passwordless/passwordless-email-receive-link.png) - -After clicking the button, the user will be automatically signed-in to your application: - -![](/media/articles/connections/passwordless/passwordless-authenticated-magic-flow.png) \ No newline at end of file diff --git a/articles/connections/passwordless/_introduction-email.md b/articles/connections/passwordless/_introduction-email.md deleted file mode 100644 index a268399543..0000000000 --- a/articles/connections/passwordless/_introduction-email.md +++ /dev/null @@ -1,13 +0,0 @@ -With the e-mail connection, the user is requested to enter their e-mail address. Auth0 then sends an email to that address containing a one-time code. - -Once the user enters this code into your application, a new user will be created in the `email` connection. The user is then authenticated by Auth0. - -![](/media/articles/connections/passwordless/passwordless-create-user-flow.png) - -If the e-mail address matches an existing user, Auth0 just authenticates the user: - -![](/media/articles/connections/passwordless/passwordless-authenticated-flow.png) - -<% if (isMobile) { %> -On mobile platforms, your application will receive an `id_token`, the user profile and, optionally, a `refresh_token`. -<% } %> \ No newline at end of file diff --git a/articles/connections/passwordless/_introduction-lock.md b/articles/connections/passwordless/_introduction-lock.md deleted file mode 100644 index 3295a82e18..0000000000 --- a/articles/connections/passwordless/_introduction-lock.md +++ /dev/null @@ -1,3 +0,0 @@ -The [Lock](https://github.com/auth0/${repository}/) is a widget that allows you to easily integrate Auth0's Passwordless Authentication into your ${platform} applications. - -After [installing and configuring](/libraries/${docsUrl}#install) ${repository} you will be able to use Lock as follows. diff --git a/articles/connections/passwordless/_introduction-sms.md b/articles/connections/passwordless/_introduction-sms.md deleted file mode 100644 index b22bb8f4a7..0000000000 --- a/articles/connections/passwordless/_introduction-sms.md +++ /dev/null @@ -1,13 +0,0 @@ -With the SMS connection, the user is requested to enter a phone number. Auth0 then uses [Twilio](http://www.twilio.com) to send a one time code to that number. - -Once the user enters this code into your application, a new user will be created in the `sms` connection. The user is then authenticated by Auth0. - -![](/media/articles/connections/passwordless/passwordless-create-user-flow.png) - -If the phone number matches an existing user, Auth0 just authenticates the user: - -![](/media/articles/connections/passwordless/passwordless-authenticated-flow.png) - -<% if (isMobile) { %> -On mobile platforms, your application will receive an `id_token`, the user profile and, optionally, a `refresh_token`. -<% } %> \ No newline at end of file diff --git a/articles/connections/passwordless/_introduction.md b/articles/connections/passwordless/_introduction.md deleted file mode 100644 index d3f09e0733..0000000000 --- a/articles/connections/passwordless/_introduction.md +++ /dev/null @@ -1,15 +0,0 @@ -# Passwordless Authentication - -Passwordless connections in Auth0 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 an <% if (withFingerprint) { %> email address, phone number or fingerprint <% } else { %> email address or phone number <% } %> to register for 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. - -In addition, the credential used for authentication is automatically validated since the user just entered it at sign-up. - -## Configuration - -These connections use an authentication channel like <% if (withFingerprint) { %> SMS, e-mail or Touch ID <% } else { %> SMS or e-mail <% } %>. Each of these channels can be configured in the dashboard under [Connections > Passwordless](${manage_url}/#/connections/passwordless). - -![](/media/articles/connections/passwordless/passwordless-connections.png) \ No newline at end of file diff --git a/articles/connections/passwordless/_ios-language-picker.md b/articles/connections/passwordless/_ios-language-picker.md deleted file mode 100644 index b93679017a..0000000000 --- a/articles/connections/passwordless/_ios-language-picker.md +++ /dev/null @@ -1,23 +0,0 @@ - -
      - - - -
      - diff --git a/articles/connections/passwordless/_old/_includes/_call-from-client-side.md b/articles/connections/passwordless/_old/_includes/_call-from-client-side.md new file mode 100644 index 0000000000..6a630739ba --- /dev/null +++ b/articles/connections/passwordless/_old/_includes/_call-from-client-side.md @@ -0,0 +1,3 @@ +:::warning +Passwordless 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 call it from the server-side, your backend's IP may easily hit these rate limits. +::: \ No newline at end of file diff --git a/articles/connections/passwordless/_old/_includes/_custom-domains.md b/articles/connections/passwordless/_old/_includes/_custom-domains.md new file mode 100644 index 0000000000..b34b890b62 --- /dev/null +++ b/articles/connections/passwordless/_old/_includes/_custom-domains.md @@ -0,0 +1,3 @@ +::: note +If you use custom domains, replace `${account.namespace}` with your custom domain. +::: diff --git a/articles/connections/passwordless/_email-controller-objc.md b/articles/connections/passwordless/_old/_includes/_email-controller-objc.md similarity index 100% rename from articles/connections/passwordless/_email-controller-objc.md rename to articles/connections/passwordless/_old/_includes/_email-controller-objc.md diff --git a/articles/connections/passwordless/_email-controller-swift.md b/articles/connections/passwordless/_old/_includes/_email-controller-swift.md similarity index 100% rename from articles/connections/passwordless/_email-controller-swift.md rename to articles/connections/passwordless/_old/_includes/_email-controller-swift.md diff --git a/articles/connections/passwordless/_email-login-objc.md b/articles/connections/passwordless/_old/_includes/_email-login-objc.md similarity index 100% rename from articles/connections/passwordless/_email-login-objc.md rename to articles/connections/passwordless/_old/_includes/_email-login-objc.md diff --git a/articles/connections/passwordless/_email-login-swift.md b/articles/connections/passwordless/_old/_includes/_email-login-swift.md similarity index 100% rename from articles/connections/passwordless/_email-login-swift.md rename to articles/connections/passwordless/_old/_includes/_email-login-swift.md diff --git a/articles/connections/passwordless/_email-send-code-objc.md b/articles/connections/passwordless/_old/_includes/_email-send-code-objc.md similarity index 100% rename from articles/connections/passwordless/_email-send-code-objc.md rename to articles/connections/passwordless/_old/_includes/_email-send-code-objc.md diff --git a/articles/connections/passwordless/_email-send-code-swift.md b/articles/connections/passwordless/_old/_includes/_email-send-code-swift.md similarity index 100% rename from articles/connections/passwordless/_email-send-code-swift.md rename to articles/connections/passwordless/_old/_includes/_email-send-code-swift.md diff --git a/articles/connections/passwordless/_init-auth0js.md b/articles/connections/passwordless/_old/_includes/_init-auth0js.md similarity index 100% rename from articles/connections/passwordless/_init-auth0js.md rename to articles/connections/passwordless/_old/_includes/_init-auth0js.md diff --git a/articles/connections/passwordless/_old/_includes/_init-auth0js_v8.md b/articles/connections/passwordless/_old/_includes/_init-auth0js_v8.md new file mode 100644 index 0000000000..8afa5014eb --- /dev/null +++ b/articles/connections/passwordless/_old/_includes/_init-auth0js_v8.md @@ -0,0 +1,12 @@ +Construct a new instance of the Auth0 client as follows: + +```html + + +``` diff --git a/articles/connections/passwordless/_old/_includes/_init-auth0js_v9.md b/articles/connections/passwordless/_old/_includes/_init-auth0js_v9.md new file mode 100644 index 0000000000..3cf13ea5f9 --- /dev/null +++ b/articles/connections/passwordless/_old/_includes/_init-auth0js_v9.md @@ -0,0 +1,12 @@ +Construct a new instance of the Auth0 client as follows: + +```html + + +``` diff --git a/articles/connections/passwordless/_old/_includes/_init-passwordless-lock.md b/articles/connections/passwordless/_old/_includes/_init-passwordless-lock.md new file mode 100644 index 0000000000..3c5dfa2ac4 --- /dev/null +++ b/articles/connections/passwordless/_old/_includes/_init-passwordless-lock.md @@ -0,0 +1,3 @@ +Lock with Passwordless Mode is a professional-looking dialog that allows users to log in after receiving a one-time password via email or text message. + +After installing [Lock](/libraries/lock) (version 11.2.0 or later), you must initialize it with your `Client Id` and `domain`. You can find this information at [Auth0 Dashboard > Applications > Applications](${manage_url}/#/applications) in your [application's settings](${manage_url}/#/applications/${account.clientId}/settings). \ No newline at end of file diff --git a/articles/connections/passwordless/_old/_includes/_introduction-lock.md b/articles/connections/passwordless/_old/_includes/_introduction-lock.md new file mode 100644 index 0000000000..55f0f12293 --- /dev/null +++ b/articles/connections/passwordless/_old/_includes/_introduction-lock.md @@ -0,0 +1,3 @@ +[Lock](https://github.com/auth0/${repository}/) is a widget that allows you to easily integrate Auth0's Passwordless Authentication into your ${platform} applications. + +After [installing and configuring](/libraries/${docsUrl}#install) ${repository}, you will be able to use Lock as follows. diff --git a/articles/connections/passwordless/_old/_includes/_introduction.md b/articles/connections/passwordless/_old/_includes/_introduction.md new file mode 100644 index 0000000000..bc99aff991 --- /dev/null +++ b/articles/connections/passwordless/_old/_includes/_introduction.md @@ -0,0 +1,17 @@ +Passwordless connections in Auth0 allow users to login without the need to remember a password. The benefits of enabling passwordless connections include: + +* Improved user experience, particularly on mobile applications, since users only need an email address or phone number to sign up and the credential used for authentication is automatically validated after sign-up. + +* Enhanced security since users avoid the insecure practice of using the same password for many purposes. + +* Less effort for you since you will not need to implement a password reset procedure. + +## Configuration + +Passwordless connections use an authentication channel like SMS or email, which need to be configured at [Auth0 Dashboard > Authentication > Passwordless](${manage_url}/#/connections/passwordless). + +::: note +We recommend implementing passwordless with Universal Login. If you are using embedded login with or Auth0.js, you will need to enable custom domains for your tenant. To learn more, see [Custom Domains](/custom-domains). +::: + +![](/media/articles/connections/passwordless/connections-passwordless-list.png) diff --git a/articles/connections/passwordless/_old/_includes/_setup-callback.md b/articles/connections/passwordless/_old/_includes/_setup-callback.md new file mode 100644 index 0000000000..4f192283c3 --- /dev/null +++ b/articles/connections/passwordless/_old/_includes/_setup-callback.md @@ -0,0 +1,3 @@ +### Configure Callback URL + +For security purposes, you must add <% if(spa){ %>your page's URL<%} else {%>the callback URL<%}%> to the list of **Allowed callback URLs** in your application's settings at [Auth0 Dashboard > Applications > Applications](${manage_url}/#/applications). \ No newline at end of file diff --git a/articles/connections/passwordless/_old/_includes/_single-browser-magic-link.md b/articles/connections/passwordless/_old/_includes/_single-browser-magic-link.md new file mode 100644 index 0000000000..1ad8e77cee --- /dev/null +++ b/articles/connections/passwordless/_old/_includes/_single-browser-magic-link.md @@ -0,0 +1,5 @@ +::: note +With magic link transactions, both the initial request and the response to the request must take place in the same browser or the transaction will fail. This is particularly relevant for iOS users, who cannot change their default web browser. + +For example, the user makes the request using Chrome, but iOS opens the magic link received via email using Safari. If this happens, the transaction fails. +::: diff --git a/articles/connections/passwordless/_sms-controller-objc.md b/articles/connections/passwordless/_old/_includes/_sms-controller-objc.md similarity index 100% rename from articles/connections/passwordless/_sms-controller-objc.md rename to articles/connections/passwordless/_old/_includes/_sms-controller-objc.md diff --git a/articles/connections/passwordless/_sms-controller-swift.md b/articles/connections/passwordless/_old/_includes/_sms-controller-swift.md similarity index 100% rename from articles/connections/passwordless/_sms-controller-swift.md rename to articles/connections/passwordless/_old/_includes/_sms-controller-swift.md diff --git a/articles/connections/passwordless/_sms-login-objc.md b/articles/connections/passwordless/_old/_includes/_sms-login-objc.md similarity index 100% rename from articles/connections/passwordless/_sms-login-objc.md rename to articles/connections/passwordless/_old/_includes/_sms-login-objc.md diff --git a/articles/connections/passwordless/_sms-login-swift.md b/articles/connections/passwordless/_old/_includes/_sms-login-swift.md similarity index 100% rename from articles/connections/passwordless/_sms-login-swift.md rename to articles/connections/passwordless/_old/_includes/_sms-login-swift.md diff --git a/articles/connections/passwordless/_sms-send-code-objc.md b/articles/connections/passwordless/_old/_includes/_sms-send-code-objc.md similarity index 100% rename from articles/connections/passwordless/_sms-send-code-objc.md rename to articles/connections/passwordless/_old/_includes/_sms-send-code-objc.md diff --git a/articles/connections/passwordless/_sms-send-code-swift.md b/articles/connections/passwordless/_old/_includes/_sms-send-code-swift.md similarity index 100% rename from articles/connections/passwordless/_sms-send-code-swift.md rename to articles/connections/passwordless/_old/_includes/_sms-send-code-swift.md diff --git a/articles/connections/passwordless/_old/_includes/_touchid-configure-component-objc.md b/articles/connections/passwordless/_old/_includes/_touchid-configure-component-objc.md new file mode 100644 index 0000000000..58bc915f26 --- /dev/null +++ b/articles/connections/passwordless/_old/_includes/_touchid-configure-component-objc.md @@ -0,0 +1,45 @@ +```objc +NSString *device = [[[UIDevice currentDevice] identifierForVendor] UUIDString]; +NSString *userId = profile.userId; + +A0TouchIDAuthentication *authentication = [[A0TouchIDAuthentication alloc] init]; +authentication.registerPublicKey = ^(NSData *pubKey, A0RegisterCompletionBlock completed, A0ErrorBlock errored) { + void(^registerBlock)() = ^{ + [self.userClient registerPublicKey:pubKey device:device user:userId success:^{ + completed(); + } failure:^(NSError *error) { + errored(error); + }]; + }; + [self.userClient removePublicKeyOfDevice:device user:userId success:^{ + registerBlock(); + } failure:^(NSError *error) { + registerBlock(); + }]; +}; + +authentication.jwtPayload = ^{ + return @{ + @"iss": userId, + @"device": device, + }; +}; + +authentication.authenticate = ^(NSString *jwt, A0ErrorBlock block) { + A0AuthParameters *parameters = [A0AuthParameters newWithDictionary:@{ + A0ParameterConnection: @"{NAME_OF_MY_DB_CONNECTION}", + A0ScopeProfile: @"openid name email nickname" + }]; + + [client loginWithIdToken:jwt deviceName:deviceName parameters:parameters success:^(A0UserProfile *profile, A0Token *token) { + // User is authenticated with Auth0 & Touch ID + } failure:^(NSError *error){ + block(error); + }]; +}; +authentication.onError = ^(NSError *error) { + // Handle authentication error +}; + +self.authentication = authentication; +``` diff --git a/articles/connections/passwordless/_old/_includes/_touchid-configure-component-swift.md b/articles/connections/passwordless/_old/_includes/_touchid-configure-component-swift.md new file mode 100644 index 0000000000..04ed55fe2b --- /dev/null +++ b/articles/connections/passwordless/_old/_includes/_touchid-configure-component-swift.md @@ -0,0 +1,45 @@ +```swift +let device = UIDevice.currentDevice().identifierForVendor().UUIDString() +let userId = profile!.userId + +let authentication = A0TouchIDAuthentication() +authentication.registerPublicKey = { (pubKey, completed, errored) in + let registerBlock = { + self.userClient.registerPublicKey(pubKey, + device: device, + user: userId, + success: { completed() }, + failure: { error in errored(error) }) + } + self.userClient.removePublicKeyOfDevice(device, + user:userId, + success: { registerBlock() }, + failure: { _ in registerBlock() }) +} + +authentication.jwtPayload = { + return [ + "iss": userId, + "device": device, + ] +} + +authentication.authenticate = { (jwt, block) in + let parameters = A0AuthParameters.newWithDictionary([ + A0ScopeProfile: "openid name email nickname" + ]) + + client.loginWithIdToken(jwt, + deviceName: device, + parameters: parameters, + success: { (profile, token) in + // User is authenticated with Auth0 & Touch ID + }, + failure: { error in block(error) }) +} +authentication.onError = { error in + // Handle authentication error +} + +self.authentication = authentication; +``` diff --git a/articles/connections/passwordless/_touchid-controller-objc.md b/articles/connections/passwordless/_old/_includes/_touchid-controller-objc.md similarity index 100% rename from articles/connections/passwordless/_touchid-controller-objc.md rename to articles/connections/passwordless/_old/_includes/_touchid-controller-objc.md diff --git a/articles/connections/passwordless/_touchid-controller-swift.md b/articles/connections/passwordless/_old/_includes/_touchid-controller-swift.md similarity index 100% rename from articles/connections/passwordless/_touchid-controller-swift.md rename to articles/connections/passwordless/_old/_includes/_touchid-controller-swift.md diff --git a/articles/connections/passwordless/_touchid-init-client-objc.md b/articles/connections/passwordless/_old/_includes/_touchid-init-client-objc.md similarity index 100% rename from articles/connections/passwordless/_touchid-init-client-objc.md rename to articles/connections/passwordless/_old/_includes/_touchid-init-client-objc.md diff --git a/articles/connections/passwordless/_touchid-init-client-swift.md b/articles/connections/passwordless/_old/_includes/_touchid-init-client-swift.md similarity index 100% rename from articles/connections/passwordless/_touchid-init-client-swift.md rename to articles/connections/passwordless/_old/_includes/_touchid-init-client-swift.md diff --git a/articles/connections/passwordless/_touchid-login-method-objc.md b/articles/connections/passwordless/_old/_includes/_touchid-login-method-objc.md similarity index 100% rename from articles/connections/passwordless/_touchid-login-method-objc.md rename to articles/connections/passwordless/_old/_includes/_touchid-login-method-objc.md diff --git a/articles/connections/passwordless/_touchid-login-method-swift.md b/articles/connections/passwordless/_old/_includes/_touchid-login-method-swift.md similarity index 100% rename from articles/connections/passwordless/_touchid-login-method-swift.md rename to articles/connections/passwordless/_old/_includes/_touchid-login-method-swift.md diff --git a/articles/connections/passwordless/_touchid-properties-objc.md b/articles/connections/passwordless/_old/_includes/_touchid-properties-objc.md similarity index 100% rename from articles/connections/passwordless/_touchid-properties-objc.md rename to articles/connections/passwordless/_old/_includes/_touchid-properties-objc.md diff --git a/articles/connections/passwordless/_touchid-properties-swift.md b/articles/connections/passwordless/_old/_includes/_touchid-properties-swift.md similarity index 100% rename from articles/connections/passwordless/_touchid-properties-swift.md rename to articles/connections/passwordless/_old/_includes/_touchid-properties-swift.md diff --git a/articles/connections/passwordless/_touchid-signup-objc.md b/articles/connections/passwordless/_old/_includes/_touchid-signup-objc.md similarity index 100% rename from articles/connections/passwordless/_touchid-signup-objc.md rename to articles/connections/passwordless/_old/_includes/_touchid-signup-objc.md diff --git a/articles/connections/passwordless/_touchid-signup-swift.md b/articles/connections/passwordless/_old/_includes/_touchid-signup-swift.md similarity index 100% rename from articles/connections/passwordless/_touchid-signup-swift.md rename to articles/connections/passwordless/_old/_includes/_touchid-signup-swift.md diff --git a/articles/connections/passwordless/_old/_includes/_using-lock-email.md b/articles/connections/passwordless/_old/_includes/_using-lock-email.md new file mode 100644 index 0000000000..a0626fff45 --- /dev/null +++ b/articles/connections/passwordless/_old/_includes/_using-lock-email.md @@ -0,0 +1,9 @@ +When this code runs, it will ask the user for their email address: + +![](/media/articles/connections/passwordless/passwordless-email-request-${platform}.png) + +Then Auth0 will send to the user an email containing the one-time code: + +![](/media/articles/connections/passwordless/passwordless-email-receive-code-${platform}.png) + +Lastly, the user enters the one-time password into Lock. Then, if the password is correct, the user is authenticated. diff --git a/articles/connections/passwordless/_old/_includes/_using-lock-ios-email.md b/articles/connections/passwordless/_old/_includes/_using-lock-ios-email.md new file mode 100644 index 0000000000..9d12403061 --- /dev/null +++ b/articles/connections/passwordless/_old/_includes/_using-lock-ios-email.md @@ -0,0 +1,53 @@ +<%= include('./_introduction-email', { isMobile: true }) %> + +## Setup + +<%= include('./_setup-email') %> + +## Implementation + +### Using Auth0 Lock + +<%= include('./_introduction-lock', { repository: 'Lock.iOS-OSX', platform: 'iOS', docsUrl: 'lock-ios' }) %> + +
      +<% if (language === "objc") { %> +<%= include('./_email-controller-objc') %> +<% } else { %> +<%= include('./_email-controller-swift') %> +<% } %> +
      + +<%= include('./_using-lock-email', { platform: 'ios' }) %> + +This code will call `onAuthenticationBlock`, where the ID Token, Refresh Token, and user profile are typically stored. Then the user will be allowed to continue to the authenticated part of the application. + +![](/media/articles/connections/passwordless/passwordless-email-enter-code-ios.png) + +### Using your own UI + +If you choose to build your own UI, your code will need to ask the user for their email address first. Then call the following method: + +
      +<% if (language === "objc") { %> +<%= include('./_email-send-code-objc') %> +<% } else { %> +<%= include('./_email-send-code-swift') %> +<% } %> +
      + +After the <passwordless login process begins, ask the user for the one-time code. Then authenticate using that code: + +
      +<% if (language === "objc") { %> +<%= include('./_email-login-objc') %> +<% } else { %> +<%= include('./_email-login-swift') %> +<% } %> +
      + +## Authenticate users with a Magic Link via email + +<%= include('./_introduction-email-magic-link') %> + +Lastly, once the user is authenticated, your app will be able to access the user profile and tokens returned by Auth0. diff --git a/articles/connections/passwordless/_old/_includes/_using-lock-ios-sms.md b/articles/connections/passwordless/_old/_includes/_using-lock-ios-sms.md new file mode 100644 index 0000000000..5d7a6db223 --- /dev/null +++ b/articles/connections/passwordless/_old/_includes/_using-lock-ios-sms.md @@ -0,0 +1,49 @@ +<%= include('./_introduction-sms', { isMobile: true }) %> + +## Setup + +<%= include('./_setup-sms-twilio') %> + +## Implementation + +### Using Auth0 Lock + +<%= include('./_introduction-lock', { repository: 'Lock.iOS-OSX', platform: 'iOS', docsUrl: 'lock-ios' }) %> + +
      +<% if (language === "objc") { %> +<%= include('./_sms-controller-objc') %> +<% } else { %> +<%= include('./_sms-controller-swift') %> +<% } %> +
      + +<%= include('./_using-lock-sms', { platform: 'ios' }) %> + +This code will call `onAuthenticationBlock`, where the ID Token, Refresh Token, and user profile are typically stored. Then the user will be allowed to continue to the authenticated part of the application. + +![](/media/articles/connections/passwordless/passwordless-sms-enter-code-ios.png) + +### Using your own UI + +If you choose to build your own UI, your code will need to ask the user for their phone number first. Then call the following method: + +
      +<% if (language === "objc") { %> +<%= include('./_sms-send-code-objc') %> +<% } else { %> +<%= include('./_sms-send-code-swift') %> +<% } %> +
      + +After the passwordless login process begins, ask the user for the one-time code. Then authenticate using that code: + +
      +<% if (language === "objc") { %> +<%= include('./_sms-login-objc') %> +<% } else { %> +<%= include('./_sms-login-swift') %> +<% } %> +
      + +Lastly, once the user is authenticated, your app will be able to access the user profile and tokens returned by Auth0. diff --git a/articles/connections/passwordless/_old/_includes/_using-lock-ios-touchid.md b/articles/connections/passwordless/_old/_includes/_using-lock-ios-touchid.md new file mode 100644 index 0000000000..01ecc54d1c --- /dev/null +++ b/articles/connections/passwordless/_old/_includes/_using-lock-ios-touchid.md @@ -0,0 +1,100 @@ +A feature specific to iOS is the support for *Touch ID*, which allows users to authenticate with their fingerprint (biometric authentication). + +![](/media/articles/connections/passwordless/passwordless-touchid-start.png) + +During sign-up, the library will generate a key pair on the device, create a user in Auth0, and register the public key for the user: + +![](/media/articles/connections/passwordless/passwordless-touchid-flow.png) + +The private key is stored in the keystore of the device. Each time a user initiates authentication with a valid fingerprint, *Touch ID* retrieves the private key from the keystore, creates a token, signs it with the private key and sends it to Auth0. Auth0 then returns an ID Token, the user profile and, optionally, a Refresh Token. + +::: note +You can use Touch ID with an iPhone 5s or later, an iPad Air 2, or an iPad mini 3 or later. +::: + +## Implementation + +### Using the Auth0 Lock + +<%= include('./_introduction-lock', { repository: 'Lock.iOS-OSX', platform: 'iOS', docsUrl: 'lock-ios' }) %> + +
      +<% if (language === "objc") { %> +<%= include('./_touchid-controller-objc') %> +<% } else { %> +<%= include('./_touchid-controller-swift') %> +<% } %> +
      + +### Using your own UI + +If you choose to build your own UI, you must install our [TouchIDAuth](https://github.com/auth0/TouchIDAuth) library to handle the features specific to *Touch ID*. + +Begin by signing up a user in a Database Connection: + +
      +<% if (language === "objc") { %> +<%= include('./_touchid-signup-objc') %> +<% } else { %> +<%= include('./_touchid-signup-swift') %> +<% } %> +
      + +::: note +You can generate a random password to avoid asking the user for one at this time. The user can change it later. +::: + +Once the user has signed up, use the `idToken` to register the public key for the user. + +First, you will need a place to store an Auth0 API application with the token until you register the key, and a place to store the TouchID component: + +
      +<% if (language === "objc") { %> +<%= include('./_touchid-properties-objc') %> +<% } else { %> +<%= include('./_touchid-properties-swift') %> +<% } %> +
      + +Now implement the following method to perform TouchID authentication: + +
      +<% if (language === "objc") { %> +<%= include('./_touchid-login-method-objc') %> +<% } else { %> +<%= include('./_touchid-login-method-swift') %> +<% } %> +
      + +Then create and store the API application: + +
      +<% if (language === "objc") { %> +<%= include('./_touchid-init-client-objc') %> +<% } else { %> +<%= include('./_touchid-init-client-swift') %> +<% } %> +
      + +Now configure the TouchID Authentication component: + +
      +<% if (language === "objc") { %> +<%= include('./_touchid-configure-component-objc') %> +<% } else { %> +<%= include('./_touchid-configure-component-swift') %> +<% } %> +
      + +Then, to begin authentication, add this line: + +<% if (language === "objc") { %> +```objc +[self.authentication start]; +``` + +<% } else { %> +```swift +self.authentication.start() +``` +<% } %> diff --git a/articles/connections/passwordless/_old/_includes/_using-lock-sms.md b/articles/connections/passwordless/_old/_includes/_using-lock-sms.md new file mode 100644 index 0000000000..74a8f80ca2 --- /dev/null +++ b/articles/connections/passwordless/_old/_includes/_using-lock-sms.md @@ -0,0 +1,9 @@ +When this code runs, it will ask the user for their phone number: + +![](/media/articles/connections/passwordless/passwordless-sms-request-${platform}.png) + +Then Auth0 will use Twilio to send to the user an SMS containing the one-time code: + +![](/media/articles/connections/passwordless/passwordless-sms-receive-code-${platform}.png) + +Lastly, the user enters the one-time password into Lock. Then, if the password is correct, the user is authenticated. diff --git a/articles/connections/passwordless/_old/_includes/_version_warning_auth0js.md b/articles/connections/passwordless/_old/_includes/_version_warning_auth0js.md new file mode 100644 index 0000000000..09a6c3bf1a --- /dev/null +++ b/articles/connections/passwordless/_old/_includes/_version_warning_auth0js.md @@ -0,0 +1,3 @@ +::: version-warning +This document covers a deprecated version of Auth0.js. We recommend that you [migrate to Auth0.js](/libraries/auth0js/v9/migration-guide) as soon as possible. +::: \ No newline at end of file diff --git a/articles/connections/passwordless/_old/email.md b/articles/connections/passwordless/_old/email.md new file mode 100644 index 0000000000..d287606cb7 --- /dev/null +++ b/articles/connections/passwordless/_old/email.md @@ -0,0 +1,36 @@ +--- +title: Implement Passwordless Email Authentication +description: Learn how to authenticate users with either a one-time-code or a magic link sent by SMS. +alias: + - email +seo_alias: email +topics: + - connections + - passwordless + - email +contentType: how-to +useCase: customize-connections +--- + +# Implement Passwordless Email Authentication + +<%= include('./_includes/_introduction-email', { isMobile: false }) %> + +## Setup + +<%= include('./_includes/_setup-email') %> + +## Single-Page Application Tutorials + + - [Authenticate users with a one-time code via email](/connections/passwordless/spa-email-code) + - [Authenticate users with a magic link via email](/connections/passwordless/spa-email-link) + +## Regular Web Application Tutorials + + - [Authenticate users with a one-time code via email](/connections/passwordless/regular-web-app-email-code) + - [Authenticate users with a magic link via email](/connections/passwordless/regular-web-app-email-link) + +## Mobile Tutorials + + - [iOS](/connections/passwordless/ios-email-swift) + - [Android](/connections/passwordless/android-email) diff --git a/articles/connections/passwordless/_old/faq.md b/articles/connections/passwordless/_old/faq.md new file mode 100644 index 0000000000..c627a4fef4 --- /dev/null +++ b/articles/connections/passwordless/_old/faq.md @@ -0,0 +1,139 @@ +--- +title: Passwordless FAQ +topics: + - connections + - passwordless +contentType: reference +useCase: customize-connections +--- +# Passwordless FAQ + +## General Questions + +### Q: When is passwordless authentication the best option for login? How does this feature improve the user experience? + +**A:** The number of passwords that users must remember has become overwhelming, and passwords that aren’t used frequently are often forgotten. When a user forgets their password, they must recover it through email using a process more cumbersome than Auth0’s simple, passwordless user experience. For many users, recovering a lost password for infrequently visited sites and apps is a common and unpleasant experience. + +In a [recent survey](https://www.passwordboss.com/password-habits-survey-part-1/), 59% of users admit to reusing passwords because it is too difficult to remember them all. Although this habit avoids the password recovery scramble, it exposes these users to risk. + +Passwordless login is best for sites and apps where users maintain a presence but don’t visit often enough that they remember a unique password. This could encompass most of the Internet. For these sites, passwordless login creates a much better user experience and better security: no password resets or reuse, and no password database as a target for hackers. + +For frequently visited sites, passwordless authentication offers a streamlined and simple user experience. Many companies, such as Slack and [Medium](https://medium.com/the-story/signing-in-to-medium-by-email-aacc21134fcd), have embraced the passwordless login as more secure than passwords. + +### Q: When is passwordless login not a good idea? What are its limitations? + +**A:** For sites and apps that users access every day, the passwordless flow may feel slower than the muscle memory of quickly entering a memorized password. As with a username/password login, if an email account is hacked or a phone is stolen and unlocked, the passwordless login is compromised, but so is every site not using multi-factor authentication (MFA). + +Websites and web applications are trending toward longer session expirations so that users are not asked to login frequently, behaving more like native apps on a mobile device. Then, when a user initiates a sensitive operation, users are asked for *step-up* authentication such as a one-time password or a code from an authentication app like Google Authenticator. Auth0’s passwordless authentication takes the same approach. Like the `sudo` command on Linux, when the user initiates an activity that requires elevated privileges, they are presented with an extra challenge. Simple and effective, this procedure eliminates the hassle of multi-factor authentication, except when necessary. + +<%= include('./_includes/_single-browser-magic-link') %> + +### Q: Is it difficult for users to become accustomed to passwordless login? + +**A:** Passwordless login is so simple that most users will immediately get it. The user experience is nearly effortless, especially with *magic links* in emails. For most end-users, a passwordless login is easier than recalling a hard-to-remember password. + +### Q: How is passwordless login different from a social login? + +**A:** With a social login, the user is authenticated through a separate account that the user owns. Users need to remember and protect fewer passwords, and the site or app owner doesn’t need to manage any passwords. + +Social logins are appropriate when users are likely to have accounts on popular social providers, and when your application can gain additional features by interacting with the social provider’s API. Auth0 supports a wide range of social providers out-of-the-box with just a few lines of code. However, social logins can be confusing to some users because of the need to login to a different site, and of the grant page which asks for additional permissions to share their data. When users are confused or worried, they might abandon their sign-up. For these users, passwordless login has the advantage of not asking them to share anything except for their email, or phone number for SMS. + +One option is to offer users several popular social logins, and offer passwordless email as an alternative if they don’t have any social accounts or prefer not to use them. + +### Q: How much does passwordless authentication from Auth0 cost? + +**A:** There is no extra charge to use this feature. Passwordless authentication is included free with every Auth0 developer account, subscription, and custom plan. + +## How to use and configure Passwordless + +### Q: What are the advantages of using *magic links*? + +**A:** A *magic link* is a link sent to a user’s email that logs the user into your site or application with a single click. It provides the simplest user experience and makes the login process smooth and friction-free. + +### Q: What are the advantages of using emailed codes? + +**A:** An emailed code requires slightly more effort for end-users than a magic link. A numeric code is sent to the user’s email. The user then types this code into a response field of the Auth0 passwordless Lock widget on your site, which handles this part automatically. Once entered and validated, the user is logged in. + +### Q: What are the advantages of using codes delivered through SMS? + +**A:** Since users often have their phone nearby, SMS messages are likely to be delivered to the user’s hand or pocket. + +An SMS login, like an emailed code, requires slightly more effort for end-users than a *magic link*. Depending on the user’s mobile subscription plan, there may be a fee for them to receive SMS messages or these messages may count against a pool of available free messages. For such users, the added cost of using the SMS side-channel may not be considered worthwhile. + +### Q: Can I offer both email and SMS options at the same time? + +**A:** Using [Auth0’s Javascript SDK](https://github.com/auth0/auth0.js), you have complete control of how passwordless authentication works with your site or application. It’s easy to implement a mixed-mode user experience and build your own UI using the SDK. However, the passwordless Lock widget does not yet support this sort of mixed-mode interface. Such a mode may be added to future versions of the widget. + +### Q: How would a user sign-in to your application using a *magic link* from a device that doesn’t have access to the registered email account? + +**A:** A user may sign-up for your service using passwordless login with their personal email and may want to use that service at work but does not have their personal email account available from their work PC. If they visit the service on their work PC and ask to log in, providing their personal email address, the *magic link* is sent to their personal email account that they cannot access from their work PC. + +The simplest way to solve this problem would be for the user to forward the *magic link* email to their work email account, and click the link from their work PC. They could also create an account with their work email address and link the two accounts, logging in with either of them. + +If this is likely to be a common scenario for your end-users, you might want to consider using emailed codes, or codes sent through SMS, rather than emailed links. + +### Q: How do I style the passwordless Lock widget to my own brand identity? + +**A:** The passwordless Lock widget accepts two parameters to change its appearance: the *primaryColor* option to change background color and the *icon* option to add your brand’s icon. You can also style the widget by modifying the CSS stylesheet. + +If you need more design control, you can implement your own UI and call any of the passwordless connections through the [Auth0 JavaScript SDK](https://github.com/auth0/auth0.js). + +### Q: How do I select which high-volume messaging provider passwordless logins will use? What are my options? + +**A:** By default, your passwordless connections will be set-up to use Auth0’s messaging provider. However, this limits your ability to monitor and manage availability, troubleshoot issues, and connect to analytics. Accordingly, we recommend that you set up your own high-volume email or SMS provider. + +Auth0 supports **Twilio SMS** for passwordless login with codes sent via SMS, and **SendGrid**, **Mandrill**, and **Amazon SES** for email-based passwordless authentication. These providers are all supported in the Auth0 Dashboard. All you need are your API credentials. + +### Q: Can I configure a different messaging provider than the ones you support directly? + +**A:** Currently, it is supported only for codes sent via SMS. To learn more about how to configure your own SMS gateway to handle the delivery of those codes, see [Set Up Custom SMS Gateway for Passwordless Connections](/connections/passwordless/sms-gateway). + +### Q: How can I use Passwordless as another factor in multi-factor authentication? + +**A:** While Auth0’s passwordless connections (including SMS and email) are not built into the Auth0 Dashboard MFA capability at this time, Auth0’s flexible [rules execution pipeline](/rules) make it easy to use these passwordless authentication methods as part of an MFA flow. Rules are snippets of JavaScript that execute on the Auth0 server as part of the authentication pipeline and give you the flexibility to call APIs or perform arbitrary computations in order to implement customized authentication logic. Simply call the passwordless connection using a redirect rule, and treat it as a [custom MFA provider](/mfa). + +In future versions of passwordless connections, supported MFA providers will be built-in. + +### Q: What happens if a user changes email or phone number? + +**A:** A self-service method for changing email or phone number is not included in this version of passwordless authentication. An administrator can change this information using the Auth0 Dashboard. + +## Security + +### Q: What if someone gains access to a user’s email address? + +**A:** If someone gains access to a user’s email account, they will be able to log in with the user’s passwordless email login with either a link or a code. This is no different than for password-protected accounts, which use email as the back channel for password resets. Typically, you protect against this risk by enabling multi-factor authentication when your application detects activity that appears suspicious such as logging in from a new device, an unknown IP address, or outside the user’s country of residence. + +### Q: What if someone gains access to a user’s SMS messages? + +**A:** As with email, if a user’s SMS messages are compromised, someone can log in as the user with SMS codes. Many phones now have built-in protections against theft, such as fingerprint readers, complex unlock codes, and remote disable and wipe features. The best protection against this risk on your site or application is to use multi-factor authentication, requiring additional *step-up* authentication when the user tries to access sensitive data or perform sensitive actions. + +### Q: How does the system prevent an intercepted one-time code or link from being used to establish an unauthorized session? + +**A:** Think of an intercepted code or link as similar to a compromised email account or stolen phone. Once the link or code is in the wrong hands, it can be used to log in as that user. But codes and links have a short time-to-live (typically 5 minutes) and can only be used once. This limits the opportunity for a hacker to use an intercepted communication to a brief window. Security experts strongly recommend using encrypted end-to-end communication between email servers and applications to prevent the easy interception of email, and you might recommend this safeguard to your end users as part of your documentation. Implementation of multi-factor *step-up* authentication for sensitive data or actions will reduce this risk as well. + +### Q: How could I use Passwordless sign in with *step-up* multi-factor authentication to improve security for more sensitive data or actions? + +**A:** Auth0 features powerful [rules](/rules) - JavaScript snippets which run during the authentication process on the Auth0 server, and allow you to insert additional authentication elements when potentially high-risk logins are detected. For instance, if your application detects a user logging in from a previously unknown IP address with a location outside of the user’s home country, your application might request a password. + +In future versions of passwordless logins, support for multi-factor *step-up* authentication will be added as part of the passwordless configuration options, replacing the use of rules to implement this security enhancement. + +### Q: Since users can click a link to log in, how can I prevent a phishing attack in which the user receives a fraudulent email that appears legitimate, but contains a link to a site that tricks them into giving up their credentials? + +**A:** Phishing attacks are about stealing credentials (user-names and passwords) through trickery. If there are no passwords to steal, these attacks will become less common. Passwordless logins are a big step in reducing the prevalence of phishing. + +Since passwordless email logins with *magic links* include a link in the email that logs a user into your site, a hacker could use it to create a fraudulent imitation of your legitimate email to trick unsuspecting users into divulging their account credentials for some other site, like their email account. + +There are several effective ways to reduce this risk. One is through education. The email to your users might include a warning not to click the link unless they recently requested to log in, and a notice that they will never be asked for any password when logging into your site. + +Another way is to apply best practices for email authentication when using this feature. There are popular and effective standards for verifying email authenticity including **SPF**, **DKIM**, and **DMARC**. We strongly recommend utilizing these capabilities by [configuring your own email provider](/email) when you set up passwordless logins, including setting up [SPF and DKIM records](/email#spf-configuration). Your email provider may have more detailed information on email authentication and availability for you to explore. + +Since you are using Auth0 passwordless logins, there are no passwords to phish, and phishing attacks cannot compromise the credentials to your site or application. This is great news. Whenever email is a component of an authentication flow however, there is always the potential for phishing (if only for harvesting the credentials of other sites). Passwordless email authentication protects your brand and online reputation, while foiling scammers. + +### Q: How does the system protect against brute-force attacks (code guessing)? + +**A:** The 6-digit numeric codes are one-time use and expire in a short time (5 minutes by default). In addition, Auth0 includes rate-limiting and IP address blocking after several failed attempts. Accordingly, it is impractical to brute-force guess these codes. The application owner will be notified by email of any attempt and can unblock the IP address for a legitimate user. + +### Q: Our company uses an email security system that scans URLs and invalidates the token. What can we do? + +**A:** The only solution to this is to ask your users to whitelist the passwordless emails. diff --git a/articles/connections/passwordless/_old/ios-magic-link.md b/articles/connections/passwordless/_old/ios-magic-link.md new file mode 100644 index 0000000000..23b6c3bce6 --- /dev/null +++ b/articles/connections/passwordless/_old/ios-magic-link.md @@ -0,0 +1,94 @@ +--- +title: Lock iOS v1 Passwordless Magic Links +description: Using Passwordless Magic Links with Lock for iOS v1 +public: false +topics: + - connections + - passwordless + - email + - ios + - magic-links +contentType: how-to +useCase: customize-connections +--- + +# Lock iOS v1: Passwordless with Magic Link + +<%= include('../../_includes/_native_passwordless_warning') %> + +Using [Lock v1 for iOS](/libraries/lock-ios/v1), you can implement a Passwordless login flow using Magic Link authentication for your iOS applications. + +::: note +Before beginning this tutorial, [enable Universal Links](/dashboard/guides/applications/enable-universal-links) between your iOS application and Auth0 Application. +::: + +## Set Up Universal Link domains for your iOS app + +iOS needs to know which domains your application handles. To configure this: + +1. Go to your project's Xcode settings page and open the *Capabilities* tab. +2. Find the *Associated Domains* section, and move the slider (located near the top right) so that it displays **On**. This enables the use of Associated Domains. +3. Click on the **plus sign** to add your Auth0 Application's domain. You'll need to use the following format: `applinks:${account.namespace}` + +<%= include('./_includes/_custom-domains') %> + +![Associated Domains](/media/articles/connections/passwordless/associated-domains.png) + +## Pass callbacks to Lock + +::: note +If you've already implemented Lock v1 for iOS, you have already configured callbacks to the Auth0 Lock Library. +::: + +In the `AppDelegate` class of your iOS application, include the following code to pass callbacks to Auth0 Lock: + +```swift + +@UIApplicationMain +class AppDelegate: UIResponder, UIApplicationDelegate { + + var window: UIWindow? + + func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]? = nil) -> Bool { + A0Lock.sharedLock().applicationLaunchedWithOptions(launchOptions) + return true + } + + func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool { + return A0Lock.sharedLock().handleURL(url, sourceApplication: app) + } + + func application(_ application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void) -> Bool { + return A0Lock.sharedLock().continueUserActivity(userActivity, restorationHandler: restorationHandler) + } +} + +``` + +### Enable Magic Link login strategy + +Because the Lock library handles the login flow, you'll indicate that it should use a Magic Link. To do this, you'll place the following code into the view controller that presents the Lock login screen: + +```swift +let lock = A0Lock.sharedLock() +let controller = lock.newEmailViewController() + +controller.useMagicLink = true // <--- ENABLE MAGIC LINKS! + +controller.onAuthenticationBlock = { (profile, token) in + // Do something with profile and token if necessary + self.dismissViewControllerAnimated(true, completion: { self.performSegueWithIdentifier("UserLoggedIn", sender: self) }) +} +lock.presentEmailController(controller, fromController: self) +``` + +* The `newEmailViewController` creates an email login view controller. +* Setting `userMagicLink` to `true` tells the email login view controller to use the Magic Link. + +### Test notes + +* Because Universal Links do not work on iOS simulators, you'll need an iOS-enabled device to test this implementation. +* When testing, do not use the Gmail app to open the email that contains the Magic Link. Gmail opens links internally or using Chrome, both of which bypass the detection of the Universal Link by iOS. + +<%= include('./_includes/_single-browser-magic-link') %> + diff --git a/articles/connections/passwordless/_old/ios-sms-objc.md b/articles/connections/passwordless/_old/ios-sms-objc.md new file mode 100644 index 0000000000..0033da04fd --- /dev/null +++ b/articles/connections/passwordless/_old/ios-sms-objc.md @@ -0,0 +1,23 @@ +--- +title: Using Passwordless Authentication on iOS with SMS +languages: + - name: Swift + url: swift + - name: Objective-C + url: objc +topics: + - connections + - passwordless + - sms + - ios + - objective-c +contentType: how-to +useCase: customize-connections +--- +# Using Passwordless on iOS with SMS + + + +<%= include('../../_includes/_native_passwordless_warning') %> + +<%= include('./_includes/_using-lock-ios-sms', { language: 'objc' }) %> diff --git a/articles/connections/passwordless/_old/ios-sms-swift.md b/articles/connections/passwordless/_old/ios-sms-swift.md new file mode 100644 index 0000000000..b440775ca9 --- /dev/null +++ b/articles/connections/passwordless/_old/ios-sms-swift.md @@ -0,0 +1,23 @@ +--- +title: Using Passwordless Authentication on iOS with SMS in Swift +languages: + - name: Swift + url: swift + - name: Objective-C + url: objc +topics: + - connections + - passwordless + - sms + - ios + - swift +contentType: how-to +useCase: customize-connections +--- +# Using Passwordless on iOS with SMS + + + +<%= include('../../_includes/_native_passwordless_warning') %> + +<%= include('./_includes/_using-lock-ios-sms', { language: 'swift' }) %> diff --git a/articles/connections/passwordless/_old/regular-web-app-email-code.md b/articles/connections/passwordless/_old/regular-web-app-email-code.md new file mode 100644 index 0000000000..a2b895b470 --- /dev/null +++ b/articles/connections/passwordless/_old/regular-web-app-email-code.md @@ -0,0 +1,121 @@ +--- +title: Implement Passwordless Email in Regular Web Apps +description: Learn how to authenticate users with a one-time code sent by email in a regular web apps. +toc: true +topics: + - connections + - web-apps + - passwordless + - email +contentType: how-to +useCase: customize-connections +--- +# Implement Passwordless Email in Regular Web Apps + +<%= include('./_includes/_call-from-client-side') %> + +<%= include('./_includes/_introduction-email', { isMobile: false }) %> + +## Setup + +<%= include('./_includes/_setup-email') %> + +<%= include('./_includes/_setup-callback', {spa:false} )%> + +## Implementation + +### Use Lock (the Auth0 UI widget) + +<%= include('./_includes/_init-passwordless-lock') %> + +Then you can trigger the login using the `callbackURL` option to specify the endpoint that will handle the server-side authentication: + +```html + + + +Login +``` + +<%= include('./_includes/_custom-domains') %> + +This will open a dialog that asks the user for their email address: + +![](/media/articles/connections/passwordless/passwordless-email-request-web.png) + +Then Auth0 will send an email to the user containing the one-time code: + +![](/media/articles/connections/passwordless/passwordless-email-receive-code-web.png) + +Lock will ask for the code that has been emailed to the provided address. The code can then be used as a one-time password to log in: + +![](/media/articles/connections/passwordless/passwordless-email-enter-code-web.png) + +Once the user enters the code received by email, Lock will authenticate the user and redirect to the specified `callbackURL`. + +::: note +You can follow any of the [Regular Web App Quickstarts](/quickstart/webapp) to see how to handle the server-side authentication callback. +::: + +### Use your own UI + +You can perform passwordless authentication in your regular web app with your own custom UI using the [Auth0 JavaScript application library](/libraries/auth0js). + +<%= include('./_includes/_init-auth0js_v9', {redirectUri:true} ) %> + +You must provide a way for the user to enter a address to which the email will be sent. Then you can begin the passwordless authentication as follows (assuming the name of your form input as `input.email`): + +```js +function sendEmail(){ + var email = $('input.email').val(); + + webAuth.passwordlessStart({ + connection: 'email', + send: 'code', + email: email + }, function (err,res) { + if (err) { + // Handle error + } + // Hide the input and show the code entry screen + $('.enter-email').hide(); + $('.enter-code').show(); + }); +} +``` + +This will send an email to the provided address. The user must now enter the code they received into your custom UI. Then you can continue with the login as follows (assuming the name of your form inputs as `input.email` and `input.code`): + +```js +function login(){ + var email = $('input.email').val(); + var code = $('input.code').val(); + + webAuth.passwordlessLogin({ + connection: 'email', + email: email, + verificationCode: code + }, function (err,res) { + if (err) { + // Handle error + } + }); +}; +``` + +If authentication is successful, the user will be redirected to the `redirectUri` specified in the Auth0 constructor. + +Check out the [Auth0.js SDK reference documentation](/libraries/auth0js) for more information. diff --git a/articles/connections/passwordless/_old/regular-web-app-email-link.md b/articles/connections/passwordless/_old/regular-web-app-email-link.md new file mode 100644 index 0000000000..05014f9095 --- /dev/null +++ b/articles/connections/passwordless/_old/regular-web-app-email-link.md @@ -0,0 +1,95 @@ +--- +title: Implement Passwordless Email with Magic Links in Regular Web Apps +description: Learn how to authenticate users with a magic link sent by email in a regular web application. +toc: true +topics: + - connections + - web-apps + - passwordless + - email +contentType: how-to +useCase: customize-connections +--- +# Implement Passwordless Email with Magic Links in Regular Web Apps + +<%= include('./_includes/_call-from-client-side') %> + +<%= include('./_includes/_introduction-email-magic-link') %> + +## Setup + +<%= include('./_includes/_setup-email') %> + +<%= include('./_includes/_setup-callback', {spa:false} ) %> + +## Implementation + +### Use Lock (the Auth0 UI widget) + +<%= include('./_includes/_init-passwordless-lock') %> + +Then you can trigger the login using the `callbackURL` option to specify the endpoint that will handle the authentication on the server-side: + +```html + + +Login +``` + +<%= include('./_includes/_custom-domains') %> + +This will open a dialog that asks the user for their email address. + +![](/media/articles/connections/passwordless/passwordless-email-request-web.png) + +Then Auth0 will send an email to the user containing the magic link. After clicking the link, the user will be signed in to your application automatically and redirected to the specified `callbackURL`. + +<%= include('./_includes/_single-browser-magic-link') %> + + +::: note +You can follow any of the [Regular Web App Quickstarts](/quickstart/webapp) to see how to handle the authentication callback server side. +::: + +### Use your own UI + +You can perform passwordless authentication in your regular web app with your own custom UI using the [Auth0 JavaScript application library](/libraries/auth0js). + +<%= include('./_includes/_init-auth0js_v9', {redirectUri:true} ) %> + +You must provide a way for the user to enter an email to which the magic link will be sent. Then you can begin the passwordless authentication as follows (assuming the name of your form input as `input.email`): + +```js +function sendEmail(){ + var email = $('input.email').val(); + + webAuth.passwordlessStart({ + connection: 'email', + send: 'link', + email: email + }, function (err,res) { + if (err) { + // Handle error + } + // Hide the input and show a "Check your email for your login link!" screen + $('.enter-email').hide(); + $('.check-email').show(); + }); +} +``` + +This will send an email containing the magic link. After clicking the link, the user will be automatically signed in and redirected to the `redirectUri` which can be specified in the Auth0 constructor. + +Check out the [Auth0.js SDK reference documentation](/libraries/auth0js) for more information. diff --git a/articles/connections/passwordless/_old/regular-web-app-sms.md b/articles/connections/passwordless/_old/regular-web-app-sms.md new file mode 100644 index 0000000000..20165ed166 --- /dev/null +++ b/articles/connections/passwordless/_old/regular-web-app-sms.md @@ -0,0 +1,122 @@ +--- +title: Implement Passwordless SMS in Regular Web Apps +description: Learn how to authenticate users with a one-time code sent by SMS in a regular web application. +toc: true +topics: + - connections + - web-apps + - passwordless + - sms +contentType: how-to +useCase: customize-connections +--- +# Implement Passwordless SMS in Regular Web Apps + +<%= include('./_includes/_call-from-client-side') %> + +<%= include('./_includes/_introduction-sms', { isMobile: false }) %> + +## Setup + +<%= include('./_includes/_setup-sms-twilio') %> + +<%= include('./_includes/_setup-callback', {spa:false} ) %> + +## Implementation + +### Use Lock + +<%= include('./_includes/_init-passwordless-lock') %> + +Then you can trigger the login widget with the following code: + +```html + + +Login +``` + +<%= include('./_includes/_custom-domains') %> + +This will open a dialog that asks the user for their phone number. + +![](/media/articles/connections/passwordless/passwordless-sms-enter-phone-web.png) + +Then Auth0 will use Twilio to send an SMS to the user containing the one-time code: + +
      SMS one-time code
      + +Lock will ask for the code that has been sent to the provided number via SMS. The code can then be used as a one-time password to log in: + +![](/media/articles/connections/passwordless/passwordless-sms-enter-code-web.png) + +Once the user enters the code received via SMS, Lock will authenticate the user and redirect to the specified `callbackURL`. + +::: note +You can follow any of the [Regular Web App Quickstarts](/quickstart/webapp) to see how to handle the server-side authentication callback. +::: + +### Use your own UI + +You can perform passwordless authentication in your regular web app with your own custom UI using the [Auth0 JavaScript application library](/libraries/auth0js). + +<%= include('./_includes/_init-auth0js_v9', {redirectUri:true} ) %> + +You must provide a way for the user to enter a phone number to which the SMS will be sent. Then you can begin the passwordless authentication as follows (assuming the name of your form input as `input.phone-number`): + +```js +function sendSMS(){ + var phone = $('input.phone-number').val(); + + webAuth.passwordlessStart({ + connection: 'sms', + send: 'code', + phoneNumber: phone + }, function (err,res) { + if (err) { + // Handle error + } + // Hide the input and show the code entry screen + $('.enter-phone').hide(); + $('.enter-code').show(); + }); +} +``` + +This will send an SMS to the provided phone number. The user must now enter the code they received into your custom UI. Then you can continue with the login as follows (assuming the name of your form inputs as `input.phone-number` and `input.code`): + +```js +function login(){ + var phone = $('input.phone-number').val(); + var code = $('input.code').val(); + + webAuth.passwordlessLogin({ + connection: 'sms', + phoneNumber: phone, + verificationCode: code + }, function (err,res) { + if (err) { + // Handle error + } + }); +}; +``` + +If authentication is successful, the user will be redirected to the `redirectUri` specified in the Auth0 constructor. + +::: note +You can follow up with any of the [Regular Web App Quickstarts](/quickstart/webapp) to see how to handle the authentication callback on the server-side. +::: + +Check out the [Auth0.js SDK reference documentation](/libraries/auth0js) for more information. diff --git a/articles/connections/passwordless/_old/regular-web-app.md b/articles/connections/passwordless/_old/regular-web-app.md new file mode 100644 index 0000000000..6a2eaf2ed5 --- /dev/null +++ b/articles/connections/passwordless/_old/regular-web-app.md @@ -0,0 +1,21 @@ +--- +title: Implement Passwordless in Regular Web Apps +description: Learn how to authenticate users without using a password in a regular web application. +topics: + - connections + - web-apps + - passwordless +contentType: how-to +useCase: customize-connections +--- +# Implement Passwordless in Regular Web Apps + +<%= include('./_includes/_call-from-client-side') %> + +<%= include('./_includes/_introduction', { withFingerprint: false }) %> + +## Tutorials for Regular Web Apps + + - [Authenticate users with a one-time code via SMS](/connections/passwordless/regular-web-app-sms) + - [Authenticate users with a one-time code via email](/connections/passwordless/regular-web-app-email-code) + - [Authenticate users with a magic link via email](/connections/passwordless/regular-web-app-email-link) diff --git a/articles/connections/passwordless/_old/spa-email-code.md b/articles/connections/passwordless/_old/spa-email-code.md new file mode 100644 index 0000000000..782f061763 --- /dev/null +++ b/articles/connections/passwordless/_old/spa-email-code.md @@ -0,0 +1,148 @@ +--- +title: Implement Passwordless Email in Single-Page Apps +description: Learn how to authenticate users with a one-time code sent by email in a Single-Page Application (SPA). +topics: + - connections + - passwordless + - spa + - email +contentType: how-to +useCase: customize-connections +--- +# Implement Passwordless Email in Single-Page Apps + +<%= include('./_includes/_introduction-email', { isMobile: false }) %> + +## Setup + +<%= include('./_includes/_setup-email') %> + +<%= include('./_includes/_setup-cors') %> + +## Implementation + +### Use Lock (the Auth0 UI widget) + +<%= include('./_includes/_init-passwordless-lock') %> + +Then you can trigger the login with the following code: + +```html + + +Login +``` + +<%= include('./_includes/_custom-domains') %> + +First, this will open a dialog that asks the user for their email address: + +![](/media/articles/connections/passwordless/passwordless-email-request-web.png) + +Then Auth0 will send an email to the user containing the one-time code: + +![](/media/articles/connections/passwordless/passwordless-email-receive-code-web.png) + +Lock will ask for the code that has been emailed to the provided address. The code can then be used as a one-time password to log in. + +![](/media/articles/connections/passwordless/passwordless-email-enter-code-web.png) + +Once the user enters the code received by email, Lock will authenticate them and call the callback function where the ID Token and profile will be available. + +### Use your own UI + +You can perform passwordless authentication in your SPA with your own custom UI using the [Auth0 JavaScript SDK](/libraries/auth0js). + +<%= include('./_includes/_init-auth0js_v9', {redirectUri:true} ) %> + +Be sure to provide a `redirectUri` and to set the `responseType: 'token'`. + +You must provide a way for the user to enter a address to which the email will be sent. Then you can begin the passwordless authentication as follows (assuming the name of your form input as `input.email`): + +```js +function sendEmail(){ + var email = $('input.email').val(); + + webAuth.passwordlessStart({ + connection: 'email', + send: 'code', + email: email + }, function (err,res) { + if (err) { + // Handle error + } + // Hide the input and show the code entry screen + $('.enter-email').hide(); + $('.enter-code').show(); + }); +} +``` + +This will send an email to the provided address. The user must now enter the code they received into your custom UI. Then you can continue with the login as follows (assuming the name of your form inputs as `input.email` and `input.code`): + +```js +function login(){ + var email = $('input.email').val(); + var code = $('input.code').val(); + + webAuth.passwordlessLogin({ + connection: 'email', + email: email, + verificationCode: code + }, function (err,res) { + if (err) { + // Handle error + } + // If successful, save the user's token and proceed + }); +}; +``` + +The `passwordlessVerify` method will verify the Passwordless transaction, then redirect the user back to the `redirectUri` that was set. You will then need to parse the URL hash in order to acquire the token, and then call the `client.userInfo` method to acquire your user's information, as in the following example: + +```js +$(document).ready(function() { + if(window.location.hash){ + webAuth.parseHash({hash: window.location.hash}, function(err, authResult) { + if (err) { + return console.log(err); + } else if (authResult){ + localStorage.setItem('accessToken', authResult.accessToken); + webAuth.client.userInfo(authResult.accessToken, function(err, user) { + if (err){ + console.log('err',err); + alert('There was an error retrieving your profile: ' + err.message); + } else { + // Hide the login UI, show a user profile element with name and image + $('.login-box').hide(); + $('.logged-in-box').show(); + localStorage.setItem('user', user); + $('.nickname').text(user.nickname); + $('.avatar').attr('src', user.picture); + } + }); + } + }); + } +}); +``` + +Check out the [Auth0.js SDK reference documentation](/libraries/auth0js) for more information. diff --git a/articles/connections/passwordless/_old/spa-email-link.md b/articles/connections/passwordless/_old/spa-email-link.md new file mode 100644 index 0000000000..80cb29cf2d --- /dev/null +++ b/articles/connections/passwordless/_old/spa-email-link.md @@ -0,0 +1,110 @@ +--- +title: Implement Passwordless Email with Magic Links in Single-Page Apps +description: Learn how to authenticate users with a magic link sent by email in a Single-Page Application (SPA). +topics: + - connections + - passwordless + - email + - spa +contentType: how-to +useCase: customize-connections +--- +# Implement Passwordless Email with Magic Links in Single-Page Apps + +<%= include('./_includes/_introduction-email-magic-link') %> + +## Setup + +<%= include('./_includes/_setup-email') %> + +<%= include('./_includes/_setup-callback', {spa:true} ) %> + +## Implementation + +### Use Lock (the Auth0 UI widget) + +<%= include('./_includes/_init-passwordless-lock') %> + +Then you can trigger the passwordless authentication using a magic link with the following code: + +```html + + + + +Login +``` + +<%= include('./_includes/_custom-domains') %> + +The user will receive an email with the magic link. Once the user clicks on this link, Auth0 will handle the authentication and redirect back to the application. + +::: note +You can follow any of the [Single-Page App Quickstarts](/quickstart/spa) to see more about using Auth0.js in a SPA. +::: + +### Use your own UI + +You can perform passwordless authentication with a magic link in your single-page application using your own UI with the [Auth0 JavaScript client library](/libraries/auth0js). + +<%= include('./_includes/_init-auth0js_v9', {redirectUri:true} ) %> + +You must provide a way for the user to enter an email to which the magic link will be sent. Then you can begin the passwordless authentication as follows (assuming the name of your form input as `input.email`): + +```js +function sendEmail(){ + var email = $('input.email').val(); + + webAuth.passwordlessStart({ + connection: 'email', + send: 'link', + email: email + }, function (err,res) { + if (err) { + // Handle error + } + // Hide the input and show a "Check your email for your login link!" screen + $('.enter-email').hide(); + $('.check-email').show(); + }); +} +``` + +This will send an email containing the magic link. After clicking the link, the user will be automatically signed in and redirected to the `redirectUri` which can be specified in the Auth0 constructor, where you will need to parse the token with `webAuth.parseHash`: + +```js +//parse hash on page load +$(document).ready(function(){ + 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 + }); + }); +}); +``` + +<%= include('./_includes/_single-browser-magic-link') %> + + +Check out the [Auth0.js SDK reference documentation](/libraries/auth0js) for more information. diff --git a/articles/connections/passwordless/_old/user-guide.md b/articles/connections/passwordless/_old/user-guide.md new file mode 100644 index 0000000000..e5889bda96 --- /dev/null +++ b/articles/connections/passwordless/_old/user-guide.md @@ -0,0 +1,58 @@ +--- +title: Passwordless Authentication User Guide +topics: + - connections + - passwordless +contentType: + - concept + - how-to + - reference +useCase: customize-connections +--- +# User Guide: Passwordless + +If you are using an app that allows for **Passwordless** authentication, you can register using either your **email address** or your **mobile phone number** instead of a login/password combination. Depending on which piece of information you provide, you will then access the app using a link that has been emailed to you or by providing a code that has been emailed or sent to you via SMS. + +* [Register and Authenticate Using Email](#register-and-authenticate-using-email) +* [Register and Authenticate Using SMS](#register-and-authenticate-using-sms) +* [Troubleshooting](#troubleshooting) + +## Register and Authenticate Using Email + +![](/media/articles/connections/passwordless/passwordless-email-request-web.png) + +If you provide your **email address**, you will receive an email containing either: + +* a link you click on to authenticate yourself, or; +* a code you provide to the app to authenticate yourself. + +### Authentication Using a Magic Link Received via Email + +You may opt to register and authenticate yourself using a magic link sent via email. Upon receipt, you will need to click on the link to access the app. + +![](/media/articles/connections/passwordless/passwordless-email-receive-link.png) + +<%= include('./_includes/_single-browser-magic-link') %> + + +### Authentication Using a One-time Use Code Received via Email + +You may opt to register and authenticate yourself using a one-time use code that you receive via email. + +![](/media/articles/connections/passwordless/passwordless-email-receive-code-web.png) + +Once received, you can return to the app to enter the code and authenticate yourself. + +![](/media/articles/connections/passwordless/passwordless-email-enter-code-web.png) + +## Register and Authenticate Using SMS + +![](/media/articles/connections/passwordless/passwordless-sms-enter-phone-web.png) + +If you provide your **mobile phone number**, you will receive a code that you will provide to the app to validate yourself. + +
      SMS one-time code
      + +The code can then be used as a one-time password to log in. + +![](/media/articles/connections/passwordless/passwordless-sms-enter-code-web.png) diff --git a/articles/connections/passwordless/_setup-callback.md b/articles/connections/passwordless/_setup-callback.md deleted file mode 100644 index cf6e83f437..0000000000 --- a/articles/connections/passwordless/_setup-callback.md +++ /dev/null @@ -1,3 +0,0 @@ -#### 4. Configure Callback URL - -For security purposes, you must to add <% if(spa){ %>your page's URL<%} else {%>the callbackURL<%}%> to the list of **Allowed callback URLs** in your app's [Settings Section](${manage_url}/#/applications) of the Dashboard. diff --git a/articles/connections/passwordless/_setup-cors.md b/articles/connections/passwordless/_setup-cors.md deleted file mode 100644 index cdbc476ca9..0000000000 --- a/articles/connections/passwordless/_setup-cors.md +++ /dev/null @@ -1,3 +0,0 @@ -#### 4. Configure CORS - -For security purposes, you must add your app's *origin URL* to the list of **Allowed Origins (CORS)** in your app's [Settings Section](${manage_url}/#/applications) of the Dashboard, unless this *origin URL* has been already added to the **Allowed callback URLs** list. diff --git a/articles/connections/passwordless/_setup-email.md b/articles/connections/passwordless/_setup-email.md deleted file mode 100644 index 3d9f404851..0000000000 --- a/articles/connections/passwordless/_setup-email.md +++ /dev/null @@ -1,37 +0,0 @@ -#### 1. Optional: Configure an email provider - -By default, Auth0 sends the email from its own messaging provider. Optionally, you can [configure your own email provider](/email/providers) to better monitor and troubleshoot the email service. - -#### 2. Configure the connection - -In the Dashboard, on the **Email** page, under [Connections > Passwordless](${manage_url}/#/connections/passwordless), you can configure the contents and behavior of the email. - -![](/media/articles/connections/passwordless/passwordless-email-config.png) - -##### Multi-Language Support - -The Message area supports usage of multiple languages. - -By making a call to the [/passwordless/start](/api/authentication/reference#get-code-or-link) authentication endpoint, you can set the value of an 'x-request-language' header to the language of your choice. If the value of this header is not set, the language will be extracted from the value in the 'accept-language' header that is automatically set by the browser. - -The Message area accepts Liquid syntax. You can use this syntax, combined with exposed parameter values, to programmatically construct elements of the message. For example, you can reference the `request_language` parameter to change the language of the message: - -```text -{% if request_language contains 'dutch' %} - Hier is uw verificatie code: {{ code }} -{% endif %} - -{% if request_language contains 'fr-FR' %} - Ceci est votre code: {{ code }} -{% endif %} -``` - -The following parameters are available when defining the template: - -| Exposed Parameter | Description | -|:------------------|:---------| -| `code` | the password to use | -| `link` | the magic link | -| `application.name` | the name of the application name where the user is signing up | -| `request_language` | the requested language for the message content | -| `operation` | equals `change_email` when the template is triggered by an update to a user's email via the API, otherwise null | diff --git a/articles/connections/passwordless/_setup-sms-twilio.md b/articles/connections/passwordless/_setup-sms-twilio.md deleted file mode 100644 index 4041b8a3d7..0000000000 --- a/articles/connections/passwordless/_setup-sms-twilio.md +++ /dev/null @@ -1,55 +0,0 @@ -#### 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. - -#### 2. Configure the connection - -In the Dashboard under [Connections > Passwordless](${manage_url}/#/connections/passwordless), set the SMS slider to the right to enable the SMS Passwordless feature. - -Enter your **Twilio Account SID** and **Twilio Auth Token** in the appropriate fields. - -**NOTE**: For information on obtaining a Twilio SID and Auth Token, see: [How to create an Application SID](https://www.twilio.com/help/faq/twilio-basics/what-is-an-application-sid) and [Auth Tokens and how to change them](https://www.twilio.com/help/faq/twilio-basics/what-is-the-auth-token-and-how-can-i-change-it). - -Select the **SMS Source** that users will see as the sender of the SMS. - -**NOTE**: For information on using Copilot, see: [Sending Messages with Copilot](https://www.twilio.com/docs/api/rest/sending-messages-copilot). - -Enter either your **Twilio Messaging Service SID** or a **From** phone number, depending on the **SMS Source** selected above. - -Lastly, enter the **Message** that will appear in the body of the SMS. - -**NOTE:** The `@@password@@` placeholder in the Message will be automatically replaced with the one-time password that is sent to the user. - -Click **SAVE**. - -![](/media/articles/connections/passwordless/passwordless-sms-config.png) - -##### Multi-Language Support - -The Message area supports usage of multiple languages. - -By making a call to the [/passwordless/start](/api/authentication/reference#get-code-or-link) authentication endpoint, you can set the value of an 'x-request-language' header to the language of your choice. If the value of this header is not set, the language will be extracted from the value in the 'accept-language' header that is automatically set by the browser. - -The Message area accepts Liquid syntax. You can use this syntax, combined with exposed parameter values, to programmatically construct elements of the message. For example, you can reference the `request_language` parameter to change the language of the message: - -```text -{% if request_language contains 'dutch' %} - Hier is uw verificatie code: {{ password }} -{% endif %} - -{% if request_language contains 'fr-FR' %} - Ceci est votre code: {{ password }} -{% endif %} -``` -The following paramaters are available when defining the template: - -| Exposed Parameter | Description | -|:------------------|:---------| -| `password` or `code` | the password to use | -| `phone_number` | the user's phone number | -| `application.name` | the name of the application name where the user is signing up | -| `request_language` | the requested language for the message content | - -#### 3. Enable your apps - -Go to the **Apps** tab of the SMS settings and enable the apps for which you would like to use Passwordless SMS. diff --git a/articles/connections/passwordless/_touchid-configure-component-objc.md b/articles/connections/passwordless/_touchid-configure-component-objc.md deleted file mode 100644 index e88e9ec8ed..0000000000 --- a/articles/connections/passwordless/_touchid-configure-component-objc.md +++ /dev/null @@ -1,45 +0,0 @@ -```objc -NSString *device = [[[UIDevice currentDevice] identifierForVendor] UUIDString]; -NSString *userId = profile.userId; - -A0TouchIDAuthentication *authentication = [[A0TouchIDAuthentication alloc] init]; -authentication.registerPublicKey = ^(NSData *pubKey, A0RegisterCompletionBlock completed, A0ErrorBlock errored) { - void(^registerBlock)() = ^{ - [self.userClient registerPublicKey:pubKey device:device user:userId success:^{ - completed(); - } failure:^(NSError *error) { - errored(error); - }]; - }; - [self.userClient removePublicKeyOfDevice:device user:userId success:^{ - registerBlock(); - } failure:^(NSError *error) { - registerBlock(); - }]; -}; - -authentication.jwtPayload = ^{ - return @{ - @"iss": userId, - @"device": device, - }; -}; - -authentication.authenticate = ^(NSString *jwt, A0ErrorBlock block) { - A0AuthParameters *parameters = [A0AuthParameters newWithDictionary:@{ - A0ParameterConnection: @"{NAME_OF_MY_DB_CONNECTION}", - A0ScopeProfile: @"openid name email nickname" - }]; - - [client loginWithIdToken:jwt deviceName:deviceName parameters:parameters success:^(A0UserProfile *profile, A0Token *token) { - // User is authenticated with Auth0 & TouchID - } failure:^(NSError *error){ - block(error); - }]; -}; -authentication.onError = ^(NSError *error) { - // Handle authentication error -}; - -self.authentication = authentication; -``` diff --git a/articles/connections/passwordless/_touchid-configure-component-swift.md b/articles/connections/passwordless/_touchid-configure-component-swift.md deleted file mode 100644 index 7171d7fe23..0000000000 --- a/articles/connections/passwordless/_touchid-configure-component-swift.md +++ /dev/null @@ -1,45 +0,0 @@ -```swift -let device = UIDevice.currentDevice().identifierForVendor().UUIDString() -let userId = profile!.userId - -let authentication = A0TouchIDAuthentication() -authentication.registerPublicKey = { (pubKey, completed, errored) in - let registerBlock = { - self.userClient.registerPublicKey(pubKey, - device: device, - user: userId, - success: { completed() }, - failure: { error in errored(error) }) - } - self.userClient.removePublicKeyOfDevice(device, - user:userId, - success: { registerBlock() }, - failure: { _ in registerBlock() }) -} - -authentication.jwtPayload = { - return [ - "iss": userId, - "device": device, - ] -} - -authentication.authenticate = { (jwt, block) in - let parameters = A0AuthParameters.newWithDictionary([ - A0ScopeProfile: "openid name email nickname" - ]) - - client.loginWithIdToken(jwt, - deviceName: device, - parameters: parameters, - success: { (profile, token) in - // User is authenticated with Auth0 & TouchID - }, - failure: { error in block(error) }) -} -authentication.onError = { error in - // Handle authentication error -} - -self.authentication = authentication; -``` diff --git a/articles/connections/passwordless/_using-lock-email.md b/articles/connections/passwordless/_using-lock-email.md deleted file mode 100644 index 8bd7d1a22f..0000000000 --- a/articles/connections/passwordless/_using-lock-email.md +++ /dev/null @@ -1,9 +0,0 @@ -When this code runs, it will ask the user for their email address: - -![](/media/articles/connections/passwordless/passwordless-email-request-${platform}.png) - -Then Auth0 will send to the user an email containing the one-time code: - -![](/media/articles/connections/passwordless/passwordless-email-receive-code-${platform}.png) - -Lastly, the user enters the one-time password into Lock. Then, if the password is correct, the user is authenticated. diff --git a/articles/connections/passwordless/_using-lock-ios-email.md b/articles/connections/passwordless/_using-lock-ios-email.md deleted file mode 100644 index efacc60004..0000000000 --- a/articles/connections/passwordless/_using-lock-ios-email.md +++ /dev/null @@ -1,67 +0,0 @@ -# Authenticate users with a one-time code via e-mail - -<%= include('./_ios-language-picker') %> - -<%= include('./_introduction-email', { isMobile: true }) %> - -## Setup - -<%= include('./_setup-email') %> - -## Implementation - -### Using Auth0 Lock - -<% if (language === "objc") { %> -<%= include('../../_includes/_package', { - org: 'auth0', - repo: 'Mobile-Samples.iOS', - path: 'Passwordless-Email/Lock/ObjC' -}) %> -<% } else { %> -<%= include('../../_includes/_package', { - org: 'auth0', - repo: 'Mobile-Samples.iOS', - path: 'Passwordless-Email/Lock/Swift' -}) %> -<% } %> - -<%= include('./_introduction-lock', { repository: 'Lock.iOS-OSX', platform: 'iOS', docsUrl: 'lock-ios' }) %> - -<% if (language === "objc") { %> -<%= include('./_email-controller-objc') %> -<% } else { %> -<%= include('./_email-controller-swift') %> -<% } %> - -<%= include('./_using-lock-email', { platform: 'ios' }) %> - -This code will call `onAuthenticationBlock`, where the `id_token`, `refresh_token` and user profile are typically stored. Then the user will be allowed to continue to the authenticated part of the application. - -![](/media/articles/connections/passwordless/passwordless-email-enter-code-ios.png) - -### Using your own UI - -If you choose to build your own UI, your code will need to ask the user for their email address first. Then call the following method: - -<% if (language === "objc") { %> -<%= include('./_email-send-code-objc') %> -<% } else { %> -<%= include('./_email-send-code-swift') %> -<% } %> - -After the passwordless login process begins, ask the user for the one-time code. Then authenticate using that code: - -<% if (language === "objc") { %> -<%= include('./_email-login-objc') %> -<% } else { %> -<%= include('./_email-login-swift') %> -<% } %> - -## Authenticate users with a Magic Link via e-mail - -<%= include('./_introduction-email-magic-link') %> - -The next version of the iOS library will support magic links through iOS 9 Universal Links. When a user clicks a magic link they have received on their device, the link will automatically open your application (instead of opening in the browser) and sign in the user. - -Lastly, once the user is authenticated, your app will be able to access the user profile and tokens returned by Auth0. diff --git a/articles/connections/passwordless/_using-lock-ios-sms.md b/articles/connections/passwordless/_using-lock-ios-sms.md deleted file mode 100644 index 0b64607643..0000000000 --- a/articles/connections/passwordless/_using-lock-ios-sms.md +++ /dev/null @@ -1,61 +0,0 @@ -# Authenticate users with a one-time code via SMS - -<%= include('./_ios-language-picker') %> - -<%= include('./_introduction-sms', { isMobile: true }) %> - -## Setup - -<%= include('./_setup-sms-twilio') %> - -## Implementation - -### Using Auth0 Lock - -<% if (language === "objc") { %> -<%= include('../../_includes/_package', { - org: 'auth0', - repo: 'Mobile-Samples.iOS', - path: 'Passwordless-SMS/Lock/ObjC' -}) %> -<% } else { %> -<%= include('../../_includes/_package', { - org: 'auth0', - repo: 'Mobile-Samples.iOS', - path: 'Passwordless-SMS/Lock/Swift' -}) %> -<% } %> - -<%= include('./_introduction-lock', { repository: 'Lock.iOS-OSX', platform: 'iOS', docsUrl: 'lock-ios' }) %> - -<% if (language === "objc") { %> -<%= include('./_sms-controller-objc') %> -<% } else { %> -<%= include('./_sms-controller-swift') %> -<% } %> - -<%= include('./_using-lock-sms', { platform: 'ios' }) %> - -This code will call `onAuthenticationBlock`, where the `id_token`, `refresh_token` and user profile are typically stored. Then the user will be allowed to continue to the authenticated part of the application. - -![](/media/articles/connections/passwordless/passwordless-sms-enter-code-ios.png) - -### Using your own UI - -If you choose to build your own UI, your code will need to ask the user for their phone number first. Then call the following method: - -<% if (language === "objc") { %> -<%= include('./_sms-send-code-objc') %> -<% } else { %> -<%= include('./_sms-send-code-swift') %> -<% } %> - -After the passwordless login process begins, ask the user for the one-time code. Then authenticate using that code: - -<% if (language === "objc") { %> -<%= include('./_sms-login-objc') %> -<% } else { %> -<%= include('./_sms-login-swift') %> -<% } %> - -Lastly, once the user is authenticated, your app will be able to access the user profile and tokens returned by Auth0. diff --git a/articles/connections/passwordless/_using-lock-ios-touchid.md b/articles/connections/passwordless/_using-lock-ios-touchid.md deleted file mode 100644 index 3d064413ef..0000000000 --- a/articles/connections/passwordless/_using-lock-ios-touchid.md +++ /dev/null @@ -1,104 +0,0 @@ -# Authenticate users with Touch ID - -<%= include('./_ios-language-picker') %> - -A feature specific to iOS is the support for *Touch ID*, which allows users to authenticate with their fingerprint (biometric authentication). - -![](/media/articles/connections/passwordless/passwordless-touchid-start.png) - -During sign-up, the library will generate a key pair on the device, create a user in Auth0, and register the public key for the user: - -![](/media/articles/connections/passwordless/passwordless-touchid-flow.png) - -The private key is stored in the keystore of the device. Each time a user initiates authentication with a valid fingerprint, *Touch ID* retrieves the private key from the keystore, creates a token, signs it with the private key and sends it to Auth0. Auth0 then returns an `id_token`, the user profile and, optionally, a `refresh_token`. - -**NOTE:** You can use Touch ID with an iPhone 5s or later, an iPad Air 2, or an iPad mini 3 or later. - -## Implementation - -### Using the Auth0 Lock - -<% if (language === "objc") { %> -<%= include('../../_includes/_package', { - org: 'auth0', - repo: 'Mobile-Samples.iOS', - path: 'Passwordless-TouchID/Lock/ObjC' -}) %> -<% } else { %> -<%= include('../../_includes/_package', { - org: 'auth0', - repo: 'Mobile-Samples.iOS', - path: 'Passwordless-TouchID/Lock/Swift' -}) %> -<% } %> - -<%= include('./_introduction-lock', { repository: 'Lock.iOS-OSX', platform: 'iOS', docsUrl: 'lock-ios' }) %> - -<% if (language === "objc") { %> -<%= include('./_touchid-controller-objc') %> -<% } else { %> -<%= include('./_touchid-controller-swift') %> -<% } %> - - - -### Using your own UI - -If you choose to build your own UI, you must install our [TouchIDAuth](https://github.com/auth0/TouchIDAuth) library to handle the features specific to *Touch ID*. - -Begin by signing up a user in a Database Connection: - -<% if (language === "objc") { %> -<%= include('./_touchid-signup-objc') %> -<% } else { %> -<%= include('./_touchid-signup-swift') %> -<% } %> - -**NOTE:** You can generate a random password to avoid asking the user for one at this time. The user can change it later. - -Once the user has signed up, use the `idToken` to register the public key for the user. - -First, you will need a place to store an Auth0 API client with the token until you register the key, and a place to store the TouchID component: - -<% if (language === "objc") { %> -<%= include('./_touchid-properties-objc') %> -<% } else { %> -<%= include('./_touchid-properties-swift') %> -<% } %> - -Now implement the following method to perform TouchID authentication: - -<% if (language === "objc") { %> -<%= include('./_touchid-login-method-objc') %> -<% } else { %> -<%= include('./_touchid-login-method-swift') %> -<% } %> - -Then create and store the API client: - -<% if (language === "objc") { %> -<%= include('./_touchid-init-client-objc') %> -<% } else { %> -<%= include('./_touchid-init-client-swift') %> -<% } %> - -Now configure the TouchID Authentication component: - -<% if (language === "objc") { %> -<%= include('./_touchid-configure-component-objc') %> -<% } else { %> -<%= include('./_touchid-configure-component-swift') %> -<% } %> - -Then, to begin authentication, add this line: - -<% if (language === "objc") { %> -```objc -[self.authentication start]; -``` - -<% } else { %> -```swift -self.authentication.start() -``` -<% } %> diff --git a/articles/connections/passwordless/_using-lock-sms.md b/articles/connections/passwordless/_using-lock-sms.md deleted file mode 100644 index 95f45f04a1..0000000000 --- a/articles/connections/passwordless/_using-lock-sms.md +++ /dev/null @@ -1,9 +0,0 @@ -When this code runs, it will ask the user for their phone number: - -![](/media/articles/connections/passwordless/passwordless-sms-request-${platform}.png) - -Then Auth0 will use Twilio to send to the user an SMS containing the one-time code: - -![](/media/articles/connections/passwordless/passwordless-sms-receive-code-${platform}.png) - -Lastly, the user enters the one-time password into Lock. Then, if the password is correct, the user is authenticated. diff --git a/articles/connections/passwordless/android-email.md b/articles/connections/passwordless/android-email.md deleted file mode 100644 index bc632ffc88..0000000000 --- a/articles/connections/passwordless/android-email.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: Using Passwordless Authentication on Anroid with e-mail ---- - -# Authenticate users with a one-time code via e-mail - -<%= include('./_introduction-email', { isMobile: true }) %> - -## Setup - -<%= include('./_setup-email') %> - -## Implementation - -### Using Auth0 Lock - -<%= include('../../_includes/_package', { - org: 'auth0', - repo: 'Mobile-Samples.Android', - path: 'Passwordless-Email/Lock' -}) %> - -<%= include('./_introduction-lock', { repository: 'Lock.Android', platform: 'Android', docsUrl: 'lock-android' }) %> - -Begin by adding the Lock e-mail library to your `build.gradle` file: - -``` -compile 'com.auth0.android:lock-email:1.10.+' -``` - -Once the user is successfully authenticated, LockActivity will send an Action using LocalBroadcasterManager and then end itself by calling finish(). The activity that will receive this Action and 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 call the activity: - -```java -Intent emailIntent = new Intent(this, LockEmailActivity.class); -startActivity(emailIntent); -``` - -<%= include('./_using-lock-email', { platform: 'android' }) %> - -![](/media/articles/connections/passwordless/passwordless-email-enter-code-android.png) - -### Using your own UI - -If you choose to build your own UI, first ask the user for their email address. Then call `requestEmailVerificationCode` on the `APIClient` - -```java -final APIClient client = lock.getAPIClient(); -client.requestEmailVerificationCode(email, new BaseCallback() { - @Override - public void onSuccess(Void payload) { - // Email sent, continue to next page. - } - - @Override - public void onFailure(Throwable error) { - // Error sending email. - } -}); -``` - -Once the passwordless login process begins, ask the user for the one-time code. Then authenticate using that code: - -```java -final APIClient client = lock.getAPIClient(); -client.emailLogin(email, passcode, authenticationParameters, new AuthenticationCallback() { - @Override - public void onSuccess(UserProfile userProfile, Token token) { - // Login success, you can now use the userProfile or token - } - - @Override - public void onFailure(Throwable throwable) { - // Login failed. - } -}); -``` - -## Authenticate users with a Magic Link via e-mail - -<%= include('./_introduction-email-magic-link') %> - -The next version of the Android library will also support this feature. diff --git a/articles/connections/passwordless/android-sms.md b/articles/connections/passwordless/android-sms.md deleted file mode 100644 index ce3c541a2a..0000000000 --- a/articles/connections/passwordless/android-sms.md +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: Using Passwordless Authentication on Android with SMS ---- - -# Authenticate users with a one-time code via SMS - -<%= include('./_introduction-sms', { isMobile: true }) %> - -## Setup - -<%= include('./_setup-sms-twilio') %> - -## Implementation - -### Using Auth0 Lock - -<%= include('../../_includes/_package', { - org: 'auth0', - repo: 'Mobile-Samples.Android', - path: 'Passwordless-SMS/Lock' -}) %> - -<%= include('./_introduction-lock', { repository: 'Lock.Android', platform: 'Android', docsUrl: 'lock-android' }) %> - -Begin by adding the Lock SMS library to your `build.gradle` file: - -``` -compile 'com.auth0.android:lock-sms:1.10.+' -``` - -Once the user is successfully authenticated, LockActivity will send an Action using LocalBroadcasterManager and then end itself by calling finish(). The activity that will receive this Action and 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 call the activity: - -```java -Intent smsIntent = new Intent(this, LockSMSActivity.class); -startActivity(smsIntent); -``` - -<%= include('./_using-lock-sms', { platform: 'android' }) %> - -![](/media/articles/connections/passwordless/passwordless-sms-enter-code-android.png) - -### Using your own UI - -If you choose to build your own UI, first ask the user for their phone number. Then call `requestSMSVerificationCode` on the `APIClient` - -```java -final APIClient client = lock.getAPIClient(); -client.requestSMSVerificationCode(phoneNumber, new BaseCallback() { - @Override - public void onSuccess(Void payload) { - // SMS sent, continue to next page. - } - - @Override - public void onFailure(Throwable error) { - // Error sending email. - } -}); -``` - -Once the passwordless login process begins, ask the user for the one-time code. Then authenticate using that code: - -```java -final APIClient client = lock.getAPIClient(); -client.smsLogin(phoneNumber, passcode, authenticationParameters, new AuthenticationCallback() { - @Override - public void onSuccess(UserProfile userProfile, Token token) { - // Login success, you can now use the userProfile or token - } - - @Override - public void onFailure(Throwable throwable) { - // Login failed. - } -}); -``` diff --git a/articles/connections/passwordless/android.md b/articles/connections/passwordless/android.md deleted file mode 100644 index bda703ed91..0000000000 --- a/articles/connections/passwordless/android.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: Using Passwordless Authentication on Android ---- - -<%= include('./_introduction', { withFingerprint: false }) %> - -## Tutorials for Android - - - [Authenticate users with a one-time code via SMS](android-sms) - - [Authenticate users with a one-time code via e-mail](android-email) diff --git a/articles/connections/passwordless/authentication-factors/email-magic-link.md b/articles/connections/passwordless/authentication-factors/email-magic-link.md new file mode 100644 index 0000000000..718985d541 --- /dev/null +++ b/articles/connections/passwordless/authentication-factors/email-magic-link.md @@ -0,0 +1,18 @@ +--- +title: Passwordless Authentication with Magic Links +description: Passwordless Authentication with Magic Links +toc: true +topics: + - connections + - passwordless + - authentication +--- +# Passwordless Authentication with Magic Links + +When implementing passwordless authentication with "magic links", the user is sent an email with a link in it. This link will allow them to login directly when clicking on it. It is similar in function to them getting an email with a one-time-use code in it, returning to your app, and entering the code, but without having to actually perform those steps. + +With magic link transactions, both the initial request and its response **must take place in the same browser or the transaction will fail**. This is particularly relevant for iOS users, who cannot change their default web browser. For example, the user might make the initial request using the Chrome browser, but when the user opens the magic link in their email, iOS automatically opens it in Safari (the default browser). If this happens, the transaction will fail. + +<%= include('../_includes/_introduction-email-magic-link') %> + +<%= include('../_includes/_setup-email') %> diff --git a/articles/connections/passwordless/authentication-factors/email-otp.md b/articles/connections/passwordless/authentication-factors/email-otp.md new file mode 100644 index 0000000000..22cbbd4f1b --- /dev/null +++ b/articles/connections/passwordless/authentication-factors/email-otp.md @@ -0,0 +1,15 @@ +--- +title: Passwordless Authentication with Email +description: Passwordless Authentication with Email +toc: true +topics: + - connections + - passwordless + - authentication +--- +# Passwordless Authentication with Email + +<%= include('../_includes/_introduction-email') %> + +<%= include('../_includes/_setup-email') %> + diff --git a/articles/connections/passwordless/authentication-factors/index.md b/articles/connections/passwordless/authentication-factors/index.md new file mode 100644 index 0000000000..d7617ab2f7 --- /dev/null +++ b/articles/connections/passwordless/authentication-factors/index.md @@ -0,0 +1,18 @@ +--- +title: Passwordless Authentication Factors +description: Describes the various authentication factors supported by Auth0 passwordless connections, including email, magic link, and SMS. +topics: + - connections + - passwordless + - authentication +useCase: customize-connections +--- +# Passwordless Authentication Factors + +With Passwordless connections, users can log in without a password. Instead, they can use a variety of other authentication factors. Auth0 Passwordless connections support the following authentication factors: + +| Factor | Description | +|-------------|-------------| +| [Email](/connections/passwordless/email-otp) | The user is asked to enter their email address, to which Auth0 sends a one-time-use code. The user enters the code into your application. | +| [Magic Link](/connections/passwordless/email-magic-link) | The user is asked to enter their email address, to which Auth0 sends an email with a link in it. The user clicks the link and is directly logged in to your application. | +| [SMS](/connections/passwordless/sms-otp) | The user is asked to enter their phone number, to which Auth0 sends a one-time-use code. By default, Auth0 uses Twilio to send the code, but if you have a custom SMS gateway, you can modify your connection to use that instead. | \ No newline at end of file diff --git a/articles/connections/passwordless/authentication-factors/sms-otp.md b/articles/connections/passwordless/authentication-factors/sms-otp.md new file mode 100644 index 0000000000..a602a64749 --- /dev/null +++ b/articles/connections/passwordless/authentication-factors/sms-otp.md @@ -0,0 +1,18 @@ +--- +title: Passwordless Authentication with SMS +description: Learn about passwordless connections, Auth0-supported passwordless methods of authentication, and how to implement passwordless authentication with Auth0. +toc: true +topics: + - connections + - passwordless + - authentication +contentType: + - index + - concept +useCase: customize-connections +--- +# Passwordless Authentication with SMS + +<%= include('../_includes/_introduction-sms') %> + +<%= include('../_includes/_setup-sms-twilio') %> diff --git a/articles/connections/passwordless/best-practices.md b/articles/connections/passwordless/best-practices.md new file mode 100644 index 0000000000..7c7e6a7c16 --- /dev/null +++ b/articles/connections/passwordless/best-practices.md @@ -0,0 +1,62 @@ +--- +title: Passwordless Connections Best Practices +description: Passwordless Connections Best Practices +toc: true +topics: + - connections + - passwordless + - authentication + - concept +--- +# Passwordless Connections Best Practices + +## Implementing login + +You can implement passwordless authentication by redirecting to Auth0's [Universal Login](/connections/passwordless/universal-login) or by [Embedding Login](/connections/passwordless/embedded-login) in your application. + +We always recommend that [you implement Universal Login](guides/login/universal-vs-embedded). + +## SMS and email as authentication factors + +Auth0's passwordless implementation enables authenticating users with a single factor. That single factor can be one-time-use code sent by email or sms, or a magic link sent by email. + +Even if using email or SMS can be more secure than a weak password, they have known issues: + +- Phone numbers are not sufficient for user authentication. The SS7 phone routing system used by cellular networks [has verified weaknesses](https://thehackernews.com/2017/05/ss7-vulnerability-bank-hacking.html) which have led to it not being recommended as an authentication factor. There are many attack vectors available, ranging from the use of social engineering, to swapping sim cards and buying access to the SS7 network. + +- Having an email address is not sufficient for user authentication (aliases, forwarding, multiple users in one account are all examples). Email providers vary in their security practices and some do not require any establishment of a user's identity. SMTP is a very old protocol, and many providers still route SMTP traffic unencrypted leading to an increased chance of an interception attack. + +We recommend that if you use passwordless authentication, you also implement [Multi-factor Authentication (MFA)](/mfa) with a different factor when the user performs a security-sensitive operation. + +## Preventing Phishing Attacks + +A possible phishing attack could look like: + +1. The user clicks a link in a malicious email or website. +1. The user lands in the attacker's site, where they are prompted to enter their phone number to authenticate. +1. The user enters the phone number, and the attacker enters the same phone number in the legitimate application. +1. The legitimate application sends an SMS to the user. +1. The user types the one-time-use code in the attacker's website. +1. The attacker can now login to the legitimate website. + +To decrease the chances of success for this attack, the user should expect that the SMS clearly identifies the application. You should configure the SMS template so it mentions the tenant name and/or the Application Name: + +```text +Your verification code for accessing's Acme @@application.name@@ is @@password@@ +``` + +## Preventing brute force attacks + +Auth0 has the following protections against brute force attacks: + +* Only the most recent one-time-use code (or link) issued will be accepted. Once the latest one is issued, any others are invalidated. Once used, the latest one is also invalidated. +* Only three failed attempts to input any single one-time-use code are allowed. After this, a new code will need to be requested. +* The one-time-use code issued will be valid for three minutes (by default) before it expires. + +The one-time-use code expiration time can be altered at [Auth0 Dashboard > Authentication > Passwordless](${manage_url}/#/connections/passwordless). + +## Link accounts + +Users might want to authenticate using different passwordless factors during their lifetime. For example, they could initially sign up with an SMS, and later start authenticating with an email. You can achieve that by enabling them to link their different profiles using [account linking](/users/concepts/overview-user-account-linking). + +<%= include('./_includes/_rate_limit_server_side') %> diff --git a/articles/connections/passwordless/email.md b/articles/connections/passwordless/email.md deleted file mode 100644 index 5317d198d6..0000000000 --- a/articles/connections/passwordless/email.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Email Passwordless Authentication -connection: Email -alias: - - email -seo_alias: email ---- - -# Authenticate users with using Passwordless Authentication via Email - -<%= include('./_introduction-email', { isMobile: false }) %> - -## Setup - -<%= include('./_setup-email') %> - -## Single-page Application Tutorials - - - [Authenticate users with a one-time code via e-mail](/connections/passwordless/spa-email-code) - - [Authenticate users with a magic link via e-mail](/connections/passwordless/spa-email-link) - -## Regular Web Application Tutorials - - - [Authenticate users with a one-time code via e-mail](/connections/passwordless/regular-web-app-email-code) - - [Authenticate users with a magic link via e-mail](/connections/passwordless/regular-web-app-email-link) - -## Mobile Tutorials - - - [iOS](/connections/passwordless/ios-email-swift) - - [Android](/connections/passwordless/android-email) diff --git a/articles/connections/passwordless/embedded-login/index.md b/articles/connections/passwordless/embedded-login/index.md new file mode 100644 index 0000000000..c75c8f4101 --- /dev/null +++ b/articles/connections/passwordless/embedded-login/index.md @@ -0,0 +1,28 @@ +--- +title: Passwordless Authentication with Embedded Login +description: Passwordless Authentication with Embedded Login +toc: true +topics: + - connections + - passwordless + - authentication +--- +# Passwordless Authentication with Embedded Login + +Auth0 supports two way of implementing authentication: *Embedded Login* and *Universal Login*. + +The industry is aligned in that redirecting to the [Universal Login](/connections/passwordless/universal-login) page is the proper way to implement authentication in all apps, but in the case of Native Applications, sometimes customers prefer to implement Embedded Login for UX reasons. + +If you need to embed the login user interface in your application, you can do it by using our [Embedded Passwordless API](/connections/passwordless/relevant-api-endpoints) or our SDKs. + +Depending on the kind of application you want to build, you'll need to implement it differently: + +- For Single Page Applications (e.g. Angular / React), refer to [Embedded Passwordless Login in Single Page Applications](/connections/passwordless/embedded-login-spa). +- For Native applications (iOS, Android, desktop applications) refer to [Embedded Passwordless Login in Native Applications](/connections/passwordless/embedded-login-native). +- For Regular Web Applications (NodeJS, Java, Rails, .NET) please check [Embedded Passwordless Login in Regular Web Applications](/connections/passwordless/embedded-login-webapps). + +## Keep reading + * [Passwordless Authentication Overview](/connections/passwordless) + * [Best practices for Passwordless Authentication](connections/passwordless/best-practices) + * [Passwordless API Documentation](/connections/passwordless/relevant-api-endpoints) + * [Migrating from deprecated Passwordless endpoints](/migrations/guides/migration-oauthro-oauthtoken-pwdless) diff --git a/articles/connections/passwordless/embedded-login/native.md b/articles/connections/passwordless/embedded-login/native.md new file mode 100644 index 0000000000..6b97465a09 --- /dev/null +++ b/articles/connections/passwordless/embedded-login/native.md @@ -0,0 +1,116 @@ +--- +title: Embedded Passwordless Login in Native Applications +description: Embedded Passwordless Login in Native Applications +toc: true +topics: + - connections + - passwordless + - authentication +--- + +# Embedded Passwordless Login in Native Applications + +To use the Embedded Passwordless APIs in Native applications, make sure you enable the **Passwordless OTP** grant at [Auth0 Dashboard > Applications > Applications](${manage_url}/#/applications) in your application's settings under **Advanced Settings** > **Grant Types**. + +Passwordless authentication for Native applications consists of two steps: + +- Capture the user identifier in your application (the user's email or phone number) and invoke the `/passwordless/start` endpoint to initiate the passwordless flow. The user will get an email or an SMS with a one-time password. + +- Prompt the user for the one-time-use code, and call the `/oauth/token` endpoint to get authentication tokens. + +Below we list a few code snippets that can be used to call these API endpoints for different scenarios. + +**Send a one-time-use password via Email** + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/passwordless/start", + "headers": [{ + "name": "Content-Type", + "value": "application/json" + }], + "postData": { + "mimeType": "application/json", + "text": "{\"client_id\": \"${account.clientId}\", \"connection\": \"email\", \"email\": \"USER_EMAIL\", \"send\": \"code\"}" + } +} +``` + +**Send a Magic via Email** + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/passwordless/start", + "headers": [{ + "name": "Content-Type", + "value": "application/json" + }], + "postData": { + "mimeType": "application/json", + "text": "{ \"client_id\": \"${account.clientId}\", \"connection\": \"email\", \"email\": \"USER_EMAIL\", \"send\": \"link\"}"} +} +``` + +**Send a one-time-use password via SMS** + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/passwordless/start", + "headers": [{ + "name": "Content-Type", + "value": "application/json" + }], + "postData": { + "mimeType": "application/json", + "text": "{ \"client_id\": \"${account.clientId}\", \"connection\": \"sms\", \"phone_number\": \"USER_PHONE_NUMBER\", \"send\": \"code\"}" + } +} +``` + +**Authenticate an SMS user** + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [{ + "name": "Content-Type", + "value": "application/json" + }], + "postData": { + "mimeType": "application/json", + "text": "{ \"grant_type\": \"http://auth0.com/oauth/grant-type/passwordless/otp\", \"client_id\": \"${account.clientId}\", \"username\": \"USER_PHONE_NUMBER\", \"otp\": \"code\", \"realm\": \"sms\", \"audience\": \"your-api-audience\", \"scope\": \"openid profile email\"}" + } +} +``` + +**Authenticate an Email user** + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [{ + "name": "Content-Type", + "value": "application/json" + }], + "postData": { + "mimeType": "application/json", + "text": "{\"grant_type\": \"http://auth0.com/oauth/grant-type/passwordless/otp\", \"client_id\": \"${account.clientId}\", \"username\": \"USER_EMAIL\", \"otp\": \"code\", \"realm\": \"email\", \"audience\": \"your-api-audience\", \"scope\": \"openid profile email\"}" + } +} +``` + +If you prefer, you can use the Android or iOS SDKs, which wrap this APIs in a platform-friendly way: + +- [Lock Android Passwordless](/libraries/lock-android/passwordless) +- [Lock iOS Passwordless](/libraries/lock-ios/passwordless) +- [Auth0.Android Passwordless](/libraries/auth0-android/passwordless) +- [Auth0.Swift Passwordless](/libraries/auth0-swift/passwordless) + +## Migrating from Legacy Implementations + +In the past, you could implement this scenario by using the `/oauth/ro` endpoint to exchange the one-time-use code for authentication tokens. Check the [migration guide](/migrations/guides/migration-oauthro-oauthtoken-pwdless) to learn how to update your code to use `/oauth/token`. diff --git a/articles/connections/passwordless/embedded-login/relevant-api-endpoints.md b/articles/connections/passwordless/embedded-login/relevant-api-endpoints.md new file mode 100644 index 0000000000..fe53db878c --- /dev/null +++ b/articles/connections/passwordless/embedded-login/relevant-api-endpoints.md @@ -0,0 +1,112 @@ +--- +title: Using Passwordless APIs +topics: + - connections + - passwordless + - api +contentType: reference +useCase: customize-connections +--- +# Implementing Passwordless using APIs + +Passwordless APIs can be used in two scenarios: + +* When implementing Universal Login and you want to customize the login page using auth0.js to interact with Auth0. +* When you want to embed the login flow in your application. + +If you decide to embed login, please make sure you understand the [security implications](/guides/login/universal-vs-embedded). + +You can learn more about how to implement Passwordless for Universal Login and Embedded login for different scenarios in these documents: + +- [Passwordless Authentication with Universal Login](/connections/passwordless/universal-login) +- [Passwordless Authentication with Embedded Login](/connections/passwordless/embedded-login) + + +## Passwordless endpoints + +### POST /passwordless/start + +The [POST /passwordless/start](/api/authentication#get-code-or-link) endpoint can be called to begin the Passwordless authentication process, for both Universal Login or Embedded Login. + +Depending on the parameters provided to the endpoint, Auth0 begins the user verification process by sending one of the following: + +* A single-use code via email or SMS message +* A single-use link via email + +The API call needs to have the following structure: + +```json +POST https://YOUR_DOMAIN/passwordless/start +Content-Type: application/json +{ + "client_id": "YOUR_CLIENT_ID", + "client_secret": "YOUR_CLIENT_SECRET", // For Regular Web Applications + "connection": "email|sms", + "email": "EMAIL", //set for connection=email + "phone_number": "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", // used when asking for a magic link + "state": "YOUR_STATE" // used when asking for a magic link, or from the custom login page + } +} +``` + +If you use a magic link, Auth0 will redirect the user to the application after the link is clicked, and the user will be logged in. + +If you use a code, your application will need to prompt for that code, and then you should use the `/oauth/token` endpoint, or the `passwordlessLogin` method in the Auth0.js SDK to exchange that code for authentication tokens. + +### POST /oauth/token + +If you are implementing passwordless for Native Applications or Regular Web Applications, you need to use `/oauth/token` to exchange the OTP code for authentication tokens. You cannot use this endpoint from Single Page Applications. + +To achieve this you first need to enable the **Passwordless OTP** grant for your application at [Dashboard > Applications > Applications](${manage_url}/#/applications) in your application's settings under **Advanced Settings** > **Grant Types**. + +The user will receive the OTP code and your Native or Web application will prompt the user for it. When the user enters the code, you can complete the authentication flow by calling the `/oauth/token` endpoint with the following parameters: + +```json +POST https://YOUR_AUTH0_DOMAIN/oauth/token +Content-Type: application/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 + "scope": "openid profile email" // whatever scopes you need +} +``` + +If all went well, Auth0 will return a response similar to the following: + +```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 +} +``` + +You can then decode the ID Token to get information about the user, or use the Access Token to call your API as normal. + +## Using Auth0.js + +When implementing Passwordless Authentication in Single Page Applications or in a customized Universal Login page, you should use Auth0.js and the included [`passwordlessLogin`](/libraries/auth0js/v9#verify-passwordless) method. The implementation is complex, so we recommend that you use the library instead of calling the APIs directly. + +## Rate Limiting in Passwordless Endpoints + +Auth0 rate limits and attack protection features only consider the IP from the machine that is making the API call. When the API call is made from a backend server, you usually want Auth0 to consider the IP from the end user, not the one from the server. + +Auth0 supports specifying an `auth0-forwarded-for` header in API calls, but it is only considered when: + +* The API call is made for a confidential application +* The API call includes the client secret +* The **Trust Token Endpoint IP Header** toggle is ON + +For a complete explanation, see this tutorial on [configuring your application to receive and trust the IP sent by your server](/api-auth/tutorials/using-resource-owner-password-from-server-side#configuring-the-auth0-application-to-receive-and-trust-the-ip-sent-by-your-server). diff --git a/articles/connections/passwordless/embedded-login/spa.md b/articles/connections/passwordless/embedded-login/spa.md new file mode 100644 index 0000000000..e46ecb8003 --- /dev/null +++ b/articles/connections/passwordless/embedded-login/spa.md @@ -0,0 +1,21 @@ +--- +title: Embedded Passwordless Authentication for SPAs +description: Embedded Passwordless Authentication for SPAs +toc: true +topics: + - connections + - passwordless + - authentication +--- +# Embedded Passwordless Authentication for SPAs + +<%= include('../../../_includes/_embedded_login_warning') %> + +## Using Auth0's SDKs to implement Embedded Login + +You can implement Passwordless Login using Auth0's Lock widget or if you need complete control of the user experience, you can implement it using Auth0.js: + +- [Implementing passwordless with Lock.js](/libraries/lock/v11#passwordless) +- [Implementing passwordless with Auth0.js](/libraries/auth0js#passwordless-login) + +<%= include('../_includes/_setup-cors') %> diff --git a/articles/connections/passwordless/embedded-login/webapps.md b/articles/connections/passwordless/embedded-login/webapps.md new file mode 100644 index 0000000000..65334f61ed --- /dev/null +++ b/articles/connections/passwordless/embedded-login/webapps.md @@ -0,0 +1,116 @@ +--- +title: Embedded Passwordless Login in Regular Web Applications +description: Embedded Passwordless Login in Regular Web Applications +toc: true +topics: + - connections + - passwordless + - authentication +--- + +# Embedded Passwordless Login in Regular Web Applications + +To use the Embedded Passwordless APIs in Regular Web Applications, make sure you enable the **Passwordless OTP** grant at [Auth0 Dashboard > Applications > Applications](${manage_url}/#/applications) in your application's settings under **Advanced Settings** > **Grant Types**. + +Passwordless authentication for Regular Web Applications consists of two steps: + +- Capture the user identifier in your application (the user's email or phone number) and invoke the `/passwordless/start` endpoint to initiate the passwordless flow. The user will get an email, an SMS with a one-time-use code or a magic link. + +- If you did not send a magic link, you need to prompt the user for the one-time-use code, and call the `/oauth/token` endpoint to get authentication tokens. + +Note that when using magic links, you don't need to call `/oauth/token`. The user will click the magic link and it will be redirected to the application's callback URL. + +Below we list a few code snippets that can be used to call these API endpoints for different scenarios. Auth0 SDKs for backend technologies (Java, .NET, Ruby, PHP, Python, Node JS) haven't been updated yet to support these endpoints, so you will need to invoke them directly. + +**Send a one-time-use code via Email** + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/passwordless/start", + "headers": [{ + "name": "Content-Type", + "value": "application/json" + }], + "postData": { + "mimeType": "application/json", + "text": "{\"client_id\": \"${account.clientId}\", \"client_secret\": \"YOUR_CLIENT_SECRET\", \"connection\": \"email\", \"email\": \"USER_EMAIL\",\"send\": \"code\"}" + } +} +``` + +**Send a magic link via Email** + +You need to specify `send` = `link`. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/passwordless/start", + "headers": [{ + "name": "Content-Type", + "value": "application/json" + }], + "postData": { + "mimeType": "application/json", + "text": "{\"client_id\": \"${account.clientId}\", \"client_secret\": \"YOUR_CLIENT_SECRET\", \"connection\": \"email\", \"email\": \"USER_EMAIL\",\"send\": \"link\"}" + } +} +``` + +**Send a one-time-use password via SMS** + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/passwordless/start", + "headers": [{ + "name": "Content-Type", + "value": "application/json" + }], + "postData": { + "mimeType": "application/json", + "text": "{\"client_id\": \"${account.clientId}\", \"client_secret\": \"YOUR_CLIENT_SECRET\", \"connection\": \"sms\", \"phone_number\": \"USER_PHONE_NUMBER\",\"send\": \"code\"}" + } +} +``` + +**Authenticate an SMS user** + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [{ + "name": "Content-Type", + "value": "application/json" + }], + "postData": { + "mimeType": "application/json", + "text": "{\"grant_type\": \"http://auth0.com/oauth/grant-type/passwordless/otp\", \"client_id\": \"${account.clientId}\", \"client_secret\": \"YOUR_CLIENT_SECRET\", \"username\": \"USER_PHONE_NUMBER\", \"otp\": \"code\", \"realm\": \"sms\", \"audience\": \"your-api-audience\",\"scope\": \"openid profile email\"}" + } +} +``` + +**Authenticate an Email user** + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/oauth/token", + "headers": [{ + "name": "Content-Type", + "value": "application/json" + }], + "postData": { + "mimeType": "application/json", + "text": "{\"grant_type\": \"http://auth0.com/oauth/grant-type/passwordless/otp\", \"client_id\": \"${account.clientId}\", \"client_secret\": \"YOUR_CLIENT_SECRET\", \"username\": \"USER_EMAIL\", \"otp\": \"code\", \"realm\": \"email\", \"audience\": \"your-api-audience\", \"scope\": \"openid profile email\"}"} +} +``` + +**Authenticate a user through a magic link** + +When you send a magic link, you don't need to call an API to authenticate the user. Users will click the link and get redirected to the callback URL. + +<%= include('../_includes/_rate_limit_server_side') %> + diff --git a/articles/connections/passwordless/faq.md b/articles/connections/passwordless/faq.md deleted file mode 100644 index a8c8a5484d..0000000000 --- a/articles/connections/passwordless/faq.md +++ /dev/null @@ -1,143 +0,0 @@ -# Passwordless FAQ - -## General Questions - -### Q: When is passwordless authentication the best option for login? How does this feature improve the user experience? - -**A:** The number of passwords that users must remember has become overwhelming, and passwords that aren’t used frequently are often forgotten. When a user forgets their password, they must recover it through email using a process more cumbersome than Auth0’s simple, passwordless user experience. For many users, recovering a lost password for infrequently visited sites and apps is a common and unpleasant experience. - -In a [recent survey](https://www.passwordboss.com/password-habits-survey-part-1/), 59% of users admit to reusing passwords because it is too difficult to remember them all. Although this habit avoids the password recovery scramble, it exposes these users to risk. - -Passwordless login is best for sites and apps where users maintain a presence but don’t visit often enough that they remember a unique password. This could encompass most of the Internet. For these sites, passwordless login creates a much better user experience and better security: no password resets or reuse, and no password database as a target for hackers. - -For frequently visited sites, passwordless authentication offers a streamlined and simple user experience. Many companies, such as Slack and [Medium](https://medium.com/the-story/signing-in-to-medium-by-email-aacc21134fcd), have embraced the passwordless login as more secure than passwords. - -### Q: When is passwordless login not a good idea? What are its limitations? - -**A:** For sites and apps that users access every day, the passwordless flow may feel slower than the muscle memory of quickly entering a memorized password. As with a username/password login, if an email account is hacked or a phone is stolen and unlocked, the passwordless login is compromised, but so is every site not using multi-factor authentication. - -Websites and web applications are trending toward longer session expirations so that users are not asked to login frequently, behaving more like native apps on a mobile device. Then, when a user initiates a sensitive operation, users are asked for *step-up* authentication such as a one-time password or a code from an authentication app like Google Authenticator. Auth0’s passwordless authentication takes the same approach. Like the `sudo` command on Linux, when the user initiates an activity that requires elevated privileges, they are presented with an extra challenge. Simple and effective, this procedure eliminates the hassle of multi-factor authentication, except when necessary. - -### Q: Is it difficult for users to become accustomed to passwordless login? - -**A:** Passwordless login is so simple that most users will immediately get it. The user experience is nearly effortless, especially with *magic links* in emails or with Apple *Touch ID*. For most end-users, a passwordless login is easier than recalling a hard-to-remember password. - -### Q: How is passwordless login different from a social login? - -**A:** With a social login, the user is authenticated through a separate account that the user owns. Users need to remember and protect fewer passwords, and the site or app owner doesn’t need to manage any passwords. - -Social logins are appropriate when users are likely to have accounts on popular social providers, and when your application can gain additional features by interacting with the social provider’s API. Auth0 supports a wide range of social providers out-of-the-box with just a few lines of code. However, social logins can be confusing to some users because of the need to login to a different site, and of the grant page which asks for additional permissions to share their data. When users are confused or worried, they might abandon their sign-up. For these users, passwordless login has the advantage of not asking them to share anything except for their email, or phone number for SMS. - -One option is to offer users several popular social logins, and offer passwordless email as an alternative if they don’t have any social accounts or prefer not to use them. - -### Q: How much does passwordless authentication from Auth0 cost? - -**A:** There is no extra charge to use this feature. Passwordless authentication is included free with every Auth0 developer account, subscription, and custom plan. - -## How to use and configure Passwordless - -### Q: What are the advantages of using *magic links*? - -**A:** A *magic link* is a link sent to a user’s email that logs the user into your site or application with a single click. It provides the simplest user experience and makes the login process smooth and friction-free. - -### Q: What are the advantages of using emailed codes? - -**A:** An emailed code requires slightly more effort for end-users than a magic link. A numeric code is sent to the user’s email. The user then types this code into a response field of the Auth0 passwordless lock widget on your site, which handles this part automatically. Once entered and validated, the user is logged in. - -### Q: What are the advantages of using codes delivered through SMS? - -**A:** Since users often have their phone nearby, SMS messages are likely to be delivered to the user’s hand or pocket. Typically, it’s impossible to steal SMS service without being in possession of the phone or SIM that is hard-coded with the wireless number. This eliminates the potential for malicious access through stolen email credentials, making SMS logins more secure. - -An SMS login, like an emailed code, requires slightly more effort for end-users than a *magic link*. Depending on the user’s mobile subscription plan, there may be a fee for them to receive SMS messages or these messages may count against a pool of available free messages. For such users, the added cost of using the SMS side-channel may not be considered worthwhile. - -### Q: Can I offer both email and SMS options at the same time? - -**A:** Using [Auth0’s Javascript SDK](https://github.com/auth0/auth0.js), you have complete control of how passwordless authentication works with your site or application. It’s easy to implement a mixed-mode user experience and build your own UI using the SDK. However, the passwordless lock widget does not yet support this sort of mixed-mode interface. Such a mode may be added to future versions of the widget. - -### Q: How would a user sign-in to your application using a *magic link* from a device that doesn’t have access to the registered email account? - -**A:** A user may sign-up for your service using passwordless login with their personal email and may want to use that service at work but does not have their personal email account available from their work PC. If they visit the service on their work PC and ask to log in, providing their personal email address, the *magic link* is sent to their personal email account that they cannot access from their work PC. - -The simplest way to solve this problem would be for the user to forward the *magic link* email to their work email account, and click the link from their work PC. They could also create an account with their work email address and link the two accounts, logging in with either of them. - -If this is likely to be a common scenario for your end-users, you might want to consider using emailed codes, or codes sent through SMS, rather than emailed links. - -### Q: How do I style the passwordless lock widget to my own brand identity? - -**A:** The passwordless lock widget accepts two parameters to change its appearance: the *primaryColor* option to change background color and the *icon* option to add your brand’s icon. You can also style the widget by modifying the CSS stylesheet. - -If you need more design control, you can implement your own UI and call any of the passwordless connections through the [Auth0 JavaScript SDK](https://github.com/auth0/auth0.js). - -### Q: How do I select which high-volume messaging provider passwordless logins will use? What are my options? - -**A:** By default, your passwordless connections will be set-up to use Auth0’s messaging provider. However, this limits your ability to monitor and manage availability, troubleshoot issues, and connect to analytics. Accordingly, we recommend that you set up your own high-volume email or SMS provider. - -Auth0 supports **Twilio SMS** for passwordless login with codes sent via SMS, and **SendGrid**, **Mandrill**, and **Amazon SES** for email-based passwordless authentication. These providers are all supported in the Auth0 dashboard. All you need are your API credentials. - -### Q: Can I configure a different messaging provider than the ones you support directly? - -**A:** Currently it is supported only for codes sent via SMS, you can follow [this link](/connections/passwordless/sms-gateway) to read more on how to configure your own SMS gateway to handle the delivery of those codes. - -### Q: How can I use Passwordless as another factor in multi-factor authentication? - -**A:** While Auth0’s passwordless connections (including SMS, email, and Apple *Touch ID*) are not built into the dashboard MFA capability at this time, Auth0’s flexible [rules execution pipeline](/rules) make it easy to use these passwordless authentication methods as part of an MFA flow. Rules are snippets of JavaScript that execute on the Auth0 server as part of the authentication pipeline and give you the flexibility to call APIs or perform arbitrary computations in order to implement customized authentication logic. Simply call the passwordless connection using a redirect rule, and treat it as a [custom MFA provider](/mfa). - -In future versions of passwordless connections, supported MFA providers will be built-in. - -### Q: What are the advantages of Apple *Touch ID* for passwordless authentication? - -**A:** Apple’s *Touch ID* fingerprint identity system is an easy way for users to identify themselves to their iPhone or iPad equipped with a fingerprint scanner. To the user, the application unlocks with the touch of a finger. - -After a one-time enrollment process, each time the user logs into your app, the *Touch ID* passwordless library uses the matched fingerprint to retrieve a private key saved in the IOS key store. *Touch ID* then generates and signs a JWT with that private key and sends it to Auth0. Auth0 validates the JWT with the user’s saved public key, and returns a token authenticating the user. - -The disadvantage of *Touch ID* as a means of authenticating users is that it only works on native IOS apps installed on later-model iPhones and iPads. It does not work on other devices, like Android, nor can it protect a website or web application. Also, a backup password authentication mechanism must be available to handle new or lost devices. Auth0 makes it simple to link accounts so that you can offer *Touch ID* on Apple devices, and SMS or email-based passwordless logins for other mobile platforms and the web. - -Auth0’s standard Lock widget for IOS fully supports *Touch ID* with a very simple UI that is easily styled to your brand identity. You can implement passwordless login for your IOS app with just a few lines of code. - -### Q: Does the Passwordless Lock Widget support Apple *Touch ID*? - -**A:** No. For *Touch ID* passwordless logins, the standard Auth0 IOS lock widget provides all the same benefits. The web-based passwordless lock widget doesn’t support *Touch ID*. - -### Q: Can I combine email or SMS Passwordless authentication with Apple *Touch ID*? - -**A:** Instead of using a backup password to handle new or lost devices, you can use the email or SMS passwordless login and link the two user identities through Auth0’s account linking feature. Your application will recognize the same authenticated user whether they log in through *Touch ID*, or through email or SMS. - -### Q: What happens if a user changes email or phone number? - -**A:** A self-service method for changing email or phone number is not included in this version of passwordless authentication. An administrator can change this information using the Auth0 Dashboard. - -## Security - -### Q: What if someone gains access to a user’s email address? - -**A:** If someone gains access to a user’s email account, they will be able to log in with the user’s passwordless email login with either a link or a code. This is no different than for password-protected accounts, which use email as the back channel for password resets. Typically, you protect against this risk by enabling multi-factor authentication when your application detects activity that appears suspicious such as logging in from a new device, an unknown IP address, or outside the user’s country of residence. - -### Q: What if someone gains access to a user’s SMS messages? - -**A:** As with email, if a user’s SMS messages are compromised, someone can log in as the user with SMS codes. Many phones now have built-in protections against theft, such as fingerprint readers, complex unlock codes, and remote disable and wipe features. The best protection against this risk on your site or application is to use multi-factor authentication, requiring additional *step-up* authentication when the user tries to access sensitive data or perform sensitive actions. - -### Q: How does the system prevent an intercepted one-time code or link from being used to establish an unauthorized session? - -**A:** Think of an intercepted code or link as similar to a compromised email account or stolen phone. Once the link or code is in the wrong hands, it can be used to log in as that user. But codes and links have a short time-to-live (typically 5 minutes) and can only be used once. This limits the opportunity for a hacker to use an intercepted communication to a brief window. Security experts strongly recommend using encrypted end-to-end communication between email servers and clients to prevent the easy interception of email, and you might recommend this safeguard to your end users as part of your documentation. Implementation of multi-factor *step-up* authentication for sensitive data or actions will reduce this risk as well. - -### Q: How could I use Passwordless sign in with *step-up* multi-factor authentication to improve security for more sensitive data or actions? - -**A:** Auth0 features powerful [rules](/rules) - JavaScript snippets which run during the authentication process on the Auth0 server, and allow you to insert additional authentication elements when potentially high-risk logins are detected. For instance, if your application detects a user logging in from a previously unknown IP address with a location outside of the user’s home country, your application might request a password, or ask a security question from inside of Auth0’s authentication flow. - -In future versions of passwordless logins, support for multi-factor *step-up* authentication will be added as part of the passwordless configuration options, replacing the use of rules to implement this security enhancement. - -### Q: Since users can click a link to log in, how can I prevent a phishing attack in which the user receives a fraudulent email that appears legitimate, but contains a link to a site that tricks them into giving up their credentials? - -**A:** Phishing attacks are about stealing credentials (user-names and passwords) through trickery. If there are no passwords to steal, these attacks will become less common. Passwordless logins are a big step in reducing the prevalence of phishing. - -Since passwordless email logins with *magic links* include a link in the email that logs a user into your site, a hacker could use it to create a fraudulent imitation of your legitimate email to trick unsuspecting users into divulging their account credentials for some other site, like their email account. - -There are several effective ways to reduce this risk. One is through education. The email to your users might include a warning not to click the link unless they recently requested to log in, and a notice that they will never be asked for any password when logging into your site. - -Another way is to apply best practices for email authentication when using this feature. There are popular and effective standards for verifying email authenticity including **SPF**, **DKIM**, and **DMARC**. We strongly recommend utilizing these capabilities by [configuring your own email provider](/email) when you set up passwordless logins, including setting up [SPF and DKIM records](/email#spf-configuration). Your email provider may have more detailed information on email authentication and availability for you to explore. - -Since you are using Auth0 passwordless logins, there are no passwords to phish, and phishing attacks cannot compromise the credentials to your site or application. This is great news. Whenever email is a component of an authentication flow however, there is always the potential for phishing (if only for harvesting the credentials of other sites). Passwordless email authentication protects your brand and online reputation, while foiling scammers. - -### Q: How does the system protect against brute-force attacks (code guessing)? - -**A:** The 6-digit numeric codes are one-time use and expire in a short time (5 minutes by default). In addition, Auth0 includes rate-limiting and IP address blocking after several failed attempts. Accordingly, it is impractical to brute-force guess these codes. The application owner will be notified by email of any attempt and can unblock the IP address for a legitimate user. diff --git a/articles/connections/passwordless/index.md b/articles/connections/passwordless/index.md index 4fc10e8ddf..31c7f5faff 100644 --- a/articles/connections/passwordless/index.md +++ b/articles/connections/passwordless/index.md @@ -1,45 +1,114 @@ --- -title: Using Passwordless SMS & Email Authentication with Auth0 +title: Passwordless Connections +description: Learn about passwordless connections, Auth0-supported passwordless methods of authentication, and how to implement passwordless authentication with Auth0. +toc: true url: /connections/passwordless +topics: + - connections + - passwordless + - authentication +contentType: + - index + - concept +useCase: customize-connections --- +# Passwordless Connections -<%= include('./_introduction', { withFingerprint: false }) %> +Passwordless connections allow users to log in without the need to remember a password. Instead, users enter their mobile phone number or email address and receive a one-time code or link, which they can then use to log in. -## Tutorials +When a user authenticates via Passwordless, the user is attached to the connection using Auth0 as the Identity Provider (IdP). Since you can't force users to use the same mobile phone number or email address every time they authenticate, users may end up with multiple user profiles in the Auth0 datastore; you can link multiple user profiles through [account linking](/extensions/account-link). -See the following tutorials for a step-by-step guide on how to implement passwordless authentication for each of these scenarios: +A passwordless connection is another type of connection separate from any existing database, social, or Enterprise connections. Even though a user from an Auth0 user database or social provider might share the same email address, the identity associated with their passwordless connection is distinct. As with linking multiple email addresses or mobile phone numbers used for the passwordless connection, [account linking](/extensions/account-link) can also be used to associate a passwordless identity with identities from other types of connections. -### Passwordless on Single Page Apps +::: note +You cannot create passwordless users from the Auth0 Dashboard. Create them directly from the [Management API](/api/management/v2#!/Users/post_users) if signup is disabled. In the **Connection** field, use **email** for passwordless users using an email address and **sms** for passwordless users using a mobile phone number. +::: - - [Authenticate users with a one time code via SMS](/connections/passwordless/spa-sms) - - [Authenticate users with a one time code via e-mail](/connections/passwordless/spa-email-code) - - [Authenticate users with a magic link via e-mail](/connections/passwordless/spa-email-link) +Passwordless differs from Multi-factor Authentication (MFA) in that only one factor is used to authenticate a user—the one-time code or link received by the user. If you want to require that users log in with a one-time code or link **in addition** to another factor (e.g., username/password or a social Identity Provider, such as Google), see [Multi-factor Authentication (MFA)](/mfa). -### Passwordless on Regular Web Apps +## Benefits - - [Authenticate users with a one time code via SMS](/connections/passwordless/regular-web-app-sms) - - [Authenticate users with a one time code via e-mail](/connections/passwordless/regular-web-app-email-code) - - [Authenticate users with a magic link via e-mail](/connections/passwordless/regular-web-app-email-link) +The benefits of using Passwordless authentication include: -### Passwordless on iOS +* Improved user experience, particularly on mobile applications, because users only need an email address or mobile phone number to sign up. - - [Authenticate users with a one time code via SMS](/connections/passwordless/ios-sms-swift) - - [Authenticate users with a one time code via e-mail](/connections/passwordless/ios-email-swift) - - [Authenticate users with Touch ID](/connections/passwordless/ios-touch-id-swift) +* Enhanced security: Passwords are a major vulnerability as users reuse passwords and are able to share them with others. Passwords are the biggest attack vector and are responsible for a significant percentage of breaches. They also lead to attacks such as credentials stuffing, corporate account takeover, and brute force attacks. -### Passwordless on Android +* Reduces the total cost of ownership, as managing passwords is expensive (implementing password complexity policies, password expiration, password reset processes, password hashing and storing, breached password detection). - - [Authenticate users with a one time code via SMS](/connections/passwordless/android-sms) - - [Authenticate users with a one time code via e-mail](/connections/passwordless/android-email) +## Supported authentication methods -### Passwordless API +Auth0 Passwordless connections support one-time-use codes sent via SMS or email, and magic links sent via email. -If you'd like to build your own implementation or understand how this works under the hood, check out the [complete API reference](/auth-api#passwordless). +
      +
      + +
      +
      +
      -## Advanced Topics +### SMS - - [Send one time codes via your own SMS Gateway](/connections/passwordless/sms-gateway) +When using passwordless authentication with SMS, users: -## Have Questions? +1. Provide a mobile phone number instead of a username/password combination. -You may find the answers on the [Auth0 Passwordless FAQ](/connections/passwordless/faq). + ![Provide Mobile Phone Number](/media/articles/connections/passwordless/passwordless-sms.png) + +2. Receive a one-time-use code via SMS. + +3. Enter the one-time-use code on the login screen to access the application. + +
      +
      + +### Email + +When using passwordless authentication with email, users: + +1. Provide an email address instead of a username/password combination. + +![Provide Email Address](/media/articles/connections/passwordless/passwordless-email.png) + +2. Depending on how you have configured your passwordless connection, receive either a one-time-use code or magic link via email. + +3. Enter the one-time-use code on the login screen (or click the magic link in the email) to access the application. + +
      +
      +
      + +## Implement Passwordless + +To implement passwordless you'll need to make two key decisions: + +- Which authentication factor you want to use (SMS or Email with one-time-use code, Email with Magic Link). +- If you are going to implement authentication using *Embedded Login* or *Universal Login*. + +### Authentication Factor + +The main driver for picking the authentication factor is user experience, and that depends on your application and its target audience. If the application will run on mobile phones, it is highly likely that users will be able to receive SMS messages. If it's an internal web application that is used in an environment where users cannot have their mobile phones with them, Email would be the only choice. + +If you decide to use Email, then you need to decide between an one-time-use code or a magic link. We recommend using one-time-use code as the login flow is more predictable for end users. To learn more refer to the following documents: + + - [Passwordless using Email and one-time-use code](/connections/passwordless/email-otp) + - [Passwordless using Email and Magic Links](/connections/passwordless/email-magic-link) + - [Passwordless using SMS](/connections/passwordless/sms-otp) + +### Implementing Login + +Auth0 supports two ways of implementing authentication: *Embedded Login* and *Universal Login*. + +The industry is aligned in that Universal Login is the proper way to implement authentication in all apps, but in the case of Native Applications, sometimes customers prefer to implement Embedded Login for UX reasons. + + - [Passwordless Authentication with Universal Login](/connections/passwordless/universal-login) + - [Passwordless Authentication with Embedded Login](/connections/passwordless/embedded-login) + +## Keep reading + + * [Best practices for Passwordless Authentication](/connections/passwordless/best-practices) + * [API Documentation](/connections/passwordless/relevant-api-endpoints) + * [Migrating from deprecated Passwordless endpoints](/migrations/guides/migration-oauthro-oauthtoken-pwdless) diff --git a/articles/connections/passwordless/ios-email-objc.md b/articles/connections/passwordless/ios-email-objc.md deleted file mode 100644 index 78cc0c8ac5..0000000000 --- a/articles/connections/passwordless/ios-email-objc.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Using Passwordless Authentication on iOS with e-mails - Objective C ---- - -<%= include('./_using-lock-ios-email', { language: 'objc' }) %> diff --git a/articles/connections/passwordless/ios-email-swift.md b/articles/connections/passwordless/ios-email-swift.md deleted file mode 100644 index a9665b7aa5..0000000000 --- a/articles/connections/passwordless/ios-email-swift.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Using Passwordless Authentication on iOS with e-mails - Swift ---- - -<%= include('./_using-lock-ios-email', { language: 'swift' }) %> diff --git a/articles/connections/passwordless/ios-sms-objc.md b/articles/connections/passwordless/ios-sms-objc.md deleted file mode 100644 index 4624868caa..0000000000 --- a/articles/connections/passwordless/ios-sms-objc.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Using Passwordless Authentication on iOS with SMS ---- - -<%= include('./_using-lock-ios-sms', { language: 'objc' }) %> diff --git a/articles/connections/passwordless/ios-sms-swift.md b/articles/connections/passwordless/ios-sms-swift.md deleted file mode 100644 index 535cffea2a..0000000000 --- a/articles/connections/passwordless/ios-sms-swift.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Using Passwordless Authentication on iOS with SMS in Swift ---- - -<%= include('./_using-lock-ios-sms', { language: 'swift' }) %> diff --git a/articles/connections/passwordless/ios-touch-id-objc.md b/articles/connections/passwordless/ios-touch-id-objc.md deleted file mode 100644 index 92a206cb5f..0000000000 --- a/articles/connections/passwordless/ios-touch-id-objc.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: Passwordless Authentication on iOS with Touch ID (Objective-C) ---- - -<%= include('./_using-lock-ios-touchid', { language: 'objc' }) %> diff --git a/articles/connections/passwordless/ios-touch-id-swift.md b/articles/connections/passwordless/ios-touch-id-swift.md deleted file mode 100644 index 16afa93876..0000000000 --- a/articles/connections/passwordless/ios-touch-id-swift.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: Passwordless Authentication on iOS with Touch ID (Swift) -connection: iOS Touch ID -image: /media/connections/touchid.svg -alias: - - ios-touchid - - ios -seo_alias: ios-touch-id-swift ---- - -<%= include('./_using-lock-ios-touchid', { language: 'swift' }) %> diff --git a/articles/connections/passwordless/ios.md b/articles/connections/passwordless/ios.md deleted file mode 100644 index 1f8932af01..0000000000 --- a/articles/connections/passwordless/ios.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: Using Passwordless Authentication on iOS ---- - -<%= include('./_introduction', { withFingerprint: true }) %> - -## Tutorials for iOS - - - [Authenticate users with a one-time code via SMS](ios-sms-swift) - - [Authenticate users with a one-time code via e-mail](ios-email-swift) - - [Authenticate users with Touch ID](ios-touch-id-swift) diff --git a/articles/connections/passwordless/regular-web-app-email-code.md b/articles/connections/passwordless/regular-web-app-email-code.md deleted file mode 100644 index 420d0c90d5..0000000000 --- a/articles/connections/passwordless/regular-web-app-email-code.md +++ /dev/null @@ -1,105 +0,0 @@ ---- -title: Using Passwordless Authentication with a one-time code via email on Regular Web Apps ---- - -# Passwordless Authentication with a one-time code via e-mail on Regular Web Apps - -<%= include('./_introduction-email', { isMobile: false }) %> - -## Setup - -<%= include('./_setup-email') %> - -<%= include('./_setup-callback', {spa:false} )%> - -## Implementation - -### Use Auth0 UI widget (Lock) - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-node-passwordless-sample', - path: '' -}) %> - -<%= include('./_init-passwordless-lock') %> - -Then you can trigger the login using the `callbackURL` option to specify the endpoint that will handle the server-side authentication: - -``` - - -Login -``` - -This will open a dialog that asks the user for their email address: - -![](/media/articles/connections/passwordless/passwordless-email-request-web.png) - -Then Auth0 will send an email to the user containing the one-time code: - -![](/media/articles/connections/passwordless/passwordless-email-receive-code-web.png) - -Lock will ask for the code that has been emailed to the provided address. The code can then be used as a one-time password to log in: - -![](/media/articles/connections/passwordless/passwordless-email-enter-code-web.png) - -Once the user enters the code received by email, Lock will authenticate the user and redirect to the specified `callbackURL`. - -**NOTE:** You can follow any of the [Regular Web App Quickstarts](/quickstart/webapp) to see how to handle the server-side authentication callback. A sample application is available in the [Node.js Passwordless Authentication repository](https://github.com/auth0/auth0-node-passwordless-sample) on GitHub. - -### Use your own UI - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-node-passwordless-sample', - path: '' -}) %> - -You can perform passwordless authentication in your regular web app with your own custom UI using the [Auth0 JavaScript client library](/libraries/auth0js). - -<%= include('./_init-auth0js', {withCallbackURL:true} ) %> - -You must provide a way for the user to enter an email to which the one-time code will be sent. Then you can begin the passwordless authentication as follows: - -```js -function sendEmail(){ - var email = $('input.email').val(); - auth0.requestEmailCode( { email:email }, function(err) { - if (err) { - alert('error sending e-mail: '+ err.error_description); - return; - } - // the request was successful and you should - // receive the passcode to the specified email - $('.enter-email').hide(); - $('.enter-code').show(); - }); -} -``` - -This will send an email containing the one-time code. The user must now enter the code into your custom UI. Then you can continue with the login as follows: - -```js -function login(){ - var email = $('input.email').val(); - var code = $('input.code').val(); - //submit the passcode to authenticate the phone - auth0.verifyEmailCode({ email: email, code: code }, function(err){ - if (err){ - alert('code verification failed. ' + err.statusCode + ' '+ err.error); - } - }); -}; -``` - -If authentication is successful, the user will be redirected to the `callbackURL` specified in the Auth0 constructor. - -**NOTE:** You can follow any of the [Regular Web App Quickstarts](/quickstart/webapp) to see how to handle the authentication callback on the server-side. diff --git a/articles/connections/passwordless/regular-web-app-email-link.md b/articles/connections/passwordless/regular-web-app-email-link.md deleted file mode 100644 index ac4273eb88..0000000000 --- a/articles/connections/passwordless/regular-web-app-email-link.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: Using Passwordless Authentication with a magic link via email on Regular Web Apps ---- - -# Passwordless Authentication with a magic link via e-mail on Regular Web Apps - -<%= include('./_introduction-email-magic-link') %> - -## Setup - -<%= include('./_setup-email') %> - -<%= include('./_setup-callback', {spa:false} ) %> - -## Implementation - -### Use Auth0 UI widget (Lock) - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-node-passwordless-sample', - path: '' -}) %> - -<%= include('./_init-passwordless-lock') %> - -Then you can trigger the login using the `callbackURL` option to specify the endpoint that will handle the authentication on the server-side: - -```html - - -Login -``` - -This will open a dialog that asks the user for their email address. - -![](/media/articles/connections/passwordless/passwordless-email-request-web.png) - -Then Auth0 will send an email to the user containing the magic link. After clicking the link, the user will be signed in to your application automatically and redirected to the specified `callbackURL`. - -**NOTE:** You can follow any of the [Regular Web App Quickstarts](/quickstart/webapp) to see how to handle the authentication callback server side. - -### Use your own UI - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-node-passwordless-sample', - path: '' -}) %> - -You can perform passwordless authentication in your regular web app with your own custom UI using the [Auth0 JavaScript client library](/libraries/auth0js). - -<%= include('./_init-auth0js', {withCallbackURL:true} ) %> - -You must provide a way for the user to enter an email to which the magic link will be sent. Then you can begin the passwordless authentication as follows: - -```js -function sendEmail(){ - var email = $('input.email').val(); - auth0.requestMagicLink({ email: email , send: 'link'}, function(err) { - if (err) { - alert('error sending e-mail: ' + err.error_description); - return; - } - // the request was successful and you should - // receive the magic link in the specified email - alert('email sent!'); - }); -} -``` - -This will send an email containing the magic link. - -After clicking the link, the user will be automatically signed in to your application and redirected to the `callbackURL` specified in the Auth0 constructor. - -**NOTE:** You can follow any of the [Regular Web App Quickstarts](/quickstart/webapp) to see how to handle the authentication callback on the server-side. diff --git a/articles/connections/passwordless/regular-web-app-sms.md b/articles/connections/passwordless/regular-web-app-sms.md deleted file mode 100644 index 984425e9b9..0000000000 --- a/articles/connections/passwordless/regular-web-app-sms.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -title: Using Passwordless Authentication in a Regular Web App with SMS ---- - -# Authenticate users with a one-time code via SMS in a Regular Web App - -<%= include('./_introduction-sms', { isMobile: false }) %> - -## Setup - -<%= include('./_setup-sms-twilio') %> - -<%= include('./_setup-callback', {spa:false} ) %> - -## Implementation - -### Use Auth0 UI widget (Lock) - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-node-passwordless-sample', - path: '' -}) %> - -<%= include('./_init-passwordless-lock') %> - -Then you can trigger the login widget with the following code: - -```html - - -Login -``` - -This will open a dialog that asks the user for their phone number. - -![](/media/articles/connections/passwordless/passwordless-sms-enter-phone-web.png) - -Then Auth0 will use Twilio to send an SMS to the user containing the one-time code: - -
      SMS one-time code
      - -Lock will ask for the code that has been sent to the provided number via SMS. The code can then be used as a one-time password to log in: - -![](/media/articles/connections/passwordless/passwordless-sms-enter-code-web.png) - -Once the user enters the code received via SMS, Lock will authenticate the user and redirect to the specified `callbackURL`. - -**NOTE:** You can follow any of the [Regular Web App Quickstarts](/quickstart/webapp) to see how to handle the server-side authentication callback. - -### Use your own UI - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-node-passwordless-sample', - path: '' -}) %> - -You can perform passwordless authentication in your regular web app with your own custom UI using the [Auth0 JavaScript client library](/libraries/auth0js). - -<%= include('./_init-auth0js', {withCallbackURL:true} ) %> - -You must provide a way for the user to enter a phone number to which the one-time code will be sent via SMS. Then you can begin the passwordless authentication as follows: - -```js -function sendSMS(){ - var phoneNumber = $('input.phone-number').val(); - auth0.requestSMSCode({ phoneNumber:phoneNumber}, function(err) { - if (err) { - alert('error sending SMS: '+ err.error_description); - return; - } - // the request was successful and you should - // receive the passcode to the specified phone - $('.enter-phone').hide(); - $('.enter-code').show(); - }); -} -``` - -This will send an SMS containing the one-time code. The user must now enter the code into your custom UI. Then you can continue with the login as follows: - -```js -function login(){ - var phone = $('input.phone-number').val(); - var code = $('input.code').val(); - //submit the passcode to authenticate the phone - auth0.verifySMSCode({ phoneNumber: phone, code: code }, function(err){ - alert('code verification failed. ' + err.statusCode + ' '+ err.error); - }); -}; -``` - -If authentication is successful, the user will be redirected to the `callbackURL` specified in the Auth0 constructor. - -**NOTE:** You can follow any of the [Regular Web App Quickstarts](/quickstart/webapp) to see how to handle the authentication callback on the server-side. diff --git a/articles/connections/passwordless/regular-web-app.md b/articles/connections/passwordless/regular-web-app.md deleted file mode 100644 index 9f931e982d..0000000000 --- a/articles/connections/passwordless/regular-web-app.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: Using Passwordless Authentication on a Regular Web Application ---- - -<%= include('./_introduction', { withFingerprint: false }) %> - -## Tutorials for Regular Web Applications - - - [Authenticate users with a one-time code via SMS](regular-web-app-sms) - - [Authenticate users with a one-time code via e-mail](regular-web-app-email-code) - - [Authenticate users with a magic link via e-mail](regular-web-app-email-link) diff --git a/articles/connections/passwordless/sample-use-cases-rules.md b/articles/connections/passwordless/sample-use-cases-rules.md new file mode 100644 index 0000000000..c8e12ff952 --- /dev/null +++ b/articles/connections/passwordless/sample-use-cases-rules.md @@ -0,0 +1,52 @@ +--- +title: Sample Use Cases - Rules with Passwordless Authentication +description: See examples using rules with passwordless connections. +topics: + - connections + - passwordless + - rules +contentType: concept +useCase: customize-connections +--- +# Sample Use Cases: Rules with Passwordless Authentication + +With [rules](/rules), you can handle more complicated cases than is possible with [passwordless connections](/connections/passwordless) alone. For instance, you can add extra precautions to further ensure possession of an email address or device. + +## Require Multi-factor Authentication for users who are outside the corporate network + +Let's say you want to require [multi-factor authentication (MFA)](/multifactor-authentication) for any users who are accessing the application using a passwordless connection from outside your corporate network. + +Using a rule, you can check whether a user is authenticating using a passwordless method (`sms`, `email`) and if their session IP falls outside of the designated corporate network, prompt them for a second authentication factor. + +::: note +You could also trigger this rule based on other criteria, such as whether the current IP matches the user's IP allowlist or whether geolocating the user reveals they are in a different country from the one listed in their user profile. +::: + +To do this, you would [create the following rule](/dashboard/guides/rules/create-rules): + +```js +function(user, context, callback) { + + const ipaddr = require('ipaddr.js'); + const corp_network = "192.168.1.134/26"; + const current_ip = ipaddr.parse(context.request.ip); + + // is auth method passwordless and IP outside corp network? + const passwordlessOutside = context.authentication.methods.find( + (method) => ( + ((method.name === 'sms') || (method.name === 'email')) && + (!current_ip.match(ipaddr.parseCIDR(corp_network))) + ) + ); + + // if yes, then require MFA + if (passwordlessOutside) { + context.multifactor = { + provider: 'any', + allowRememberBrowser: false + }; + } + + callback(null, user, context); +} +``` diff --git a/articles/connections/passwordless/sms-gateway.md b/articles/connections/passwordless/sms-gateway.md deleted file mode 100644 index 1e5d39e384..0000000000 --- a/articles/connections/passwordless/sms-gateway.md +++ /dev/null @@ -1,114 +0,0 @@ ---- -title: Send one time codes via your own SMS Gateway ---- - -# Send one time codes via your own SMS Gateway - -By default the SMS connection will use Twilio to send the one time code. If you already have your own infrastructure to send text messages cannot or might not want to use Twilio. - -Instead you'll want your own infrastructure to handle the delivery of these one time codes. - -## Configure your SMS Gateway - -The configuration of your own SMS Gateway currently needs to happen through the Management API. You would first need to get your connections (strategy: `sms`) from the [GET connections endpoint](/api/v2#!/Connections/get_connections). - -This will return your SMS connection with your Twilio settings: - -``` -[ - { - "id": "con_...", - "options": { - "strategy": "sms", - "twilio_sid": "...", - "twilio_token": "...", - "from": "+1 234 567", - "template": "Your verification code is: @@password@@", - "brute_force_protection": true, - "disable_signup": false, - "name": "sms", - "syntax": "md_with_macros", - "totp": { - "time_step": 300, - "length": 6 - } - }, - "strategy": "sms", - "name": "sms", - "enabled_clients": [ - ... - ] - } -] -``` - -You can now modify the options of the connection: - - - `provider`: Set this to `sms_gateway` - - `gateway_url`: Set this to the URL of your SMS Gateway. Note that Auth0 must be able to reach it in order for this to work. - -``` -{ - "options": { - "strategy": "sms", - "provider": "sms_gateway", - "gateway_url": "{URL_OF_YOUR_GATEWAY}", - "from": "+1 234 567", - "template": "Your verification code is: @@password@@", - "brute_force_protection": true, - "disable_signup": false, - "name": "sms", - "syntax": "md_with_macros", - "totp": { - "time_step": 300, - "length": 6 - } - } -} -``` - -You can then send the updated configuration to the Management API using the [PATCH connections endpoint](/api/v2#!/Connections/patch_connections_by_id). - -After updating the connection for any user that signs up or authenticates using the Passwordless SMS connection the following payload will be sent to your SMS gateway: - -``` -{ - "recipient": "+1 399 999", - "body": "Your verification code is: 12345", - "sender": "+1 234 567", -} -``` - -## Configure an authenticated SMS Gateway - -The previous settings assume your SMS Gateway accepts non-authenticated requests. The `sms_gateway` provider also allows you to configure token based authentication (using `gateway_authentication`): - -``` -{ - "options": { - "strategy": "sms", - "provider": "sms_gateway", - "gateway_url": "{URL_OF_YOUR_GATEWAY}", - "gateway_authentication": { - "method": "bearer", - "subject": "urn:Auth0", - "audience": "urn:MySmsGateway", - "secret": "MySecretToSignTheToken" - }, - "from": "+1 234 567", - "template": "Your verification code is: @@password@@", - "brute_force_protection": true, - "disable_signup": false, - "name": "sms", - "syntax": "md_with_macros", - "totp": { - "time_step": 300, - "length": 6 - } - } -} -``` - -With this configuration, when the payload is sent to the SMS Gateway a JWT will be added to the `Authorization` header which contains a token with the `subject` and `audience` configured in the connection and signed with the `secret`. - -Additionally, if you secret is base64 url encoded you can set `options.secret_base64_encoded` to `true`. diff --git a/articles/connections/passwordless/sms.md b/articles/connections/passwordless/sms.md deleted file mode 100644 index 306dc159ba..0000000000 --- a/articles/connections/passwordless/sms.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: SMS Passwordless Authentication -connection: SMS -url: /connections/passwordless/sms -image: -alias: - - sms -seo_alias: sms ---- - -# Authenticate users with a one-time code via SMS - -<%= include('./_introduction-sms', { isMobile: false }) %> - -## Setup - -<%= include('./_setup-sms-twilio') %> - -## Web Tutorials - -- [Single-page Applications](/connections/passwordless/spa-sms) -- [Regular Web Applications](/connections/passwordless/regular-web-app-sms) - -## Mobile Tutorials - - - [iOS](ios-sms-swift) - - [Android](android-sms) diff --git a/articles/connections/passwordless/spa-email-code.md b/articles/connections/passwordless/spa-email-code.md deleted file mode 100644 index ad83994d3f..0000000000 --- a/articles/connections/passwordless/spa-email-code.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: Using Passwordless Authentication with a one-time code via email on SPA ---- - -# Authenticate users with a one-time code via e-mail on SPA - -<%= include('./_introduction-email', { isMobile: false }) %> - -## Setup - -<%= include('./_setup-email') %> - -<%= include('./_setup-cors') %> - -## Implementation - -### Use Auth0 UI widget (Lock) - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-jquery-passwordless-sample', - path: '' -}) %> - -<%= include('./_init-passwordless-lock') %> - -Then you can trigger the login with the following code: - -```html - - -Login -``` - -First, this will open a dialog that asks the user for their email address: - -![](/media/articles/connections/passwordless/passwordless-email-request-web.png) - -Then Auth0 will send an email to the user containing the one-time code: - -![](/media/articles/connections/passwordless/passwordless-email-receive-code-web.png) - -Lock will ask for the code that has been emailed to the provided address. The code can then be used as a one-time password to log in. - -![](/media/articles/connections/passwordless/passwordless-email-enter-code-web.png) - -Once the user enters the code received by email, Lock will authenticate them and call the callback function where the `id_token` and profile will be available. - -### Use your own UI - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-jquery-passwordless-sample', - path: '' -}) %> - -You can perform passwordless authentication in your SPA with your own custom UI using the [Auth0 JavaScript client library](/libraries/auth0js). - -<%= include('./_init-auth0js', {withCallbackURL:false} ) %> - -You must provide a way for the user to enter the email to which the one-time code will be sent. Then you can begin the passwordless authentication with the following code: - -```js - -function sendEmail(){ - var email = $('input.email').val(); - auth0.requestEmailCode({ email: email }, function(err) { - if (err) { - alert('error sending e-mail: ' + err.error_description); - return; - } - // the request was successful and you should - // receive the code to the specified email - $('.enter-email').hide(); - $('.enter-code').show(); - }); -} -``` - -This will send an email containing the one-time code. The user must now enter the code into your custom UI. Then you can continue with the login as follows: - -```js -function login(){ - var email = $('input.email').val(); - var code = $('input.code').val(); - - //submit the passcode to complete authentication - auth0.verifyEmailCode({ email: email, code: code }, function(err, profile, id_token, access_token) { - if (err) { - alert('Couldn\'t login ' + err.message); - } else { - - //save id_token to local storage - localStorage.setItem('userToken', id_token); - - //use profile - alert('Welcome '+ profile.name); - } - }); -} -``` diff --git a/articles/connections/passwordless/spa-email-link.md b/articles/connections/passwordless/spa-email-link.md deleted file mode 100644 index 4858b03c43..0000000000 --- a/articles/connections/passwordless/spa-email-link.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -title: Using Passwordless Authentication with a Magic Link via email on SPA ---- - -# Authenticate users with a Magic Link via e-mail on SPA - -<%= include('./_introduction-email-magic-link') %> - -## Setup - -<%= include('./_setup-email') %> - -<%= include('./_setup-callback', {spa:true} ) %> - -## Implementation - -### Use Auth0 UI widget (Lock) - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-jquery-passwordless-sample', - path: '' -}) %> - -<%= include('./_init-passwordless-lock') %> - -Then you can trigger the passwordless authentication using a magic link with the following code: - -```html - - -Login -``` - -The user will receive an email with the magic link. Once the user clicks on this link, Auth0 will handle the authentication and redirect back to the application with the token as the hash location. You can parse the hash and retrieve the full user profile as follows: - -```js -//parse hash on page load -$(document).ready(function(){ - var hash = lock.parseHash(window.location.hash); - - if (hash && hash.error) { - alert('There was an error: ' + hash.error + '\n' + hash.error_description); - } else if (hash && hash.id_token) { - //use id_token for retrieving profile. - localStorage.setItem('id_token', hash.id_token); - //retrieve profile - lock.getProfile(hash.id_token, function (err, profile) { - if (err){ - //handle err - } else { - //use user profile - } - }); - } -}); -``` - -### Use your own UI - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-jquery-passwordless-sample', - path: '' -}) %> - -You can perform passwordless authentication with a magic link in your single-page application using your own UI with the [Auth0 JavaScript client library](/libraries/auth0js). - -<%= include('./_init-auth0js', {withCallbackURL:false} ) %> - -You can then trigger the passwordless login using a magic link with the following code: - -```js -function sendMagicLink(){ - var email = $('input.email').val(); - auth0.requestMagicLink({ email: email }, function(err) { - if (err) { - alert('error sending e-mail: ' + err.error_description); - return; - } - // the request was successful and you should - // receive the magic link in the specified email - }); -} -``` - -Once the user clicks the magic link, they will be redirected to the application callback URL, where you will need to parse the token with `auth0.parseHash`: - -```js -//parse hash on page load -$(document).ready(function(){ - var hash = auth0.parseHash(window.location.hash); - - if (hash && hash.error) { - alert('There was an error: ' + hash.error + '\n' + hash.error_description); - } else if (hash && hash.id_token) { - //use id_token for retrieving profile. - localStorage.setItem('id_token', hash.id_token); - //retrieve profile - auth0.getProfile(hash.id_token, function (err, profile) { - if (err){ - //handle err - } else { - //use user profile - } - }); - } -}); -``` diff --git a/articles/connections/passwordless/spa-sms.md b/articles/connections/passwordless/spa-sms.md deleted file mode 100644 index cc7e01fc48..0000000000 --- a/articles/connections/passwordless/spa-sms.md +++ /dev/null @@ -1,113 +0,0 @@ ---- -title: Using Passwordless Authentication in SPA with SMS ---- - -# Authenticate users with a one-time code via SMS in a SPA - -<%= include('./_introduction-sms', { isMobile: true }) %> - -## Setup - -<%= include('./_setup-sms-twilio') %> - -<%= include('./_setup-cors') %> - -## Implementation - -### Use Auth0 UI widget (Lock) - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-jquery-passwordless-sample', - path: '' -}) %> - -<%= include('./_init-passwordless-lock') %> - -You can then trigger the login widget with the following code: - -```html - - -Login -``` - -This will open a dialog that asks the user for their phone number. - -![](/media/articles/connections/passwordless/passwordless-sms-enter-phone-web.png) - -Then Auth0 will use Twilio to send to the user an SMS containing the one-time code: - -
      SMS one-time code
      - -Lock will ask for the code that has been sent via SMS to the provided number. The code can then be used as a one-time password to log in: - -![](/media/articles/connections/passwordless/passwordless-sms-enter-code-web.png) - -If the code is correct, the user will be authenticated. This will call the callback of the `lock.sms` function where the `id_token`, `refresh_token` and user profile are typically stored. Then the user will be allowed to continue to the authenticated part of the application. - -### Use your own UI - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-jquery-passwordless-sample', - path: '' -}) %> - -You can perform passwordless authentication in your SPA with your own custom UI using the [Auth0 JavaScript client library](/libraries/auth0js). - -<%= include('./_init-auth0js', {withCallbackURL:false} ) %> - -You must provide a way for the user to enter a phone number to which the SMS will be sent. Then you can begin the passwordless authentication as follows: - -```js -function sendSMS(){ - var phoneNumber = $('input.phone-number').val(); - auth0.requestSMSCode({ phoneNumber:phoneNumber }, function(err) { - if (err) { - alert('error sending SMS: '+ err.error_description); - return; - } - // the request was successful and you should - // receive the passcode to the specified phone - $('.enter-phone').hide(); - $('.enter-code').show(); - }); -} -``` - -This will send an SMS to the provided phone number. The user must now enter the code into your custom UI. Then you can continue with the login as follows: - -```js -function login(){ - var phone = $('input.phone-number').val(); - var code = $('input.code').val(); - //submit the passcode to authenticate the phone - auth0.verifySMSCode({ phoneNumber: phone, code: code }, function (err, profile, id_token, access_token) { - if (err){ - alert('Couldn\'t login ' + err.message); - } else { - // the authentication was successful - // you can use profile, id_token and access_token - localStorage.setItem('userToken', id_token); - alert('Welcome ' + profile.name ); - } - }); -}; -``` diff --git a/articles/connections/passwordless/spa.md b/articles/connections/passwordless/spa.md deleted file mode 100644 index 9b29daee11..0000000000 --- a/articles/connections/passwordless/spa.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: Using Passwordless Authentication on a Single Page Application ---- - -<%= include('./_introduction', { withFingerprint: false }) %> - -## Tutorials for Single-page Applications - - - [Authenticate users with a one-time code via SMS](spa-sms) - - [Authenticate users with a one-time code via e-mail](spa-email-code) - - [Authenticate users with a magic link via e-mail](spa-email-link) - -**NOTE:** Sample applications are available in the [jQuery Passwordless Authentication repository](https://github.com/auth0/auth0-jquery-passwordless-sample) on GitHub. diff --git a/articles/connections/passwordless/universal-login.md b/articles/connections/passwordless/universal-login.md new file mode 100644 index 0000000000..2cb64289ec --- /dev/null +++ b/articles/connections/passwordless/universal-login.md @@ -0,0 +1,16 @@ +--- +title: Passwordless Authentication with Universal Login +description: Passwordless Authentication with Universal Login +toc: true +topics: + - connections + - passwordless + - authentication +--- +# Passwordless Authentication with Universal Login + +[Universal Login](/universal-login) is Auth0's implementation of the login flow. 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. It's the preferred way to implement Passwordless Authentication. + +To implement Passwordless Authentication in Universal Login you need to customize the login page's HTML. To learn how to do it, please refer to [Configure Universal Login with Passwordless](/dashboard/guides/universal-login/configure-login-page-passwordless). + +To integrate Universal Login in your application, please refer to our [Quickstarts](/quickstarts), where you'll find complete examples for all application types and popular platforms. diff --git a/articles/connections/passwordless/use-sms-gateway-passwordless.md b/articles/connections/passwordless/use-sms-gateway-passwordless.md new file mode 100644 index 0000000000..14b0df73e8 --- /dev/null +++ b/articles/connections/passwordless/use-sms-gateway-passwordless.md @@ -0,0 +1,164 @@ +--- +title: Set Up Custom SMS Gateway for Passwordless Connections +topics: + - connections + - passwordless + - sms +contentType: how-to +useCase: customize-connections +--- +# Set Up Custom SMS Gateway for Passwordless Connections + +This guide will show you how to use a custom SMS gateway to send out your one-time-use codes. + +By default, [Passwordless SMS connections](/connections/passwordless#supported-authentication-methods) use [Twilio](https://www.twilio.com/) to send out one-time use codes. However, if you have a custom SMS gateway, you can modify your connection to use that instead. + +::: note +Auth0 does **not** support basic SMS authentication. +::: + +1. Set up a SMS passwordless connection. To learn how, see [Set Up Passwordless Connections](/connections/passwordless#implement-passwordless). + +2. Get an [Access Token for Management API](/api/management/v2/tokens). You will need this to make calls to the Management API to update your Passwordless connection. + +3. Use the [GET Connections](/api/management/v2#!/Connections/get_connections) endpoint to retrieve information about the connections associated with your tenant. More specifically, you need to get the ID for your Passwordless SMS connection so that you can use it in a later API call that updates the connection itself. + + Be sure to replace `ACCESS_TOKEN` with the token you obtained in step 1 before making the following call to the Management API: + +```har +{ + "method": "GET", + "url": "https://your-auth0-tenant.com/api/v2/connections", + "headers": [ + { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN_HERE" } + ] +} +``` + + The response from the endpoint will be an array of objects. Each object represents one connection affiliated with your tenant. + +4. Identify your connection ID. You can find the ID associated with your Passwordless connection by reviewing the array of objects you returned from the [GET Connections](/api/management/v2#!/Connections/get_connections) endpoint in step 2. + + To find the specific object for your Passwordless connection, you can search for the `"name": "sms"` property. Notice that the connection currently displays the Twilio information you provided during the setup process. + +```json +[ + { + "id": "con_UX85K7K0N86INi9U", + "options": { + "disable_signup": false, + "name": "sms", + "twilio_sid": "TWILIO_SID", + "twilio_token": "TWILIO_AUTH_TOKEN", + "from": "+15555555555", + "syntax": "md_with_macros", + "template": "Your SMS verification code is: @@password@@", + "totp": { + "time_step": 300, + "length": 6 + }, + "messaging_service_sid": null, + "brute_force_protection": true + }, + "strategy": "sms", + "name": "sms", + "is_domain_connection": false, + "realms": [ + "sms" + ], + "enabled_clients": [] + } +] +``` + +5. Update the connection. You can do this by making a PATCH call to the [Update a Connection](/api/management/v2#!/Connections/patch_connections_by_id) endpoint. More specifically, you'll be updating the connections `options` object to provide information about the SMS Gateway. + + **You must send the entire `options` object with each call; otherwise, you will overwrite the existing data that is not included in subsequent calls.** + + Make the following changes: + + * Remove both the `twilio_sid` and `twilio_token` parameters + * Add the `provider` parameter, and set it to `sms_gateway`) + * Add the `gateway_url` parameter, and set it to the URL of your SMS gateway. Auth0 **must** be able to reach this URL for it to use your gateway to send messages on your behalf) + + Your payload will look something like the following: + +```json +{ + "options": { + "strategy": "sms", + "provider": "sms_gateway", + "gateway_url": "URL_OF_YOUR_GATEWAY", + "from": "+1 234 567", + "template": "Your verification code is: @@password@@", + "brute_force_protection": true, + "forward_req_info": "true", + "disable_signup": false, + "name": "sms", + "syntax": "md_with_macros", + "totp": { + "time_step": 300, + "length": 6 + } + }, + "is_domain_connection": false, + "enabled_clients": [] +} +``` + +## Authenticated requests + +If your SMS Gateway accepts authenticated requests that are token-based, you can add the following to your `options` object: + +```json +"gateway_authentication": { + "method": "bearer", + "subject": "urn:Auth0", + "audience": "urn:MySmsGateway", + "secret": "MySecretToSignTheToken", + "secret_base64_encoded": false +} +``` + +When you include `gateway_authentication` in your **options** object, Auth0 adds a [JSON Web Token](/tokens/concepts/jwts) to the `Authorization` header whenever it sends requests to your SMS gateway. The token contains the `gateway_authentication.subject` and `gateway_authentication.audience` values, and is signed with `gateway_authentication.secret`. + +If your secret is base64-url-encoded, set `secret_base64_encoded` to `true`. + +6. Once you have updated your connection, Auth0 will send the following to your SMS Gateway every time a user signs up or logs in with your Passwordless connection. + +```json +{ + "recipient": "+1 399 999", + "body": "Your verification code is: 12345", + "sender": "+1 234 567" +} +``` + +If you set the `forward_req_info` property in the ****options** object to `true`, the gateway will also receive information from the HTTP request that initiated the Passwordless process. This includes the IP address of the client calling `/passwordless/start` and its User Agent. + +```json +{ + "recipient": "+1 399 999", + "body": "Your verification code is: 12345", + "sender": "+1 234 567", + "req" : { + "ip" : "167.56.227.117", + "user-agent" : "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.109 Safari/537.36" + } +} +``` + +## Error handling + +Auth0 will only consider the HTTP code returned from the SMS Gateway; it ignores the rest of the response (e.g., response body and response type). + +If the SMS Gateway returns an HTTP code other than 200, the `/passwordless/start` endpoint will return an HTTP 400 code and a response the looks like the following: + +``` +{ + "error":"sms_provider_error", + "error_description":"Unexpected response while calling the SMS gateway: "} +} +``` + +If the SMS Gateway returns HTTP 401, the `error_description` will be **Authentication failed while calling the SMS gateway: 401**. (Please note that the error description verbiage is subject to change at any time.) diff --git a/articles/connections/passwordless/user-guide.md b/articles/connections/passwordless/user-guide.md deleted file mode 100644 index 5e186ed750..0000000000 --- a/articles/connections/passwordless/user-guide.md +++ /dev/null @@ -1,81 +0,0 @@ -# User Guide: Passwordless - -If you are using an app that allows for **Passwordless** authentication, you can register using either your **email address** or your **mobile phone number** instead of a login/password combination. Depending on which piece of information you provide, you will then access the app using a link that has been emailed to you or by providing a code that has been emailed or sent to you via SMS. - -* [Register and Authenticate Using Email](#register-and-authenticate-using-email) -* [Register and Authenticate Using SMS](#register-and-authenticate-using-sms) -* [Troubleshooting](#troubleshooting) - -## Register and Authenticate Using Email - -![](/media/articles/connections/passwordless/passwordless-email-request-web.png) - -If you provide your **email address**, you will receive an email containing either: - -* a link you click on to authenticate yourself, or; -* a code you provide to the app to authenticate yourself. - -### Authentication Using a Magic Link Received via Email - -You may opt to register and authenticate yourself using a magic link sent via email. Upon receipt, you will need to click on the link to access the app. - -![](/media/articles/connections/passwordless/passwordless-email-receive-link.png) - -### Authentication Using a One-time Use Code Received via Email - -You may opt to register and authenticate yourself using a one-time use code that you receive via email. - -![](/media/articles/connections/passwordless/passwordless-email-receive-code-web.png) - -Once received, you can return to the app to enter the code and authenticate yourself. - -![](/media/articles/connections/passwordless/passwordless-email-enter-code-web.png) - -## Register and Authenticate Using SMS - -![](/media/articles/connections/passwordless/passwordless-sms-enter-phone-web.png) - -If you provide your **mobile phone number**, you will receive a code that you will provide to the app to validate yourself. - -
      SMS one-time code
      - -The code can then be used as a one-time password to log in. - -![](/media/articles/connections/passwordless/passwordless-sms-enter-code-web.png) - -## Troubleshooting - -The following section contains troubleshooting information that might be useful to you. - -### Can I share my password with others? - -No, because Passwordless authentication removes the need for and use of passwords. - -### How long is the one-time use code/link valid? - -The amount of time the one-time use authentication code/link is valid can be set and changed by your app's administrator. It is unlikely, however, that the code/link is valid for a very long period of time, so you should use it as soon as possible. - -### What if I am using multiple devices? - -If you've requested your authentication links or codes via email, you can use any device that is capable of accessing that email account. You simply need to log in to your email account to get the required information and then provide the information when attempting to access the app. - -If the device you're using doesn't have access to the required email account, you can forward the email to an account accessible using that device. - -If you are requesting an authentication code via SMS message, you can use any device that will receive messages sent to the phone number associated with your account. Once you have that information, you will be able to provide the code to gain access to the application. - -### What happens if I don't receive the authentication emails/SMS messages I requested? - -If you do not receive your requested email or SMS message, please do not request a new one. Instead, check the following: - -#### Email - -* Did the email get filed into your junk/spam folder? -* Has there been some type of server delay preventing you from receiving your email? - -### SMS Message - -* Do you have the connectivity to receive messages? - -### What happens if I request and receive multiple authentication emails and/or SMS messages? - -If you accidentally request more than one email or SMS message containing magic links or authentication codes, the last **five** codes will be valid. Once you successfully log in using any of the codes/links, **all** of the existing codes/links will be invalidated. diff --git a/articles/connections/social/37signals.md b/articles/connections/social/37signals.md deleted file mode 100644 index e61b284038..0000000000 --- a/articles/connections/social/37signals.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -connection: Basecamp -image: /media/connections/basecamp.png -alias: - - basecamp - - thirtysevensignals -seo_alias: 37signals -description: How to obtain a Client Id and Client Secret for 37Signals. ---- - -# Obtain a *Client Id* and *Client Secret* for 37Signals - -To configure a 37Signals OAuth2 connection, you will need to register your Auth0 tenant on the [37Signals Integration Portal](https://integrate.37signals.com/). - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -### 1. Register a new App - -Log into the Integration Portal. Select **New Application** and enter some general information about your app (name, website, logo) on first page: - -![](/media/articles/connections/social/37signals/37signals-register-1.png) - -### 2. Define the scope of access and enter your callback URL - -On the next page, select which 37Signals applications you want to access, and enter your Auth0 callback URL in the **Redirect URI** field: - - https://${account.namespace}/login/callback - -![](/media/articles/connections/social/37signals/37signals-register-2.png) - -### 3. Generate your *Client Id* and *Client Secret* - -Once your app is registered, a `Client Id` and `Client Secret` are generated for you. - -![](/media/articles/connections/social/37signals/37signals-register-4.png) - -Go to your Auth0 Dashboard and select **Connections > Social**, then choose **37Signals**. Copy the `Client Id` and `Client Secret` from the Integration Portal into the fields on this page. - -![](/media/articles/connections/social/37signals/37signals-add-connection.png) - -<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/amazon.md b/articles/connections/social/amazon.md index 5699e6f2bf..4d135ba0b4 100644 --- a/articles/connections/social/amazon.md +++ b/articles/connections/social/amazon.md @@ -1,45 +1,28 @@ --- +title: Connect Apps to Amazon connection: Amazon Web Services image: /media/connections/amazon.png alias: - aws - amazon-web-services seo_alias: amazon -index: 9 -description: How to obtain a Client Id and Client Secret for Amazon. +toc: true +public: true +index: 1 +description: Learn how to add login functionality to your app with Amazon. You will need to obtain a Client Id and Client Secret for Amazon. +topics: + - connections + - social + - amazon +contentType: how-to +useCase: + - customize-connections + - add-idp --- - -# Obtain a *Client Id* and *Client Secret* for Amazon - -To configure an Amazon connection with Auth0, you will need to register your app on the Amazon portal. - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -### 1. Add a new Application -Log into [Login with Amazon](http://login.amazon.com) and select **App Console**. - -![](/media/articles/connections/social/amazon/amazon-login-1.png) - -### 2. Register a new application - -Click on the **Register New Application** button and enter a **Name**, **Description**, and **Privacy Notice URL** for your app. Click **Save**. - -![](/media/articles/connections/social/amazon/amazon-register-app.png) - -### 3. Enter your callback URL - -Expand the **Web Settings** section. Enter your Auth0 JavaScript origin in the **Allowed JavaScript Origins** field and callback URLs in the **Allowed Return URLs** field. The JavaScript origin address for your app should be: - - https://${account.namespace}/login/ - -and the callback address for your app should be: - - https://${account.namespace}/login/callback - -### 4. Copy your *Client Id* and *Client Secret* - -Go to your Auth0 Dashboard and select **Connections > Social**, then choose **Amazon**. Copy the `Client Id` and `Client Secret` from the **Web Settings** of your app on Amazon into the fields on this page on Auth0. - -![](/media/articles/connections/social/amazon/amazon-add-connection.png) - +<%= include('../../../snippets/social/amazon/0') %> +<%= include('../../../snippets/social/amazon/1') %> +<%= include('../../../snippets/social/amazon/2') %> +<%= include('../../../snippets/social/amazon/3') %> +<%= include('../../../snippets/social/amazon/4') %> +<%= include('../../../snippets/social/amazon/5') %> <%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/aol.md b/articles/connections/social/aol.md deleted file mode 100644 index d28ed46dee..0000000000 --- a/articles/connections/social/aol.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -connection: AOL Reader -image: /media/connections/aol.png -seo_alias: aol -description: How to obtain a Client Id and Client Secret for AOL Reader. ---- - -# Obtain an *Client Id* and *Client Secret* for AOL Reader - -To configure an AOL Reader connection with Auth0, contact [AOL Reader Support](http://help.reader.aol.com/knowledgebase) and provide the following information: - -* Your name -* Your e-mail address -* The name of your app -* Your callback URL: - - `https://${account.namespace}/login/callback` - -<%= include('../_quickstart-links.md') %> \ No newline at end of file diff --git a/articles/connections/social/apple-native.md b/articles/connections/social/apple-native.md new file mode 100644 index 0000000000..f633400742 --- /dev/null +++ b/articles/connections/social/apple-native.md @@ -0,0 +1,91 @@ +--- +title: Add Sign In with Apple to Native iOS Apps +connection: Apple Native +image: /media/connections/apple.png +public: true +description: Learn how to add native login functionality to your native app with Apple. +topics: + - authentication + - connections + - social + - apple +contentType: how-to +useCase: + - add-login + - customize-connections + - add-idp +--- +# Add Sign In with Apple to Native iOS Apps + +You can add functionality to your native iOS application to allow your users to authenticate using Sign In with Apple. For more implementation details, you can try the Auth0 [iOS Swift - Sign In with Apple Quickstart](/quickstart/native/ios-swift-siwa). + +## How it works + +For a native app, the Sign in with Apple login flow works as follows: + +![Sign In with Apple Authentication Flow](/media/articles/connections/social/apple/apple-siwa-authn-flow.png) + +* **Steps 1 & 2**: User authenticates via Apple's SDK on their iOS device, and receive an authorization code in the response. The user does not have to leave the app and use a browser to log in. + ::: warning + Avoid using a nonce. It will cause the request to Apple to fail in step 4 and Auth0 will return a 400 error to the user: "Error from Apple connection." + ::: +* **Step 3**: The application calls Auth0's `/oauth/token` endpoint to exchange the Apple authorization code for Auth0 tokens. +* **Step 4 & 5**: The Auth0 platform exchanges the Authorization code with Apple for tokens. Auth0 validates the tokens, and uses the claims in the tokens to construct the identity of the user. +* **Step 6**: Auth0 saves the user profile, executes rules and authorization, then issues Auth0 access tokens (refresh tokens and ID tokens) as requested. These tokens are used to protect your APIs and users managed by Auth0. + +## Prerequisites + +Before you configure Sign In with Apple for your native app in Auth0, you must: + +* Have an [Apple Developer](https://developer.apple.com/programs/) account, which is a paid account with Apple. (There is no free trial available unless you are part of their [iOS Developer University Program](https://developer.apple.com/support/compare-memberships/).) +* [Register Your App in the Apple Developer Portal](/connections/apple-siwa/set-up-apple) if you have not already done so. Make a note of the following IDs and key for the application connection settings in the Auth0 Dashboard: + * App ID + * Apple Team ID + * Client Secret Signing Key + * Key ID + +::: 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. +::: + +## Configure and enable the connection in Auth0 + +Once you have the credentials you need from your Apple Developer account, you need to configure the application client and the connection settings in Auth0. + +1. Navigate to [Auth0 Dashboard > Applications > Applications](${manage_url}/#/applications), choose your application, and select the gear icon to view the settings page. +1. At the bottom of the page, select **Show Advanced Settings** and then the **Device Settings** view. Under **Native Social Login**, enable the **Enable Sign In with Apple** toggle. + ![Application Client Settings: Advanced Device Settings](/media/articles/connections/social/apple/dashboard-applications-edit_view-settings-advanced_device-settings_native_apple-enabled.png) +1. Under **iOS**, fill in the **App ID** field with the native app's App ID/Bundle Identifier. +1. Navigate to [Auth0 Dashboard > Authentication > Social](${manage_url}/#/connections/social), and select **Create Connection**. +1. Select the **Apple** connection and consent. +1. On the **Settings** tab, fill in the following fields: + * **Apple Team ID** + * **Client Secret Signing Key** + * **Key ID** + + ![Application Connection Settings](/media/articles/connections/social/apple/dashboard-connections-social-create_enter-details_apple.png) +1. Select the **Applications** view to enable this connection for your application +1. Click **Save**. + +::: note +Native apps cannot be tested from the browser. This means that the **Try Connection** button on the Apple connection is used exclusively for testing web-based flows. +::: + +## Logout + +Since the Native iOS login implementation does not make use of standard browser-based flows, application owners must also take care to perform logout appropriately. When an application needs to perform a logout, it must take the following actions: + + * [Revoke the Auth0 Refresh Token](/api/authentication#revoke-refresh-token) + * Delete the Auth0 refresh token stored in the iCloud Keychain + * Delete the Apple user identifier stored in the iCloud keychain + +Also, keep in mind that logout can result from user actions (i.e., clicking a "log out" button) or from a user revoking access to the given app. The latter will be indicated through the native [ASAuthorizationAppleIDProvider.getCredentialState](https://developer.apple.com/documentation/authenticationservices/asauthorizationappleidprovider/3175423-getcredentialstate) method. + +:::note +One nuance of Apple's IdP is that it only returns requested scopes (such as email, first name, and last name) in the ID token on the **first** response. More destructive approaches to logout (such as deleting the user) could result in loss of profile information, which would require end users to unauthorize and reauthorize an app. +::: + +## Keep reading + +* [Rate Limits on Native Social Logins](/policies/rate-limits#limits-on-native-social-logins) +* [Test Sign In with Apple Configuration](/connections/apple-siwa/test-siwa-connection) diff --git a/articles/connections/social/apple.md b/articles/connections/social/apple.md new file mode 100644 index 0000000000..0f807aeb82 --- /dev/null +++ b/articles/connections/social/apple.md @@ -0,0 +1,27 @@ +--- +title: Connect Web Apps to Apple +connection: Apple +image: /media/connections/apple.png +seo_alias: apple +description: Learn how to add login functionality to your web app with Apple. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +toc: true +public: true +index: 2 +topics: + - authentication + - connections + - social + - apple +contentType: concept +useCase: + - add-login + - connections + - add-siwa +--- +<%= include('../../../snippets/social/apple/0') %> +<%= include('../../../snippets/social/apple/1') %> +<%= include('../../../snippets/social/apple/2') %> +<%= include('../../../snippets/social/apple/3') %> +<%= include('../../../snippets/social/apple/4') %> +<%= include('../../../snippets/social/apple/5') %> +<%= include('../../../snippets/social/apple/6') %> diff --git a/articles/connections/social/auth0-oidc.md b/articles/connections/social/auth0-oidc.md index 27da8e3799..303c56f4e7 100644 --- a/articles/connections/social/auth0-oidc.md +++ b/articles/connections/social/auth0-oidc.md @@ -1,125 +1,18 @@ --- connection: Auth0 OpenIDConnect -seo_alias: auth0-oidc +title: Auth0 OpenIDConnect Connection image: /media/connections/auth0.png -description: You can use a Client on another Auth0 account as an identity provider in your current Auth0 account. +public: false +description: You can use an Application on another Auth0 tenant as an OIDC identity provider in your current Auth0 tenant. +topics: + - connections + - social +contentType: how-to +useCase: + - customize-connections + - add-idp --- - -# Authenticate using OpenIDConnect to another Auth0 account - -You can use a Client on another Auth0 account (referred to below as the **child account**) as an identity provider in your current Auth0 account (the **master account**). - -## Configure the Child Auth0 Account - -1. Create a Client or edit an existing one. -2. Take note of its **clientID** and **clientSecret**. You will need these to create the connection in the master account. -3. Add the master account's login callback to the list of **Allowed Callback URLs**: `https://${account.namespace}/login/callback` - -![](/media/articles/connections/social/auth0-oidc/child-app.png) - -## Configure the Master Auth0 Account - -The Auth0-to-Auth0 connection is not yet supported in the Dashboard. You need to create the connection using the [Create a connection](/api/v2#!/Connections/post_connections) endpoint, which will require an [Management API V2 token](/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 **auth-oidc-connection.json** file containing: - -```js -{ - "name": "YOUR-AUTH0-CONNECTION-NAME", - "strategy": "auth0-oidc", - "options": { - "client_id": "CHILD_CLIENT_ID", - "client_secret": "CHILD_CLIENT_SECRET", - "domain": "CHILD_AUTH0_DOMAIN", - "scope": "openid" - }, - "enabled_clients":["${account.clientId}"] -} -``` - -The required parameters for this connection are: - -* **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 Client in the child Auth0 account. -* **options.client_secret**: the `cliendSecret` of the target Client in the child Auth0 account. -* **options.domain**: the domain of the child Auth0 account. - -Optionally, you can add: - -* **options.scope**: the scope parameters for which you wish to request consent (i.e. `profile`, `identities`, etc.). -* **enabled_clients**: an array containing the identifiers of the clients for which the connection is to be enabled. If the array is empty or the property is not specified, no clients are enabled. - -## Use the Auth0 connection - -You can use any of the standard Auth0 mechanisms (e.g. direct links, [Auth0 Lock](/libraries/lock), [auth0.js](/auth0js), etc.) to login a user with the auth0-oidc connection. - -A direct link would look like: - -`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](/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 child Auth0 account where they can choose their identity provider (from the enabled connections of the target Client) and enter their credentials. - -![](/media/articles/connections/social/auth0-oidc/login-page.png) - -## The resulting profile - -Once the user is authenticated, the resulting profile will contain the [Auth0 Normalized User Profile](/user-profile/normalized) fields. For example: - -```js -{ - "name": "user-in-child@mail.com", - "email": "user-in-child@mail.com", - "email_verified": false, - "nickname": "user-in-child", - "picture": "https://s.gravatar.com/avatar/cb89d47afd405d39a8bce96b8b17bcbc?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fus.png", - "clientID": "${account.clientId}", - "updated_at": "2015-11-05T18:10:17.813Z", - "user_id": "auth0-oidc|your-auth0-oidc-conn-name|auth0|563b9b6cf50bc24402a69b80", - "identities": [ - { - "user_id": "your-auth0-oidc-conn-name|auth0|563b9b6cf50bc24402a69b80", - "provider": "auth0-oidc", - "connection": "tenant2", - "isSocial": true - } - ], - "created_at": "2015-11-05T18:09:49.575Z", - "global_client_id": "abOXA94rTYTYk6wDZsbQXJBv5VYiArmI", - "persistent": {} -} -``` - -Note that the generated `user_id` has the following format: - -`auth0-oidc|YOUR_AUTH0_CONNECTION_NAME|THE_CHILD_AUTH0_CONNECTION|THE_CHILD_USER_ID` - -The `access_token` is the JWT of the user in the child Auth0 connection. If you decode it, you will see all the properties that were requested in the `scope` of the auth0-oidc connection. For example, for `scope=openid identities` will return: - -```js -{ - "identities": [ - { - "user_id": "563b9b6cf50bc24402a69b80", - "provider": "auth0", - "connection": "Username-Password-Authentication", - "isSocial": false - } - ], - "iss": "https://child.auth0.com/", - "sub": "auth0|563b9b6cf50bc24402a69b80", - "aud": "eQVR4UI4b6ht1hXIcb90cMJN6pvvDPWD", - "exp": 1446783017, - "iat": 1446747017 -} -``` - -This token can be used to access the Auth0 API of the child account. +<%= include('../../../snippets/social/auth0-oidc/0') %> +<%= include('../../../snippets/social/auth0-oidc/1') %> +<%= include('../../../snippets/social/auth0-oidc/2') %> +<%= include('../../../snippets/social/auth0-oidc/3') %> diff --git a/articles/connections/social/baidu.md b/articles/connections/social/baidu.md index a9544903c8..afdfb9ba85 100644 --- a/articles/connections/social/baidu.md +++ b/articles/connections/social/baidu.md @@ -1,36 +1,25 @@ --- +title: Connect Apps to Baidu connection: Baidu image: /media/connections/baidu.png seo_alias: baidu -description: How to obtain an API Key and Secret Key for Baidu. +description: Learn how to add login functionality to your app with Baidy. You will need to obtain a Client Id and Client Secret for Baidu. +toc: true +public: true +index: 3 +topics: + - connections + - social + - baidu +contentType: how-to +useCase: + - customize-connections + - add-idp --- - -# Obtain an API Key and Secret Key for Baidu - -To configure a Baidu OAuth2 connection, you will need to register your Auth0 tenant on their [integration portal](https://developer.baidu.com/dev). - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Log into the integration portal and register a new App: - -![](/media/articles/connections/social/baidu/baidu-register-1.png) - - -## 2. Get your API Key and Secret Key - -Once the application is registered, enter your new `API Key` and `Secret Key` into the connection settings in Auth0. - -![](/media/articles/connections/social/baidu/baidu-register-2.png) - - -## 3. Enter the callback URL: - -Use the following value for the callback URL: - - https://${account.namespace}/login/callback - -Select your application on the console, and then click on `API 管理 -> 安全设置` - -![](/media/articles/connections/social/baidu/baidu-register-3.png) - +<%= include('../../../snippets/social/baidu/0') %> +<%= include('../../../snippets/social/baidu/1') %> +<%= include('../../../snippets/social/baidu/2') %> +<%= include('../../../snippets/social/baidu/3') %> +<%= include('../../../snippets/social/baidu/4') %> +<%= include('../../../snippets/social/baidu/5') %> <%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/basecamp.md b/articles/connections/social/basecamp.md new file mode 100644 index 0000000000..d397de664a --- /dev/null +++ b/articles/connections/social/basecamp.md @@ -0,0 +1,30 @@ +--- +title: Connect Apps to Basecamp +connection: Basecamp +image: /media/connections/basecamp.png +alias: + - basecamp + - thirtysevensignals +seo_alias: 37signals +description: How to obtain a Client Id and Client Secret for Basecamp (formerly 37Signals). +toc: true +public: true +index: 4 +topics: + - connections + - social + - 37signals + - basecamp +contentType: how-to +useCase: + - customize-connections + - add-idp + - add-login +--- +<%= include('../../../snippets/social/basecamp/0') %> +<%= include('../../../snippets/social/basecamp/1') %> +<%= include('../../../snippets/social/basecamp/2') %> +<%= include('../../../snippets/social/basecamp/3') %> +<%= include('../../../snippets/social/basecamp/4') %> +<%= include('../../../snippets/social/basecamp/5') %> +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/bitbucket.md b/articles/connections/social/bitbucket.md index c32dda52fc..d5a6229b6b 100644 --- a/articles/connections/social/bitbucket.md +++ b/articles/connections/social/bitbucket.md @@ -1,92 +1,25 @@ --- connection: Bitbucket +title: Bitbucket Social Connection image: /media/connections/bitbucket.png seo_alias: bitbucket -description: This page shows you how to connect your Auth0 app to Bitbucket. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +description: Learn how to connect your Auth0 app to Bitbucket. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +toc: true +public: true +index: 5 +topics: + - connections + - social + - bitbucket +contentType: how-to +useCase: + - customize-connections + - add-idp --- - -# Connect your app to Bitbucket - -To connect your Auth0 app to Bitbucket, you will need to generate a *Key* and *Secret* in a Bitbucket app, copy these keys into your Auth0 settings, and enable the connection. - -
      - Heads up! This connection will only work with Lock version 9.2 or higher. -
      - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Login to Bitbucket - -Login to [Bitbucket](https://bitbucket.org/). - -Click on your account icon in the upper right and select **Bitbucket settings**: - -![](/media/articles/connections/social/bitbucket/bitbucket-01.png) - -Select **OAuth** in the left nav: - -![](/media/articles/connections/social/bitbucket/bitbucket-02.png) - -## 2. Create your app - -Click **Add consumer**. - -Provide a name for your app. - -In the Callback URL field, enter the folowing: - -`https://${account.namespace}/login/callback` - -Select the Permissions you want to enable for this connection. - -Click **Save**. - -![](/media/articles/connections/social/bitbucket/bitbucket-03.png) - -## 3. Get your *Key* and *Secret* - -On the page that follows, click the name of your app under **OAuth consumers** to reveal your keys: - -![](/media/articles/connections/social/bitbucket/bitbucket-04.png) - -## 4. Copy your *Client Id* and *Client Secret* into Auth0 - -In a separate window, login to your [Auth0 Dashboard](${manage_url}) and select **Connections > Social** in the left nav. - -Select **Bitbucket**: - -![](/media/articles/connections/social/bitbucket/bitbucket-05.png) - -Copy the `Key` and `Secret` from the **OAuth integrated applications** page on Bitbucket into the fields on this page on Auth0. - -Select the **Permissions** you want to enable. - -Click **SAVE**. - -![](/media/articles/connections/social/bitbucket/bitbucket-06.png) - -## 5. Enable the Connection - -Go to the **Apps** tab of the Bitbucket connection on Auth0 and select each of your existing Auth0 apps for which you want to enable this connection: - -![](/media/articles/connections/social/bitbucket/bitbucket-07.png) - -## 6. Test the connection - -Close the **Settings** window to return to the [Connections > Social](${manage_url}/#/connections/social) section of the Auth0 dashboard. - -A **TRY** icon will now be displayed next to the Bitbucket logo: - -![](/media/articles/connections/social/bitbucket/bitbucket-08.png) - -Click **TRY**. - -Click **Grant access** to allow your app access. - -![](/media/articles/connections/social/bitbucket/bitbucket-09.png) - -If you have configured everything correctly, you will see the **It works!!!** page: - -![](/media/articles/connections/social/bitbucket/bitbucket-10.png) - +<%= include('../../../snippets/social/bitbucket/0') %> +<%= include('../../../snippets/social/bitbucket/1') %> +<%= include('../../../snippets/social/bitbucket/2') %> +<%= include('../../../snippets/social/bitbucket/3') %> +<%= include('../../../snippets/social/bitbucket/4') %> +<%= include('../../../snippets/social/bitbucket/5') %> <%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/box.md b/articles/connections/social/box.md index 05c4e762f0..f37f77a117 100644 --- a/articles/connections/social/box.md +++ b/articles/connections/social/box.md @@ -1,47 +1,25 @@ --- +title: Connect Apps to Box connection: Box image: /media/connections/box.png seo_alias: box -description: How to obtain a Client Id and Client Secret for Box. +description: Learn how to add login functionality to your app with Box. You will need to obtain a Client Id and Client Secret for Box. +toc: true +public: true +index: 6 +topics: + - connections + - social + - box +contentType: how-to +useCase: + - customize-connections + - add-idp --- - -# Obtain a *Client Id* and *Client Secret* for Box - -To configure a Box OAuth2 connection, you will need to register your Auth0 tenant on their [developer portal](https://developers.box.com/). - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Register a new Box app - -Log into the Box developer portal and click **My Apps** and then select **Create a Box Application**: - -![](/media/articles/connections/social/box/box-register-1.png) - -Name your new app and click **Create Application**: - -![](/media/articles/connections/social/box/box-register-2.png) - -## 2. Edit your app Properties - -Once the app is created, click on **Edit Application** and review the form. There are a number of properties that you can change (e.g. contact information, logos, etc.): - -![](/media/articles/connections/social/box/box-register-3.png) - -Scroll down to find the `client_id` and `client_secret` fields under the **OAuth2 Parameters** section: - -![](/media/articles/connections/social/box/box-register-4.png) - -Enter this URL as the `redirect_uri`: - - https://${account.namespace}/login/callback - -While on this page, make sure to define the appropriate permission **Scopes** for your app. - -## 3. Copy your *Client Id* and *Client Secret* - -Go to your Auth0 Dashboard and select **Connections > Social**, then choose **Box**. Copy the `Client Id` and `Client Secret` from the **OAuth2 Parameters** section of your app on Box into the fields on this page on Auth0: - -![](/media/articles/connections/social/box/box-add-connection.png) - +<%= include('../../../snippets/social/box/0') %> +<%= include('../../../snippets/social/box/1') %> +<%= include('../../../snippets/social/box/2') %> +<%= include('../../../snippets/social/box/3') %> +<%= include('../../../snippets/social/box/4') %> +<%= include('../../../snippets/social/box/5') %> <%= include('../_quickstart-links.md') %> - diff --git a/articles/connections/social/clever.md b/articles/connections/social/clever.md new file mode 100644 index 0000000000..0f076fb330 --- /dev/null +++ b/articles/connections/social/clever.md @@ -0,0 +1,20 @@ +--- +title: Connect Apps to Clever +connection: Clever +image: /media/connections/clever.png +seo_alias: clever +description: For security reasons, Auth0 no longer integrates with Clever. +toc: true +public: true +index: 6 +topics: + - connections + - social + - clever +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +<%= include('../../../snippets/social/clever/0') %> + diff --git a/articles/connections/social/devkeys.md b/articles/connections/social/devkeys.md index 73e1e91117..67f8dfc5cf 100644 --- a/articles/connections/social/devkeys.md +++ b/articles/connections/social/devkeys.md @@ -1,33 +1,57 @@ --- description: Caveats you need to be aware of when using Auth0 Dev Keys for social providers. +topics: + - connections + - social + - dev-keys +contentType: reference +useCase: + - customize-connections + - add-idp --- -# Using the Auth0 Developer Keys with Social Connections +# Test Social Connections with Auth0 Developer Keys -When using any of the Social Identity Providers, you need to register your application with the relevant Identity Provider in order to obtain a Client ID and Client Secret. +When using any of the available [Social Identity Providers](/connections/identity-providers-social), you need to register your application with the relevant Identity Provider in order to obtain a Client ID and Client Secret. -Auth0 allows you to enable any Social Identity Provider without specifying your own Client ID and Client Secret. In this instance Auth0 will use its own developer keys when authorizing the user with these providers. This allows you to quickly enable and test a specific Social Identity Provider, but it should definitely not be used in production. +Auth0 allows you to test a Social Identity Provider without specifying your own Client ID and Client Secret by using Auth0 developer keys. This allows you to quickly enable and test a specific Social Identity Provider, but it should **not be used in production**. -::: panel-info Client ID and Client Secret -The exact terminology of Client ID / Client Secret may differ between various Identity Providers. For example, Twitter refers to these as a Consumer Key / Consumer Secret and LinkedIn refers to an API Key / Secret Key. +Auth0 developer keys are not available in [Private Cloud deployments](/private-cloud). + +For production environments, make sure to [follow the steps for your chosen provider](/identityproviders) to obtain the Client ID and Client secret from the provider, this will avoid the [limitations](#limitations-of-developer-keys) of using developer keys. + +::: panel-warning Custom Developer keys +One or more connections are using Auth0 development keys which are only intended for use in development and testing. The connections should be configured with your own Developer Keys to enable the consent page to show your logo instead of Auth0's and to configure Single Sign-on (SSO) for these connections. Auth0 development keys are not recommended for Production environments. +::: + +::: panel Client ID and Client Secret +The exact terminology of a Client ID / Client Secret may differ between various Identity Providers. For example, Twitter refers to these as a Consumer Key / Consumer Secret and LinkedIn refers to an API Key / Secret Key. ::: -## Caveats +## Limitations of Developer Keys -When using the Auth0 developer keys, there are a few caveats you need to be aware of. These may cause your application to behave differently - or some functionality to not work at all - depending on whether you use your own Client ID and Client Secret, or whether you use the Auth0 developer keys. +The Auth0 developer keys are to be used for testing purposes so there are a few caveats you need to be aware of when using them. These may cause your application to behave differently - or some functionality to not work at all - depending on whether you use your own Client ID and Client Secret, or whether you use the Auth0 developer keys. -1. When using the Auth0 developer keys, the consent screen for the various Identity Providers will display Auth0's logo and information to your users. When you register your own application you have the opportunity to use your own logo and other application information. +When using the Auth0 developer keys, the authentication flow for the various Identity Providers will at times display Auth0's name, logo and information to your users. When you register your own application, you have the opportunity to use your own logo and other application information instead. - ![](/media/articles/connections/social/devkeys/consent-screen.png) +![Consent Screen](/media/articles/connections/social/devkeys/consent-screen.png) -2. [Single Sign On](/sso) will not function properly when using the Auth0 developer keys. The reason for this is that the Auth0 developer applications with all the relevant Identity Providers are configured to call back to the URL `https://login.auth0.com/login/callback` instead of the callback URL for your own tentant, i.e. `https://${account.namespace}/login/callback`. +## Limitations of Developer Keys when using Classic Universal Login - This results in the SSO cookie not being set on your own tenant domain, so the next time a user authenticates no SSO cookie will be detected, even if you configured your client to **Use Auth0 instead of the Identity Provider to do Single Sign On**. +If you are using the [Classic Universal Login experience](/universal-login/classic), these limitations also apply: + +1. You cannot use developer keys with [custom domains](/custom-domains). + +2. [Single Sign-on](/sso) will not function properly when using the Auth0 developer keys. The reason for this is that the Auth0 developer applications with all the relevant Identity Providers are configured to call back to the URL `https://login.auth0.com/login/callback` instead of the callback URL for your own tenant, for example `https://${account.namespace}/login/callback`. + + This results in the SSO cookie not being set on your own tenant domain, so the next time a user authenticates no SSO cookie will be detected, even if you configured your application to **Use Auth0 instead of the Identity Provider to do Single Sign-on** (legacy tenants only). 3. [Redirecting users from Rules](/rules/redirect) will not function properly. This is because redirect rules are resumed on the endpoint `https://${account.namespace}/continue`. When using Auth0's developer 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. 4. [Federated Logout](/logout#log-out-a-user) does not work. When using the Auth0 developer keys, calling `/v2/logout?federated` will sign the user out of Auth0, but not out of the Social Identity Provider. -5. `prompt=none` won't work on the [/authorize](/api/authentication/reference#social) endpoint. [Auth0.js' renewAuth() method](/libraries/auth0js#using-renewauth-to-acquire-new-tokens) uses `prompt=none` internally, so that won't work either. +5. `prompt=none` won't work on the [/authorize](/api/authentication/reference#social) endpoint. [Auth0.js' checkSession() method](/libraries/auth0js#using-checksession-to-acquire-new-tokens) uses `prompt=none` internally, so that won't work either. + +6. If Auth0 is acting as a SAML Identity Provider and you use a social connection with the Auth0 developer keys, the generated SAML response will have some errors, like a missing `InResponseTo` attribute or an empty `AudienceRestriction` element. -6. If Auth0 is acting as a SAML Identity Provider and you use a social connection with the Auth0 developer keys, the generated SAML response will have some errors, like a missing `InResponseTo` attribute or an empty `AudienceRestriction` element. +7. [Multi-factor Authentication in Auth0](/mfa) will not function properly. When MFA authentication is successful, a post will generate in `https://${account.namespace}/mf`. When using Auth0's developer keys, the session is established on a special endpoint that is generic and tenant agnostic, and calling `/mf` will not find your previous session, resulting in an error diff --git a/articles/connections/social/digitalocean.md b/articles/connections/social/digitalocean.md new file mode 100644 index 0000000000..1291253272 --- /dev/null +++ b/articles/connections/social/digitalocean.md @@ -0,0 +1,25 @@ +--- +title: Connect Apps to DigitalOcean +connection: DigitalOcean +image: /media/connections/digitalocean.png +seo_alias: digitalocean +description: Learn how to add login functionality to your app with DigitalOcean. You will need to obtain a Client ID and Client Secret for DigitalOcean. +toc: true +public: true +index: 6 +topics: + - connections + - social + - digitalocean +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +<%= include('../../../snippets/social/digitalocean/0') %> +<%= include('../../../snippets/social/digitalocean/1') %> +<%= include('../../../snippets/social/digitalocean/2') %> +<%= include('../../../snippets/social/digitalocean/3') %> +<%= include('../../../snippets/social/digitalocean/4') %> +<%= include('../../../snippets/social/digitalocean/5') %> +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/discord.md b/articles/connections/social/discord.md new file mode 100644 index 0000000000..f72c9cac60 --- /dev/null +++ b/articles/connections/social/discord.md @@ -0,0 +1,25 @@ +--- +title: Connect Apps to Discord +connection: Discord +image: /media/connections/discord.png +seo_alias: discord +description: Learn how to add login functionality to your app with Discord. You will need to obtain a Client ID and Client Secret for Discord. +toc: true +public: true +index: 6 +topics: + - connections + - social + - discord +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +<%= include('../../../snippets/social/discord/0') %> +<%= include('../../../snippets/social/discord/1') %> +<%= include('../../../snippets/social/discord/2') %> +<%= include('../../../snippets/social/discord/3') %> +<%= include('../../../snippets/social/discord/4') %> +<%= include('../../../snippets/social/discord/5') %> +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/docomo.md b/articles/connections/social/docomo.md new file mode 100644 index 0000000000..84d7c89092 --- /dev/null +++ b/articles/connections/social/docomo.md @@ -0,0 +1,25 @@ +--- +title: Connect Apps to Docomo dAccount +connection: Docomo +image: /media/connections/daccount.png +seo_alias: docomo +description: Learn how to add login functionality to your app with Docomo dAccount. You will need to obtain a Client Id and Client Secret for Docomo. +toc: true +public: true +index: 7 +topics: + - connections + - social + - docomo +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +<%= include('../../../snippets/social/docomo/0') %> +<%= include('../../../snippets/social/docomo/1') %> +<%= include('../../../snippets/social/docomo/2') %> +<%= include('../../../snippets/social/docomo/3') %> +<%= include('../../../snippets/social/docomo/4') %> +<%= include('../../../snippets/social/docomo/5') %> +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/dribbble.md b/articles/connections/social/dribbble.md new file mode 100644 index 0000000000..a16be5240a --- /dev/null +++ b/articles/connections/social/dribbble.md @@ -0,0 +1,25 @@ +--- +title: Connect Apps to Dribbble +connection: Dribbble +image: /media/connections/dribbble.png +seo_alias: dribbble +description: Learn how to add login functionality to your app with Dribbble. You will need to obtain a Client ID and Client Secret for Dribbble. +toc: true +public: true +index: 6 +topics: + - connections + - social + - dribbble +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +<%= include('../../../snippets/social/dribbble/0') %> +<%= include('../../../snippets/social/dribbble/1') %> +<%= include('../../../snippets/social/dribbble/2') %> +<%= include('../../../snippets/social/dribbble/3') %> +<%= include('../../../snippets/social/dribbble/4') %> +<%= include('../../../snippets/social/dribbble/5') %> +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/dropbox.md b/articles/connections/social/dropbox.md index d726f725fc..5e5203dc45 100644 --- a/articles/connections/social/dropbox.md +++ b/articles/connections/social/dropbox.md @@ -1,90 +1,25 @@ --- +title: Connect Apps to Dropbox connection: Dropbox image: /media/connections/dropbox.png seo_alias: dropbox -description: This page shows you how to connect your Auth0 app to Dropbox. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +description: Learn how to connect your Auth0 app to Dropbox. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +toc: true +public: true +index: 8 +topics: + - connections + - social + - dropbox +contentType: how-to +useCase: + - customize-connections + - add-idp --- - -# Connect your app to Dropbox - -To connect your Auth0 app to Dropbox, you will need to generate a *Client ID* and *Client Secret* in a Dropbox app, copy these keys into your Auth0 settings, and enable the connection. - -
      - Heads up! This connection will only work with Lock version 9.2 or higher. -
      - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Login to the developer portal - -Go to the [Dropbox Developer](https://www.dropbox.com/developers) portal and log in with your Dropbox credentials. - -Click **Create your app**: - -![](/media/articles/connections/social/dropbox/dropbox-01.png) - -## 2. Create your app - -1. Under **Choose an API**, select **Dropbox API**. -2. Under **Choose the type of access you need**, select **App folder** or **Full Dropbox**, depending on your needs. -3. Name your app. -4. Click **Create app**. - -![](/media/articles/connections/social/dropbox/dropbox-02.png) - -## 3. Enter your callback URL - -On your app's **Settings** page that follows, enter this URL in the **Redirect URIs** field: - -`https://${account.namespace}/login/callback` - -Click **Add**: - -![](/media/articles/connections/social/dropbox/dropbox-03.png) - -## 4. Get your *Client ID* and *Client Secret* - -On the same **Settings** page, your `App key` and `App secret` will be displayed: - -![](/media/articles/connections/social/dropbox/dropbox-04.png) - -## 5. Copy your *Client Id* and *Client Secret* into Auth0 - -In a separate window, login to your [Auth0 Dashboard](${manage_url}) and select **Connections > Social** in the left nav. - -Select **Dropbox**. - -![](/media/articles/connections/social/dropbox/dropbox-05.png) - -Copy the `App key` and `App secret` from the **Settings** page of the Dropbox Developer portal into the fields on this page on Auth0: - -![](/media/articles/connections/social/dropbox/dropbox-06.png) - -Click **SAVE**. - -## 6 Enable the Connection - -Select the **Apps** tab of the Dropbox connection on Auth0 and select each of your existing Auth0 apps for which you want to enable this connection: - -![](/media/articles/connections/social/dropbox/dropbox-07.png) - -## 7 Test the connection - -Close the **Settings** window to return to the [Connections > Social](${manage_url}/#/connections/social) section of the Auth0 dashboard. - -A **TRY** icon will now be displayed next to the Dropbox logo: - -![](/media/articles/connections/social/dropbox/dropbox-08.png) - -Click **TRY**. - -Click **Allow** to grant your app access. - -![](/media/articles/connections/social/dropbox/dropbox-09.png) - -If you have configured everything correctly, you will see the **It works!!!** page: - -![](/media/articles/connections/social/dropbox/dropbox-10.png) - +<%= include('../../../snippets/social/dropbox/0') %> +<%= include('../../../snippets/social/dropbox/1') %> +<%= include('../../../snippets/social/dropbox/2') %> +<%= include('../../../snippets/social/dropbox/3') %> +<%= include('../../../snippets/social/dropbox/4') %> +<%= include('../../../snippets/social/dropbox/5') %> <%= include('../_quickstart-links.md') %> - diff --git a/articles/connections/social/dwolla.md b/articles/connections/social/dwolla.md index 88708ff7c6..1a7aa00217 100644 --- a/articles/connections/social/dwolla.md +++ b/articles/connections/social/dwolla.md @@ -1,43 +1,25 @@ --- +title: Connect Apps to Dwolla connection: Dwolla image: /media/connections/dwolla.png seo_alias: dwolla -description: How to obtain a Client Id and Client Secret for Dwolla. +description: Learn how to add login functionality to your app with Dwolla. You will need to obtain a Client Id and Client Secret for Dwolla. +toc: true +public: true +index: 9 +topics: + - connections + - social + - dwolla +contentType: how-to +useCase: + - customize-connections + - add-idp --- - -# Obtain a *Client ID* and *Client Secret* for Dwolla - -To configure OAuth2 connections with Dwolla, you will need to register Auth0 on the Dwolla Developer portal. - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Log into the developer portal - -Log into the Dwolla [Developer portal](https://uat.dwolla.com/applications) and click **Create an application**: - -![](/media/articles/connections/social/dwolla/dwolla-1.png) - -## 2. Register your new app - -Complete the information on this page. Enter the following URL in the **OAuth Redirect URL** field: - - https://${account.namespace}/login/callback - -![](/media/articles/connections/social/dwolla/dwolla-2.png) - -Click **Create application**. - -## 3. Get your *Key* and *Secret* - -Once the application is registered, your app's `Key` and `Secret` will be displayed on the following page: - -![](/media/articles/connections/social/dwolla/dwolla-3.png) - -## 4. Copy your *Key* and *Secret* - -Go to the [Social Connections](${manage_url}/#/connections/social) section of your Auth0 Dashboard and choose **Dwolla**. Copy the `Key` and `Secret` from the **Application** page of your app on Dwolla into the `Client Id` and `Client Secret` fields on this page on Auth0: - -![](/media/articles/connections/social/dwolla/dwolla-4.png) - +<%= include('../../../snippets/social/dwolla/0') %> +<%= include('../../../snippets/social/dwolla/1') %> +<%= include('../../../snippets/social/dwolla/2') %> +<%= include('../../../snippets/social/dwolla/3') %> +<%= include('../../../snippets/social/dwolla/4') %> +<%= include('../../../snippets/social/dwolla/5') %> <%= include('../_quickstart-links.md') %> - diff --git a/articles/connections/social/evernote-sandbox.md b/articles/connections/social/evernote-sandbox.md new file mode 100644 index 0000000000..ef6c0b5c73 --- /dev/null +++ b/articles/connections/social/evernote-sandbox.md @@ -0,0 +1,27 @@ +--- +title: Connect Apps to Evernote Sandbox +connection: Evernote Sandbox +image: /media/connections/evernote.png +seo_alias: evernote-sandbox +description: Learn how to add login functionality to your app with Evernote Sandbox. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +toc: true +public: true +index: 11 +topics: + - connections + - social + - evernote + - sandbox +contentType: how-to +useCase: + - customize-connections + - add-idp + - add-login +--- +<%= include('../../../snippets/social/evernote-sandbox/0') %> +<%= include('../../../snippets/social/evernote-sandbox/1') %> +<%= include('../../../snippets/social/evernote-sandbox/2') %> +<%= include('../../../snippets/social/evernote-sandbox/3') %> +<%= include('../../../snippets/social/evernote-sandbox/4') %> +<%= include('../../../snippets/social/evernote-sandbox/5') %> +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/evernote.md b/articles/connections/social/evernote.md index 7e6abfa7a3..6970f35238 100644 --- a/articles/connections/social/evernote.md +++ b/articles/connections/social/evernote.md @@ -1,57 +1,26 @@ --- +title: Connect Apps to Evernote connection: Evernote image: /media/connections/evernote.png seo_alias: evernote -description: How to obtain a Consumer Key and Consumer Secret for Evernote. +description: Learn how to add login functionality to your app with Evernote. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +toc: true +public: true +index: 10 +topics: + - connections + - social + - evernote +contentType: how-to +useCase: + - customize-connections + - add-idp + - add-login --- - -# Obtain a *Consumer Key* and *Consumer Secret* for Evernote - -To configure Evernote OAuth connections, you will need to create an API Key on the Evernote Developers portal. - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Log into the Developers portal - -Log into the [Evernote Developers](http://dev.evernote.com) portal and click **Get an API Key**: - -![](/media/articles/connections/social/evernote/evernote-1.png) - -## 2. Request an API Key - -Complete the information on this page and click **Request Key**. - -![](/media/articles/connections/social/evernote/evernote-2.png) - -## 3. Get your *Consumer Key* and *Consumer Secret* - -Your `Consumer Key` and `Consumer Secret` will be displayed on the following page: - -![](/media/articles/connections/social/evernote/evernote-3.png) - -## 4. Copy your *Consumer Key* and *Consumer Secret* - -Go to the [Social Connections](${manage_url}/#/connections/social) section of your Auth0 Dashboard and choose **Evernote Sandbox**. Copy the `Consumer Key` and `Consumer Secret` from the Evernote API Key page into the fields on this page on Auth0: - -![](/media/articles/connections/social/evernote/evernote-4.png) - -## 5. Move your key to production - -When ready to deploy your application, you must request your API key be activated on production. - -Go to [Support Resources for Evernote Developers](https://dev.evernote.com/support/) and click **Activate an API Key**: - -![](/media/articles/connections/social/evernote/evernote-5.png) - -Complete the information on this page, including you *API Consumer Key*, and click **Submit**: - -![](/media/articles/connections/social/evernote/evernote-6.png) - -## 6. Copy your *Consumer Key* and *Consumer Secret* - -Go to the [Social Connections](${manage_url}/#/connections/social) section of your Auth0 Dashboard and choose **Evernote**. Copy the `Consumer Key` and `Consumer Secret` from the Evernote API Key page into the fields on this page on Auth0: - -![](/media/articles/connections/social/evernote/evernote-7.png) - +<%= include('../../../snippets/social/evernote/0') %> +<%= include('../../../snippets/social/evernote/1') %> +<%= include('../../../snippets/social/evernote/2') %> +<%= include('../../../snippets/social/evernote/3') %> +<%= include('../../../snippets/social/evernote/4') %> +<%= include('../../../snippets/social/evernote/5') %> <%= include('../_quickstart-links.md') %> - diff --git a/articles/connections/social/exact.md b/articles/connections/social/exact.md index 69bc9a4d6f..fe6dee81a7 100644 --- a/articles/connections/social/exact.md +++ b/articles/connections/social/exact.md @@ -1,54 +1,25 @@ --- +title: Connect Apps to Exact connection: Exact image: /media/connections/exact.png seo_alias: exact -description: How to obtain a Client Id and Client Secret for Exact. +description: Learn how to add login functionality to your app with Exact. +toc: true +public: true +index: 12 +topics: + - connections + - social + - exact +contentType: how-to +useCase: + - customize-connections + - add-idp --- - -# Obtain a *Client Id* and *Client Secret* for Exact - -To configure an Exact OAuth2 connection, you will need to register your Auth0 tenant on the [Exact Online App Center](https://apps.exactonline.com/). - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Register a new app - -Log into the Exact Online App Center and click on **Manage Apps**: - -![](/media/articles/connections/social/exact/exact-register-1.png) - -and then click **Add a new application**: - -![](/media/articles/connections/social/exact/exact-register-2.png) - -## 2. Edit your App Properties. - -Enter your app name: - -![](/media/articles/connections/social/exact/exact-register-3.png) - -In the `Redirect URI`field, enter this value: - - https://${account.namespace}/login/callback - -and click **Save**. - -## 3. Get your new app's *Client Id* and *Client Secret* - -On the following page, your new app will be listed. To retrieve the `Client Id` and `Client Secret`, click **Edit**: - -![](/media/articles/connections/social/exact/exact-register-4.png) - -On this page, from the **Authorization** section, copy the `Client Id` and `Client Secret` provided. - -![](/media/articles/connections/social/exact/exact-register-5.png) - -## 4. Copy the *Client Id* and *Client Secret* to the Auth0 dashbaord. - -Go to your Auth0 Dashboard and select **Connections > Social**, then choose **Exact**. Copy the `Client Id` and `Client Secret` from the **Manage App** page of your app in the Exact Online App Center into the fields on this page on Auth0. - -![](/media/articles/connections/social/exact/exact-register-6.png) - -**NOTE:** You can register applications in multiple regions with Exact. By default Auth0 will use `https://start.exactonline.nl`, but this value can be overridden with the `Base URL` parameter. - +<%= include('../../../snippets/social/exact/0') %> +<%= include('../../../snippets/social/exact/1') %> +<%= include('../../../snippets/social/exact/2') %> +<%= include('../../../snippets/social/exact/3') %> +<%= include('../../../snippets/social/exact/4') %> +<%= include('../../../snippets/social/exact/5') %> <%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/facebook-native.md b/articles/connections/social/facebook-native.md new file mode 100644 index 0000000000..b74d186c6c --- /dev/null +++ b/articles/connections/social/facebook-native.md @@ -0,0 +1,129 @@ +--- +title: Add Facebook Login to Native Apps +connection: Facebook Native +image: /media/connections/facebook.png +public: true +description: Learn how to add login functionality to your native app with Facebook. +topics: + - authentication + - connections + - social + - facebook +contentType: how-to +useCase: + - add-login + - customize-connections + - add-idp +--- +# Add Facebook Login to Native Apps + +You can add functionality to your native application to allow your users to authenticate using Facebook natively, within the application. This does not require redirection via a web browser and will let mobile applications comply with [Facebook Developer Policy](https://developers.facebook.com/policy/) which requires that mobile applications use the Facebook SDK for [Android](https://developers.facebook.com/docs/android) or [iOS](https://developers.facebook.com/docs/ios) to authenticate. + +::: note +When integrating with the Facebook SDKs, your applications will be sharing data with Facebook. Make sure you understand the data that is being shared and that you reflect it properly in your application's privacy policy. Auth0 has no control over what data will be shared with Facebook via the SDK. + +Check the [Facebook GDPR](https://www.facebook.com/business/m/one-sheeters/gdpr-developer-faqs) page for more information about data collected by the Facebook SDK and Facebook Login. +::: + +## How it works + +The Native Facebook login flow works as follows: + +* **Step 1**: The application authenticates a user via the Facebook SDK and acquires an Access Token. +* **Step 2**: The application uses that Access Token to request a special [Facebook Session Info Access Token](https://developers.facebook.com/docs/facebook-login/access-tokens/session-info-access-token). +* **Step 3**: Use the Facebook SDK to retrieve the users's profile +* **Step 4**: The application can then use the Facebook Session Info token to authenticate with Auth0. + +## Prerequisites + +Before you configure Native Facebook login for your native app via Auth0, you must: + +1. [Set up your application](/connections/social/facebook) with Facebook and as an Auth0 connection +1. [Use the relevant Facebook SDK in your application](https://developers.facebook.com/docs/apis-and-sdks/) +1. Navigate to [Auth0 Dashboard > Applications > Applications](${manage_url}/#/applications), and create an application with Auth0 (if you have not already). +1. At the bottom of the settings page, select **Show Advanced Settings** and then the **Device Settings** view. Under **Native Social Login**, enable the **Enable Sign In with Facebook** toggle. + ![Native Social Login Settings](/media/articles/connections/nativesocial/dashboard-applications-edit_view-settings-advanced_device-settings_facebook-enabled.png) +1. Complete the following implementation details: + +## Implementation details + +As above, the process to authenticate a user profile using Native Facebook login is a four-step one, from your application's perspective: + +### Step 1 + +The application authenticates a user via the Facebook SDK. It will obtain an Access Token from Facebook. + +### Step 2 + +The application uses the Access Token to request a [Facebook Session Info Access Token](https://developers.facebook.com/docs/facebook-login/access-tokens/session-info-access-token). + +This request will look similar to the following: + +``` +GET https://graph.facebook.com/v5.0/oauth/access_token? +grant_type=fb_attenuate_token& +client_id=457704041391802& +fb_exchange_token= +``` + +and the response: + +```json +{ + "access_token": "XAAGgR4b...1lHWNCpqrAhcpoAZDZD", + "token_type": "bearer", + "expires_in": 5183924 +} +``` + +### Step 3 + +The application needs to retrieve the user profile from Facebook using the Facebook SDK, which will end in a request similar to the following: + +``` +GET https://graph.facebook.com/v5.0/?access_token=&fields=email,name +``` + +### Step 4 + +The application can then use the session info Access Token and the Facebook user profile to authenticate with Auth0 by calling Auth0's `/oauth/token` endpoint using the Token Exchange flow with the `facebook-session-access-token` token type. If all goes well, Auth0 will return a normal response from the exchange, with the addition of the user profile. The user profile should be a JSON object, encoded as a string. + +``` +POST https://${account.namespace}/oauth/token + +grant_type: 'urn:ietf:params:oauth:grant-type:token-exchange' +subject_token_type: 'http://auth0.com/oauth/token-type/facebook-info-session-access-token' +audience: 'your-api' +scope: 'read:appointments openid profile email email_verified' +subject_token: 'XAAGgR4b...1lHWNCpqrUHZAEtUuZAhcpoAZDZD' +client_id: '${account.clientId}' +user_profile: '{"email":"john@example.com", "name":"John Doe"}' +``` + +and the response from Auth0: + +```json +{ + "access_token": "eyJ0eXA..yXQaPLVXg", + "id_token": "eyJ0.tFE5HPipdOsA", + "scope": "openid profile email read:appointments", + "expires_in": 86400, + "token_type": "Bearer" +} +``` + +## User Profile and Email Validation + +In the previous example, you had to retrieve the User Profile from Facebook and include it in the call to `/oauth/token`. This is because the Facebook Session Access Token cannot be used to directly retrieve the profile, and the Facebook Access Token cannot be sent directly to the server, due to [Apple's AppStore Review Guidelines](https://developer.apple.com/app-store/review/guidelines). Therefore, it must be retrieved in the client and sent to Auth0 in this fashion. + +Given that Auth0 can't guarantee that the user profile is the same that was returned by Facebook, it will set the `email_verified` field to `false`. + +## Logout + +Since the native login implementation does not make use of standard browser-based flows, application owners must also take care to perform logout appropriately. When an application needs to perform a logout, it should also [Revoke the Auth0 Refresh Token](/api/authentication#revoke-refresh-token). + +## Keep reading + +* [Native Facebook Login with iOS Swift](/quickstart/native/ios-swift-facebook-login) +* [Native Facebook Login with Android](/quickstart/native/android-facebook-login) +* [Rate Limits on Native Social Logins](/policies/rate-limits#limits-on-native-social-logins) diff --git a/articles/connections/social/facebook.md b/articles/connections/social/facebook.md index 6f7dab4bd8..7bf0d1cb91 100644 --- a/articles/connections/social/facebook.md +++ b/articles/connections/social/facebook.md @@ -1,113 +1,29 @@ --- +title: Connect Apps to Facebook connection: Facebook -index: 2 +index: 13 image: /media/connections/facebook.png seo_alias: facebook -description: This page shows you how to connect your Auth0 app to Facebook. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +description: Learn how to add login functionality to your app with Facebook. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +toc: true +public: true +topics: + - authentication + - connections + - social + - facebook +contentType: how-to +useCase: + - add-login + - customize-connections + - add-idp --- - -# Connect your app to Facebook - -To connect your Auth0 app to Facebook, you will need an **App ID** and **App Secret** from your Facebook app, then copy these keys into your Auth0 settings and enable the connection. - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Login to Facebook Developers - -Go to [Facebook Developers](https://developers.facebook.com) and login with your account. Select **Add a New App** from the dropdown in the upper right: - -![Add a New App](/media/articles/connections/social/facebook/facebook-1.png) - -## 2. Name your application - -Provide a **Display Name** and **Contact Email**. - -Select a **Category** and click **Create App ID**: - -![Create a New App](/media/articles/connections/social/facebook/facebook-2.png) - -Complete the **Security Check**. - -## 3. Setup Facebook Login - -On the **Product Setup** page that follows, click **Get Started** next to **Facebook Login**: - -![Click Get Started](/media/articles/connections/social/facebook/facebook-3.png) - -This will bring up **Client OAuth Settings** for **Facebook Login**. - -![Client OAuth Settings](/media/articles/connections/social/facebook/oauth-settings.png) - -Enter the following URL in the **Valid OAuth redirect URIs** field: - -`https://${account.namespace}/login/callback` - -![Enter OAuth redirect URI](/media/articles/connections/social/facebook/facebook-3b.png) - -Click **Save Changes**. - -## 4. Make your App Public - -Next, click on **App Review** on the left navigation bar. Near the top of the page under **Make (Your App Name) App public?** click to move the slider to **Yes**. - -![Make Public](/media/articles/connections/social/facebook/facebook-public.png) - -## 5. Get your **App ID** and **App Secret** - -Click **Settings** in the left nav. On this page you can retrieve your **App ID** and **App Secret**. - -![Settings page](/media/articles/connections/social/facebook/facebook-4.png) - -Click **Show** to reveal the **App Secret** (you may be required to re-enter your Facebook password). - -In a seperate tab or window, go to the [Connections > Social](${manage_url}/#/connections/social) section of the Auth0 dashboard. - -Click on the box with the **Facebook** logo. - -This will bring up the Facebook connection settings. - -Copy the **App ID** and **App Secret** from the **Settings** of your app on Facebook: - -![Auth0 Facebook Settings](/media/articles/connections/social/facebook/auth0-fb-settings.png) - -Select all the **Attributes** and **Permissions** you want to enable. - -**Note:** Your users will be able to choose which Attributes they wish to share, and by default this selection is only made when they first authorize the application. [Click here to learn more about handling declined permissions.](/connections/social/reprompt-permissions) - -Then click the **Clients** tab and select the applications you wish to enable this connection for. - -![Enable clients](/media/articles/connections/social/facebook/enable-clients.png) - -When finished click **Save**. - -## 6. Test the Connection - -In the [Connections > Social](${manage_url}/#/connections/social) section of the Auth0 dashboard a **TRY** icon will now be displayed next to the Facebook logo: - -![Click Try](/media/articles/connections/social/facebook/try-connection.png) - -Click **TRY**. - -The Facebook allow access dialog will appear. - -![Continue](/media/articles/connections/social/facebook/allow-access.png) - -Click continue and if configured correctly, you will see the **It works!!!** page: - -![](/media/articles/connections/social/facebook/facebook-8b.png) - -## Additional Info - -### Create a Test App - -Facebook now allows you to test your application by creating a copy of it to use for testing purposes. If you create a test application it will have it's own separate **App ID** and **App Secret**. Auth0 only allows one Facebook connection to be configured per account. One option for testing is that create the connection to the test connection and then change the values when you are ready to connect to the production application. - -Another option is to create another Auth0 account used for testing purposes. A new account can be created in the [Dashboard](${manage_url}) by clicking on your account name in the top right corner and selecting **New Account** from the dropdown. See the [Setting Up Multiple Environments](/dev-lifecycle/setting-up-env) for more information on multiple environments. - -### Deauthorize Callback URL - -On the **Facebook Login** Client OAuth Settings page, you can also set a Deauthorize Callback URL to be called when a user deauthorizes your app. - -[Facebook Docs for Facebook Login](https://developers.facebook.com/docs/facebook-login) - +<%= include('../../../snippets/social/facebook/0') %> +<%= include('../../../snippets/social/facebook/1') %> +<%= include('../../../snippets/social/facebook/2') %> +<%= include('../../../snippets/social/facebook/3') %> +<%= include('../../../snippets/social/facebook/4') %> +<%= include('../../../snippets/social/facebook/5') %> +<%= include('../../../snippets/social/facebook/6') %> +<%= include('../../../snippets/social/facebook/7') %> <%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/figma.md b/articles/connections/social/figma.md new file mode 100644 index 0000000000..2e1647388c --- /dev/null +++ b/articles/connections/social/figma.md @@ -0,0 +1,25 @@ +--- +title: Connect Apps to Figma +connection: Figma +image: /media/connections/figma.png +seo_alias: figma +description: Learn how to add login functionality to your app with Figma. You will need to obtain a Client ID and Client Secret for Figma. +toc: true +public: true +index: 6 +topics: + - connections + - social + - figma +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +<%= include('../../../snippets/social/figma/0') %> +<%= include('../../../snippets/social/figma/1') %> +<%= include('../../../snippets/social/figma/2') %> +<%= include('../../../snippets/social/figma/3') %> +<%= include('../../../snippets/social/figma/4') %> +<%= include('../../../snippets/social/figma/5') %> +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/fitbit.md b/articles/connections/social/fitbit.md index 1102f79b12..0442465522 100644 --- a/articles/connections/social/fitbit.md +++ b/articles/connections/social/fitbit.md @@ -1,62 +1,25 @@ --- +title: Connect Apps to Fitbit connection: Fitbit image: /media/connections/fitbit.png seo_alias: fitbit +toc: true +public: true index: 14 -description: How to obtain a Client Id and Client Secret for Fitbit. +description: Learn how to add login functionality to your app with Fitbit. You will need to obtain a Client Id and Client Secret for Fitbit. +topics: + - connections + - social + - fitbit +contentType: how-to +useCase: + - customize-connections + - add-idp --- - -# Obtain a *Client ID* and *Client Secret* for Fitbit - -::: panel-warning Fitbit has ended support for OAuth 1.0 -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. -::: - -To configure a Fitbit OAuth 2.0 connection, you will need to register a new application in Fitbit. - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Register a New Fitbit App - -Log into the [Fitbit's Developer site](https://dev.fitbit.com) and select **REGISTER AN APP**: - -![](/media/articles/connections/social/fitbit/fitbit-register-oauth2.png) - -## 2. Enter Your Callback URL - -Complete the registration form with information about your new app. In the **Callback URL** field, enter: - - https://${account.namespace}/login/callback - -and click **Register**. - -## 3. Copy Your New App's *Client ID* and *Client Secret* - -From the **Edit Application** page, copy the `Client ID` and `Client Secret`: - -![](/media/articles/connections/social/fitbit/fitbit-manage-oauth2.png) - -## 4. Enter Your Client ID and Client Secret - -Go to your Auth0 Dashboard and select **Connections > Social**, then choose **Fitbit**. Copy the `Client ID` and `Client Secret` from the **Manage My Apps** page of your app on Fitbit into the fields on this page on Auth0: - -![](/media/articles/connections/social/fitbit/fitbit-auth0-dashboard.png) - -## 5. Enable the Connection - -Go to the **Apps** tab of the Fitbit connection on your Auth0 Dashboard and select each of your existing Auth0 clients for which you want to enable this connection: - -![](/media/articles/connections/social/fitbit/fitbit-apps.png) - -## 6. Test the Connection - - - Close the Settings window to return to the Connections > Social section of your Auth0 dashboard. - - A TRY icon will now be displayed next to the Fitbit logo; click "TRY". - - Finally, click "Grant access" to allow access. - -If you have configured everything correctly, you will see the "It works" page! - -**NOTE:** Fitbit is a registered trademark and service mark of Fitbit, Inc. Auth0 is designed for use with the Fitbit platform. This product is not part of Fitbit, and Fitbit does not service or warrant the functionality of this product. - +<%= include('../../../snippets/social/fitbit/0') %> +<%= include('../../../snippets/social/fitbit/1') %> +<%= include('../../../snippets/social/fitbit/2') %> +<%= include('../../../snippets/social/fitbit/3') %> +<%= include('../../../snippets/social/fitbit/4') %> +<%= include('../../../snippets/social/fitbit/5') %> <%= include('../_quickstart-links.md') %> - diff --git a/articles/connections/social/github.md b/articles/connections/social/github.md index 8d1da308cd..4e61bb806c 100644 --- a/articles/connections/social/github.md +++ b/articles/connections/social/github.md @@ -1,41 +1,27 @@ --- +title: Connect Apps to GitHub connection: Github image: /media/connections/github.png seo_alias: github -index: 7 -description: How to obtain a Client Id and Client Secret for GitHub. +toc: true +public: true +index: 16 +description: Learn how to add login functionality to your app with GitHub. You can also access the GitHub API. +topics: + - connections + - social + - github +contentType: how-to +useCase: + - customize-connections + - add-idp --- -# Obtain a *Client Id* and *Client Secret* for GitHub - -To configure a GitHub connection, you will need to register Auth0 with GitHub. - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Add a new application -Log into GitHub and go to [Register new application](https://github.com/settings/applications/new): - -![](/media/articles/connections/social/github/github-addapp-1.png) - -## 2. Register your new app - -Complete the information on this page then click **Register application**. The callback address for your app will be: - - https://${account.namespace}/login/callback - -![](/media/articles/connections/social/github/github-addapp-2.png) - -## 3. Get your *Client Id* and *Client Secret* - -Once the application is registered, your app's `Client Id` and `Client Secret` will be displayed on the following page: - -![](/media/articles/connections/social/github/github-addapp-3.png) - -### 4. Copy your *Client Id* and *Client Secret* - -Go to your Auth0 Dashboard and select **Connections > Social**, then choose **Github**. Copy the `Client Id` and `Client Secret` from the **Developer Applications** of your app on Github into the fields on this page on Auth0. - -![](/media/articles/connections/social/github/github-addapp-4.png) - +<%= include('../../../snippets/social/github/0.md') %> +<%= include('../../../snippets/social/github/1.md') %> +<%= include('../../../snippets/social/github/2.md') %> +<%= include('../../../snippets/social/github/3.md') %> +<%= include('../../../snippets/social/github/4.md') %> +<%= include('../../../snippets/social/github/5.md') %> +<%= include('../../../snippets/social/github/6.md') %> <%= include('../_quickstart-links.md') %> - diff --git a/articles/connections/social/goodreads.md b/articles/connections/social/goodreads.md index 823ea1805a..670c3e39f4 100644 --- a/articles/connections/social/goodreads.md +++ b/articles/connections/social/goodreads.md @@ -1,38 +1,25 @@ --- +title: Connect Apps to Goodreads connection: Goodreads image: /media/connections/goodreads.png seo_alias: goodreads -description: How to obtain a Consumer Key and Consumer Secret for Goodreads. +toc: true +public: false +index: 17 +description: Learn how to add login functionality to your app with Goodreads. +topics: + - connections + - social + - goodreads +contentType: how-to +useCase: + - customize-connections + - add-idp --- - -# Obtain a Consumer Key and Consumer Secret for Goodreads - -To configure a Goodreads connection with Auth0, you will need to register your app on the Goodreads developers site. - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Apply for a developer key - -Log into the [Goodreads developer site](https://www.goodreads.com/api), and select *developer key*: - -![](/media/articles/connections/social/goodreads/goodreads-register-1.png) - -## 2. Enter information about your app - -Complete the form then click **Apply for a Developer Key**. Enter this in the `Callback URL` field: - - https://${account.namespace}/login/callback - -![](/media/articles/connections/social/goodreads/goodreads-register-2.png) - -## 3. Get your *Consumer Key* and *Consumer Secret* - -Once the application is registered, the `Key` and `Secret` for your new app will be displayed on the following page: - -![](/media/articles/connections/social/goodreads/goodreads-register-3.png) - -### 4. Copy your *Consumer Key* and *Consumer Secret* - -Go to your Auth0 Dashboard and select **Connections > Social**, then choose [custom OAuth2 connections](/connections/social/oauth2) and add Goodreads (OAuth1) as a provider, you can check Bitbucket's [example](/oauth2-examples) since it also uses OAuth1. Copy the `Consumer Key` and `Consumer Secret` from the **Api Key** page of your app on Goodreads into the fields `client_id` and `client_secret`. The `requestTokenURL` would be http://www.goodreads.com/oauth/request_token, the `accessTokenURL` would be http://www.goodreads.com/oauth/access_token and the `userAuthorizationURL` would be http://www.goodreads.com/oauth/authorize. - +<%= include('../../../snippets/social/goodreads/0') %> +<%= include('../../../snippets/social/goodreads/1') %> +<%= include('../../../snippets/social/goodreads/2') %> +<%= include('../../../snippets/social/goodreads/3') %> +<%= include('../../../snippets/social/goodreads/4') %> +<%= include('../../../snippets/social/goodreads/5') %> <%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/google.md b/articles/connections/social/google.md index 6f0063569d..1ab56627fb 100644 --- a/articles/connections/social/google.md +++ b/articles/connections/social/google.md @@ -1,128 +1,31 @@ --- +title: Connect Apps to Google connection: Google -index: 1 +toc: true +public: true +index: 18 image: /media/connections/google.png -description: This page shows you how to connect your Auth0 client to Google. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +description: Learn how to add login functionality to your app with Google. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. alias: - gmail - google-oauth - google-oauth2 seo_alias: google +topics: + - authentication + - connections + - social + - google +contentType: how-to +useCase: + - add-login + - customize-connections + - add-idp --- - -# Connect Your Client to Google - -To connect your Auth0 client to Google and Google Apps, you will need to generate a *Client ID* and *Client Secret* in a Google project, copy these keys into your Auth0 settings, and enable the Connection. - -**NOTE**: This doc refers to the client steps to connect your client to Google. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Access the Google API Manager - -While logged in to your Google account, go to the [API Manager](https://console.developers.google.com/projectselector/apis/credentials). - -## 2. Create Your New App - -To create your new app, navigate to **Credentials** using the left-hand menu: - -![](/media/articles/connections/social/google/credentials.png) - -While you are on the **Credentials** page, click on **Create a project**. - -In the dialog box that appears, provide a Project name, answer Google's email- and privacy-related questions, and click **Create**: - -![](/media/articles/connections/social/google/create-new-project.png) - -Google will take a moment to create your project. When the process completes, Google will prompt you to create the credentials you need. - -![](/media/articles/connections/social/google/create-credentials.png) - -Click on **Create credentials** to display a pop-up menu listing the types of credentials you can create. Select the **OAuth client ID** option. - -## 3. Set Up the Consent Screen - -At this point, Google will display a warning banner that says, "To create an OAuth client ID, you must first set a product name on the consent screen." Click **Configure consent screen** to begin this process. - -![](/media/articles/connections/social/google/create-client-id.png) - -Provide a **Product Name** that will be shown to users when they log in through Google. - -![](/media/articles/connections/social/google/oauth-consent-screen.png) - -Click **Save**. - -## 4. Create your *Client Id* and *Client Secret* - -At this point, you will be prompted to provide additional information about your app. - -![](/media/articles/connections/social/google/create-client-id-config.png) - -Select **Web application**, and provide a name for your app. - -Under **Restrictions**, enter the following information: - -* **Authorized JavaScript origins:** `https://${account.namespace}` -* **Authorized redirect URI:** `https://${account.namespace}/login/callback` - -Click **Create**. Your `Client Id` and `Client Secret` will be displayed: - -![](/media/articles/connections/social/google/oauth-client-info.png) - -Save your `Client Id` and `Client Secret` to enter into the connection settings in Auth0 in Step 7. - -## 6. Enable the Admin SDK Service - -If you are planning to connect to Google Apps enterprise domains, you will need to enable the **Admin SDK** service. - -Navigate to the **Library** page of the API Manager. - -Select **Admin SDK** from the list of APIs: - -![](/media/articles/connections/social/google/api-manager-library.png) - -On the **Admin SDK** page, click **Enable**. - -![](/media/articles/connections/social/google/enable-admin-sdk.png) - -## 7. Enable the Connection - -Login to the [Auth0 Dashboard](${manage_url}) and select **Connections > Social** in the left navigation. - -Select the connection with the Google logo to access this connection's **Settings** page: - -![](/media/articles/connections/social/google/goog-settings.png) - -Select each of your existing Auth0 Clients for which you want to enable this connection. - -Click **Save**. - -![](/media/articles/connections/social/google/goog-api-aoth0-apps.png) - -## 8. Copy your *Client Id* and *Client Secret* into Auth0 - -Copy the `Client Id` and `Client Secret` from the Credentials page of your project in the **Google API Manager** into the fields on this page on Auth0. - -![](/media/articles/connections/social/google/goog-api-aoth0-settings.png) - -Select the **Permissions** for each of the features you want to allow your app to access. - -Click **Save**. - -## 9. Test your connection - -Go back to the [Connections > Social](${manage_url}/#/connections/social) section of the Auth0 dashboard. - -If you have configured your connection correctly, you will see a **Try** icon next to the Google logo: - -![](/media/articles/connections/social/google/goog-api-trylogo.png) - -Click **Try**. - -Click **Allow** in the permissions pop-up screen: - -![](/media/articles/connections/social/google/goog-api-permit.png) - -If you have configured everything correctly, you will see the **It works!!!** page: - -![](/media/articles/connections/social/google/goog-api-works.png) - +<%= include('../../../snippets/social/google/0') %> +<%= include('../../../snippets/social/google/1') %> +<%= include('../../../snippets/social/google/2') %> +<%= include('../../../snippets/social/google/3') %> +<%= include('../../../snippets/social/google/4') %> +<%= include('../../../snippets/social/google/5') %> <%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/imgur.md b/articles/connections/social/imgur.md new file mode 100644 index 0000000000..aa6b7fdf15 --- /dev/null +++ b/articles/connections/social/imgur.md @@ -0,0 +1,25 @@ +--- +title: Connect Apps to Imgur +connection: Imgur +image: /media/connections/imgur.png +seo_alias: imgur +description: Learn how to add login functionality to your app with Imgur. You will need to obtain a Client ID and Client Secret for Imgur. +toc: true +public: true +index: 6 +topics: + - connections + - social + - imgur +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +<%= include('../../../snippets/social/imgur/0') %> +<%= include('../../../snippets/social/imgur/1') %> +<%= include('../../../snippets/social/imgur/2') %> +<%= include('../../../snippets/social/imgur/3') %> +<%= include('../../../snippets/social/imgur/4') %> +<%= include('../../../snippets/social/imgur/5') %> +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/index.md b/articles/connections/social/index.md new file mode 100644 index 0000000000..de716ecff7 --- /dev/null +++ b/articles/connections/social/index.md @@ -0,0 +1,18 @@ +--- +title: Social Identity Providers +description: Learn about the social identity providers supported by Auth0. +topics: + - connections + - identity-providers +contentType: + - reference +useCase: + - customize-connections + - add-idp +--- +# Social Identity Providers + +Auth0 supports the following social providers for web applications out of the box. You can also use any [OAuth2 Authorization Server](/connections/social/oauth2) or explore partner-supported social connections in the [Auth0 Marketplace](https://marketplace.auth0.com/). + +<% var socialConnections = cache.find('articles/connections/social', {sort: 'index'}); %> +<%= include('../_connections', { connections: socialConnections }) %> \ No newline at end of file diff --git a/articles/connections/social/instagram.md b/articles/connections/social/instagram.md index 85eada0d3b..90dbc9e91a 100644 --- a/articles/connections/social/instagram.md +++ b/articles/connections/social/instagram.md @@ -1,96 +1,65 @@ --- +title: Connect Apps to Instagram connection: Instagram -index: 4 +index: 19 image: /media/connections/instagram.png seo_alias: instagram -description: This page shows you how to connect your Auth0 app to Instagram. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +description: Learn how to add login functionality to your app with Instagram. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +toc: true +public: false +topics: + - connections + - social + - instagram +contentType: how-to +useCase: + - customize-connections + - add-idp --- +# Connect Apps to Instagram -# Connect your app to Instagram +You can add functionality to your web app that allows your users to log in with Instagram. -To connect your Auth0 app to Instagram, you will need to generate a *Client ID* and *Client Secret* in an Instagram app, copy these keys into your Auth0 settings, and enable the connection. +::: note +Instagram has deprecated their legacy APIs in favor of the new [Instagram Graph API](https://developers.facebook.com/docs/instagram-basic-display-api), which requires users to authenticate using Facebook Login. +::: -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. +## Prerequisites -## 1. Log into the developer portal +Before you connect your Auth0 app to Instagram, you must have a [Facebook Developer](https://developers.facebook.com/) account. Follow the instructions in [Getting Started with the Instagram Graph API](https://developers.facebook.com/docs/instagram-api/getting-started/). You must get an access token that allows you to access the Facebook API. -Go to the Instagram [Developer portal](http://instagram.com/developer) and log in with your Instagram credentials. +## Steps -If asked, complete the Developer Signup: +To connect your app to Instagram, you will: -![](/media/articles/connections/social/instagram/instagram-devportal-0.png) +1. [Set up your app with the Graph API](#set-up-your-app-with-the-graph-api) +2. [Create and enable a connection in Auth0](#create-and-enable-a-connection-in-auth0) +3. [Test the connection](#test-the-connection) -On the page that follows, click **Register Your Application**: +### Set up your app with the Graph API -![](/media/articles/connections/social/instagram/instagram-devportal-1.png) +1. Log in to the [Facebook Developer](https://developers.facebook.com/) portal. +2. Follow steps for [App Development](https://developers.facebook.com/docs/apps#register) to register your app. +3. Add **Facebook Login** to your app in the **App Dashboard**. +4. On the **Facebook Login > Settings** page, under **Valid Oauth Redirect URIs**, enter your callback URL: + `https://${account.namespace}/login/callback` -## 2. Register your app + You can also set a **Deauthorize Callback URL** that will be called when a user deauthorizes your app. -Click **Register a New Client**: +<%= include('../_find-auth0-domain-redirects') %> -![](/media/articles/connections/social/instagram/instagram-devportal-2.png) +::: note +If your application requests sensitive permissions, it may be [subject to review by Facebook](https://developers.facebook.com/docs/apps/review/). Only the `default` and `email` permissions do not currently require app review. For info on Facebook permissions, see Facebook's [Facebook Login Permissions Reference](https://developers.facebook.com/docs/facebook-login/permissions/). +::: -## 3. Enter your callback URL +Once you are done you should have two pieces of information: the **Client ID** and **Client Secret** for your app. -Complete the form. Enter these values in the following fields: +### Create and enable a connection in Auth0 -**Website URL**: `https://${account.namespace}` +[Set up the Instagram social connection](/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Client Secret**. -**Valid redirect URI**: `https://${account.namespace}/login/callback` - -Click **Register**. +### Test the connection -![](/media/articles/connections/social/instagram/instagram-devportal-3.png) - -## 4. Get your *Client ID* and *Client Secret* - -Once your app is registered, you will be navigated to the **Manage Clients** page. Click on the **Manage** button for your new client. - -![](/media/articles/connections/social/instagram/instagram-devportal-4.png) - -This will bring you to the page that contains your **Client ID** and **Client Secret**. Copy these for use in the next step. - -![](/media/articles/connections/social/instagram/instagram-devportal-4-1.png) - -## 5. Copy your *Client Id* and *Client Secret* into Auth0 - -In a separate window, go to the [Connections > Social](${manage_url}/#/connections/social) section of the Auth Dashboard. - -Select **Instagram**. - -Copy the `Client Id` and `Client Secret` from the **Manage Client** page of the Instagram Developer portal into the fields on this page on Auth0. - -Select the **Permissions** you want to enable. - -Click **SAVE**. - -![](/media/articles/connections/social/instagram/instagram-devportal-5.png) - -## 6. Enable the Connection - -Go to the **Apps** tab of the Instagram connection on Auth0 and select each of your existing Auth0 apps for which you want to enable this connection: - -![](/media/articles/connections/social/instagram/instagram-devportal-6.png) - -## 7. Test the connection - -Close the **Settings** window to return to the [Connections > Social](${manage_url}/#/connections/social) section of the Auth0 dashboard. - -A **TRY** icon will now be displayed next to the Instagram logo: - -![](/media/articles/connections/social/instagram/instagram-devportal-7.png) - -Click **TRY**. - -Click **Authorize** to allow your app access. - -![](/media/articles/connections/social/instagram/instagram-devportal-7a.png) - -If you have configured everything correctly, you will see the **It works!!!** page: - -![](/media/articles/connections/social/instagram/instagram-devportal-7b.png) - -[Click here to learn more about authentication with Instagram](https://www.instagram.com/developer/authentication/) +You're ready to [test your connection](/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**. <%= include('../_quickstart-links.md') %> - diff --git a/articles/connections/social/line.md b/articles/connections/social/line.md new file mode 100644 index 0000000000..6100242dc5 --- /dev/null +++ b/articles/connections/social/line.md @@ -0,0 +1,27 @@ +--- +title: Connect Apps to LINE +connection: LINE +toc: true +public: true +index: 20 +image: /media/connections/line.png +seo_alias: line +description: Learn how to add login functionality to your app with LINE. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +topics: + - authentication + - connections + - social + - line +contentType: how-to +useCase: + - add-login + - customize-connections + - add-idp +--- +<%= include('../../../snippets/social/line/0') %> +<%= include('../../../snippets/social/line/1') %> +<%= include('../../../snippets/social/line/2') %> +<%= include('../../../snippets/social/line/3') %> +<%= include('../../../snippets/social/line/4') %> +<%= include('../../../snippets/social/line/5') %> +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/linkedin.md b/articles/connections/social/linkedin.md index 718b3db818..4420d9472c 100644 --- a/articles/connections/social/linkedin.md +++ b/articles/connections/social/linkedin.md @@ -1,91 +1,27 @@ --- +title: Connect Apps to LinkedIn connection: LinkedIn -index: 3 +toc: true +public: true +index: 21 image: /media/connections/linkedin.png seo_alias: linkedin -description: This page shows you how to connect your Auth0 app to LinkedIn. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +description: Learn how to add login functionality to your app with LinkedIn. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +topics: + - authentication + - connections + - social + - linkedin +contentType: how-to +useCase: + - add-login + - customize-connections + - add-idp --- - -# Connect your app to LinkedIn - -To connect your Auth0 app to LinkedIn, you will need to generate a *Client ID* and *Client Secret* in a LinkedIn app, copy these keys into your Auth0 settings, and enable the connection. - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Log into the developer portal - -Login to the [LinkedIn Developer portal](http://developer.linkedin.com/) and click **My Apps**: - -![](/media/articles/connections/social/linkedin/linkedin-devportal-1.png) - -## 2. Create your app - -Click **Create Application**: - -![](/media/articles/connections/social/linkedin/linkedin-devportal-2.png) - -## 3. Complete information about your app - -Complete the form. - -Enter the following URL in the **Website URL** field: - -`https://${account.namespace}` - -Click **Submit**. - -![](/media/articles/connections/social/linkedin/linkedin-devportal-3.png) - -## 4. Enter your callback URL - -Enter the following URL in the **Authorized Redirect URLs** field and click **Add**: - -`https://${account.namespace}/login/callback` - -Click **Update**. - -![](/media/articles/connections/social/linkedin/linkedin-devportal-4.png) - -## 5. Get your *Client ID* and *Client Secret* - -On the same page, your `Client ID` and `Client Secret` will be displayed: - -![](/media/articles/connections/social/linkedin/linkedin-devportal-5.png) - -## 6. Copy your *Client Id* and *Client Secret* into Auth0 - -Login to the Auth0 [Dashboard](${manage_url}) and select **Connections > Social** in the left navigation. - -Select the LinkedIn connection to access its **Settings** page. - -Copy the `Client Id` and `Client Secret` from the **Authentication** page of your app on LinkedIn into the fields on this page on Auth0: - -![](/media/articles/connections/social/linkedin/linkedin-devportal-6.png) - -## 7. Enable the Connection - -Go to the **Apps** tab of the LinkedIn connection on Auth0 and select each of your existing Auth0 apps for which you want to enable this connection: - -![](/media/articles/connections/social/linkedin/linkedin-devportal-7.png) - -## 8. Test your app - -Go back to the [Connections > Social](${manage_url}/#/connections/social) section of the Auth0 dashboard. - -A **TRY** icon will now be displayed next to the LinkedIn logo: - -![](/media/articles/connections/social/linkedin/linkedin-devportal-8.png) - -Click **TRY**. - -Provide your LinkedIn credentials and click **Allow access**. - -![](/media/articles/connections/social/linkedin/linkedin-devportal-8a.png) - -If you have configured everything correctly, you will see the **It works!!!** page: - -![](/media/articles/connections/social/linkedin/linkedin-devportal-8b.png) - +<%= include('../../../snippets/social/linkedin/0') %> +<%= include('../../../snippets/social/linkedin/1') %> +<%= include('../../../snippets/social/linkedin/2') %> +<%= include('../../../snippets/social/linkedin/3') %> +<%= include('../../../snippets/social/linkedin/4') %> +<%= include('../../../snippets/social/linkedin/5') %> <%= include('../_quickstart-links.md') %> - - diff --git a/articles/connections/social/microsoft-account.md b/articles/connections/social/microsoft-account.md index 02f7113be6..4ec2590a98 100644 --- a/articles/connections/social/microsoft-account.md +++ b/articles/connections/social/microsoft-account.md @@ -1,102 +1,32 @@ --- +title: Connect Apps to Microsoft connection: Microsoft Account image: /media/connections/ms.png -index: 12 +toc: true +public: true +index: 22 alias: - live-id - microsoft-live - windowslive - windows-live seo_alias: microsoft-account -description: How to configure your Auth0 app for an OAuth connection to Microsoft Account. +description: Learn how to add login functionality to your app with Microsoft Accounts. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +topics: + - authentication + - connections + - social + - microsoft +contentType: how-to +useCase: + - add-login + - customize-connections + - add-idp --- - -# Connect your app to Microsoft Account - -To connect your Auth0 app to Microsoft Account, you will need to create an app on the Microsoft Application Registration Portal, generate an `Application Id` and `Secret`, copy these credentials into Auth0, and enable the connection. - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Create an application - -Login to the [Microsoft Application Registration Portal](https://apps.dev.microsoft.com). - -Click **Add an app**. - -![](/media/articles/connections/social/microsoft-account/ma-portal-1a.png) - -**NOTE:** If you have existing apps, there may be two **Add an app** buttons. Select the first. - -Name your new app and click **Create application**: - -![](/media/articles/connections/social/microsoft-account/ma-portal-1.png) - -## 2. Copy your Application Id - -On the **Registration** page that follows, copy the **Application Id**. This is your `client_id`. - -![](/media/articles/connections/social/microsoft-account/ma-portal-2.png) - -## 3. Get your password - -Click **Generate New Password**. - -Copy your password. This is your `client_secret`. - -![](/media/articles/connections/social/microsoft-account/ma-portal-3.png) - -## 4. Enter your callback URL - -Click **Add Platform**, then select **Web**. - -![](/media/articles/connections/social/microsoft-account/ma-portal-4a.png) - -Enter the following under **Redirect URIs**: - -`https://${account.namespace}/login/callback` - -![](/media/articles/connections/social/microsoft-account/ma-portal-4.png) - -Scroll down to **Advanced Options** and make sure **Live SDK support** is checked. - -![](/media/articles/connections/social/microsoft-account/ma-portal-4b.png) - -Click **Save**. - -## 5. Copy your *Client Id* and *Client Secret* - -Go to the [Auth0 Dashboard](${manage_url}) and select **Connections > Social** from the left menu. - -Select the **Microsoft** connection. - -Copy the `Client Id` and `Client Secret` you saved earlier into the fields on this page on Auth0. - -Click **Save**. - -![](/media/articles/connections/social/microsoft-account/ma-portal-5.png) - -## 6. Enable your apps - -Select the **Apps** tab of the Microsoft Account settings page in Auth0 and enable the applications you want to use with this connection. - -Click **Save**. - -![](/media/articles/connections/social/microsoft-account/ma-portal-6.png) - -## 7. Test your connection - -On the [Social Connections](${manage_url}/#/connections/social) page in the Auth0 dashboard, click the **Try** button next to the Microsoft connection. - -![](/media/articles/connections/social/microsoft-account/ma-portal-7.png) - -Click Yes to allow your Microsoft app to access your information. - -![](/media/articles/connections/social/microsoft-account/ma-portal-8.png) - -If you see the **It Works!** page, you have successfully configured your connection to Microsoft Account. - -![](/media/articles/connections/social/microsoft-account/ma-portal-9.png) - +<%= include('../../../snippets/social/microsoft-account/0') %> +<%= include('../../../snippets/social/microsoft-account/1') %> +<%= include('../../../snippets/social/microsoft-account/2') %> +<%= include('../../../snippets/social/microsoft-account/3') %> +<%= include('../../../snippets/social/microsoft-account/4') %> +<%= include('../../../snippets/social/microsoft-account/5') %> <%= include('../_quickstart-links.md') %> - - diff --git a/articles/connections/social/miicard.md b/articles/connections/social/miicard.md deleted file mode 100644 index e4a0d0d0d1..0000000000 --- a/articles/connections/social/miicard.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -connection: miiCard -image: /media/connections/miicard.png -seo_alias: miicard -description: How to obtain a Client Id and Client Secret for miiCard. ---- - -# Obtain a Consumer Key and Consumer Secret for miiCard - -Please contact miiCard to get [self-management](http://www.miicard.com/developers/self-management) capabilities on your miiCard account. - -Once this is enabled, you will be able to complete the Auth0 setup. The `Consumer Key` and `Consumer Secret` will be available on the __miiCard Business Portal__: - -![](/media/articles/connections/social/miicard/miicard-businessportal.png) - -<%= include('../_quickstart-links.md') %> \ No newline at end of file diff --git a/articles/connections/social/oauth2.md b/articles/connections/social/oauth2.md index 85993b8c3f..963d33a05e 100644 --- a/articles/connections/social/oauth2.md +++ b/articles/connections/social/oauth2.md @@ -1,73 +1,194 @@ --- -connection: Generic OAuth2 Provider +connection: OAuth2 Provider (Generic) image: /media/connections/oauth2.png seo_alias: oauth2 -index: 13 -description: You can add any OAuth2 provider using the Auth0 Custom Social Connections extension. +toc: true +index: 15 +description: Learn how to add any OAuth2 provider using Auth0 Custom Social Connections. +topics: + - connections + - social + - oauth2 +contentType: how-to +useCase: + - customize-connections + - add-idp --- +# Connect Apps to Generic OAuth2 Authorization Servers -# Add a generic OAuth2 Authorization Server to Auth0 +The most common [identity providers](/identityproviders) are available in [Auth0's Dashboard](${manage_url}) and in the [Auth0 Marketplace](https://marketplace.auth0.com/features/social-connections). However, you can add any other OAuth2 provider using a **Custom Social Connection**. -The most common [identity providers](/identityproviders) are readily available on Auth0's dashboard. However, you can add any other OAuth2 provider using the **Custom Social Connections** [extension](${manage_url}/#/extensions). +To create a new Custom Social Connection, navigate to [**Auth0 Dashboard > Authentication > Social**](${manage_url}/#/connections/social), click **Create Connection**, scroll to the bottom of the list, and click **Create Custom**. -![](/media/articles/connections/social/oauth2/custom-social-connections.png) +The form that appears contains several fields that you must use to configure the custom connection: -### The fetchUserProfile script +- **Connection Name**: Logical identifier for the Connection you are creating. This name cannot be changed, must start and end with an alphanumeric character, and can only contain alphanumeric characters and dashes. +- **Authorization URL**: URL to which users are redirected to log in. + :::note + Do not attempt to set the OAuth2 `response_mode` parameter in the authorization URL. This connection only supports the default `response_mode` (`query`). + ::: +- **Token URL**: URL used to exchange the received authorization code for access tokens and, if requested, ID tokens. +- **Scope** - `scope` parameters to send with the authorization request. Separate multiple scopes with spaces. +- **Client ID**: Client ID for Auth0 as an application used to request authorization and exchange the authorization code. To get a Client ID, you will need to register with the identity provider. +- **Client Secret**: Client Secret for Auth0 as an application used to exchange the authorization code. To get a Client Secret, you will need to register with the identity provider. +- **Fetch User Profile Script**: Node.js script used to call a userinfo URL with the provided access token. To learn more about this script, see [Fetch User Profile Script](#fetch-user-profile-script). -A custom `fetchUserProfile` script will be called after the user has logged in with the OAuth2 provider. Auth0 will execute this script to call the OAuth2 provider API and get the user profile: +:::note +When configuring the custom identity provider, use the callback URL `https://${account.namespace}/login/callback`. +::: + +Once you create the custom connection, you will see the **Applications** view. Here, you can enable and disable applications for which you would like the connection to appear. + +## Fetch User Profile Script + +The fetch user profile script is called after the user has logged in with the OAuth2 provider. Auth0 executes this script to call the OAuth2 provider API and get the user profile: ```js -function(access_token, ctx, callback){ - // call the oauth2 provider and return a profile - // here we are returning a "mock" profile, you can use this to start with to test the flow. - var profile = { - user_id: '123', - given_name: 'Eugenio', - family_name: 'Pace', - email: 'eugenio@mail.com' - }; - - callback(null, profile); +function fetchUserProfile(accessToken, context, callback) { + request.get( + { + url: 'https://auth.example.com/userinfo', + headers: { + 'Authorization': 'Bearer ' + accessToken, + } + }, + (err, resp, body) => { + if (err) { + return callback(err); + } + + if (resp.statusCode !== 200) { + return callback(new Error(body)); + } + + let bodyParsed; + try { + bodyParsed = JSON.parse(body); + } catch (jsonError) { + return callback(new Error(body)); + } + + const profile = { + user_id: bodyParsed.account.uuid, + email: bodyParsed.account.email + }; + + callback(null, profile); + } + ); } ``` -The `access_token` parameter is used for authenticating requests to the provider's API. +The `user_id` property in the returned profile is required, and the `email` property is optional but highly recommended. To learn more about what attributes can be returend, see [User Profile Root Attributes](/users/updating-user-profile-root-attributes). -**NOTE:** We recommend using the field names from the [normalized profile](/user-profile#normalized-user-profile). +You can filter, add, or remove anything from the profile returned from the provider. However, it is recommended that you keep this script as simple as possible. More sophisticated manipulation of user information can be achieved through the use of [Rules](/rules). One advantage of using Rules is that they apply to any connection. -For example, the following code will retrieve the user profile from the **GitHub** API: +## Log in using the custom connection -```js -function(access_token, ctx, callback) { - request.get('https://api.github.com/user', { - 'headers': {\ - 'Authorization': 'Bearer ' + access_token, - 'User-Agent': 'Auth0' - } - }, function(e,r,b){ - if( e ) return cb(e); - if( r.statusCode !== 200 ) return callback(new Error('StatusCode:'+r.statusCode)); - callback(null,JSON.parse(b)); - }); +You can use any of the Auth0 standard mechanisms to log a user in with your custom connection. A direct link would look like: + +```text +https://${account.namespace}/authorize + ?response_type=code + &client_id=${account.clientId} + &redirect_uri=${account.callback} + &scope=openid%20profile%20email + &connection=NAME_OF_CONNECTION +``` + +## Modify the icon and display name + +To add an icon to the identity provider's login button or change the text used on the login button, you can use the `icon_url` property of the `options` object and the `display_name` property, respectively, via the [Management API](/api/management/v2#!/Connections/patch_connections_by_id). + +:::note +These fields will only affect how the Connection is displayed in the [New Universal Login Experience](https://auth0.com/docs/universal-login/new-experience). +::: + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/connections/CONNECTION-ID", + "headers": [ + { "name": "Content-Type", "value": "application/json" } + ], + "postData": { + "mimeType": "application/json", + "text": "{ \"options\": { \"client_id\": \"...\", \"client_secret\": \"...\", \"icon_url\": \"https://cdn.example.com/assets/icon.png\", \"scripts\": { \"fetchUserProfile\": \"...\" }, \"authorizationURL\": \"https://public-auth.example.com/oauth2/authorize\", \"tokenURL\": \"https://auth.example.com/oauth2/token\", \"scope\": \"auth\" }, \"enabled_clients\": [ \"...\" ] }, \"display_name\": \"Connection Name\"" + } } ``` -You can filter, add or remove anything from the profile returned from the provider. However, it is recommended that you keep this script as simple as possible. More sophisticated manipulation of user information can be achieved through the use of [Rules](/rules). One advantage of using Rules is that they apply to *any* connection. +![Custom OAuth2 Connection with a custom icon and name](/media/articles/connections/social/oauth2/custom-connection-icon.png) + +## Pass provider-specific parameters + +You can pass provider-specific parameters to the Authorization endpoint of OAuth 2.0 providers. These can be either static or dynamic. + +### Pass static parameters + +To pass static parameters (parameters that are sent with every authorization request), you can use the `authParams` element of the `options` when configuring an OAuth 2.0 connection via the [Management API](/api/management/v2#!/Connections/patch_connections_by_id). The call below will set a static parameter of `custom_param` set to `custom.param.value` on all authorization requests: + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/connections/CONNECTION-ID", + "headers": [ + { "name": "Content-Type", "value": "application/json" } + ], + "postData": { + "mimeType": "application/json", + "text": "{ \"options\": { \"client_id\": \"...\", \"client_secret\": \"...\", \"authParams\": { \"custom_param\": \"custom.param.value\" }, \"scripts\": { \"fetchUserProfile\": \"...\" }, \"authorizationURL\": \"https://public-auth.example.com/oauth2/authorize\", \"tokenURL\": \"https://auth.example.com/oauth2/token\", \"scope\": \"auth\" }, \"enabled_clients\": [ \"...\" ] }" + } +} +``` -## Login using the custom connection +### Pass dynamic parameters -You can use any of the Auth0 standard mechanisms (e.g. direct links, [Auth0 Lock](/libraries/lock), [auth0.js](/libraries/auth0js), etc.) to login a user with the your custom connection. +In certain circumstances, you may want to pass a dynamic value to an OAuth 2.0 Identity Provider. In this case, you can use the `authParamsMap` element of the `options` to specify a mapping between one of the existing additional parameters accepted by the [Auth0 `/authorize` endpoint](/api/authentication#social) to the parameter accepted by the Identity Provider. -A direct link would look like: +Using the same example above, let's assume that you want to pass the `custom_param` parameter to the authorization endpoint, but you want to specify the actual value of the parameter when calling the Auth0 `/authorize` endpoint. - https://${account.namespace}/authorize/?client_id=${account.clientId}&response_type=code&redirect_uri=${account.callback}&state=OPAQUE_VALUE&connection=THE_NAME_OF_THE_CONNECTION +In this case, you can use one of the existing addition parameters accepted by the `/authorize` endpoint, such as `access_type`, and map that to the `custom_param` parameter: + +```har +{ + "method": "PATCH", + "url": "https://${account.namespace}/api/v2/connections/CONNECTION-ID", + "headers": [ + { "name": "Content-Type", "value": "application/json" } + ], + "postData": { + "mimeType": "application/json", + "text": "{ \"options\": { \"client_id\": \"...\", \"client_secret\": \"...\", \"authParamsMap\": { \"custom_param\": \"access_type\" }, \"scripts\": { \"fetchUserProfile\": \"...\" }, \"authorizationURL\": \"https://auth.example.com/oauth2/authorize\", \"tokenURL\": \"https://auth.example.com/oauth2/token\", \"scope\": \"auth\" }, \"enabled_clients\": [ \"...\" ] }" + } +} +``` + +Now when calling the `/authorize` endpoint, you can pass the access type in the `access_type` parameter, and that value will in turn be passed along to the authorization endpoint in the `custom_param` parameter. + +## Pass Extra Headers + +In some instances, you will need to pass extra headers to the Token endpoint of an OAuth 2.0 provider. To configure extra headers, open the Settings for the Connection, and in the **Custom Headers** field, specify a JSON object with the custom headers as key-value pairs: + +```json +{ + "Header1" : "Value", + "Header2" : "Value" +} +``` + +Let's use an example where an Identity Provider may require you to pass an `Authorization` header with [Basic access authentication](https://en.wikipedia.org/wiki/Basic_access_authentication) credentials. In this scenario, you can specify the following JSON object in the **Custom Headers** field: + +```json +{ + "Authorization": "Basic [your credentials]" +} +``` -To add a custom connection in Lock, you can add a custom button by following the instructions at [Adding custom connections to lock](/libraries/lock/v9/ui-customization#adding-a-new-ui-element-using-javascript) and using this link as the button `href`. +Where `[your credentials]` are the actual credentials to send to the Identity Provider. -## Other resources +## Keep Reading -* [Adding custom connections to lock](/libraries/lock/v9/ui-customization#adding-a-new-ui-element-using-javascript) -* [Generic OAuth2 or OAuth1 examples](/oauth2-examples) -* [Identity Providers supported by Auth0](/identityproviders) +* [Social Identity Providers](https://auth0.com/docs/connections/identity-providers-social) +* [All Identity Providers supported by Auth0](/identityproviders) * [Identity Protocols supported by Auth0](/protocols) -* [Add a generic OAuth1 Authorization Server to Auth0](/oauth1) diff --git a/articles/connections/social/paypal-sandbox.md b/articles/connections/social/paypal-sandbox.md new file mode 100644 index 0000000000..f03edf9368 --- /dev/null +++ b/articles/connections/social/paypal-sandbox.md @@ -0,0 +1,27 @@ +--- +title: Connect Apps to PayPal Sandbox +connection: PayPal Sandbox +image: /media/connections/paypal.png +seo_alias: paypal +toc: true +public: true +index: 24 +description: Learn how to add login functionality to your app with PayPal Sandbox. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +topics: + - connections + - social + - paypal + - sandbox +contentType: how-to +useCase: + - customize-connections + - add-idp + - add-login +--- +<%= include('../../../snippets/social/paypal-sandbox/0') %> +<%= include('../../../snippets/social/paypal-sandbox/1') %> +<%= include('../../../snippets/social/paypal-sandbox/2') %> +<%= include('../../../snippets/social/paypal-sandbox/3') %> +<%= include('../../../snippets/social/paypal-sandbox/4') %> +<%= include('../../../snippets/social/paypal-sandbox/5') %> +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/paypal.md b/articles/connections/social/paypal.md index bd90a44316..805085dd6a 100644 --- a/articles/connections/social/paypal.md +++ b/articles/connections/social/paypal.md @@ -1,78 +1,25 @@ --- +title: Connect Apps to PayPal connection: PayPal image: /media/connections/paypal.png seo_alias: paypal -index: 10 -description: How to obtain a Client Id and Client Secret for PayPal. +toc: true +public: true +index: 23 +description: Learn how to add login functionality to your app with PayPal. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +topics: + - connections + - social + - paypal +contentType: how-to +useCase: + - customize-connections + - add-idp --- - -# Obtain a PayPal Client Id and Secret - -To configure an OAuth connection with PayPal, register your Auth0 Client on the [**PayPal Developer Portal**](https://developer.paypal.com/). - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Registering Your Auth0 Client Using the PayPal Developer Portal - -Go to the [PayPal Developer Portal](https://developer.paypal.com/) and log in with your PayPal credentials. Click on **Dashboard** in the upper-right corner. - -![](/media/articles/connections/social/paypal/dev-portal.png) - -You will be directed to the **My Apps & Credentials** page. Scroll down to under the **REST API Apps** section, click **Create App**. - -![](/media/articles/connections/social/paypal/apps-and-creds.png) - -On the **Create New App** page, provide a value for **App Name** and click **Create App**: - -![](/media/articles/connections/social/paypal/create-new-app.png) - -## 2. Obtain Your PayPal Client ID and Secret - -Once PayPal has created your app, you will be shown the API credentials for this particular application. Copy both the **Client ID** and **Secret** values (the Secret value is initially hidden) for later use. - -![](/media/articles/connections/social/paypal/api-creds.png) - -## 3. Provide PayPal with Information About Your Auth0 Client - -Scroll down to the **Sandbox App Settings** section and **Show** the **Return URL** box. Enter the following value: - -`https://${account.namespace}/login/callback` - -![](/media/articles/connections/social/paypal/sandbox-settings.png) - -If you would like to control the scope of access to customer data (such as profile information, email address, home address, and phone number) through Auth0, you need to enable access to this information by selecting the desired attributes under the **Advanced Options**, which becomes available to you if you enable the **Log In with PayPal** feature. - -![](/media/articles/connections/social/paypal/log-in-with-paypal.png) - -Click **Save**: - -## 4. Provide Your PayPal Client Id and Secret to Your Auth0 Client - -Go to the [Connections > Social](${manage_url}/#/connections/social) section of the Auth0 Dashboard. Under the **Social** page, click to enable **PayPal**. - -![](/media/articles/connections/social/paypal/social-connections.png) - -Paste in the **Client Id** and **Secret** from the **PayPal Developer Portal** into the **App ID** and **App Secret** fields on this page on Auth0, respectively, then click **Save**. - -![](/media/articles/connections/social/paypal/paypal-settings.png) - -## 5. Enable and Test the Connection - -Switch the **Paypal** connection in the dashboard to enabled. Then under **Clients**, choose which of your clients you want to enable this connection and then click **SAVE**. - -![Enable Clients](/media/articles/connections/social/paypal/enable-clients.png) - -Now you should see a **TRY** button for the **Paypal** connection. - -![Try Paypal](/media/articles/connections/social/paypal/try-button.png) - -This allows you to test your connection to see if it has been configured properly. - -**Note:** The Target URL field that you enter can take up to 3 hours for the change to go into effect with Paypal. This can cause the connection to fail until it is updated. - -## Additional Information - -[Paypal Docs](https://developer.paypal.com/docs/) - +<%= include('../../../snippets/social/paypal/0') %> +<%= include('../../../snippets/social/paypal/1') %> +<%= include('../../../snippets/social/paypal/2') %> +<%= include('../../../snippets/social/paypal/3') %> +<%= include('../../../snippets/social/paypal/4') %> +<%= include('../../../snippets/social/paypal/5') %> <%= include('../_quickstart-links.md') %> - diff --git a/articles/connections/social/pinterest.md b/articles/connections/social/pinterest.md new file mode 100644 index 0000000000..ed39fbed47 --- /dev/null +++ b/articles/connections/social/pinterest.md @@ -0,0 +1,25 @@ +--- +title: Connect Apps to Pinterest +connection: Pinterest +image: /media/connections/pinterest.png +seo_alias: pinterest +description: Learn how to add login functionality to your app with Pinterest. You will need to obtain a Client ID and Client Secret for Pinterest. +toc: true +public: false +index: 6 +topics: + - connections + - social + - pinterest +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +<%= include('../../../snippets/social/pinterest/0') %> +<%= include('../../../snippets/social/pinterest/1') %> +<%= include('../../../snippets/social/pinterest/2') %> +<%= include('../../../snippets/social/pinterest/3') %> +<%= include('../../../snippets/social/pinterest/4') %> +<%= include('../../../snippets/social/pinterest/5') %> +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/planning-center.md b/articles/connections/social/planning-center.md index c7782597ed..1f05c7844e 100644 --- a/articles/connections/social/planning-center.md +++ b/articles/connections/social/planning-center.md @@ -1,45 +1,25 @@ --- +title: Connect Apps to Planning Center connection: Planning Center image: /media/connections/planning-center.png seo_alias: planning-center -description: How to obtain a Client Id and Client Secret for Planning Center. +description: Learn how to add login functionality to your app with Planning Center. You will need to get a Client Id and Client Secret for Planning Center. +toc: true +public: true +index: 25 +topics: + - connections + - social + - planning-center +contentType: how-to +useCase: + - customize-connections + - add-idp --- - -# Obtain a *Client ID* and *Secret* for Planning Center - -To configure an OAuth2 connection with Planning Center Online, you will need to register Auth0 with Planning Center on their Developer portal. - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Log into the Planning Center Developer portal - -Go to the [Planning Center Developer](https://api.planningcenteronline.com/) portal. Log in with your credentials and click **Register** on the **Developer Applications** page: - -![](/media/articles/connections/social/planning-center/planning-center-api-1.png) - -## 2. Complete information about your instance of Auth0 - -Complete the form. In the **Authorization callback URLs** field, enter this URL: - - https://${account.namespace}/login/callback - -and click **Submit**: - -![](/media/articles/connections/social/planning-center/planning-center-api-2.png) - -## 3. Get your *Client ID* and *Secret* - -Once your app is registered, your `Client Id` and `Secret` will be displayed: - -![](/media/articles/connections/social/planning-center/planning-center-api-3.png) - -## 4. Copy your *Client Id* and *Secret* - -Go to the [Social Connections](${manage_url}/#/connections/social) page of your Auth0 Dashboard and select **Planning Center**. - -Copy the `Client Id` and `Secret` from the **Developer Applications** page of the Planning Center Developer portal into the fields on this page on Auth0. - -![](/media/articles/connections/social/planning-center/planning-center-api-4.png) - +<%= include('../../../snippets/social/planning-center/0') %> +<%= include('../../../snippets/social/planning-center/1') %> +<%= include('../../../snippets/social/planning-center/2') %> +<%= include('../../../snippets/social/planning-center/3') %> +<%= include('../../../snippets/social/planning-center/4') %> +<%= include('../../../snippets/social/planning-center/5') %> <%= include('../_quickstart-links.md') %> - diff --git a/articles/connections/social/quickbooks-online.md b/articles/connections/social/quickbooks-online.md new file mode 100644 index 0000000000..739f4c3141 --- /dev/null +++ b/articles/connections/social/quickbooks-online.md @@ -0,0 +1,25 @@ +--- +title: Connect Apps to QuickBooks Online +connection: QuickBooks Online +image: /media/connections/quickbooks.png +seo_alias: quickbooks-online +description: Learn how to add login functionality to your app with QuickBooks Online. You will need to obtain a Client ID and Client Secret for QuickBooks Online. +toc: true +public: true +index: 6 +topics: + - connections + - social + - quickbooks-online +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +<%= include('../../../snippets/social/quickbooks-online/0') %> +<%= include('../../../snippets/social/quickbooks-online/1') %> +<%= include('../../../snippets/social/quickbooks-online/2') %> +<%= include('../../../snippets/social/quickbooks-online/3') %> +<%= include('../../../snippets/social/quickbooks-online/4') %> +<%= include('../../../snippets/social/quickbooks-online/5') %> +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/renren.md b/articles/connections/social/renren.md index 95deb4802b..e6a74ba09f 100644 --- a/articles/connections/social/renren.md +++ b/articles/connections/social/renren.md @@ -1,43 +1,25 @@ --- +title: Connect Apps to RenRen connection: RenRen image: /media/connections/renren.png seo_alias: renren -description: How to obtain an API Key and Secret Key for RenRen. +description: Learn how to add login functionality to your app with RenRen. You will need to obtain an API Key and Secret Key for RenRen. +toc: true +public: true +index: 26 +topics: + - connections + - social + - renren +contentType: how-to +useCase: + - customize-connections + - add-idp --- - -# Obtain an *API Key* and *Secret Key* for RenRen - -To configure a RenRen OAuth2 connection, you will need to register Auth0 on the RenRen integration portal. - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Create a new App - -Log into the RenRen [integration portal](http://app.renren.com/developers) and click **Create New App**: - -![](/media/articles/connections/social/renren/renren-register-1.png) - -## 2. Enter app information - -Complete the required information on this page. Enter the following value for the *callback URL*: - - https://${account.namespace}/login/callback - -Click **Create App**. - -![](/media/articles/connections/social/renren/renren-register-2.png) - -## 3. Get your *API Key* and *Secret Key* - -Once the app is created, the `API Key` and `Secret Key` will be displayed on the following page: - -![](/media/articles/connections/social/renren/renren-register-3.png) - -## 4. Copy your *API Key* and *Secret Key* - -Go to the [Social Connections](${manage_url}/#/connections/social) section of your Auth0 Dashboard and choose **RenRen**. Copy the `API Key` and `Secret Key` from the **New App** page on RenRen into fields on this page on Auth0: - -![](/media/articles/connections/social/renren/renren-register-4.png) - +<%= include('../../../snippets/social/renren/0') %> +<%= include('../../../snippets/social/renren/1') %> +<%= include('../../../snippets/social/renren/2') %> +<%= include('../../../snippets/social/renren/3') %> +<%= include('../../../snippets/social/renren/4') %> +<%= include('../../../snippets/social/renren/5') %> <%= include('../_quickstart-links.md') %> - diff --git a/articles/connections/social/reprompt-permissions.md b/articles/connections/social/reprompt-permissions.md index b43e451e93..dfe3a2a4b8 100644 --- a/articles/connections/social/reprompt-permissions.md +++ b/articles/connections/social/reprompt-permissions.md @@ -1,19 +1,31 @@ --- -description: How to handle declined authorization permissions and how to reprompt for these permissions. +description: Describes how to handle declined authorization permissions and how to re-prompt for these permissions. +topics: + - connections + - social +contentType: how-to +useCase: + - customize-connections + - add-idp --- -# Handling Declined Authorization Permissions +# Handle Declined Authorization Permissions -When your users are authorizing your application some providers such as Facebook allow the user to be selective over which attributes they wish to share. By default, this selection is only made when the user is first authorizing the app. If your user chooses not to allow certain attributes which are required by your application(such as email) the user will not be able to access your application. Your user will need to be reprompted for permissions and grant the required attribute to be able to login. +When your users are authorizing your application, some providers (such as Facebook) allow the user to select the attributes they wish to share. -## How to Reprompt for Permissions +By default, this selection is made only when the user authorizes the app for the first time. If your user chooses to *not* allow certain attributes (such as their email) that are required by your application, the user will not be able to access your application. -By setting the `prompt=consent` parameter for [/authorize](/api/authentication/reference#social) in the [Authorization API](/api/authentication), your user will be prompted to grant permissions for your application again. +In such instances, your user will need to be re-prompted to grant permission to the required attribute(s) to login. -This parameter can also be set using [Lock](/libraries/lock) as an [Authentication Parameter](/libraries/lock/sending-authentication-parameters) with `prompt: 'consent'`. +## Re-prompt for permissions -Alternatively it can be set with [Auth0.js](https://github.com/auth0/auth0.js), with `prompt: 'consent'`. +By setting the **prompt=consent** parameter when calling the [/authorize](/api/authentication/reference#social) endpoint of the [Authorization API](/api/authentication), your user will be prompted again to grant permissions for your application. -## Learn More -[Click here to learn more about handling declined Facebook permissions.](https://developers.facebook.com/docs/facebook-login/handling-declined-permissions) -[Click here to learn more about GitHub scopes](https://developer.github.com/v3/oauth/#scopes) +This parameter can also be set using Lock as an [Authentication Parameter](/libraries/lock/sending-authentication-parameters) with **prompt: 'consent'**. + +Alternatively, you can set this with [Auth0.js](https://github.com/auth0/auth0.js) using **prompt: 'consent'**. + +## Keep reading + +* [Learn more about handling declined Facebook permissions](https://developers.facebook.com/docs/facebook-login/handling-declined-permissions) +* [Learn more about GitHub scopes](https://developer.github.com/v3/oauth/#scopes) \ No newline at end of file diff --git a/articles/connections/social/salesforce-community.md b/articles/connections/social/salesforce-community.md new file mode 100644 index 0000000000..7288863f0a --- /dev/null +++ b/articles/connections/social/salesforce-community.md @@ -0,0 +1,30 @@ +--- +title: Connect Apps to Salesforce Community +connection: Salesforce Community +image: /media/connections/salesforce.png +seo_alias: salesforce-community +toc: true +public: true +index: 29 +description: Learn how to add login functionality to your app with Salesforce Community. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +topics: + - connections + - social + - salesforce + - salesforce-community +contentType: how-to +useCase: + - customize-connections + - add-idp + - add-login +--- +<%= include('../../../snippets/social/salesforce-community/0') %> +<%= include('../../../snippets/social/salesforce-community/1') %> +<%= include('../../../snippets/social/salesforce-community/2') %> +<%= include('../../../snippets/social/salesforce-community/3') %> +<%= include('../../../snippets/social/salesforce-community/4') %> +<%= include('../../../snippets/social/salesforce-community/5') %> +<%= include('../../../snippets/social/salesforce-community/6') %> +<%= include('../../../snippets/social/salesforce-community/7') %> +<%= include('../../../snippets/social/salesforce-community/8') %> +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/salesforce-sandbox.md b/articles/connections/social/salesforce-sandbox.md new file mode 100644 index 0000000000..78bc4bf722 --- /dev/null +++ b/articles/connections/social/salesforce-sandbox.md @@ -0,0 +1,26 @@ +--- +title: Connect Apps to Salesforce Sandbox +connection: Salesforce Sandbox +image: /media/connections/salesforce.png +seo_alias: salesforce-sandbox +toc: true +public: true +index: 28 +description: Learn how to add login functionality to your app with Salesforce Sandbox. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +topics: + - connections + - social + - salesforce +contentType: how-to +useCase: + - customize-connections + - add-idp + - add-login +--- +<%= include('../../../snippets/social/salesforce-sandbox/0') %> +<%= include('../../../snippets/social/salesforce-sandbox/1') %> +<%= include('../../../snippets/social/salesforce-sandbox/2') %> +<%= include('../../../snippets/social/salesforce-sandbox/3') %> +<%= include('../../../snippets/social/salesforce-sandbox/4') %> +<%= include('../../../snippets/social/salesforce-sandbox/5') %> +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/salesforce.md b/articles/connections/social/salesforce.md index f7c3b3b86d..c5c0ad838e 100644 --- a/articles/connections/social/salesforce.md +++ b/articles/connections/social/salesforce.md @@ -1,69 +1,26 @@ --- +title: Connect Apps to Salesforce connection: Salesforce image: /media/connections/salesforce.png seo_alias: salesforce -index: 6 -description: How to obtain a Client Id and Client Secret for Salesforce. +toc: true +public: true +index: 27 +description: Learn how to add login functionality to your app with Salesforce. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +topics: + - connections + - social + - salesforce +contentType: how-to +useCase: + - add-login + - customize-connections + - add-idp --- - -# Obtain a *Client Id* and *Client Secret* for Salesforce - -To configure a Salesforce OAuth2 connection you will need to register your Auth0 tenant on their **Administer** panel. - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Register a New App - -Log into [Salesforce](https://login.salesforce.com/). Click on **Setup** in the upper right, next to your account name. Navigate to **Build > Create > Apps**. Under **Connected Apps**, click **New**: - -![](/media/articles/connections/social/salesforce/salesforce-register-1.png) - -## 2. Complete the *New Connected App* form - -1. Enter the required basic information (*Connected App Name*, *API Name* and *Contact Email*). -2. Select **Enable OAuth Settings** under **API (Enable OAuth Settings)**. -3. Enter your callback URL: `https://${account.namespace}/login/callback` -4. Add *Access your basic information* to the **Selected OAuth Scopes**. -5. Click **Save**. - - ![](/media/articles/connections/social/salesforce/salesforce-register-2.png) - -## 3. Get your *Consumer Key* and *Consumer Secret* - -Once your app is registered, the page will diplay your `Consumer Key` and `Consumer Secret`: - -![](/media/articles/connections/social/salesforce/salesforce-register-3.png) - -## 4. Copy your *Consumer Key* and *Consumer Secret* - -Go to your Auth0 [Dashboard](${manage_url}/#/connections/social) and select **Connections > Social**, then choose **Salesforce**. - -Copy the `Consumer Key` and `Consumer Secret` from the **Connected App** page of your app on Salesforce into the fields on this page on Auth0 and click **Save**: - -![](/media/articles/connections/social/salesforce/salesforce-register-4.png) - -:: panel-info Salesforce Community Auth - -Authenticating users in a Salesforce community uses different endpoints that the regular Salesforce app. - -The authorization URL for a Community site will be: - - https://{name of your community}.force.com/{community path}/oauth2/authorize - -For example, if your community is names __contoso__ and it is for __customers__: - - https://contoso.force.com/customers/oauth2/authorize?response_type=token&client_id=your_app_id&redirect_uri=your_redirect_uri - -Notice that Auth0 will automatically pass all required OAuth2 parameters (e.g. `response_type`, `client_id`, etc) and concatenate other elements to the path (e.g. `oauth2/authorize`). All that is required is that you configure the __base__ community site URL: - - https://contoso.force.com/customers - -For full details see this [Salesforce article](http://www.salesforce.com/us/developer/docs/chatterapi/Content/quickstart_communities.htm). - -It is common to customize the login page for __Community__ sites. If you do so, remember that the login page is part of the login transaction and you must honor the OAuth2 flow. - -[This sample](https://github.com/salesforceidentity/basic-custom-login) provides details on how to do it properly. -:: - +<%= include('../../../snippets/social/salesforce/0') %> +<%= include('../../../snippets/social/salesforce/1') %> +<%= include('../../../snippets/social/salesforce/2') %> +<%= include('../../../snippets/social/salesforce/3') %> +<%= include('../../../snippets/social/salesforce/4') %> +<%= include('../../../snippets/social/salesforce/5') %> <%= include('../_quickstart-links.md') %> - diff --git a/articles/connections/social/shopify.md b/articles/connections/social/shopify.md index 468f727bc5..ddafd35d4b 100644 --- a/articles/connections/social/shopify.md +++ b/articles/connections/social/shopify.md @@ -1,94 +1,27 @@ --- +title: Connect Apps to Shopify connection: Shopify image: /media/connections/shopify.png seo_alias: shopify -description: How to connect your Auth0 app to Shopify. +toc: true +public: true +index: 30 +description: Learn how to add login functionality to your app with Shopify. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +topics: + - authentication + - connections + - social + - shopify +contentType: how-to +useCase: + - add-login + - customize-connections + - add-idp --- - -# Connect your app to Shopify - -To connect your Auth0 app to Shopify, you will need to create an app on the Shopify Partner portal to generate *API Key* and *Shared Secret*, copy these credentials into your Auth0 settings, and enable the connection. - -::: panel-warning User profile not available -Due to Shopify's OAuth implementation, successful user authentication returns the **Shop** profile, not the user profile. -::: - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -### 1. Create an app on the Shopify Partner portal - -Login to the [Shopify Partner](https://app.shopify.com/services/partners) portal. Select **Apps** in the left nav and click **Create a new app**: - -![](/media/articles/connections/social/shopify/shopify-devportal-1.png) - - -### 2. Create your app - -Complete the form. - -In the fields below, enter the following: - -* **App URL**: `https://YOUR_TENANT.auth0.com` -* **Redirection URL**: `https://YOUR_TENANT.auth0.com/login/callback` - -![](/media/articles/connections/social/shopify/shopify-devportal-2.png) - -Click **Create app**. - -### 3. Get your API Key and Shared Secret - -On the page that follows, your `API Key` and `Shared Secret` will be displayed. Save these for use in the next step. - -![](/media/articles/connections/social/shopify/shopify-devportal-3.png) - -### 4. Enter your API Key and Shared Secret into Auth0 - -In a separate window, go to the [Connections > Social](${manage_url}/#/connections/social) section of the Auth0 Dashboard. - -Select Shopify: - -![](/media/articles/connections/social/shopify/shopify-devportal-4.png) - -Copy the `API Key` and `Shared Secret` from the Apps page on Shopify into the fields on this page on Auth0. - -Enter your **Shop name**. - -Select the **Permissions** you want to enable. - -Click **SAVE**. - -![](/media/articles/connections/social/shopify/shopify-devportal-5.png) - -### 5. Enable the Connection - -Go to the **Apps** tab of the Shopify connection on Auth0 and select each of your existing Auth0 apps for which you want to enable this connection: - -![](/media/articles/connections/social/shopify/shopify-devportal-6.png) - -### 6. Test the connection - -Close the Settings window to return to the **Connections > Social** section of the Auth0 dashboard. - -A TRY icon will now be displayed next to the Shopify logo: - -![](/media/articles/connections/social/shopify/shopify-devportal-7.png) - -Click TRY. - -Login to your Shopify store. - -Click **Install app** to allow your app access. - -![](/media/articles/connections/social/shopify/shopify-devportal-8.png) - -If you have configured everything correctly, you will see the It works!!! page: - -![](/media/articles/connections/social/shopify/shopify-devportal-9.png) - -::: panel-info Shopify Multipass -You can use Shopify's [Multipass](https://help.shopify.com/api/reference/multipass) feature to automatically authenticate users who have already been verified by Auth0 on Shopify. -::: - +<%= include('../../../snippets/social/shopify/0') %> +<%= include('../../../snippets/social/shopify/1') %> +<%= include('../../../snippets/social/shopify/2') %> +<%= include('../../../snippets/social/shopify/3') %> +<%= include('../../../snippets/social/shopify/4') %> +<%= include('../../../snippets/social/shopify/5') %> <%= include('../_quickstart-links.md') %> - - diff --git a/articles/connections/social/slack.md b/articles/connections/social/slack.md new file mode 100644 index 0000000000..727f5e3f5c --- /dev/null +++ b/articles/connections/social/slack.md @@ -0,0 +1,25 @@ +--- +title: Connect Apps to Slack +connection: Slack +image: /media/connections/slack.png +seo_alias: slack +description: Learn how to add login functionality to your app with Slack. You will need to obtain a Client ID and Client Secret for Slack. +toc: true +public: true +index: 6 +topics: + - connections + - social + - slack +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +<%= include('../../../snippets/social/slack/0') %> +<%= include('../../../snippets/social/slack/1') %> +<%= include('../../../snippets/social/slack/2') %> +<%= include('../../../snippets/social/slack/3') %> +<%= include('../../../snippets/social/slack/4') %> +<%= include('../../../snippets/social/slack/5') %> +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/soundcloud.md b/articles/connections/social/soundcloud.md index 55b11a3479..6c41a9add6 100644 --- a/articles/connections/social/soundcloud.md +++ b/articles/connections/social/soundcloud.md @@ -1,50 +1,59 @@ --- +title: Connect Apps to SoundCloud connection: SoundCloud -index: 5 +toc: true +public: false +index: 31 image: /media/connections/soundcloud.png seo_alias: soundcloud -description: How to obtain a Client Id and Client Secret for SoundCloud. +description: Learn how to add login functionality to your app with SoundCloud. You will need to obtain a Client Id and Client Secret for SoundCloud. +topics: + - connections + - social + - soundcloud +contentType: how-to +useCase: + - customize-connections + - add-idp --- -# Configuring an OAuth 2.0 Connection with SoundCloud +# Connect Apps to SoundCloud -To configure an OAuth 2.0 connection with SoundCloud, you will need to register your Auth0 Client with SoundCloud using their [Developer Portal](http://developers.soundcloud.com/). +You can add functionality to your web app that allows your users to log in with SoundCloud. -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Register Your App and Obtain API Credentials with SoundCloud - -::: panel-warning SoundCloud Registration Process -As noted below, SoundCloud does **not** have an automated process to register your app. Auth0 does not have any control over this process, you must apply to SoundCloud and work with them to get your application configuration. Only after SoundCloud approves your application can you use SoundCloud with Auth0. +::: panel-warning Restricted SoundCloud App Registration +SoundCloud's manual application registration process is currently closed, so **new applications cannot be registered**. SoundCloud does **not** have an automated process to register your app. You must apply to SoundCloud and work with them to get your application configured which can take up to 2 weeks. Only after SoundCloud approves your application can you use SoundCloud with Auth0. See [How to Request a SoundCloud API Key](https://support.appmachine.com/hc/en-us/articles/115000057244-How-to-request-a-SoundCloud-API-key) for details. ::: -Navigate to the [SoundCloud Developer Portal](http://developers.soundcloud.com/). Using the navigation menu on the right side, click on **Register a new app**: - -![](/media/articles/connections/social/soundcloud/soundcloud-devportal-1.png) +## Prerequisites -You will be asked to fill out a Developer Application (which is a Google Forms document) that provides SoundCloud information about your Auth0 Client. +Before connecting your Auth0 app to SoundCloud, you must have a [SoundCloud Developer](http://developers.soundcloud.com/) account. -Once you have completed and submitted your application, you will be contacted by the SoundCloud team with further instructions on how to proceed. Only at this point will you be given the appropriate API credentials to complete the integration. +## Steps -## 2. Set Up a SoundCloud Social Connection in Auth0 +To connect your app to SoundCloud, you will: -Once your Auth0 Client has been added to your SoundCloud account, you can get the `Client ID` and `Client Secret` necessary for the Auth0 Connection Settings. +1. [Set up your app in SoundCloud](#set-up-your-app-in-soundcloud) +2. [Create and enable a connection in Auth0](#create-and-enable-a-connection-in-auth0) +3. [Test the connection](#test-the-connection) -![](/media/articles/connections/social/soundcloud/soundcloud-devportal-2.png) +### Set up your app in SoundCloud -Be sure to provide the following as your `Redirect URI for Authentication` on the SoundCloud dashboard: `https://${account.namespace}/login/callback` +1. [Create a new app on your SoundCloud profile](https://soundcloud.com/you/apps/new), and complete your SoundCloud Application Registration by following the steps on the screen. + * Find your SoundCloud profile URL by [logging into SoundCloud](https://soundcloud.com/) and clicking your profile name in the top-right corner of the screen. Once navigated to your profile, your profile URL is displayed in your browser's address bar. + * Answer **Will your app authenticate users?** with `No, my app will only use publicly accessible resources`. -Go to the [Connections > Social](${manage_url}/#/connections/social) section of the Auth0 dashboard and enable **SoundCloud**. + Your app will be in review for a maximum period of two weeks. Once approved, you will be able to use your SoundCloud API key to stream music from SoundCloud within your AppMachine app. -![](/media/articles/connections/social/soundcloud/social.png) +2. When your request is approved, you will receive your own SoundCloud **Client ID**. Enter it in the **Music** block in the appropriate field under **Settings: Client ID**. -You will be prompted to provide your SoundCloud `Client ID` and `Client Secret`. +### Create and enable a connection in Auth0 -![](/media/articles/connections/social/soundcloud/auth0-settings.png) +[Set up the SoundCloud social connection](/dashboard/guides/connections/set-up-connections-social) in Auth0. Make sure you have the generated **Client ID** and **Client Secret**. -**Save** your settings. Switch to the *Clients* tab, and select the Client(s) you want to use the SoundCloud integration. **Save** again. +### Test the connection -![](/media/articles/connections/social/soundcloud/clients.png) +You're ready to [test your connection](/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**. <%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/spotify.md b/articles/connections/social/spotify.md new file mode 100644 index 0000000000..24a9ab8aa7 --- /dev/null +++ b/articles/connections/social/spotify.md @@ -0,0 +1,25 @@ +--- +title: Connect Apps to Spotify +connection: Spotify +image: /media/connections/spotify.png +seo_alias: spotify +description: Learn how to add login functionality to your app with Spotify. You will need to obtain a Client ID and Client Secret for Spotify. +toc: true +public: true +index: 6 +topics: + - connections + - social + - spotify +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +<%= include('../../../snippets/social/spotify/0') %> +<%= include('../../../snippets/social/spotify/1') %> +<%= include('../../../snippets/social/spotify/2') %> +<%= include('../../../snippets/social/spotify/3') %> +<%= include('../../../snippets/social/spotify/4') %> +<%= include('../../../snippets/social/spotify/5') %> +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/stripe-connect.md b/articles/connections/social/stripe-connect.md new file mode 100644 index 0000000000..e7ddb3e6ff --- /dev/null +++ b/articles/connections/social/stripe-connect.md @@ -0,0 +1,25 @@ +--- +title: Connect Apps to Stripe Connect +connection: Stripe Connect +image: /media/connections/stripe.png +seo_alias: stripe-connect +description: Learn how to add login functionality to your app with Stripe Connect. You will need to obtain a Client ID and Client Secret for Stripe Connect. +toc: true +public: true +index: 6 +topics: + - connections + - social + - stripe-connect +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +<%= include('../../../snippets/social/stripe-connect/0') %> +<%= include('../../../snippets/social/stripe-connect/1') %> +<%= include('../../../snippets/social/stripe-connect/2') %> +<%= include('../../../snippets/social/stripe-connect/3') %> +<%= include('../../../snippets/social/stripe-connect/4') %> +<%= include('../../../snippets/social/stripe-connect/5') %> +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/thecity.md b/articles/connections/social/thecity.md deleted file mode 100644 index ed09272a70..0000000000 --- a/articles/connections/social/thecity.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -connection: The City -image: /media/connections/thecity.png -seo_alias: thecity -description: How to obtain an App ID and Secret with The City. ---- - -# Obtaining an App ID and Secret with The City - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Log in into The City portal - -Log in into your The City portal, and select __Admin__: - -![](/media/articles/connections/social/thecity/thecity-register-1.png) - ---- - -## 2. Create new Plugin - -Select __API > Plugin > Create plugin__: - -![](/media/articles/connections/social/thecity/thecity-register-2.png) - -Complete the form using this callback URL: - -![](/media/articles/connections/social/thecity/thecity-register-3.png) - - https://${account.namespace}/login/callback - -Press __Create__ - ---- - -## 3. Get your App ID & Secret - -Once the application is created, enter your new `App ID` and `Secret` into the connection settings in Auth0. - -![](/media/articles/connections/social/thecity/thecity-register-4.png) - -<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/twitch.md b/articles/connections/social/twitch.md new file mode 100644 index 0000000000..8812a908db --- /dev/null +++ b/articles/connections/social/twitch.md @@ -0,0 +1,25 @@ +--- +title: Connect Apps to Twitch +connection: Twitch +image: /media/connections/twitch.png +seo_alias: twitch +description: Learn how to add login functionality to your app with Twitch. You will need to obtain a Client ID and Client Secret for Twitch. +toc: true +public: true +index: 6 +topics: + - connections + - social + - twitch +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +<%= include('../../../snippets/social/twitch/0') %> +<%= include('../../../snippets/social/twitch/1') %> +<%= include('../../../snippets/social/twitch/2') %> +<%= include('../../../snippets/social/twitch/3') %> +<%= include('../../../snippets/social/twitch/4') %> +<%= include('../../../snippets/social/twitch/5') %> +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/twitter.md b/articles/connections/social/twitter.md index 0ff37b4d07..b3eaa6dbb5 100644 --- a/articles/connections/social/twitter.md +++ b/articles/connections/social/twitter.md @@ -1,99 +1,28 @@ --- +title: Connect Apps to Twitter connection: Twitter image: /media/connections/twitter.png -description: This page shows you how to connect your Auth0 client to Twitter. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. seo_alias: twitter -index: 8 +description: Learn how to add login functionality to your app with Twitter. You will need to generate keys, copy these into your Auth0 settings, and enable the connection. +toc: true +public: true +index: 32 +topics: + - connections + - social + - twitter +contentType: how-to +useCase: + - customize-connections + - add-idp --- - -# Connect your Client to Twitter - -To connect your Auth0 client to Twitter, you will need to generate *Consumer* and *Secret* Keys in a Twitter application, copy these into your Auth0 settings, and enable the connection. - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## Create a Twitter application - -1. Login to [Twitter Application Management](https://apps.twitter.com/). - -2. Click **Create New App**: - - ![](/media/articles/connections/social/twitter/twitter-api-1.png) - -3. Provide the required information. For **Callback URL**, enter `https://${account.namespace}/login/callback` - - ![](/media/articles/connections/social/twitter/twitter-api-2.png) - -4. Agree to the *Developer Agreement* and click **Create your Twitter Application**. - -5. Once the app is created, go to the **Settings** tab and verify that the **Allow this application to be used to Sign in with Twitter** option is selected. - - ![](/media/articles/connections/social/twitter/twitter-api-3.png) - -## Get your *Consumer Key* and *Consumer Secret* - -1. Your *Consumer Key* and *Consumer Secret* will be displayed in the **Keys and Access Tokens** tab of your app on Twitter: - - ![](/media/articles/connections/social/twitter/twitter-api-4.png) - -2. Leave this window open. - -## Copy your *Consumer Key* and *Consumer Secret* into Auth0 - -1. In a separate window, login to the [Auth0 Dashboard](${manage_url}) and select **Connections > Social** in the left navigation. - -2. Select the connection with the Twitter logo to access this connection's **Settings** page. - -3. Copy the *Consumer Key* and *Consumer Secret* from your app's **Keys and Access Tokens** tab on Twitter into the fields on this page on Auth0. - - ![](/media/articles/connections/social/twitter/twitter-api-5.png) - -4. Click **Save**. - -::: panel-info Twitter Profile Attribute Permissions -Unlike many social identity providers, Twitter manages profile attribute permissions at the application level. By default, your client will be granted *Read* and *Write* permissions. You can customize these in the **Permissions** section of the [Twitter Application Management](https://apps.twitter.com) page. For more information, see: [Application Permission Model](https://dev.twitter.com/oauth/overview/application-permission-model). -::: - -## Enable the Connection - -1. Go to the **Clients** tab of the Twitter connection on Auth0 and select each of your existing Auth0 clients for which you want to enable this connection: - - ![](/media/articles/connections/social/twitter/twitter-api-6.png) - -2. Click **Save**. - -## Test your connection - -1. Go back to the [Connections > Social](${manage_url}/#/connections/social) section of the Auth0 dashboard. If you have configured your app correctly, you will see a **Try** icon next to the Twitter logo: - - ![](/media/articles/connections/social/twitter/twitter-api-7.png) - -2. Click the Twitter logo to return to the **Settings** page of this connection and click **Try**: - - ![](/media/articles/connections/social/twitter/twitter-api-8.png) - -3. You will be asked to sign-in to Twitter to authorize your new app to access your Twitter account: - - ![](/media/articles/connections/social/twitter/twitter-api-9.png) - -4. If you have configured everything correctly, you will see the **It works!!!** page: - - ![](/media/articles/connections/social/twitter/twitter-api-10.png) - -## Get an Access Token from Twitter (Optional) - -Twitter allows application owners to generate OAuth access tokens that can be used to call the Twitter API on their own behalf. - -To generate an Access Token and Secret: - -1. Go to the [Application Management](https://apps.twitter.com) page on Twitter and select your application. - -2. Click **Keys and Access Tokens**. - -3. Click **Create my access token** near the bottom of the page to generate an authorized Access Token and Secret. Do not share your Access Token Secret. - - ![](/media/articles/connections/social/twitter/twitter-api-11.png) - -**NOTE**: You can also regenerate or revoke your Access Token and Secret in case they have been compromised. - +<%= include('../../../snippets/social/twitter/0') %> +<%= include('../../../snippets/social/twitter/1') %> +<%= include('../../../snippets/social/twitter/2') %> +<%= include('../../../snippets/social/twitter/3') %> +<%= include('../../../snippets/social/twitter/4') %> +<%= include('../../../snippets/social/twitter/5') %> +<%= include('../../../snippets/social/twitter/6') %> +<%= include('../../../snippets/social/twitter/7') %> +<%= include('../../../snippets/social/twitter/8') %> <%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/vimeo.md b/articles/connections/social/vimeo.md new file mode 100644 index 0000000000..abd1f9bc9a --- /dev/null +++ b/articles/connections/social/vimeo.md @@ -0,0 +1,25 @@ +--- +title: Connect Apps to Vimeo +connection: Vimeo +image: /media/connections/vimeo.png +seo_alias: vimeo +description: Learn how to add login functionality to your app with Vimeo. You will need to obtain a Client Id and Client Secret for Vimeo. +toc: true +public: true +index: 6 +topics: + - connections + - social + - vimeo +contentType: how-to +useCase: + - customize-connections + - add-idp +--- +<%= include('../../../snippets/social/vimeo/0') %> +<%= include('../../../snippets/social/vimeo/1') %> +<%= include('../../../snippets/social/vimeo/2') %> +<%= include('../../../snippets/social/vimeo/3') %> +<%= include('../../../snippets/social/vimeo/4') %> +<%= include('../../../snippets/social/vimeo/5') %> +<%= include('../_quickstart-links.md') %> diff --git a/articles/connections/social/vkontakte.md b/articles/connections/social/vkontakte.md index 8a7d5f58f2..dc24590df4 100644 --- a/articles/connections/social/vkontakte.md +++ b/articles/connections/social/vkontakte.md @@ -1,98 +1,25 @@ --- +title: Connect Apps to vKontakte connection: vKontakte image: /media/connections/vkontakte.png seo_alias: vkontakte -description: How to connect your Auth0 app to vKontakte. +description: Learn how to add login functionality to your app with vKontakte. +toc: true +public: true +index: 33 +topics: + - connections + - social + - vkontakte +contentType: how-to +useCase: + - customize-connections + - add-idp --- - -# Connect your app to vKontakte - -To connect your Auth0 app to vKontakte, you will need to generate an `Application ID` and `Secure Key` in a vKontakte app, copy these keys into your Auth0 settings, and enable the connection. - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Create a new vKontakte application - -Login to [vKontakte Developers](https://new.vk.com/dev). - -Go to **My Apps** and click **Create an Application**: - -![](/media/articles/connections/social/vkontakte/vkontakte-login.png) - -Select **Website** as the **Category**. - -Provide a name for your app. - -In the **Site address** field, enter the following: - -`https://${account.namespace}` - -In the **Base domain** field, enter the following: - -`${account.namespace}` - -![](/media/articles/connections/social/vkontakte/vkontakte-create-app.png) - -Click **Connect Site** to create the app. - -You will be required to confirm your request with a code send via SMS: - -![](/media/articles/connections/social/vkontakte/vkontakte-validate-create-app.png) - - -## 2. Enter your *redirect URL* - -Once the application is created, select **Settings** in the left nav. - -In the **Authorized redirect URI** field, enter the following: - -`https://${account.namespace}/login/callback` - -Click **Save**. - -![](/media/articles/connections/social/vkontakte/vkontakte-redirect.png) - -## 3. Get your *Application ID* and *Secure Key* - -From the top of the same page, copy the `Application ID` and `Secure Key` for use in the next step. - -![](/media/articles/connections/social/vkontakte/vkontakte-keys.png) - -## 4. Enter your *Application ID* and *Secure Key* into Auth0 - -In a separate window, go to the [Connections > Social](${manage_url}/#/connections/social) section of the Auth0 dashboard. - -Select **vKontakte**: - -![](/media/articles/connections/social/vkontakte/vkontakte-logo.png) - -Copy the `Application ID` and `Secure Key` from the **Settings** page of your app on vKontakte into the fields on this page on Auth0. - -Select the Permissions you want to enable. - -Click **SAVE**. - -![](/media/articles/connections/social/vkontakte/vkontakte-add-connection.png) - -## 5. Enable the Connection - -Go to the **Apps** tab of the vKontakte connection on Auth0 and select each of your existing Auth0 apps for which you want to enable this connection and click **Save**: - -![](/media/articles/connections/social/vkontakte/vkontakte-add-apps.png) - -## 6. Test the connection - -Close the **Settings** window to return to the **Connections > Social** section of the Auth0 dashboard. - -A **TRY** icon will now be displayed next to the vKontakte logo: - -![](/media/articles/connections/social/vkontakte/vkontakte-try.png) - -Click **TRY**. - -If you have configured everything correctly, you will see the **It works!!!** page: - -![](/media/articles/connections/social/vkontakte/vkontakte-works.png) - +<%= include('../../../snippets/social/vkontakte/0') %> +<%= include('../../../snippets/social/vkontakte/1') %> +<%= include('../../../snippets/social/vkontakte/2') %> +<%= include('../../../snippets/social/vkontakte/3') %> +<%= include('../../../snippets/social/vkontakte/4') %> +<%= include('../../../snippets/social/vkontakte/5') %> <%= include('../_quickstart-links.md') %> - diff --git a/articles/connections/social/weibo.md b/articles/connections/social/weibo.md index 99a0753dc5..da8a641a45 100644 --- a/articles/connections/social/weibo.md +++ b/articles/connections/social/weibo.md @@ -1,78 +1,25 @@ --- +title: Connect Apps to Weibo +description: Learn how to add login functionality to your app with Weibo. connection: Weibo image: /media/connections/weibo.png seo_alias: weibo -description: How to obtain an App ID and App Secret for Weibo. +public: true +index: 34 +toc: true +topics: + - connections + - social + - weibo +contentType: how-to +useCase: + - customize-connections + - add-idp --- - -# Obtaining an App ID and App Secret for Weibo - -To configure a Weibo connection you will need to register Auth0 on the [Weibo App portal](http://open.weibo.com/apps). - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Add a new Application - -First log in into your [Weibo portal](http://open.weibo.com/apps), once you have logged in go to the [Development page](http://open.weibo.com/development) and click on the orange button. - -![Weibo Development Page](/media/articles/connections/social/weibo/development-page.png) - -This will bring up options for which type of application you wish to create. Select the web application option which should be third from the left. - -![Select Web App](/media/articles/connections/social/weibo/select-web-app.png) - -In the first field, enter the name for your application. Make sure **Web Application** (the third option 网页应用) is selected for the application type. The check box agrees to the terms. - -![Create New App](/media/articles/connections/social/weibo/create-app.png) - -## 2. Enter your callback URLs - -Then you will be brought to your application information page. Click on advanced (高级信息) options from the left sidebar. - -![Select Advanced](/media/articles/connections/social/weibo/click-advanced.png) - -Under OAuth2.0 授权设置 enter `https://${account.namespace}/login/callback` as the callback urls. Then click on the green button. - -![Enter your callback urls](/media/articles/connections/social/weibo/enter-callback.png) - -## 3. Get your **App Key** and **App Secret** - -Return to the basic information page (基本信息) for your application by clicking on the top option under the gear icon for Application Information. - -![Select Basic](/media/articles/connections/social/weibo/click-basic.png) - -This page will contain your **App Key** and **App Secret**, to be used in the next step. - -![Copy your App Key and App Secret](/media/articles/connections/social/weibo/get-app-key-secret.png) - -## 4. Setup the Connection in Auth0 - -In a seperate tab or page, go to the [Connections > Social](${manage_url}/#/connections/social) section of the Auth0 dashboard. - -Click on the **Weibo** connection. - -Enter your **App Key** and **App Secret** from Weibo, select your **Attributes** and **Permissions** then click **SAVE**. - -![Paste your App Key and App Secret](/media/articles/connections/social/weibo/enter-keys.png) - -Next click on the **Clients** tab next to **Settings** and enable which of your clients will be able to use this connection. - -![Enable the Clients](/media/articles/connections/social/weibo/enable-clients.png) - -When finished, click **SAVE**. - -## 5. Test the Connection - -On the [Connections > Social](${manage_url}/#/connections/social) page of the Auth0 dashboard you should now see a **TRY** button with the Weibo connection. - -![Try Button](/media/articles/connections/social/weibo/try-connection.png) - -Click on this to test the new connection. This should bring up a confirmation page for the connection: - -![Confirmation page](/media/articles/connections/social/weibo/confirmation.png) - -If accepted, you should be able to see the **It Works!** confirmation page that your connection has been configured correctly. - +<%= include('../../../snippets/social/weibo/0') %> +<%= include('../../../snippets/social/weibo/1') %> +<%= include('../../../snippets/social/weibo/2') %> +<%= include('../../../snippets/social/weibo/3') %> +<%= include('../../../snippets/social/weibo/4') %> +<%= include('../../../snippets/social/weibo/5') %> <%= include('../_quickstart-links.md') %> - - diff --git a/articles/connections/social/wordpress.md b/articles/connections/social/wordpress.md index dc9b9c29c6..3a74755bca 100644 --- a/articles/connections/social/wordpress.md +++ b/articles/connections/social/wordpress.md @@ -1,44 +1,25 @@ --- +title: Connect Apps to WordPress +description: Learn how to add login functionality to your app with WordPress. You will need to obtain a Client Id and Client Secret for WordPress. connection: WordPress image: /media/connections/wordpress.png seo_alias: wordpress -index: 11 -description: How to obtain a Client Id and Client Secret for WordPress. +public: true +index: 35 +toc: true +topics: + - connections + - social + - wordpress +contentType: how-to +useCase: + - customize-connections + - add-idp --- - -# Obtaining a Client ID and Client Secret for WordPress - -To configure WordPress OAuth2 connections, you will need to register Auth0 with the [WordPress Developer Portal](http://developer.wordpress.com/). - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Log In to the Developer Portal - -Go to the [WordPress Developer Portal](http://developer.wordpress.com/), and log in with your WordPress credentials. Select **My Applications**. - -![](/media/articles/connections/social/wordpress/wordpress-dev-portal.png) - -## 2. Provide Your Auth0 Client Information. - -If you have not already registered your application with Wordpress, click **Create New Application**: - -![](/media/articles/connections/social/wordpress/create-new-app.png) - -Complete the fields on the *Create an Application* screen with the requested details. Use this URL as your callback: `https://${account.namespace}/login/callback` - -![](/media/articles/connections/social/wordpress/create-new-app-config-screen.png) - -Once you've done so (or if you have previously registered your application), you will see your application listed on your dashboard landing page. - -![](/media/articles/connections/social/wordpress/my-apps.png) - -## 3. Get Your Client ID and Client Secret - -Once you have created/registered your application, you will see it listed on your dashboard landing page. Click **Manage Application** to be taken to a display of your OAuth Information. - -![](/media/articles/connections/social/wordpress/oauth-info.png) - -Copy your new `Client ID` and `Client Secret` values, and paste them into the appropriate Connection settings page in Auth0. - +<%= include('../../../snippets/social/wordpress/0') %> +<%= include('../../../snippets/social/wordpress/1') %> +<%= include('../../../snippets/social/wordpress/2') %> +<%= include('../../../snippets/social/wordpress/3') %> +<%= include('../../../snippets/social/wordpress/4') %> +<%= include('../../../snippets/social/wordpress/5') %> <%= include('../_quickstart-links.md') %> - diff --git a/articles/connections/social/yahoo.md b/articles/connections/social/yahoo.md index 3ee82ec44f..ea9a93396c 100644 --- a/articles/connections/social/yahoo.md +++ b/articles/connections/social/yahoo.md @@ -1,71 +1,25 @@ --- +title: Connect Apps to Yahoo +description: Learn how to add login functionality to your app with Yahoo. You will need to obtain a Consumer Key and Consumer Secret for Yahoo. connection: Yahoo! image: /media/connections/yahoo.png seo_alias: yahoo -index: 15 -description: How to obtain a Consumer Key and Consumer Secret for Yahoo! +public: true +index: 36 +toc: true +topics: + - connections + - social + - yahoo +contentType: how-to +useCase: + - customize-connections + - add-idp --- - -# Obtaining a Client Key and Client Secret for Yahoo! - -These steps will guide you through how to create an application with Yahoo! and how to add it as a social connection in the Auth0 Dashboard. - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Add a New Application - -To begin, you need a Yahoo user ID. If you don’t have one ([login.yahoo.com](https://login.yahoo.com) or [admanager.yahoo.com](https://admanager.yahoo.com)), you need to create one. - -Then, go to [Yahoo Developer Apps](https://developer.yahoo.com/apps/) and click on the **Create an App** button. - -![Click the Create an App button](/media/articles/connections/social/yahoo/create-an-app.png) - -Create an **Application Name** and select **Web Application** as the **Application Type**. - -![Enter your app data](/media/articles/connections/social/yahoo/enter-fields.png) - -In the **Callback Domain** field enter: - -`https://${account.namespace}` - -For the **API Permissions** make sure to select at least one user data API: - -![API Permissions](/media/articles/connections/social/yahoo/api-permissions.png) - -## 2. Get your **Client Key** and **Client Secret** - -Once the application is created you will see a **Client ID** (Consumer Key) and **Client Secret** (Consumer Secret). Copy these values as you will use them to set up the connection in Auth0. - -![Get Client ID and Client Secret](/media/articles/connections/social/yahoo/client-id-and-secret.png) - -## 3. Set up the Connection in Auth0 - -In a seperate tab or page, go to the [Connections > Social](${manage_url}/#/connections/social) section of the Auth0 dashboard. - -Click on the **Yahoo!** connection. - -Enter your **Client Key** and **Client Secret** from Yahoo! then click **SAVE**. - -![Enter your key and secret](/media/articles/connections/social/yahoo/setup-connection.png) - -Next click on the **Clients** tab next to **Settings** and enable which of your clients will be able to use this connection. - -![Enable Clients](/media/articles/connections/social/yahoo/enable-clients.png) - -When finished, click **SAVE**. - -## 4. Test the Connection - -On the [Connections > Social](${manage_url}/#/connections/social) page of the Auth0 dashboard you should now see a **TRY** button with the Yahoo! connection. - -![Try button](/media/articles/connections/social/yahoo/try-button.png) - -Click on this to test the new connection. This should bring up a confirmation page for the connection: - -![Connection Approval](/media/articles/connections/social/yahoo/approve-connection.png) - -If accepted, you should be able to see the **It Works!** confirmation page that your connection has been configured correctly. - +<%= include('../../../snippets/social/yahoo/0') %> +<%= include('../../../snippets/social/yahoo/1') %> +<%= include('../../../snippets/social/yahoo/2') %> +<%= include('../../../snippets/social/yahoo/3') %> +<%= include('../../../snippets/social/yahoo/4') %> +<%= include('../../../snippets/social/yahoo/5') %> <%= include('../_quickstart-links.md') %> - - diff --git a/articles/connections/social/yammer.md b/articles/connections/social/yammer.md index 5b264b60ed..8a5242f8ff 100644 --- a/articles/connections/social/yammer.md +++ b/articles/connections/social/yammer.md @@ -1,71 +1,25 @@ --- +title: Connect Apps to Yammer +description: How to obtain the credentials required to configure your Auth0 connection to Yammer. connection: Yammer image: /media/connections/yammer.png -description: How to obtain the credentials required to configure your Auth0 connection to Yammer. seo_alias: yammer +public: true +index: 37 +toc: true +topics: + - connections + - social + - yammer +contentType: how-to +useCase: + - customize-connections + - add-idp --- - -# Obtain an *App ID* and *App Secret* for Yammer - -To configure Yammer for OAuth connections, you will need to register your Auth0 namespace on the Yammer Developer Center. - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Login to Yammer Developer Center - -Go to [Yammer Developer Center](https://developer.yammer.com/) and login with your account. Click on **Apps** in the top menu: - -![](/media/articles/connections/social/yammer/yammer-connect-1.png) - -Click on **Register an App**: - -![](/media/articles/connections/social/yammer/yammer-connect-2.png) - -Then click **Register New App**: - -![](/media/articles/connections/social/yammer/yammer-connect-3.png) - -## 2. Name your application - -Name your app and complete the form. -For the **Redirect URI**, enter `https://${account.namespace}/login/callback`. -Click **Continue**. - -![](/media/articles/connections/social/yammer/yammer-connect-4.png) - -## 3. Get your *Client ID* and *Client Secret* - -Once your app is created, your `Client ID` and `Client Secret` will be displayed: - -![](/media/articles/connections/social/yammer/yammer-connect-5.png) - -## 4. Copy the *Client ID* and *Client Secret* into Auth0 - -Go to the [Connections > Social](${manage_url}/#/connections/social) section of the Auth0 dashboard and select **Yammer**. -Copy the `Client ID` and `Client Secret` from the **Basic Info** page of your app on Yammer into the fields on this page on Auth0. -Click **Save**: - -![](/media/articles/connections/social/yammer/yammer-connect-6.png) - -## 5. Test your app - -Go back to the [Connections > Social](${manage_url}/#/connections/social) section of the Auth0 dashboard. - -If you have configured your app correctly, you will see a Try icon next to the Yammer logo. -Toggle on the switch to enable Yammer authentication: - -![](/media/articles/connections/social/yammer/yammer-connect-7.png) - -Select the apps you would like to use Yammer authentication with. -Click **Continue**: - -![](/media/articles/connections/social/yammer/yammer-connect-8.png) - -Now you can test your new app by clicking **Try**: - -![](/media/articles/connections/social/yammer/yammer-connect-9.png) - -![](/media/articles/connections/social/yammer/yammer-connect-10.png) - +<%= include('../../../snippets/social/yammer/0') %> +<%= include('../../../snippets/social/yammer/1') %> +<%= include('../../../snippets/social/yammer/2') %> +<%= include('../../../snippets/social/yammer/3') %> +<%= include('../../../snippets/social/yammer/4') %> +<%= include('../../../snippets/social/yammer/5') %> <%= include('../_quickstart-links.md') %> - diff --git a/articles/connections/social/yandex.md b/articles/connections/social/yandex.md index 02afaac16d..39e858e5ef 100644 --- a/articles/connections/social/yandex.md +++ b/articles/connections/social/yandex.md @@ -1,44 +1,25 @@ --- +title: Connect Apps to Yandex +description: How to obtain an Application ID and Application Password for Yandex. connection: Yandex image: /media/connections/yandex.png seo_alias: yandex -description: How to obtain an Application ID and Application Password for Yandex. ---- - -# Obtaining an Application ID and Application Password for Yandex - -To configure an Yandex connection you will need to register your Auth0 instance as a Yandex application. - -This doc refers to the client steps to connect your client. If you are looking to manage authentication in your application, see [Next Steps](#next-steps) below. - -## 1. Create a new Application in Yandex: - -Log in into Yandex and [create a new app](https://oauth.yandex.ru/client/new): - -> Complete instructions are available [here](http://api.yandex.ru/oauth/doc/dg/tasks/register-client.xml) - ---- - -## 2. Register a new application - -Complete the form: - -![](/media/articles/connections/social/yandex/yandex-create-app.png) - -The callback address for your app should be: - - https://${account.namespace}/login/callback - - -Notice that `scopes` in Yandex are defined in this screen. Select what kind of information you are requesting for your app. - +public: true +index: 38 +toc: true +topics: + - connections + - social + - yandex +contentType: how-to +useCase: + - customize-connections + - add-idp --- - -## 3. Get your Application ID and Application Password - -Once the application is registered, enter your new `Application ID` and `Application Password` into the connection settings in Auth0. - -![](/media/articles/connections/social/yandex/yandex-add-connection.png) - +<%= include('../../../snippets/social/yandex/0') %> +<%= include('../../../snippets/social/yandex/1') %> +<%= include('../../../snippets/social/yandex/2') %> +<%= include('../../../snippets/social/yandex/3') %> +<%= include('../../../snippets/social/yandex/4') %> +<%= include('../../../snippets/social/yandex/5') %> <%= include('../_quickstart-links.md') %> - diff --git a/articles/connector/client-certificates.md b/articles/connector/client-certificates.md index 228caf8583..ffce9fcd95 100644 --- a/articles/connector/client-certificates.md +++ b/articles/connector/client-certificates.md @@ -1,25 +1,40 @@ --- description: How to setup authentication using client certificates. +topics: + - connector + - ad/ldap + - client-certificates +contentType: how-to +useCase: + - add-login + - customize-connections + - add-idp --- # Client Certificate Support -In addition to Kerberos, the AD/LDAP Connector also allows users to authenticate using __client certificates__. With this, users authenticate with a certificate installed on their machine or device. +In addition to Kerberos, the [AD/LDAP Connector](/connector) also allows users to authenticate using **client certificates**. With this, users authenticate with a certificate installed on their machine or device. -## Configuration +## Configure the AD/LDAP connection -To activate Client Certificates on an LDAP connection, simply enable the option in the dashboard: +To activate client certificates on an AD/LDAP connection: + +1. Go to [Connections > Enterprise](${manage_url}/#/connections/enterprise) and select your AD/LDAP connection. +2. Toggle the **Use client SSL certificate authentication** option in the settings. +3. Provide IP address ranges in the **IP Ranges** field. Only users coming from the given IP ranges are prompted to authenticate using client certificates. Users from different IP ranges are prompted to login with the username/password login form. ![](/media/articles/connector/client-certs/connector-client-cert-enable.png) -> Note that you'll also need to configure the IP Ranges. Only users coming from these IP Ranges will be prompted to authenticate using Client Certificates. Users that originate from different IP Ranges will be presented with the traditional username/password login form. +## Configure the certificates -Once this has been configured in Auth0 you'll need to configure the certificates in the AD/LDAP Connector. Supporting Client Certificates will require the following: +Once the AD/LDAP connection has been configured in Auth0, you'll need to configure the certificates in the AD/LDAP Connector. Supporting client certificates will require the following: 1. An __SSL certificate__ for the **Front Facing Url**, because the interaction between the end user and the Connector will need to happen over HTTPS. 2. One or more __CA certificates__. 3. A __Client Certificate__ signed by the CA for each user that needs to authenticate using Client Certificates. +Before uploading certificates to the AD/LDAP connector, convert X509 certificates to Base64. To do this you can use a simple online tool like [this one](https://www.base64decode.org/), or you can use [Certutil.exe](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/certutil#BKMK_encode) on Windows Server. + The SSL certificate and the CA certificate can be uploaded in the AD/LDAP Connector: ![](/media/articles/connector/client-certs/connector-client-cert-config.png) diff --git a/articles/connector/considerations-non-ad.md b/articles/connector/considerations-non-ad.md index 9e2680c9df..a70e29d7fc 100644 --- a/articles/connector/considerations-non-ad.md +++ b/articles/connector/considerations-non-ad.md @@ -1,10 +1,18 @@ --- description: How to configure the Connector for OpenLDAP and other directories that are not AD. +topics: + - connector + - openldap +contentType: how-to +useCase: + - add-login + - customize-connections + - add-idp --- # Considerations for OpenLDAP and non-AD directories -The Connector comes by default highly optimized for **Active Directory**. To configure it any other LDAP directories (e.g. OpenLDAP) you will have to customize these settings in the **config.json** file: +The Connector comes by default highly optimized for **Active Directory**. To configure it any other LDAP directories (such as OpenLDAP) you will have to customize these settings in the **config.json** file: ``` "LDAP_USER_BY_NAME": "(cn={0})", diff --git a/articles/connector/high-availability.md b/articles/connector/high-availability.md index 9ab0b55b9a..cfc2cb90ea 100644 --- a/articles/connector/high-availability.md +++ b/articles/connector/high-availability.md @@ -1,40 +1,59 @@ --- -description: How to install multiple instances of the connectory for higher availability. +description: How to install multiple instances of the connector for higher availability. +topics: + - connector +contentType: how-to +useCase: + - add-login + - customize-connections + - add-idp --- +# Deploy the Connector in a High Availability (HA) Environment -# High availability +The connector is a critical component. Therefore we recommend a highly available deployment with redundancy (that is, installing multiple instances of it). -The connector is a very important component, therefore we recommend a highly available deployment through redundancy: installing multiple instances of it. +## How high availability helps -If one of the instances fails either because of a network issue or hardware issue, Auth0 will redirect the login transactions to the other connector. +Each instance of the high-availability cluster will be always up and running and connected to Auth0. Auth0 will send login transactions and other requests to any of the available connectors. -Having a highly available deployment also allows updating the connector with zero downtime. +If one of the instances fails because of a network or a hardware issue, Auth0 will redirect the login transactions to the other connector. -## Instructions for Windows +Having a highly available deployment also allows you to update the connector with zero downtime. -1. Install the connector as explained [here](/connector/install). -2. Make sure all steps are complete and the connector is up and running. -3. Navigate to the Admin Console and export the configuration: [http://localhost:8357/#export](http://localhost:8357/#export) -4. Install the connector on a second server following the same instructions as above. -5. When prompted for the __Ticket URL__, go to the __Import / Export__ tab and import the configuration there. +## Overview of the multiple-connector installation process -![](/media/articles/connector/high-availability/connector-high-avail-console.png) +Installing multiple instances of the connector in a high-availability deployment involves: -## Instructions for Linux +- **A regular first-time installation.** This is where you provide the ticket URL that links the connector to a specific connection in your Auth0 tenant and other configuration parameters. +- **Making copies of the original installation and populating it to other servers.** This ensures that the same configuration and certificates securing communications are used in each instance. -1. Install the connector as explained [here](/connector/install). -2. Make sure all steps are complete and the connector is up and running. -3. Copy **config.json**, **lib/profileMapper.js** and everything under the **certs** folder from: - - Windows: `C:\Program Files (x86)\Auth0\AD LDAP Connector\` - - Linux: `/opt/auth0/ad-ldap` +::: note +The following instructions are for Windows/Linux users only. +::: -4. Install the connector on a second server following the same instructions as above. When prompted for the __Ticket URL__ close the dialog. -5. On the **second server**, overwrite the default files, `config.json`, `lib/profileMapper.js` and the files in `certs` directory, with the versions of those files from the **first server** that were copied/saved in step 3 above. -6. Restart the service on the second server. +### Step 1. Setting up your first server -## Kerberos or certificate based authentication considerations +1. [Install the connector](/connector/install) on the first server. +1. Once the connector is installed, configured, and working correctly on your first server, copy **config.json**, **lib/profileMapper.js** and everything in the **certs** folder from: + - *For Windows users*: **C:\Program Files (x86)\Auth0\AD LDAP Connector\** + - *For Linux users*: **/opt/auth0/ad-ldap** +1. Back up the files copied from the step above, since you will use them to configure the additional instances of the connector on your other server(s). -If you enable [Kerberos](/connector/kerberos) or [client certificates](/connector/client-certificates) based authentication in your AD/LDAP connections, users will contact the connector directly, instead of going through the Auth0 server. In these scenarios where multiple connector instances exist, we recommend fronting them with a network load balancer. The `SERVER_URL` parameter can be used to publish the public location where the connector will be listening to incoming requests. +### Step 2. Setting up additional servers -This URL should be then mapped in the network load balancer to all internal instances of the deployed connectors. No special distribution policy is required (e.g. uniform round-robin, with no sticky sessions, should work). +1. [Install the connector](/connector/install) on the additional servers. **Do not configure the connector on the additional server yet.** +2. Replace the configuration files for your additional servers **with the files you saved from configuring your first server.** When done, you'll over overwritten the additional servers' **config.json** and **lib/profileMapper.js** files, as well as the **./certs/** folder. +3. Restart the **Auth0 ADLDAP** and **Auth0 ADLDAP** Admin Windows Services on the secondary servers. +4. Open the troubleshooting screen (accessible at **http://localhost:8357/#troubleshoot**) and run the troubleshooting test. Make sure all tests pass. +### Verify your connection + +Once you've completed the installation process, you verify your installation using the **Connections** section of the Auth0 Dashboard. The AD Connection will have a green dot next to its name to indicate that it can use the connection successfully. + +## Kerberos or certificate-based authentication considerations + +If you enable [Kerberos](/connector/kerberos) or [client certificates](/connector/client-certificates) based authentication in your AD/LDAP connections, users will contact the connector directly instead of going through the Auth0 server. + +In scenarios where multiple connector instances exist, we recommend fronting them with a network load balancer. The `SERVER_URL` parameter can be used to publish the public location where the connector will be listening to incoming requests. + +The `SERVER_URL` should be then mapped in the network load balancer to all internal instances of the deployed connectors. No special distribution policy is required (e.g., uniform round-robin, with no sticky sessions, works). diff --git a/articles/connector/index.md b/articles/connector/index.md index d06facec08..52f5506f2d 100644 --- a/articles/connector/index.md +++ b/articles/connector/index.md @@ -3,8 +3,18 @@ url: /connector classes: topic-page title: Active Directory/LDAP Connector description: Explains what the connector is and links to resources to learn more about it. +topics: + - connector +contentType: + - index + - concept + - how-to +useCase: + - add-login + - customize-connections + - add-idp --- - +

      Active Directory/LDAP Connector

      diff --git a/articles/connector/install-other-platforms.md b/articles/connector/install-other-platforms.md index 35cc3719d2..d97c116c95 100644 --- a/articles/connector/install-other-platforms.md +++ b/articles/connector/install-other-platforms.md @@ -1,16 +1,24 @@ --- description: A guide on installing the AD/LDAP Connector on different platforms. +topics: + - connector +contentType: how-to +useCase: + - add-login + - customize-connections + - add-idp --- - # Install the AD/LDAP Connector on Non-Microsoft Platforms This document covers how to install the AD/LDAP Connector on non-Microsoft Platforms. -:::panel-info Prerequisites +::: warning Prior to installing the AD/LDAP Connector, please ensure that you have already installed [Git](https://git-scm.com/download/linux), [Node.js](https://nodejs.org), and [npm](http://blog.npmjs.org/post/85484771375/how-to-install-npm). ::: -**Note**: For most platforms, you will need to run the required commands with root privileges. +::: note +For most platforms, you will need to run the required commands with root privileges. +::: 1. Download the package to `/tmp`: @@ -18,17 +26,17 @@ Prior to installing the AD/LDAP Connector, please ensure that you have already i 2. Expand the package and install its dependencies: - ```text - > mkdir /opt/auth0-adldap - > tar -xzf /tmp/adldap.tar.gz -C /opt/auth0-adldap --strip-components=1 - > cd /opt/auth0-adldap - > npm install + ```bash + mkdir /opt/auth0-adldap + tar -xzf /tmp/adldap.tar.gz -C /opt/auth0-adldap --strip-components=1 + cd /opt/auth0-adldap + npm install ``` -3. Start your server: +3. Start your server. - ```text - > node server.js + ```bash + node server.js ``` When prompted for the ticket number, enter the full ticket URL from the **Settings** tab of the **Setup AD/LDAP connector** screen in the Auth0 Management Dashboard: @@ -46,11 +54,26 @@ Prior to installing the AD/LDAP Connector, please ensure that you have already i "LDAP_BIND_PASSWORD":"YOUR_LDAP_USER_PASSWORD" //cleartextpassword ``` - > If you're using LDAP, refer to the [Modifying the Connector Settings](/connector/modify) page. + ::: note + If you're using LDAP, refer to the [Modifying the Connector Settings](/connector/modify) page. + ::: 5. Run `node server.js` once more to start the Connector. Note that the `LDAP_BIND_PASSWORD` line in `config.json` changes to `LDAP_BIND_CREDENTIALS` at this point. -6. Once the Connector is running, you will need to daemonize the Connector (if you don't already have a tool selected, you can consider [upstart](http://upstart.ubuntu.com/) or [systemd](https://www.freedesktop.org/wiki/Software/systemd/)). +6. Once the Connector is running, you will need to daemonize the Connector (if you don't already have a tool selected, you can consider [upstart](http://upstart.ubuntu.com/) or [systemd](https://www.freedesktop.org/wiki/Software/systemd/)). For example, for using systemd with Ubuntu Xenial, the file `/lib/systemd/system/auth0-adldap.service` could contain the following: + + ```text + [Unit] + Description=Auth0 AD LDAP Agent + After=network.target + + [Service] + Type=simple + Restart=always + User=ubuntu + WorkingDirectory=/opt/auth0-adldap + ExecStart=/usr/bin/node server.js + ``` -#### Notes +7. Run `node admin/server.js` to access the admin UI -- the admin UI will be running and available on `http://localhost:8357`. -* If you get an `Invalid Ticket` message when configuring the Connector for the first time, the most likely cause is a network issue (for example, you have the Connector running behind a proxy). Try troubleshooting by connecting to `https://your_tenant.auth0.com/testall` with a browser other than Internet Explorer. +::: note +If you get an `Invalid Ticket` message when configuring the Connector for the first time, the most likely cause is a network issue (for example, you have the Connector running behind a proxy). +::: diff --git a/articles/connector/install.md b/articles/connector/install.md index 869589c94b..87943bb0b8 100644 --- a/articles/connector/install.md +++ b/articles/connector/install.md @@ -1,5 +1,12 @@ --- description: Directions on how to install the Connector with Windows. +topics: + - connector +contentType: how-to +useCase: + - add-login + - customize-connections + - add-idp --- # Installing the Connector on Windows @@ -12,7 +19,7 @@ The Connector is packaged as a standard Microsoft Installer file (__MSI__). Down
      • - + Auth0 Active Directory/LDAP Connector for Windows @@ -56,7 +63,7 @@ Once you have entered the __TICKET URL__, you must enter the LDAP settings: ![](/media/articles/connector/install/adldap-connector-admin-settings.png) -- **LDAP Connection String (eg: ldap://ldap.internal.contoso.com):** This is the protocol + the domain name or ip address of your LDAP server. The protocol can be either `ldap` or `ldaps`. If you need to use `ldaps` make sure that the certificate is valid in the current server. +- **LDAP Connection String (eg: ldap://ldap.internal.contoso.com):** This is the protocol + the domain name or ip address of your LDAP server. Your LDAP server is the local domain controller where Active Directory is installed. The protocol can be either `ldap` or `ldaps`. If you need to use `ldaps` make sure that the certificate is valid in the current server. - **Base DN (eg: dc=contoso,dc=com):** This is the base container for all the queries performed by the connector. - **Username (eg: cn=svcauth0,dc=services,dc=contoso,dc=com):** The full distinguish name of a user to perform queries. - **Password:** The password of the user. diff --git a/articles/connector/kerberos.md b/articles/connector/kerberos.md index 11f0fd9560..06a12a5e0d 100644 --- a/articles/connector/kerberos.md +++ b/articles/connector/kerberos.md @@ -1,81 +1,151 @@ --- -description: Explains Kerberos Support with Auth0, how to configure it, the flow, and auto-login with Lock. +description: Explains AD/LDAP Federation Support with Auth0, how to configure it, the flow, and auto-login with Lock. +toc: true +topics: + - connector + - ad/ldap + - kerberos +contentType: + - how-to + - concept +useCase: + - add-login + - customize-connections + - add-idp --- +# Federating with Active Directory through the AD/LDAP Connector -# Kerberos Support - -Kerberos is a security protocol used by Active Directory which is based on tickets and can provide nearly invisible authentication to users on domain-joined machines. This allows users to use resources in the corporate network (eg: SharePoint, Dynamics CRM, Web Applications) without having to enter their credentials for each application. - -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. +The AD/LDAP connector makes it easy for your users to authenticate when they are on a domain-joined machine within the corporate network. ## Configuration -To activate Kerberos on an Active Directory, simply enable the option in the dashboard. +To activate this feature for Active Directory/LDAP, simply enable the option in the Dashboard. -![](/media/articles/connector/kerberos/connector-kerberos-configuration.png) +Go to the **Connections > Enterprise > Active Directory > LDAP**, select the connection you want configure, and click the **Settings** icon. -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. +![](/media/articles/connector/kerberos/connector-kerberos-configuration.png) -> We recommend restarting the Windows Service that hosts the AD Connector every time this setting is changed. This way, changes will take effect immediately. +After enabling it, you'll also be able to configure the **IP Ranges**. When users originate from these IP address ranges Auth0 will be able to redirect to the AD/LDAP identity provider and leverage their native authentication mechanisms. The IP addresses are configured using the [CIDR-notation](http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing). Note that these should be ranges that are visible by Auth0. If Auth0 is deployed on-premises you'll typically enter internal IP address ranges of your users. +::: note +We recommend restarting the Windows Service that hosts the AD Connector every time this setting is changed. This way, changes will take effect immediately. +::: + When Auth0 is running in the cloud, it won't be able to see your user's internal IP address. In that case you'd configure the public facing/WAN IP address(es) of your company. -> Normally the step above is not necessary. When Kerberos is enabled, Auth0 server will assume all requests coming from that IP address are originating from your intranet. For normal use then, simply turn Kerberos on and then leave the IP configurations empty. If your intranet spans multiple networks and those are different from where the connector is installed, then it is important to define it here. +### Auto-detected range for Kerberos + +When Kerberos authentication is enabled, the visible IP address of the server where the AD Connector is running is implicitly added to the network IP range. + +This means that if a user's requests originate from the same visible IP address as that of the AD Connector, then Kerberos authentication will be attempted. ## Flow -Depending on the location of the user the authentication flow will be different when Kerberos is enabled. Let's take Fabrikam as an example. Since Fabrikam uses the SaaS version of Auth0 they configured their Public IP Address (`24.12.34.56/32`) in the connection. +Depending on the location of the user the authentication flow will be different when IP ranges are set. Let's take Fabrikam as an example. Since Fabrikam uses the SaaS version of Auth0 they configured their Public IP Address (`24.12.34.56/32`) in the connection. -Users connecting from within the building will all originate from `24.12.34.56` (as configured on the connection). When they authenticate, the users can follow the Kerberos flow and have a seamless SSO experience. +Users connecting from within the building will all originate from `24.12.34.56` (as configured on the connection). When they authenticate, the users can follow the AD/LDAP native flow and have a seamless Single Sign-on (SSO) experience. -**Note:** For this to work, the network must allow the users to connect to the AD/LDAP Connector on the port configured in the `config.json` file. In [highly available](/connector/high-availability) deployments of the connector, the address users will be connecting to is the network load balancer in front of all connectors instances. +::: note +For this to work, the network must allow the users to connect to the AD/LDAP Connector on the port configured in the `config.json` file. In [highly available](/connector/high-availability) deployments of the connector, the address users will be connecting to is the network load balancer in front of all connectors instances. +::: ![](/media/articles/connector/kerberos/connector-kerberos-flow.png) -On the other hand, when users are not in the corporate network (e.g.: at a customer, working from home without VPN) they won't be able to access the AD/LDAP Connector directly. The users will need to enter their username/password, and Auth0 will validate these credentials with the AD/LDAP Connector (which will in turn use Active Directory to validate those credentials). +On the other hand, when users are not in the corporate network (for example, at a customer site, working from home without VPN) they won't be able to access the AD/LDAP Connector directly. The users will need to enter their username/password, and Auth0 will validate these credentials with the AD/LDAP Connector (which will in turn use Active Directory to validate those credentials). ![](/media/articles/connector/kerberos/connector-credentials-flow.png) ## Auto-login with Lock -When an application is using the Login Page hosted by Auth0 (typicaly used for SAML/WS-Federation protocols and SSO Integrations) the Lock will show a button which allows users to authenticate using "Windows Authentication". If they don't want to use this they can continue and have the Lock show all other available connections. - -In some cases the requirement could be to automatically sign in the user if Kerberos is possible (based on the IP-address of the end user). The following changes can be added to the Auth0 Login Page (or to your own page hosting the Lock) to automatically sign in the user if Kerberos is possible: - -```js -/* - * Helper to get a querystring value. - */ -function getParameterByName( name ){ - name = name.replace(/[\[]/,"\\\[").replace(/[\]]/,"\\\]"); - var regexS = "[\\?&]"+name+"=([^&#]*)"; - var regex = new RegExp( regexS ); - var results = regex.exec( window.location.href ); - if( results == null ) - return ""; - else - return decodeURIComponent(results[1].replace(/\+/g, " ")); -} - -/* - * Verify if Kerberos is possible (based on the IP address). - * If it is, try to authenticate the user. - */ -lock.$auth0.getSSOData(true, function(err, data) { - if (!err) { +::: warning +Detecting IP ranges in an Active Directory/LDAP connection and using those ranges with Lock to allow integrated Windows Authentication is a feature that works in Lock 10, but can only be used in Lock 11 in Universal Login scenarios. This feature is *disabled* in Lock 11 when Lock 11 is used in Embedded Login scenarios. +::: + +When an application is using Lock 10 or 11 within the Login Page hosted by Auth0 (typically used for SAML/WS-Federation protocols and Single Sign-on (SSO) Integrations), there will be a button which allows users to authenticate using "Windows Authentication". + +In some cases the requirement could be to automatically sign in the user if Kerberos is possible (based on the IP-address of the end user). The following changes can be added to the Auth0 Login Page to automatically sign in the user if Kerberos is possible: + +```html + + + + + +``` + +## Skipping Kerberos at runtime + +You can prevent Kerberos from being used, even if the user is logging in from an IP address within the range configured in the connection's settings, by passing `rememberLastLogin: false` to `lock.show()` + + +```js + +function useKerberos() { + // return true to use Kerberos, false to bypass +}; + +lock.show({rememberLastLogin: useKerberos()}); ``` + ## Troubleshooting To enable verbose logging of Kerberos requests, add a system level environment variable `DEBUG=kerberos-server`. Then restart the Connector. Try logging in again, and check the logs for more information. + +## Firefox support for Kerberos + +By default, [Firefox](https://www.mozilla.org/firefox) [rejects all "negotiate" requests required to authenticate users with Kerberos](https://developer.mozilla.org/en-US/docs/Mozilla/Integrated_authentication). If you wish to use Firefox with Kerberos, you need to whitelist the server where the connector is installed. To do that: + +* Open a Firefox tab and type `about:config` in the address bar. +* Dismiss any warning message, and in the search box type `negotiate`. +* Locate the `network.negotiate-auth.trusted-uris` item and double click to change its value. +* Type the domain name of the server where the connector is installed. If you have multiple instances of the connector behind a load balancer, add the dns name of the balancer. +The value accepts a comma-separated list of URL prefixes or domains in the form of `mydomain.com, https://myotherdomain.com`. +* Click **Ok**. You don't need to restart the server for the changes to take effect. diff --git a/articles/connector/modify.md b/articles/connector/modify.md index 6bfbff6d90..c4b4a16f84 100644 --- a/articles/connector/modify.md +++ b/articles/connector/modify.md @@ -1,11 +1,16 @@ --- description: How to modify AD/LDAP Connector settings in the console, Profile Mapper, or config file. +topics: + - connector +contentType: how-to +useCase: + - add-login + - customize-connections + - add-idp --- # Modify the AD/LDAP Connector Settings - - ## AD/LDAP Connector Admin Console The **Connector Admin** screen can be launched by bringing up a browser on the AD/LDAP connector server and connecting to: `http://localhost:8357`. @@ -26,7 +31,9 @@ Once you submit the above information, the connector will perform a series of te Make sure that all tests are green. -**NOTE**: For an explanation of each test, see the [Troubleshooting](/connector/install#troubleshooting) section of the AD/LDAP installation instructions. +::: note +For an explanation of each test, see the [Troubleshooting](/connector/install#troubleshooting) section of the AD/LDAP installation instructions. +::: Your AD/LDAP Connector will start using the new directory parameters after all changes pass all the tests. If any test fails, the changes will not be saved. @@ -34,13 +41,13 @@ Your AD/LDAP Connector will start using the new directory parameters after all c To modify the mapping of profile attributes from AD/LDAP attributes to attributes in the Auth0 user profile, launch the **Connector Admin Console** as [described above](#launch-the-ad-ldap-connector-admin-console) and click on **Profile Mapper**. -**Profile Mapper** displays a code editor screen with a short description at the top. The body of the editor screen shows a javascript function which maps attributes from a source directory service (represented by the `raw_data` variable) into a variable that gets returned to populate the __Auth0 User Profile__. +**Profile Mapper** displays a code editor screen with a short description at the top. The body of the editor screen shows a javascript function which maps attributes from a source directory service (represented by the `raw_data` variable) into a variable that gets returned to populate the __Auth0 User Profile__. The first part of the function instantiates a variable called `profile` and has a mapping for the core portion of the Auth0 User Profile. Additional attributes can be set below that using syntax in the form: `profile['department'] = raw_data['companydept'];` -In this example, `department` is the name of the attribute in the Auth0 User Profile and `companydept` is the name of the attribute in the source directory service (e.g. AD). +In this example, `department` is the name of the attribute in the Auth0 User Profile and `companydept` is the name of the attribute in the source directory service (such as AD). ## Import / Export @@ -48,7 +55,7 @@ The __Import/Export__ feature of the **Connector Admin Console** can be used to ## Troubleshooting -The __Troubleshooting__ feature of the **Connector Admin Console** can be used to detect issues with the environment that may prevent the AD/LDAP connector from working properly. It will check for common problems like network connectivity, clock skew, connectivity to LDAP, etc. +The __Troubleshooting__ feature of the **Connector Admin Console** can be used to detect issues with the environment that may prevent the AD/LDAP connector from working properly. It will check for common problems like network connectivity, clock skew, connectivity to LDAP, and so on. This feature also displays the contents of the AD/LDAP connector log file. @@ -60,62 +67,71 @@ The __Search__ feature is designed to allow the testing of search queries used b The __Update__ feature provides a convenient way to update the AD/LDAP connector to a more recent version. Updates are fully automated. -**NOTE**: Internet connectivity is required for an update to work. +::: note +Internet connectivity is required for an update to work. +::: ## Configuration file -The `config.json` file is the AD/LDAP Connector's main configuration file. It can be edited to make advanced changes that are not available via the AD/LDAP **Connector Admin Console**. The file is located in the install directory for the AD/LDAP Connector. The following settings are supported in this file: - - - `AD_HUB`: The Auth0 endpoint to which the connector will connect. This value is maintained by the connector. - - `CA_CERT`: An authority certificate or array of authority certificates to check the remote host against. - - `CLIENT_CERT_AUTH`: Specifies if **Client Certificate Authentication** is enabled or not. This value is configured in Auth0 and maintained by the connector. - - `CONNECTION`: The name of the connection in Auth0 which is linked to this instance of the connector. This value is maintained by the connector. - - `CONNECTIONS_API_V2_KEY`: A Management APIv2 token which is used to call the [Get a connection](/api/management/v2#!/Connections/get_connections_by_id) endpoint. Set this when you need to troubleshoot the connector. This will compare the local certificate to the one configured in Auth0 and detect a possible mismatch. - - `FIREWALL_RULE_CREATED`: Will be set to `true` once the Firewall rule has been created for the Kerberos Server (only when Kerberos is enabled). - - `GROUPS`: Include the user's groups when enriching the profile. Default: `true`. - - `GROUP_PROPERTY`: The attribute of the group object that will be used when adding the groups to a user. Default: `cn`. - - `GROUPS_CACHE_SECONDS`: Total time in seconds to cache a user's groups. Default: 600 seconds. - - `GROUPS_TIMEOUT_SECONDS`: The timeout in seconds for searching all groups a user belongs to. Default: 20 seconds. - - `HTTP_PROXY`: The URL of a proxy server if one is required to connect from the AD/LDAP Connector to Auth0. - - `KERBEROS_AUTH`: Specifies if **Kerberos Authentication** is enabled or not. This value is configured in Auth0 and maintained by the connector. - - `LAST_SENT_THUMBPRINT`: Thumbprint of the last certificate which was sent to Auth0. - - `LDAP_BASE`: Defines the location in the directory from which the LDAP search begins. Eg: `DC=fabrikam,DC=local`. - - `LDAP_BASE_GROUPS`: Defines the location in the directory from wich the LDAP search for groups begins. - - `LDAP_BIND_PASSWORD`: The password of the LDAP user. This setting will automatically be removed after the connector has been initialized. - - `LDAP_BIND_CREDENTIALS`: The encrypted password of the LDAP user. This setting will automatically be added after the connector has been initialized. - - `LDAP_BIND_USER`: The user for which we will bind a connection to LDAP. - - `LDAP_HEARTBEAT_SECONDS`: The keep-alive in seconds to keep the LDAP connection open. - - `LDAP_SEARCH_ALL_QUERY`: The LDAP query used to list all users in the LDAP store. Default: `(objectCategory=person)`. - - `LDAP_SEARCH_GROUPS`: The LDAP query used to find groups in the LDAP store. Default: `(member:1.2.840.113556.1.4.1941:={0})`. - - `LDAP_SEARCH_QUERY`: The LDAP query used to find users in the LDAP store. Default: `(&(objectCategory=person)(anr={0}))`. - - `LDAP_USER_BY_NAME`: The LDAP query used to find the user during authentication. This setting allows you to specify which attribute will be considered as the user's username, like the common name, the sAMAccountName, UPN, ... Default: `(sAMAccountName={0})`. - - `LDAP_URL`: The LDAP connection string, eg: `ldap://fabrikam-dc.fabrikam.local`. - - `PORT`: The port on which the server will run when Kerberos or Client Certificate Authentication is enabled. - - `PROVISIONING_TICKET`: The Auth0 provisioning ticket used to communicate with Auth0. - - `REALM`: The Auth0 realm, eg: `urn:auth0:fabrikam`. This value is maintained by the connector. - - `SERVER_URL`: The default connector URL will be `server-name:port`, but this setting allows you to overwrite this (eg: `connector.mycompany.com`). - - `SESSION_SECRET`: The session secret used to encrypt the session cookie. - - `SITE_NAME`: When Client Certificate Authentication is enabled, but not possible the AD Connector will show a fallback login page. This setting allows you to specify the title that will show on top of the page. Default: name of the AD connection. - - `SSL_KEY_PASSWORD`: The password for the SSL certificate. - - `SSL_PFX`: Base64 encoded certificate to use for SSL. - - `TENANT_SIGNING_KEY`: Your Auth0 tenant used to verify JWTs (eg: when a user authenticates, we verify that the authentication request comes from Auth0 using a JWT). - - `WSFED_ISSUER`: The issuer being set in the WS-Federation responses. If a connection is configured with email domains, the first email domain configured in Auth0 will be used as issuer. Default: `urn:auth0`. +The `config.json` file is the AD/LDAP Connector's main configuration file. You can this to make advanced changes that are not available via the AD/LDAP **Connector Admin Console**. The file is located in the install directory for the AD/LDAP Connector, which (for Windows) is usually found at `C:\Program Files (x86)\Auth0\AD LDAP Connector`. The following settings are supported in this file: + +| Setting | Description | Default | +|---------------|-------------|----------| +| `AD_HUB` | The Auth0 endpoint to which the connector will connect. This value is maintained by the connector. | | +| `CA_CERT` | An authority certificate or array of authority certificates to check the remote host against. | | +| `CLIENT_CERT_AUTH` | Specifies if **Client Certificate Authentication** is enabled or not. This value is configured in Auth0 and maintained by the connector. | | +| `CONNECTION` | The name of the connection in Auth0 which is linked to this instance of the connector. This value is maintained by the connector. | | +| `CONNECTIONS_API_V2_KEY` | A Management APIv2 token used to call the [Get a connection](/api/management/v2#!/Connections/get_connections_by_id) endpoint. Set this when you need to troubleshoot the connector. This compares the local certificate to the one configured in Auth0 and detects a possible mismatch. | | +| `FIREWALL_RULE_CREATED` | Set to `true` once the Firewall rule has been created for the Kerberos Server (only when Kerberos is enabled). | | +| `GROUPS` | Include the user's groups when enriching the profile. | `true` | +| `GROUP_PROPERTY` | The attribute of the group object used when adding the groups to a user. | `cn` | +| `GROUPS_CACHE_SECONDS` | Total time in seconds to cache a user's groups. | 600 seconds. | +| `GROUPS_TIMEOUT_SECONDS` | The timeout in seconds for searching all groups a user belongs to. | 20 seconds | +| `HTTP_PROXY` | The proxy server URL if one is required to connect from the AD/LDAP Connector to Auth0. +| `KERBEROS_AUTH` | Set if **Kerberos Authentication** is enabled or not. This value is configured in Auth0 and maintained by the connector. | | +| `LAST_SENT_THUMBPRINT` | Thumbprint of the last certificate which was sent to Auth0. | | +| `LDAP_BASE` | Defines the location in the directory where the LDAP search begins. For example: `DC=fabrikam,DC=local`. | | +| `LDAP_BASE_GROUPS` | Defines the location in the directory where the LDAP groups search begins. | | +| `LDAP_BIND_PASSWORD` | The password of the LDAP user. This setting is automatically removed after the connector initializes. | | +| `LDAP_BIND_CREDENTIALS` | The encrypted password of the LDAP user. This setting is automatically added after the connector initializes. | | +| `LDAP_BIND_USER` | The user for binding a connection to LDAP. | | +| `LDAP_HEARTBEAT_SECONDS` | Time in seconds to keep the LDAP connection open. | | +| `LDAP_SEARCH_ALL_QUERY` | The LDAP query used to list all users in the LDAP store. | `(objectCategory=person)` | +| `LDAP_SEARCH_GROUPS` | The LDAP query used to find groups in the LDAP store. For example: `(&(objectCategory=group)(member={0}))` | `(member:1.2.840.113556.1.4.1941:={0})` | +| `LDAP_SEARCH_QUERY` | The LDAP query used to find users in the LDAP store. | `(&(objectCategory=person)(anr={0}))` | +| `LDAP_USER_BY_NAME` | The LDAP query used to find the user during authentication. This setting lets you specify which attribute is considered the user's username. For example, like the common name: the sAMAccountName, UPN, et cetera. This setting also supports multiple values for an OR search, for example: `(|(sAMAccountName={0})(userPrincipalName={0}))` | `(sAMAccountName={0})` | +| `LDAP_URL` | The LDAP connection string. For example: `ldap://fabrikam-dc.fabrikam.local`. | | +| `PORT` | The port the server runs on when Kerberos or Client Certificate Authentication is enabled. | | +| `PROVISIONING_TICKET` | The Auth0 provisioning ticket used to communicate with Auth0. | | +| `REALM` | The Auth0 realm, for example: `urn:auth0:fabrikam`. This value is maintained by the connector. | | +| `SERVER_URL` | The default connector URL will be `server-name:port`, but this setting allows you to overwrite this. For example: `connector.mycompany.com`. | | +| `SESSION_SECRET` | The session secret used to encrypt the session cookie. | | +| `SITE_NAME` | When Client Certificate Authentication is enabled, but not possible the AD Connector will show a fallback login page. This setting allows you to specify the title that will show on top of the page. | Name of the AD connection. | +| `SSL_CA_PATH` | Absolute path to the base directory where the CA certificate file(s) are located. | | +| `SSL_KEY_PASSWORD` | The password for the SSL certificate. | | +| `SSL_PFX` | Base64 encoded certificate to use for SSL. | | +| `TENANT_SIGNING_KEY` | Your Auth0 tenant used to verify JWTs. +| `WSFED_ISSUER` | The issuer being set in the WS-Federation responses. If a connection is configured with email domains, the first email domain configured in Auth0 will be used as issuer. | `urn:auth0` | + +This file can be used to determine which tenants are using a particular connector. + +For more information on LDAP queries, check out [Active Directory: LDAP Syntax Filters](https://social.technet.microsoft.com/wiki/contents/articles/5392.active-directory-ldap-syntax-filters.aspx). ## Point an AD/LDAP Connector to a new connection -Sometimes you will need to point your AD/LDAP Connector instance to a new connection in Auth0. For instance: If you have migrated to a new Auth0 account (tenant), or if you changed the name of the Auth0 connection. +Sometimes you will need to point your AD/LDAP Connector instance to a new connection in Auth0. For instance: If you have migrated to a new Auth0 tenant, or if you changed the name of the Auth0 connection. Since you cannot rename connections in Auth0, the only option is to create a new Active Directory / LDAP connection and point your existing Connector instances to it. Here's how: -1. Create the new Active Directory / LDAP connection in the Auth0 dashboard and copy the resulting **TICKET URL**. +1. Create the new Active Directory / LDAP connection in the Auth0 dashboard and copy the resulting **TICKET URL**. If you are using the [custom-domains](/custom-domains) feature, you will need to replace the `${account.namespace}` part of the **TICKET URL** with your custom domain, such as `identity.fabrikam.com`. 2. On the AD/LDAP Connector host in the Connector Admin app, perform an export of the existing settings via the **Import/Export** tab. This is just a precaution in case something were to happen in the following steps that would accidentally overwrite your custom settings. If you are running the Connector on a host that does not have a web browser to access to the Connector Admin website, simply make a copy of your `config.json` file. 3. On the AD/LDAP Connector host, edit the `config.json` file and change the value of the `PROVISIONING_TICKET` property to the **TICKET URL** you copied in Step 1. -4. If you moved from one Auth0 account to another, remove the property in the `config.json` file that has the name `urn:auth0:OLD_AUTH0_TENANT_NAME`. If this is not removed, the Connector will still function but this old configuration data is not needed. +4. If you moved from one Auth0 tenant to another, remove the property in the `config.json` file that has the name `urn:auth0:OLD_AUTH0_TENANT_NAME`. If this is not removed, the Connector will still function but this old configuration data is not needed. 5. Restart the AD/LDAP Connector service (the **Auth0 ADLDAP** service in Windows). 6. Take a look at the Connector logs (**Troubleshooting** tab in the Connector Admin tool or tail the `logs.log` file) and make sure there is a recent entry that looks something like: `2016-03-10T22:47:32.970Z - debug: [2016-03-10 22:47:32] Loading settings from ticket: YOUR_TICKET_URL/info` - + 7. Make sure the new Active Directory / LDAP connection in the Auth0 dashboard is now showing as connected (the dot to the left of the new connection is green and not red). If not, refer to the [Troubleshooting](/connector/troubleshooting) page. 8. Perform a test authentication through your new connection and make sure you see activity in your Connector logs as well. diff --git a/articles/connector/overview.md b/articles/connector/overview.md index d55e1af6c4..0e2d35042a 100644 --- a/articles/connector/overview.md +++ b/articles/connector/overview.md @@ -1,23 +1,52 @@ --- +title: AD/LDAP Connector Overview description: An overview of what the AD/LDAP Connector is and why it's necessary. +topics: + - connector +contentType: concept +useCase: + - add-login + - customize-connections + - add-idp --- -# Overview +# AD/LDAP Connector Overview -Auth0 [integrates with Active Directory/LDAP](/connections/enterprise/active-directory) through an **AD/LDAP Connector** installed on your network. +Auth0 [integrates with Active Directory/LDAP](/connections/enterprise/active-directory-ldap) through an **AD/LDAP Connector** installed on your network. -The **AD/LDAP Connector** acts as a bridge between your **Active Directory** service and the **Auth0**. This is necessary, since AD typically runs and is accessible to your internal network, while Auth0 is a cloud service (and therefore running in a different context from your AD service). +The **AD/LDAP Connector** acts as a bridge between your **Active Directory (AD)** service and Auth0, which is required because AD typically runs and is accessible in your internal network while Auth0 is a cloud service (and therefore runs in a different context than your AD service). + +::: panel-warning AD/LDAP Connector and Your Customer's Servers +The AD/LDAP Connector is designed for scenarios where your company controls the AD/LDAP server. The connector should **not** be installed on your customer's servers. + +For B2B scenarios where you want to allow your customer's users to access your applications using their enterprise credentials, connect to your customer's federation service (e.g., their own Auth0 service, ADFS, or any SAML identity provider) using one of the available enterprise connections. + +If you install an AD/LDAP connector on your customer's servers and it is connected directly to your Auth0 domain, you will have to handle the passwords of your customer's users directly. Auth0 strongly recommends against these types of deployments and does not support them. +::: ![](/media/articles/connector/ad-data-flow.png) +1. When a user authenticates with Auth0, they are redirected to the AD/LDAP Connector. +2. The AD/LDAP Connector validates the user against against your Active Directory (AD) service. +3. The AD/LDAP Connector sends the results of the validation back to Auth0. + The Connector supports authentication based on the following: -* [LDAP](/protocols/ldap); -* [Kerberos](/connector/kerberos); -* [Client Certificates](/connector/client-certificates). +* [LDAP](/protocols/ldap) +* [Kerberos](/connector/kerberos) +* [Client Certificates](/connector/client-certificates) + +## Cache + +By default, an AD/LDAP Connection caches user profiles and credentials (note: Auth0 stores a *hash* of the user's password) to ensure optimal uptime and performance, and updates the data each time a user logs in. The cache is only used when the connector is down or unreachable. + +The cached data is always stored unless you [disable caching credentials](/dashboard/guides/connections/disable-cache-ad-ldap). + +::: warning +Values in the cache are case-sensitive, which means that login attempts will only succeed if users provide the exact username that was cached. +::: ## Notes * All connections from the Connector to the Auth0 Server are outbound only, so you do not need to make any changes to your firewall. -* By default, an AD/LDAP Connection caches user profiles and credentials to ensure optimal uptime and performance (Auth0 stores a *hash* of the user's password). You can disable credential caching at the [connections](/identityproviders) level. * For [high availability and load balancing](/connector/high-availability), you can install multiple instances of the AD/LDAP Connector. diff --git a/articles/connector/prerequisites.md b/articles/connector/prerequisites.md index 115f817c62..e2701a9251 100644 --- a/articles/connector/prerequisites.md +++ b/articles/connector/prerequisites.md @@ -1,5 +1,12 @@ --- description: Lists all the prerequisites to installing and configuring the connector. +topics: + - connector +contentType: reference +useCase: + - add-login + - customize-connections + - add-idp --- # Prerequisites @@ -10,7 +17,7 @@ Typically the AD/LDAP Connector needs to be installed by a sys admin or an opera The Connector can be installed on an existing server, even a Domain Controller. However, more often it's installed on virtual machines provisioned just for the Connector. Regardless, the host server should have the following hardware and software specifications/configurations: -#### Hardware Requirements +### Hardware Requirements - **Architecture**: x86 or x86-64 - **CPU cores**: min. 1, recommended 2 @@ -18,12 +25,12 @@ The Connector can be installed on an existing server, even a Domain Controller. - **Operating System**: The connector can run on Windows or Linux. Windows is required if Kerberos authentication will be used. - **RAM**: min. 2GB -#### Windows Version +### Windows Version We recommend use of Windows Server 2012. The connector can run on Windows 7+ or Windows 2008R2+ with PowerShell 3.0 or higher -#### Time Synchronization +### Time Synchronization It is very important to have the Connector host server clock automatically synchronized with an NTP server. Otherwise the connector will fail to start and report a __clock skew error__. @@ -31,30 +38,32 @@ It is very important to have the Connector host server clock automatically synch The host server requires outbound network connectivity to the following services: -#### Auth0 +### Auth0 The connector must be installed on a server with outbound connectivity to the Auth0 service at: `https://${account.namespace}` on port **443**. The connector can be installed and configured behind a __proxy server__ but we don't recommend this. -> You can enable a proxy through the environment or configuration variable `HTTP_PROXY`. +::: note +You can enable a proxy through the environment or configuration variable `HTTP_PROXY`. +::: -#### LDAP +### LDAP -The Connector must be installed on a server with access to the LDAP server on port **389 for ldap** or **636 for ldaps**. Before installing the Connector you should know the **LDAP Connection String** and the **Base DN** required to connect to your LDAP directory ([more infomation](/connector/install#link-to-ldap)). +The Connector must be installed on a server with access to the LDAP server on port **389 for ldap** or **636 for ldaps**. Before installing the Connector you should know the **LDAP Connection String** and the **Base DN** required to connect to your LDAP directory ([more information](/connector/install#link-to-ldap)). ## Inbound Connectivity -You do not need inbound connectivity enabled to the Connector unless **Kerberos** or **Client Certificate authentication** is enabled. In these cases, the server(s) on which the connector is installed must be reachable from your users' browsers on port 443. If more than one instance of the connector is installed, you should use a load balancer to direct traffic to one connector or the another. +You do not need inbound connectivity enabled to the Connector unless **Kerberos** or **Application Certificate authentication** is enabled. In these cases, the server(s) on which the connector is installed must be reachable from your users' browsers on port 443. If more than one instance of the connector is installed, you should use a load balancer to direct traffic to one connector or the another. ## Service Account The Connector will be run using a service account that must be a domain user that at a minimum has read access to the directory. You will need the username/password of this account when performing the install. -## One Connector per Auth0 Account/Connection +## One Connector per Auth0 Tenant/Connection -If you establish multiple Auth0 accounts, perhaps to isolate development and production environments, you will need to set up an AD/LDAP connection and set up a Connector for each Auth0 account that needs this form of authentication. A Connector is tied to a specific Connection within an Auth0 account. It is possible to have multiple Connectors within one Auth0 account. This is needed 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. In addition, multiple Connectors can point to the same AD or LDAP directory, but a Connector can only be used by one Auth0 Connection within one Auth0 account. +If you establish multiple Auth0 tenants, perhaps to isolate development and production environments, you will need to set up an AD/LDAP connection and set up a Connector for each Auth0 tenant that needs this form of authentication. A Connector is tied to a specific Connection within an Auth0 tenant. It is possible to have multiple Connectors within one Auth0 tenant. This is needed 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. In addition, multiple Connectors can point to the same AD or LDAP directory, but a Connector can only be used by one Auth0 Connection within one Auth0 tenant. ## High Availability -The Connector can be installed on multiple host servers for redundancy (most organizations provision two) in case one server becomes unavailable. Each server will have the same requirements listed above. No load balancer is required as that is performed by the Auth0 server itself, unless you enable __Kerberos__ or __Client Certificate__ based authentication. +The Connector can be installed on multiple host servers for redundancy (most organizations provision two) in case one server becomes unavailable. Each server will have the same requirements listed above. No load balancer is required as that is performed by the Auth0 server itself, unless you enable __Kerberos__ or __Application Certificate__ based authentication. diff --git a/articles/connector/scom-monitoring.md b/articles/connector/scom-monitoring.md index 087aa7f1a3..314815c2de 100644 --- a/articles/connector/scom-monitoring.md +++ b/articles/connector/scom-monitoring.md @@ -1,5 +1,14 @@ --- description: How to monitor the AD/LDAP Connector with System Center Operations Manager. +topics: + - connector + - ad/ldap + - scom +contentType: how-to +useCase: + - add-login + - customize-connections + - add-idp --- # Monitoring the AD/LDAP Connector with System Center Operations Manager @@ -22,7 +31,4 @@ You can monitor the service status using System Center as you would do with any * Select the limits of **CPU** and **Memory limits**. Eg: 10% of CPU and 200MB of RAM are good limits to trigger alerts. -We also recommend setting up a _synthetic transaction_ to monitor end to end authentication. More information about monitoring is available [here](/monitoring). - -## AD/LDAP Connector Health Webtask -[Here](https://github.com/sandrinodimattia/auth0-ldap-connector-health-webtask) is a way to monitor health of AD/LDAP connector from Auth0 perspective. This can be done in addition to monitoring from an infrastructure perspective. +We also recommend setting up a _synthetic transaction_ to monitor end-to-end authentication. See [Monitor Auth0 Using SCOM](/monitoring/guides/monitor-using-SCOM) for more information. diff --git a/articles/connector/test-dc.md b/articles/connector/test-dc.md index d88b5bea57..2380010fa6 100644 --- a/articles/connector/test-dc.md +++ b/articles/connector/test-dc.md @@ -1,8 +1,15 @@ --- description: How to create and test an Active Directory Domain Controller. toc: true +topics: + - connector + - ad/ldap +contentType: how-to +useCase: + - add-login + - customize-connections + - add-idp --- - # Creating a Test Active Directory Domain Controller Auth0's AD/LDAP integration is relatively easy to set up, but it does require that you have access to an existing AD service and sufficient privileges to [install and configure the Connector](/connector/install). What if, however, you'd just like to try out the Connector or set up a dev/test environment? The following steps guides you in creating a minimal AD Domain Controller installation on a cloud-deployed virtual machine for these purposes. @@ -12,60 +19,62 @@ Auth0's AD/LDAP integration is relatively easy to set up, but it does require th You can run your VM on any cloud platform, but this guide will walk through how to set one up on Microsoft Azure. 1. If you don't have an account with Azure, [create one](https://azure.microsoft.com) before proceeding. -2. Log into the [Azure Management](https://manage.windowsazure.com) console. -3. At the bottom left corner, click **NEW**, then **COMPUTE** > **VIRTUAL MACHINE** > **QUICK CREATE** -4. Complete the form: - - * Choose a DNS name. Example: `auth0-test-ad` - * Image: **Windows Server 2012 R2 Datacenter** - * Size: **D1** - * User name: `ad-admin` - * Password: (generate your own secure password) - * Region: (your choice) - -5. Click the **CREATE A VIRTUAL MACHINE** button. It will take a few minutes for the VM to provision. -6. Click on the **ENDPOINTS** tab of the new VM, and take note of the **PUBLIC PORT** for the **Remote Desktop** endpoint. +1. Log into the [Azure Management](https://manage.windowsazure.com) console. +1. At the bottom left corner, click **NEW**, then **COMPUTE** > **VIRTUAL MACHINE** > **QUICK CREATE** +1. Complete the form: + * Choose a DNS name. Example: `auth0-test-ad` + * Image: **Windows Server 2012 R2 Datacenter** + * Size: **D1** + * User name: `ad-admin` + * Password: (generate your own secure password) + * Region: (your choice) +1. Click the **CREATE A VIRTUAL MACHINE** button. It will take a few minutes for the VM to provision. +1. Click on the **ENDPOINTS** tab of the new VM, and take note of the **PUBLIC PORT** for the **Remote Desktop** endpoint. ![](/media/articles/connector/test-dc/remote-desktop-port.png) -7. Open up Microsoft Remote Desktop client (Windows or Mac) or the client of your choice (such as [rdesktop](http://www.rdesktop.org/) for Linux systems). Create a new connection to your VM: +1. Open up Microsoft Remote Desktop client (Windows or Mac) or the client of your choice (such as [rdesktop](http://www.rdesktop.org/) for Linux systems). Create a new connection to your VM: ![](/media/articles/connector/test-dc/remote-desktop-connection.png) -8. Open the connection, disregarding any certificate warnings presented by the Remote Desktop client. You should be logged in automatically and eventually see a desktop that looks like this: +1. Open the connection, disregarding any certificate warnings presented by the Remote Desktop client. You should be logged in automatically and eventually see a desktop that looks like this: - ![](/media/articles/connector/test-dc/new-vm-desktop.png) + ![](/media/articles/connector/test-dc/new-vm-desktop.png) -9. If you're prompted to find PC's, devices, and content on the local network, choose **No**. +1. If you're prompted to find PC's, devices, and content on the local network, choose **No**. ## Install Active Directory Domain Services 1. Click the PowerShell icon ![](/media/articles/connector/test-dc/powershell-icon.png) in the Windows Task Bar to open the **PowerShell Command Prompt**. - ![](/media/articles/connector/test-dc/powershell-command-prompt.png) + ![](/media/articles/connector/test-dc/powershell-command-prompt.png) -2. Install Active Directory Domain Services (ADDS) using this command: -```powershell -> Install-windowsfeature -name AD-Domain-Services –IncludeManagementTools -``` +1. Install Active Directory Domain Services (ADDS) using this command: + ```powershell + > Install-windowsfeature -name AD-Domain-Services –IncludeManagementTools + ``` + + ::: note + Note that the `Install-windowsfeature` command first became available in Windows Server 2012. In Windows Server 2008, the equivalent command was `Add-windowsfeature` (See [MSDN](https://msdn.microsoft.com/en-us/library/ee662309.aspx) for more information). + ::: ## Promote the Server to a Domain Controller -1. Promote the server to a domain controller that manages a FQDN of `mycompany.local`: -```powershell -> Install-ADDSForest –DomainName mycompany.local -``` -2. When prompted for the **SafeModeAdministratorPassword**, enter the Administrator password you used when creating the VM. -3. You will also be prompted to confirm whether or not you want to continue. Click Enter to do so. The promotion script will run and the VM will automatically reboot. +1. Promote the server to a domain controller that manages a FQDN of `mycompany.local`: + ```powershell + > Install-ADDSForest –DomainName mycompany.local + ``` +1. When prompted for the **SafeModeAdministratorPassword**, enter the Administrator password you used when creating the VM. +1. You will also be prompted to confirm whether or not you want to continue. Click Enter to do so. The promotion script will run and the VM will automatically reboot. ## Add Test Groups and Users 1. Once the VM finishes rebooting, log in to the VM using the Remote Desktop client. -2. Open the PowerShell Command Prompt. -3. Run the following script, which will: - * Create two groups: **Accounting** and **IT** - * Create two users: **Bob Johnson** and **Mary Smith** - * Add Bob to the **Accounting** group and Mary to the **Account** *and* **IT** groups +1. Open the PowerShell Command Prompt. +1. Run the following script, which will: + * Create two groups: **Accounting** and **IT** + * Create two users: **Bob Johnson** and **Mary Smith** + * Add Bob to the **Accounting** group and Mary to the **Account** *and* **IT** groups ```powershell > New-ADGroup -Name "Accounting" -GroupScope "DomainLocal" @@ -76,46 +85,48 @@ You can run your VM on any cloud platform, but this guide will walk through how > Add-ADGroupMember -Identity Accounting -Members "bob.johnson", "mary.smith" > Add-ADGroupMember -Identity IT -Members "mary.smith" + ``` ## Install and Configure the AD/LDAP Connector -1. Using the [Auth0 Management Dashboard](${manage_url}), create a new **Active Directory/LDAP** connection with the name `auth0-test-ad` by following [these steps](/connections/enterprise/active-directory). - **NOTE**: Be sure to copy the **Ticket URL** that is generated at the end of those instructions. -2. On the VM, [disable **Internet Explorer Enhanced Security Configuration**](http://blog.blksthl.com/2012/11/28/how-to-disable-ie-enhanced-security-in-windows-server-2012/). -3. Open **Internet Explorer** with the **Ticket URL** you saved in step 1. -4. Follow the instructions in the browser to download, install, and configure the **Connector**. When you are prompted for the LDAP service account, use the admin account you created for the VM: - * Username: `mycompany\ad-admin` - * Password: (same as before) -5. When you're done configuring and installing the Connector, reboot the server. -6. Log back into the VM using Remote Desktop. -7. Open the Connector configuration site by navigating to `http://localhost:8357/`. -8. Check that the **Connector** is able to find a user: - * Click on the **Search** tab. - * Under "Find User by Login", type `mary.smith`. - * Click **Search**. - - You should get JSON back that contains that user's AD profile data: - - ![](/media/articles/connector/test-dc/test-find-user.png) +1. Using the [Auth0 Management Dashboard](${manage_url}), create a new **Active Directory/LDAP** connection with the name `auth0-test-ad` by following [these steps](/connections/enterprise/active-directory-ldap). + ::: note + Be sure to copy the **Ticket URL** that is generated at the end of those instructions. + ::: +1. On the VM, disable **Internet Explorer Enhanced Security Configuration**. +1. Open **Internet Explorer** with the **Ticket URL** you saved in step 1. +1. Follow the instructions in the browser to download, install, and configure the **Connector**. When you are prompted for the LDAP service account, use the admin account you created for the VM: + * Username: `mycompany\ad-admin` + * Password: (same as before) +1. When you're done configuring and installing the Connector, reboot the server. +1. Log back into the VM using Remote Desktop. +1. Open the Connector configuration site by navigating to `http://localhost:8357/`. +1. Check that the **Connector** is able to find a user: + * Click on the **Search** tab. + * Under "Find User by Login", type `mary.smith`. + * Click **Search**. You should get JSON back that contains that user's AD profile data: + + ![](/media/articles/connector/test-dc/test-find-user.png) ## Test an Authentication Flow from Auth0 To ensure that everything is working using your Auth0 account, we're going to configure your **Default App** in Auth0 to use your new **Active Directory / LDAP** Connection, and use the `/authorize` endpoint to initiate an authentication flow. -1. Using the [Auth0 Management Dashboard](${manage_url}), navigate to your [Clients](${manage_url}/#/clients). -2. Click the **Settings** icon of your **Default App** -3. Add `http://jwt.io` to the list of the Client's **Allowed Callback URLs**. -4. Click the **Connections** tab. -5. Under **Enterprise**, enable the `auth0-test-ad` **Active Directory / LDAP** connection. -6. Test the authentication flow by opening the following link in your browser: -``` -https://${account.namespace}/authorize?response_type=token&scope=openid%20profile&client_id=${account.clientId}&redirect_uri=http://jwt.io&connection=auth0-test-ad -``` - -7. Log in with one of the test users that was created in the directory: - * Username: `mary.smith` or `bob.johnson` - * Password: `Pass@word1!` - ![](/media/articles/connector/test-dc/auth-flow-login.png) -8. If everything is working, you should be redirected to the JWT.io website to see the contents of the resulting JWT: - ![](/media/articles/connector/test-dc/auth-success.png) +1. Using the [Auth0 Management Dashboard](${manage_url}), navigate to your [Applications](${manage_url}/#/applications). +1. Click the **Settings** icon of your **Default App** +1. Add `http://jwt.io` to the list of the Application's **Allowed Callback URLs**. +1. Click the **Connections** tab. +1. Under **Enterprise**, enable the `auth0-test-ad` **Active Directory / LDAP** connection. +1. Test the authentication flow by opening the following link in your browser: + ```html + https://${account.namespace}/authorize?response_type=token&scope=openid%20profile&client_id=${account.clientId}&redirect_uri=http://jwt.io&connection=auth0-test-ad + ``` + +1. Log in with one of the test users that was created in the directory: + * Username: `mary.smith` or `bob.johnson` + * Password: `Pass@word1!` + + ![](/media/articles/connector/test-dc/auth-flow-login.png) +1. If everything is working, you should be redirected to the JWT.io website to see the contents of the resulting JWT: + ![](/media/articles/connector/test-dc/auth-success.png) diff --git a/articles/connector/troubleshooting.md b/articles/connector/troubleshooting.md index 7e20f61fa5..81dd3e05c5 100644 --- a/articles/connector/troubleshooting.md +++ b/articles/connector/troubleshooting.md @@ -1,12 +1,21 @@ --- -description: This page has help and troubleshooting with using the connector. +title: Troubleshoot Active Directory/LDAP Connector +description: Common issues and troubleshooting information for the Active Directory/LDAP Connector. +toc: true +topics: + - connector + - ad/ldap +contentType: reference +useCase: + - add-login + - customize-connections + - add-idp --- - -# Troubleshooting +# Troubleshoot Active Directory/LDAP Connector We do our best to support many scenarios and different configurations. -Unfortunately some issues are very hard to predict. Especially those that happen behind our customer's firewall. We have less control over that environment, and the related infrastructure dependencies (e.g. network, proxies, OS versions, etc). +Unfortunately some issues are very hard to predict. Especially those that happen behind our customer's firewall. We have less control over that environment, and the related infrastructure dependencies (such as network, proxies, OS versions, and so on). If you are experiencing problems with the connector, please [open a support ticket](${env.DOMAIN_URL_SUPPORT}) with the following information: @@ -34,7 +43,9 @@ The __Run__ button on the __Troubleshooting__ page will run the troubleshooting ![](/media/articles/connector/troubleshooting/connector-admin-console-troubleshooter.png) -**Note:** In order to detect issues with certificates you'll need to set `CONNECTIONS_API_V2_KEY` in the `config.json` file as described [here](/connector/modify#using-the-configuration-file). +::: note +In order to detect issues with certificates you'll need to set `CONNECTIONS_API_V2_KEY` in the `config.json` file as described [here](/connector/modify#using-the-configuration-file). +::: The __Export__ button will create a .zip file containing the `config.json` file, the `lib\\profileMapper.js` file, the `certs` folder and the output of the troubleshooting tool. Send this troubleshooting package to us by opening a [support ticket](${env.DOMAIN_URL_SUPPORT}) if you're experiencing problems with the connector. @@ -52,11 +63,11 @@ These are the most common problems: ### Clock skew -Make sure the clock of your server is current. - -If the time is not correct, it will cause authentication requests to fail. This can be fixed by ensuring that the System is properly configured to use to pool a sync server via the NTP (Network Time Protocol). +Make sure the clock of your server is current. If the time is not correct, it will cause authentication requests to fail. This can be fixed by ensuring the system is properly configured to poll a sync server via the Network Time Protocol (NTP). -Note: on windows environments the ntp provider is usually the same domain controller. Make sure that your Domain Controller is synchronized with some external service. +::: note +On Windows environments the NTP provider is usually the same domain controller. Make sure that your Domain Controller is synchronized with some external service. +::: ### No connection to Active Directory @@ -66,28 +77,24 @@ In a Windows Network with Active Directory you can try the `nltest` command. To ![](/media/articles/connector/troubleshooting/connector-nltest-domain.png) -To see to which domain the current server is connected you can also try: - - - nltest /dsgetdc: - - -When the domain does not exist or is unreachable `nltest` will return an error message: +To see to which domain the current server is connected you can also try: `nltest /dsgetdc:`` - Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN +When the domain does not exist or is unreachable `nltest` will return an error message: `Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN` ### UNABLE_TO_VERIFY_LEAF_SIGNATURE error message -This error applies to the AD/LDAP Connector in combination with the Auth0 Appliance. +This error applies to the AD/LDAP Connector in combination with the Private Cloud. -When the connector will fail to start if unable to validate the SSL certificate configured in the appliance. This can happen when the Root Certificate (or any Intermediate Certificates) are missing in the machine's Certificate Store (Windows). In order to solve this you should import the certificate chain in the **Local Machine > Trusted Root** certificate store on the machine where the AD/LDAP Connector is installed. +When the connector will fail to start if unable to validate the SSL certificate configured in the Private Cloud. This can happen when the Root Certificate (or any Intermediate Certificates) are missing in the machine's Certificate Store (Windows). In order to solve this you should import the certificate chain in the **Local Machine > Trusted Root** certificate store on the machine where the AD/LDAP Connector is installed. ### Running the connector behind a proxy If the machine hosting the connector is behind a proxy, you can configure an `HTTP_PROXY` system environment variable pointing to the URL of your proxy, or you can set this variable in the `config.json` file in the connector installation directory. If using an authenticated proxy, the URL must be in the format `http://USERNAME:PASSWORD@SERVER_URL:PORT`. -> Changing the `config.json` file or setting environment variables requires restarting the connector service for the changes to take effect. +::: note +Changing the `config.json` file or setting environment variables requires restarting the connector service for the changes to take effect. +::: The `HTTP_PROXY` URL cannot point to a [.pac (proxy auto-config) file](https://en.wikipedia.org/wiki/Proxy_auto-config), it must be the URL of the proxy itself. If your proxy is configured through a .pac file, you must download the .pac file and find the proxy URL there. @@ -124,12 +131,26 @@ The Connector uses two levels of configurable caching: The server caches the _"last successfully authenticated user profile"_, including the username and password (hash). It is enabled by default, and can be disabled. -> The purpose of this first level cache is to maximize availability of authentication transactions when AD is unavailable (e.g. a network outage). It is only activated if the Connector/AD/LDAP servers are unavailable. +::: note +The purpose of this first level cache is to maximize availability of authentication transactions when AD is unavailable (such as a network outage). It is only activated if the Connector/AD/LDAP servers are unavailable. +::: The Connector caches only *groups* a user might be a member of. Its lifetime is controlled with the `GROUPS_CACHE_SECONDS` configuration variable. If not present, the value is 600 seconds. -> Groups are cached, because by default, the Connector retrieves all group membership of a user recursively, which can be costly in some AD/LDAP installations. Cache is deleted on each Connector restart. +::: note +Groups are cached, because by default, the Connector retrieves all group membership of a user recursively, which can be costly in some AD/LDAP installations. Cache is deleted on each Connector restart. +::: These two settings might affect how profile information flows to an app. But in general, AD changes don't happen very often. In some AD/LDAP installations, user attributes synchronization takes few minutes too. + +### Connector restarts after "auth0: Connection closed." message in the log + +To avoid the requirement of an open inbound port in your servers, the Connector creates a websocket connection to an available node in Auth0's server cluster and keeps it open to listen to incoming messages from Auth0. + +Approximately once a day (though this frequency might vary under certain circumstances) each server node will terminate the connection to allow internal deployment processes to occur. The Connector will detect the closed connection and terminate the process, allowing the service stack to restart the process, create a new connection to an available node and resume operations. To avoid any downtime, make sure you enable [the cache for the connection](/connector/overview#cache). + +### Receive a "postUrl is required" error + +This is usually thrown if additional configuration for custom domains have not been made. See [the custom domains documentation](/custom-domains/additional-configuration#configure-ad-ldap-connections) for more info. diff --git a/articles/connector/update.md b/articles/connector/update.md index ee4a959486..f4985be888 100644 --- a/articles/connector/update.md +++ b/articles/connector/update.md @@ -1,5 +1,13 @@ --- description: Explains the different ways to update the AD/LDAP Connector. +topics: + - connector + - ad/ldap +contentType: how-to +useCase: + - add-login + - customize-connections + - add-idp --- # Updating the AD/LDAP Connector @@ -27,16 +35,18 @@ The updater script will update the AD/LDAP Connector from the command line by ru 5. Install the AD/LDAP Connector 6. Restore the existing configuration, certificates and profileMapper.js 7. Start the Windows Service - + To run the updater script execute the following statement in the command line: - + ``` @powershell -NoProfile -ExecutionPolicy Bypass -Command "iex ((new-object net.webclient).DownloadString('https://cdn.auth0.com/connector/windows/update-connector.ps1'))" ``` ![](/media/articles/connector/update/connector-update-script.png) - -**NOTE:** The updater script uses specific PowerShell commands that are only avaible in Windows PowerShell 3.0 and higher. If you're running on Windows 2008 and Windows 2008 R2 you might need to update your [PowerShell](https://www.microsoft.com/en-us/download/details.aspx?id=34595) version first. + +::: note +The updater script uses specific PowerShell commands that are only available in Windows PowerShell 3.0 and higher. If you're running on Windows 2008 and Windows 2008 R2 you might need to update your [PowerShell](https://www.microsoft.com/en-us/download/details.aspx?id=34595) version first. +::: ## Updating manually (Windows/Linux) @@ -60,7 +70,9 @@ Download the Windows Installer from . The s Use the GitHub repository for other platforms: . -**Note:** Always verify the checksum of the downloaded installer as explained [here](/checksum). +::: note +Always verify the checksum of the downloaded installer as explained [here](/checksum). +::: ### 3. Backup your current config @@ -70,7 +82,7 @@ The configuration can be exported from the Admin Console. The **Download** butto ![](/media/articles/connector/update/connector-import-export.png) -#### Manually +#### Manually Before updating the connector backup these files from `%Program Files(x86)%\Auth0\AD LDAP Connector\`: @@ -78,7 +90,9 @@ Before updating the connector backup these files from `%Program Files(x86)%\Auth * `certs` folder * `lib\profileMapper.js` **only if you modified this file manually** -> The PATH above works for Windows based machines. Installations in other platforms will be located somewhere else, but contain the same assets. +::: note +The PATH above works for Windows based machines. Installations in other platforms will be located somewhere else, but contain the same assets. +::: ### 4. Run the installer diff --git a/articles/cross-origin-authentication/index.md b/articles/cross-origin-authentication/index.md new file mode 100644 index 0000000000..8f20a49401 --- /dev/null +++ b/articles/cross-origin-authentication/index.md @@ -0,0 +1,91 @@ +--- +title: Cross-Origin Authentication +description: An explanation of cross-origin authentication in Auth0 and its compatibility with browsers. +topics: + - cors +contentType: + - index + - concept +useCase: + - strategize +--- +# Cross-Origin Authentication + +Auth0 strongly recommends that authentication transactions be handled via [Universal Login](/universal-login). Doing so offers [the easiest and most secure way to authenticate users](guides/login/universal-vs-embedded). However, some situations may require that authentication forms be directly embedded in an application. Although not recommended, cross-origin authentication provides a way to do this. + +## What is cross-origin authentication? + +When authentication requests are made from your application (via the Lock widget or a custom login form) to Auth0, the user's credentials are sent to a domain which differs from the one that serves your application. Collecting user credentials in an application served from one origin and then sending them to another origin can present certain security vulnerabilities, including the possibility of a phishing attack. + +Auth0 provides a cross-origin authentication flow which makes use of [third-party cookies](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#Third-party_cookies). The use of third-party cookies allows Lock and Auth0's backend to perform the necessary checks to allow for secure authentication transactions across different origins. This helps to prevent phishing when creating a Single Sign-on experience with the Lock widget or a custom login form in your application and it also helps to create a secure login experience even if SSO is not the goal. + +::: note +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 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. +::: + +## Limitations + +Because cross-origin authentication is achieved using third-party cookies, disabling third-party cookies will make cross-origin authentication fail. Some browsers, such as the newest version of Firefox, disable third-party cookies by default, meaning that cross-origin authentication will not work for users on Firefox. The only way to make embedded login work for Firefox users is to use a custom domain, as described below. + +There are two approaches you can follow to remediate the issue: + +- Enable a [Custom Domain](/custom-domains) on your tenant and host your web application in a domain that has the same top-level domain as your Auth0 custom domain. For example, you host an application at `https://northwind.com` and set your Auth0 custom domain as `https://login.northwind.com`. This way the cookies are no longer third-party (because both your Auth0 tenant and your application are using the same top-level domain), and thus, are not blocked by browsers. +- Provide a [cross-origin verification page](#create-a-cross-origin-verification-page) that will make cross-origin authentication work in a **limited number of browsers** even with third-party cookies disabled (see the [browser testing information](#browser-testing-support) below). + +These issues are another reason why the more practical solution is to use [Universal Login](/universal-login). + +## Configure your application for cross-origin authentication + +Configuring your application for cross-origin authentication is a process that requires a few steps: + +1. Ensure that the **Allowed Web Origins** field in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) is set to the domain making the request. Note that the URLs specified for Allowed Web Origins **cannot** contain wildcards or relative paths after the domain. +1. Ensure that your application is using [Lock](/libraries/lock) 11 or higher, or [Auth0.js](/libraries/auth0js) version 9 or higher. +1. If you don't enable [Custom Domains](/custom-domains), you will need to create a page which uses auth0.js to act as a fallback for the cross-origin transaction. More information on setting up this page is provided below. + +## Create a cross-origin verification page + +There are some cases when third-party cookies will not be available. Certain browser versions do not support third party cookies and, if they do, there will be times that they will be disabled in a user's settings. You can use auth0.js in your application on a dedicated page to properly handle cases when third-party cookies are disabled. **This page must be served over SSL**. + +Using `crossOriginVerification` as a fallback will only work if the browser is on the support matrix as **Yes** under **Third-Party Cookies Disabled**. For some browsers, such as **Chrome**, **Opera**, and **Safari**, when third-party cookies are disabled, cross-origin authentication will not work at all unless you enable [Custom Domains](/custom-domains). + +::: note +**Safari's** configuration is labeled as "Prevent cross-site tracking" and uses [Intelligent Tracking Prevention](https://webkit.org/blog/7675/intelligent-tracking-prevention/). Unfortunately, this also prevents third-party cookies from being useful in authentication scenarios. Here's an example of how it affects [token renewal](/api-auth/token-renewal-in-safari). +::: + +Provide a page in your application which instantiates `WebAuth` from [auth0.js](/libraries/auth0js). Call `crossOriginVerification` immediately. The name of the page is at your discretion. + +```html + + + + + + +``` + +When third party cookies are not available, auth0.js renders an `iframe` to call a different cross-origin verification flow. + +Add the URL of this callback page to the **Cross-Origin Verification Fallback** field in your Application's settings in the [Dashboard](${manage_url}), under the **Advanced > OAuth** panel. + +For production environments, verify that the Location URL for the page does not point to localhost. + +::: note +See the [cross-origin auth sample](https://github.com/auth0/lock/blob/master/support/callback-cross-auth.html) for more information. +::: + +<%= include('../_includes/_co_authenticate_errors', { library : 'Auth0.js v9 (and Lock v11)'}) %> + +## Browser testing support + +The following browsers can use cross-origin authentication when third-party cookies are disabled: + +* Microsoft Internet Explorer +* Microsoft Edge + +<%= include('../_includes/_samesite_none') %> diff --git a/articles/custom-domains/_additional-steps.md b/articles/custom-domains/_additional-steps.md new file mode 100644 index 0000000000..b5c6c2894d --- /dev/null +++ b/articles/custom-domains/_additional-steps.md @@ -0,0 +1,3 @@ +## Additional steps for specific Auth0 features + +There are additional configuration steps you must complete depending on which Auth0 features you are using. See the [Configure Custom Domains for Specific Features](/custom-domains/additional-configuration) document for more information. \ No newline at end of file diff --git a/articles/custom-domains/_cloudflare-cname-flattening.md b/articles/custom-domains/_cloudflare-cname-flattening.md new file mode 100644 index 0000000000..3d1136b98d --- /dev/null +++ b/articles/custom-domains/_cloudflare-cname-flattening.md @@ -0,0 +1,3 @@ +::: panel Turn off Cloudflare CNAME Flattening +Cloudflare uses a feature called CNAME Flattening, which affects Auth0 verification and certificate renewal in the way that it handles DNS records. With CNAME flattening enabled, Auth0 will be unable to renew your certificates. For details, see [Cloudflare documentation](https://support.cloudflare.com/hc/en-us/articles/200169056-Understand-and-configure-CNAME-Flattening). +::: diff --git a/articles/custom-domains/_provide-domain-name.md b/articles/custom-domains/_provide-domain-name.md new file mode 100644 index 0000000000..8023559bba --- /dev/null +++ b/articles/custom-domains/_provide-domain-name.md @@ -0,0 +1,19 @@ +## Provide your domain name to Auth0 + +1. Go to [Dashboard > Tenant Settings](${manage_url}/#/tenant). +2. Select the **Custom Domains** tab. + + <% if (platform === "auth0") { %> + ![Tenant Settings](/media/articles/custom-domains/custom-domains.png) +3. Enter your custom domain in the provided box, and select **Auth0-managed certificates**. + <% } %> + + <% if (platform === "self") { %> + ![Tenant Settings](/media/articles/custom-domains/custom-domains-self-managed.png) +3. Enter your custom domain in the provided box. + <% } %> +4. Click **Add Domain**. + + ::: note + You can only add one domain per tenant even though the **Add Domain** button still appears after you add a domain. + ::: diff --git a/articles/custom-domains/_subscription.md b/articles/custom-domains/_subscription.md new file mode 100644 index 0000000000..6298b3c024 --- /dev/null +++ b/articles/custom-domains/_subscription.md @@ -0,0 +1,3 @@ +::: panel Feature availability +Auth0 custom domains are available with any paid [subscription plan](${manage_url}/#/tenant/billing/subscription). If you want to manage the SSL/TLS certificates yourself, you will need an **Enterprise** subscription. For more information refer to [Auth0 pricing plans](https://auth0.com/pricing). +::: diff --git a/articles/custom-domains/_warning-repeat-steps.md b/articles/custom-domains/_warning-repeat-steps.md new file mode 100644 index 0000000000..51c2581b83 --- /dev/null +++ b/articles/custom-domains/_warning-repeat-steps.md @@ -0,0 +1,3 @@ +::: warning +If you are unable to complete the verification process within three days, you'll need to repeat these steps. +::: \ No newline at end of file diff --git a/articles/custom-domains/additional-configuration.md b/articles/custom-domains/additional-configuration.md new file mode 100644 index 0000000000..fcbb1039dc --- /dev/null +++ b/articles/custom-domains/additional-configuration.md @@ -0,0 +1,200 @@ +--- +title: Configure Features to Use Custom Domains +description: Describes the configuration steps you might need to follow in order to set up custom domains, depending on the Auth0 features you are using +toc: true +topics: + - custom-domains +contentType: how-to +useCase: customize-domains +--- +# Configure Features to Use Custom Domains + +To configure Auth0 features to use your custom domain, you may need to complete additional steps depending on the features you are using. For example, you may need to make changes before you can use your custom domain in your login page or to call your APIs. + +If you have been using Auth0 for some time and decide to enable a custom domain, you will have to migrate your existing apps and update the settings as described below. Note that existing sessions created at `${account.namespace}` will no longer be valid once you start using your custom domain, so users will have to log in again. + +## Prerequisite + +You should have already configured and verified your custom domain. To learn how, see [Verify ownership](/custom-domains/auth0-managed-certificates#verify-ownership). + +## Features + +| **Feature** | **Section to read** | +|-|-| +| Universal Login with a customized login page | [Universal Login](#universal-login) | +| Lock embedded in your application | [Embedded Lock](#embedded-lock) | +| Auth0 SPA SDK, Auth0.js, or other Auth0 SDKs | [Auth0 SPA SDK, Auth0.js, and other SDKs](#auth0-spa-sdk-auth0-js-and-other-sdks) | +| Custom domain with Auth0 emails | [Use custom domains in emails](#use-custom-domains-in-emails) | +| Social identity providers | [Configure social identity providers](#configure-social-identity-providers) | +| G Suite connections with your custom domain | [Configure G Suite connections](#configure-g-suite-connections) | +| Issue Access Tokens for your APIs or access Auth0 APIs from your application | [APIs](#apis) | +| SAML Identity Providers | [Configure SAML identity providers](#configure-saml-identity-providers) | +| SAML applications | [Configure SAML applications](#configure-saml-applications) | +| WS-Fed applications | [Configure WS-Fed applications](#configure-ws-fed-applications) | +| Azure AD connections | [Configure Azure AD connections](#configure-azure-ad-connections) | +| ADFS connections | [Configure ADFS connections](#configure-adfs-connections) | +| AD/LAP connections with Kerberos support | [Configure AD/LAP connections](#configure-ad-ldap-connections) | + +## Universal Login + +If you use [Universal Login](/universal-login) and you have customized the login page, you must update the code to use your custom domain. If you use the **default** login page without customization, you do not need to make any changes. + +If you are using [Lock](/libraries/lock), you must set the `configurationBaseUrl` and `overrides` options as seen in the following sample script: + +```js +var lock = new Auth0Lock(config.clientID, config.auth0Domain, { + //code omitted for brevity + configurationBaseUrl: config.clientConfigurationBaseUrl, + overrides: { + __tenant: config.auth0Tenant, + __token_issuer: config.authorizationServer.issuer + }, + //code omitted for brevity +}); +``` + +If you use [Auth0.js](/libraries/auth0js) on the Universal Login page, you must set the `overrides` option. + +```js +var webAuth = new auth0.WebAuth({ + clientID: config.clientID, + domain: config.auth0Domain, + //code omitted for brevity + overrides: { + __tenant: config.auth0Tenant, + __token_issuer: config.authorizationServer.issuer + }, + //code omitted for brevity +}); +``` + +::: note +For most, the Auth0.js and Lock libraries retrieve the tenant name (required for `/usernamepassword/login`) and the issuer (required for `id_token` validation) from the domain. However, if you're a Private Cloud customer who uses a proxy or a custom domain name where the domain name is different from the tenant/issuer, you can use `__tenant` and `__token_issuer` to provide your unique values. +::: + +## Embedded Lock + +If you use [Lock](/libraries/lock) v11 embedded in your application, you must update the code to use your custom domain when initializing Lock. You will also need to set the `configurationBaseUrl` to the appropriate CDN URL. + +::: 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. +::: + +```js +var lock = new Auth0Lock('${account.clientId}', 'YOUR_CUSTOM_DOMAIN', { + //code omitted for brevity + configurationBaseUrl: 'https://cdn.us.auth0.com' + //code omitted for brevity +}); +``` + +## Auth0 SPA SDK, Auth0.js, and other SDKs + +If you use the [Auth0 SPA SDK](/libraries/auth0-spa-js), [Auth0.js](/libraries/auth0js), or [other SDKs](/support/matrix#auth0-sdks), you will have to initialize the SDK using your custom domain. For example, if you are using the Auth0.js SDK, you must set the following: + +```js +webAuth = new auth0.WebAuth({ + domain: 'YOUR_CUSTOM_DOMAIN', + clientID: '${account.clientId}' +}); +``` + +And for the Auth0 SPA SDK: + +```js +const auth0 = await createAuth0Client({ + domain: 'YOUR_CUSTOM_DOMAIN', + client_id: '${account.clientId}' +}); +``` + +::: note +Note that the Management API only accepts Auth0 domains. If you use a custom domain and also intend to perform [Management API actions with Auth0.js](/libraries/auth0js/v9#user-management), you must instantiate a new copy of `webAuth` using your Auth0 domain. +::: + +## Use custom domains in emails + +If you want to use your custom domain with your Auth0 emails, you must enable this feature. + +Go to [Dashboard > Tenant Settings > Custom Domains](${manage_url}/#/tenant/custom_domains), and enable the **Use Custom Domain in Emails** toggle. When the toggle is green, this feature is enabled. + +![Use Custom Domain in Emails toggle](/media/articles/custom-domains/cd_email_toggle.png) + +## Configure social identity providers + +If you want to use your custom domain with social identity providers, you must update your applications' [Allowed Callback URLs](${manage_url}/#/applications/${account.clientId}/settings) to include your custom domain (such as `https://login.northwind.com/login/callback`). + +::: warning +You cannot use [Auth0 developer keys](/connections/social/devkeys) with custom domains unless you are using the [New Universal Login Experience](/universal-login/new). +::: + +## Configure G Suite connections + +If you want to use your custom domain with G Suite connections, you must update the Authorized redirect URI in your OAuth Client Settings. In the Google Developer Console, go to **Credentials**, choose your OAuth client in the list, and you will see a settings page with the app Client ID, secret, and other fields. In the **Authorized redirect URIs** field, add a URL in the format `https:///login/callback` that includes your custom domain (such as `https://login.northwind.com/login/callback`). + +## APIs + +If you use Auth0 with a custom domain to issue Access Tokens for your APIs, you must validate the JWT issuer(s) against your custom domain. For example, if you use the [express-jwt](https://github.com/auth0/express-jwt) middleware, you must make the following change: + +```js +app.use(jwt({ + issuer: 'https://', + algorithms: ["RS256"], + //code omitted for brevity +})); +``` + +## Configure SAML identity providers + +To use your custom domain with SAML Identity Providers (IdPs), you must update your **Assertion Consumer Service (ACS) URL(s)** with the Identity Provider(s). Depending on what is supported by the IdP, you can do this in one of two ways: + +1. You can get the service provider metadata from Auth0 at `https:///samlp/metadata?connection=`. This will include the updated ACS URL. Then, you must manually update this value in your IdP(s) settings. This change to your IdP(s) must happen at the same time as you begin using your custom domain in your applications. This can pose a problem if there are multiple IdPs to configure. + +2. If supported by the IdP, you can use signed requests to fulfill this requirement: + + - Download the signing certificate from `https://.auth0.com/pem`. Note that `https://.com/pem` will return the same certificate + - Give the certificate to the IdP(s) to upload. This enables the IdP to validate the signature on the `AuthnRequest` message that Auth0 sends to the IdP + - The IdP will import the certificate and, if necessary, signature verification should be enabled (exact steps vary by IdP) + - Turn on the **Sign Request** toggle in the Dashboard under **Connections > Enterprise > SAML > CONNECTION**. This will trigger Auth0 to sign the SAML `AuthnRequest` messages it sends to the IdP. + +Once this is done, and you start using your custom domain when you initiate an authentication request in your application, the IdP will receive that custom domain in your signed request. Because your application’s signed request is trusted, the IdP should automatically override whatever was configured as your ACS URL and replace it with the value sent in the signed request. However, there are IdPs that do **not** accept the ACS URL in the signed request, so you must check with yours first to confirm whether this is supported or not. + +If this is supported, it will prevent you from having to change one or many IdP settings all at the same time and allow you to prepare them to accept your signed requests ahead of time. You can then change the statically configured ACS URL in your IdP settings at a later date as well. + +Note that if your SAML identity provider is configured to use your custom domain, testing the connection via the **Try** button in the Dashboard will **not** work and the default links for downloading metadata from Auth0 will always show the default domain, not the custom domain. + +If you have an IdP-initiated authentication flow, you will need to update the IdP(s) and your application(s) at the same time to use the custom domain. + +## Configure SAML applications + +If you want to use your custom domain with SAML applications (when Auth0 is the IdP), you must update your service provider with new identity provider metadata from Auth0. You can obtain the updated metadata reflecting the custom domain from `https:///samlp/metadata/`. Note that the issuer entity ID for the assertion returned by Auth0 will change when using a custom domain (from something like `urn:northwind.auth0.com` to one with the custom domain, such as `urn:login.northwind.com`). + +If you have an IdP-initiated authentication flow, you will need to update the URL used to invoke the IdP-initiated authentication flow to reflect the custom domain. Instead of `https://.auth0.com/samlp/`, you should use `https:///samlp/`. + +If you use the Auth0 APIs, such as the Management API, the API identifier will use your default tenant domain name (such as `https://${account.namespace}/userinfo` and `https://${account.namespace}/api/v2/`). + +## Configure WS-Fed applications + +If you want to use your custom domain with WS-Fed applications 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`. + +## Configure Azure AD connections + +If you want to use your custom domain with Azure AD connections, you must update the Allowed Reply URL in your Azure AD settings. In your Azure Active Directory, go to **Apps registrations** and select your app. Then click **Settings -> Reply URLs** and add a URL with your custom domain in the format `https:///login/callback` (such as `https://login.northwind.com/login/callback`). + +## Configure ADFS connections + +If you want to use your custom domain with ADFS connections, you must update the endpoint in your ADFS settings. This will need to be updated to use your custom domain in the callback URL in the format `https:///login/callback` (such as `https://login.northwind.com/login/callback`). + +## Configure AD/LDAP connections + +If you do not need Kerberos support, AD/LDAP connections do not require further configuration. + +In order to use AD/LDAP connections with Kerberos support, you will need to update the ticket endpoint to work with the custom domain. As mentioned in the [Auth0 AD/LDAP connector documentation](/connector/modify#point-an-ad-ldap-connector-to-a-new-connection), the `config.json` file needs to be modified, with the `PROVISIONING_TICKET` value changed to use your custom domain in the format `https:///p/ad/jUG0dN0R`. + +Once this change is saved, you need to restart the AD/LDAP Connector service for the change to take effect. + +## Keep reading + +* [Configure Custom Domains with Auth0-Managed Certificates](/custom-domains/auth0-managed-certificates) +* [Configure Custom Domains with Self-Managed Certificates](/custom-domains/self-managed-certificates) +* [Troubleshooting Custom Domains](/custom-domains/troubleshoot) diff --git a/articles/custom-domains/auth0-managed-certificates.md b/articles/custom-domains/auth0-managed-certificates.md new file mode 100644 index 0000000000..e71cbcdc37 --- /dev/null +++ b/articles/custom-domains/auth0-managed-certificates.md @@ -0,0 +1,64 @@ +--- +title: Configure Custom Domains with Auth0-Managed Certificates +description: Learn how to configure custom domains where Auth0 manages the SSL/TLS certificates. +topics: + - custom-domains + - certificates + - SSL/TLS-certificates +contentType: how-to +useCase: + - configure-customize-domains + - configure-auth0-managed-certificates +--- + +# Configure Custom Domains with Auth0-Managed Certificates + +<%= include('./_subscription') %> + +If you want Auth0 to manage the certificates for your custom domain, you only need to add a CNAME record on the domain. Auth0 validates the record and then generates the certificate on Auth0 servers. These certificates are renewed automatically every three months. You can configure this easily, and you won't have to maintain the certificates yourself. + +To set up your custom domain using Auth0-managed certificates, you must provide your domain name to Auth0 and verify that you own that domain. Once verified, you will need to configure your Auth0 features to start using your custom domain. + +<%= include('./_provide-domain-name', { platform: 'auth0' }) %> + +## Verify ownership + +Before you can use the domain with Auth0, you'll need to verify that you own it. + +1. Go to [Dashboard > Tenant Settings](${manage_url}/#/tenant), and add the CNAME verification record listed in the Dashboard to your domain's DNS record. + + ![DSN Record](/media/articles/custom-domains/auth0-managed.png) + +2. Click **Verify** to proceed. + + It may take a few minutes before Auth0 is able to verify your CNAME record, depending on your DNS settings. If Auth0 was able to verify your domain name, you'll see a confirmation window. This means the verification process is complete, and within 1 to 2 minutes, your custom domain should be ready to use. + +::: panel Add the CNAME verification record to your domain's DNS record +Once added, the CNAME record must be present at all times to avoid issues during certificate renewal. If your DNS provider enables a proxy on the CNAME record by default, it will leave the custom domain in a pending state indefinitely. You may need to check your DNS provider settings and disable the proxy. The following steps may vary for your domain host provider. + +1. Log in to your domain management service. + +2. Create a new record. + + | Parameter | Value | + | -- | -- | + | **Record type** | **CNAME** | + | **Name** | Enter your custom domain name (such as **login.northwind.com**). | + | **Time to Live (TTL)** | Use default value | + | **Value** | Paste in the **CNAME** value provided by the Auth0 Dashboard for your domain's DNS record. | + +3. When done, save your record. +::: + +If Auth0 was able to verify your domain name, you'll see a confirmation window. This means the verification process is complete, and within 1 to 2 minutes, your custom domain should be ready to use. + + ![Domain Verification](/media/articles/custom-domains/domain-verification.png) + +<%= include('./_warning-repeat-steps') %> + +<%= include('./_additional-steps') %> + +## Keep reading + +* [Troubleshooting Custom Domains](/custom-domains/troubleshoot) +* [Configure Custom Domains with Self-Managed Certificates](/custom-domains/self-managed-certificates) diff --git a/articles/custom-domains/index.md b/articles/custom-domains/index.md new file mode 100644 index 0000000000..2c1e617b13 --- /dev/null +++ b/articles/custom-domains/index.md @@ -0,0 +1,105 @@ +--- +title: Custom Domains +description: Understand how Auth0 custom domains work so that you can map your tenant domain to a domain of your choosing instead of redirecting users to Auth0's domain. +topics: + - custom-domains + - whitelisting + - custom-domain features + - certificates +contentType: + - index + - concept +useCase: customize-domains +--- +# Custom Domains + +<%= include('./_subscription') %> + +Auth0 allows you to map the domain for your tenant to **one custom domain** of your choosing. This allows you to maintain a consistent experience for your users by keeping them on your domain instead of redirecting or using Auth0's domain. You must register and own the domain name to which you are mapping your Auth0 domain. For example, if your Auth0 domain is **northwind.auth0.com**, you can have your users to see, use, and remain on **login.northwind.com**. + +We recommend that you use custom domains with Universal Login for the most seamless and secure experience for your users. See [Universal Login](/universal-login) to determine if your use case requires custom domains. + +## Token issuance + +Auth0 issues tokens with the **iss** claim of whichever domain you used with the request. For example: + +| If you use | **iss** claim value with custom domain | +| -- | -- | +| `https://northwind.auth0.com/authorize...` | `https://northwind.auth0.com/` | +| `https://login.northwind.com/authorize...` | `https://login.northwind.com/` | + +::: note +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). +::: + +## Metadata endpoints + +Auth0 implements certain metadata endpoints to ease interoperability and configuration of third-party IdPs and +applications. When these metadata contain URIs pointing back to Auth0, the URL can either use the Auth0 subdomain or +your custom domain depending on the hostname used to request the metadata. + +| If you use | Reference inside metadata | +| -- | -- | +| `https://northwind.auth0.com/.well-known/...` | `https://northwind.auth0.com/...` | +| `https://northwind.auth0.com/samlp/metadata/...` | `https://northwind.auth0.com/...` | +| `https://login.northwind.com/samlp/metadata/...` | `https://login.northwind.com/...` | + +This applies to the following features: +- [OpenID Connect Discovery](/protocols/oidc/openid-connect-discovery) +- [Auth0 as a SAML SP](/protocols/saml/saml-sp-generic) +- [Auth0 as a SAML Identity Provider](/protocols/saml/saml-idp-generic) + +## Whitelisting + +Be aware that Auth0 does not provide a static list of IP addresses because they are subject to change. We recommend that you whitelist your custom domain instead. + +## Exceptions + +You can use either your `${account.namespace}` domain to access Auth0 or your custom domain. There are, however, a few exceptions: + +- If you use embedded Lock or an SDK, the configuration is pre-defined to use either your custom domain or the `${account.namespace}` domain, so you have to use one or the other. +- If you start a session in `${account.namespace}`, and go to `custom-domain.com`, the user will have to login again. + +## Auth0 features that use custom domains + +The following Auth0 features can use custom domains. See [Configure Custom Domains for Specific Features](/custom-domains/additional-configuration) for details. + +::: note +Features not in the list are **not supported** by Auth0 with custom domains. +::: + +| Features/Flows | Details | +| -- | -- | +| Universal Login | For a seamless and secure user experience | +| MFA | All factors | +| Guardian | MFA Widget version 1.3.3/Guardian.js version 1.3.0 or later | +| Emails | Links included in the emails use your custom domain | +| Connections | Database, social, G Suite, Azure AD, ADFS, AD/LDAP | +| Lock | Version 11 with cross-origin authentication | +| Passwordless | With Universal Login (The email link sent using the custom domain if the option is enabled in **Dashboard > Tenant Settings > Custom Domains**.) | +| SAML | Connections and applications | +| WS-Federation | Auth0 as identity provider using WS-Fed add-on | +| OAuth 2.0/OIDC-Compliant flows | Using the [`/authorize`](/api/authentication#authorize-application) and [`/oauth/token`](/api/authentication#get-token) endpoints | + +## Certificate management options + +### Auth0-managed certificates + +With the [Auth0-managed certificate approach](/custom-domains/auth0-managed-certificates), Auth0 obtains certificates for your domain and then manages the SSL handshake directly with the client. + +### Self-managed certificates + +With the [self-managed certificate approach](/custom-domains/self-managed-certificates), you are completely responsible for handling the SSL certificates and setting up and managing a reverse proxy for content to be sent to Auth0. Auth0 does not negotiate SSL with the end user’s client, but with the proxy. The proxy in turn negotiates SSL with the end user. To prevent someone from trying to use your Auth0 account from a domain you don’t own, Auth0 needs to validate that the domain belongs to you. Therefore, you need to send Auth0 a header (`cname-api-key`) to validate. You must be an **Enterprise** customer to use this option. + +## Keep reading + +* [Configure Custom Domains for Specific Features](/custom-domains/additional-configuration) +* [Universal Login](/universal-login) +* [Multi-factor Authentication](/mfa) +* [Emails in Auth0](/email) +* [Connections](/identityproviders) +* [Lock v11 for Web](/libraries/lock/v11) +* [Passwordless Authentication](/api-auth/passwordless) +* [SAML](/protocols/saml) +* [WS-Federation](/protocols/ws-fed) +* [Which OAuth 2.0 Flow Should I Use?](/api-auth/which-oauth-flow-to-use) diff --git a/articles/custom-domains/self-managed-certificates.md b/articles/custom-domains/self-managed-certificates.md new file mode 100644 index 0000000000..0d5110075d --- /dev/null +++ b/articles/custom-domains/self-managed-certificates.md @@ -0,0 +1,127 @@ +--- +title: Configure Custom Domains with Self-Managed Certificates +description: Learn how to configure custom domains where you are responsible for SSL/TLS certificates, the reverse proxy to handle SSL termination, and forwarding requests to Auth0. +topics: + - custom-domains + - certificates + - reverse-proxy + - SSL/TLS-certificates +contentType: how-to +useCase: + - configure-customize-domains + - forward-requests-to-auth0 + - configure-reverse-proxy + - configure-self-managed-certificates +--- +# Configure Custom Domains with Self-Managed Certificates + +<%= include('./_subscription') %> + +If you choose to manage the certificates for your custom domains yourself, it requires multiple DNS records on the domain. You have to purchase or provide the certificates from any known Certificate Authority and manage the renewals yourself. You will also need a reverse proxy, where the certificate will be installed. Once the domain is verified, we will accept traffic from the proxy. + +Choose this option to: + +* Have more control of your certificates (such as choosing your own CA or certificate expiration). +* Enable additional monitoring over your API calls to Auth0. + +To set up your custom domain using self-managed certificates, you need to provide your domain name to Auth0, verify that you own that domain, and configure the reverse proxy. Once your custom domain has been set up, you will need to configure your Auth0 features to start using your custom domain. + +<%= include('./_provide-domain-name', { platform: 'self' }) %> + +## Verify ownership + +Before you can use the domain with Auth0, you'll need to verify that you own it. + +1. Go to [Dashboard > Tenant Settings](${manage_url}/#/tenant), and copy the TXT verification record listed in the Dashboard to your domain's DNS record. + + ![DSN Record](/media/articles/custom-domains/self-managed.png) + +::: panel Add the TXT verification record to your domain's DNS record +The following steps may vary for your domain host provider. + +1. Log in to your domain management service. + +2. Create a new record, and save: + + | Parameter | Value | + | -- | -- | + | **Record type** | **TXT** | + | **Name** | Enter your custom domain name (such as **login.northwind.com**). | + | **Time to Live (TTL)** | Use default value | + | **Value** | Paste in the **TXT** value provided by the Auth0 Dashboard for your domain's DNS record. | +::: + + It may take a few minutes before Auth0 can verify your TXT record, depending on your DNS settings. + +2. Click **Verify** to proceed. + + If Auth0 was able to verify your domain name, you'll see a confirmation window. + + ::: note + Save the information provided in this window, specifically the `cname-api-key` value, since this is the **only** time you'll see this value. + ::: + + ![Domain Verification](/media/articles/custom-domains/api-key.png) + + The verification process is complete, and within 1 to 2 minutes, your custom domain should be ready to use. + +<%= include('./_warning-repeat-steps') %> + +## Configure reverse proxy + +The reverse proxy server retrieves resources on behalf of your client from one or more servers. These resources are then returned to the client, appearing as if they originated from the proxy server itself. + +You can use a service such as [Cloudflare](/custom-domains/set-up-cloudflare), [Azure CDN](/custom-domains/set-up-azure-cdn), or [AWS Cloudfront](/custom-domains/set-up-cloudfront) and configure settings for your custom domain. You will add the new CNAME value to your DNS for your custom domain pointing to the reverse proxy server domain name for distribution. + +1. After you've created the reverse proxy settings on your service, go to [Dashboard > Tenant Settings](${manage_url}/#/tenant) **Custom Domains** tab. + +2. Add a new CNAME record to your DNS for your custom domain pointing to the service domain name for your distribution. You can find this by looking for the **Distribution ID** on your reverse proxy server configuration. + + ::: note + Once added, the CNAME record must be present at all times to avoid issues during certificate renewal. + ::: + +3. The way you configure the proxy server will vary depending on the service you use. You will likely need to configure the following types of settings: + +* [Distribution](#distribution-settings) +* [Origin custom headers](#origin-custom-header-settings) +* [Default cache behaviour](#default-cache-behavior-settings) + +### Distribution settings + + | Setting | Value | + | - | - | + | Origin Domain Name | Set this to the **Origin Domain Name** value obtained from the Auth0 Dashboard during the Custom Domains setup process. | + | Origin ID | A description for the origin. This value lets you distinguish between multiple origins in the same distribution and therefore must be unique. | + | Origin Protocol Policy | Set to `HTTPS Only`. | + | Alternate Domain Names (CNAMEs) | Set to your custom domain name (the same one your configured in the Auth0 Dashboard). | + +### Origin custom header settings + + | Setting | Value | + | -- | -- | + | Header Name | Set to `cname-api-key`. | + | Value | Set to the CNAME API Key value that you were given immediately after you verified ownership of your domain name with Auth0. | + +### Default cache behavior settings + + | Setting | Value | + | - | - | + | Viewer Protocol Policy | Select **Redirect HTTP to HTTPS**. | + | Allowed HTTP Methods | Select **GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE**. | + | Cache Based on Selected Request Headers | Select **Whitelist**. | + | Whitelist Headers | Enter `User-Agent`, and click **Add Custom >>** to add the custom whitelist header. Do the same for `Origin` and `Referer` headers. | + | Forward Cookies | Select **All**. | + | Query String Forwarding and Caching | Select **Forward all, cache based on all**. | + +<%= include('./_additional-steps') %> + +<%= include('./_cloudflare-cname-flattening') %> + +## Keep reading + +* [Troubleshooting Custom Domains](/custom-domains/troubleshoot) +* [Configure Cloudflare for Use as Reverse Proxy](/custom-domains/set-up-cloudflare) +* [Configure AWS CloudFront for Use as Reverse Proxy](/custom-domains/set-up-cloudfront) +* [Configure Azure CDN for Use as Reverse Proxy](/custom-domains/set-up-azure-cdn) +* [Configure Custom Domains with Auth0-Managed Certificates](/custom-domains/auth0-managed-certificates) diff --git a/articles/custom-domains/set-up-azure-cdn.md b/articles/custom-domains/set-up-azure-cdn.md new file mode 100644 index 0000000000..b0a1a6d43e --- /dev/null +++ b/articles/custom-domains/set-up-azure-cdn.md @@ -0,0 +1,60 @@ +--- +name: Configure Azure CDN for Use as Reverse Proxy +description: Learn how to set up Azure CDN for use as the custom domain proxy for Auth0. +topics: + - custom-domains + - azure + - cdn + - reverse-proxy +contentType: how-to +useCase: + - customize-domains + - self-managed-certificates +--- + +# Configure Azure CDN for Use as Reverse Proxy + +<%= include('./_subscription') %> + +To set up Azure CDN as a reverse proxy, an Azure CDN Premium plan is required. + +1. Complete the steps on [Configure Custom Domains with Self-Managed Certificates](/custom-domains/self-managed-certificates) if you haven't already. Make note of the **Origin Domain Name** and **cname-api-key** values since you'll need these later. +2. Login to the [Azure Portal](https://portal.azure.com/). +3. [Create a new Azure CDN Profile](https://docs.microsoft.com/en-us/azure/cdn/cdn-create-new-endpoint#create-a-new-cdn-profile). +4. [Create a new Azure CDN endpoint](https://docs.microsoft.com/en-us/azure/cdn/cdn-create-new-endpoint#create-a-new-cdn-endpoint) using the CDN Profile you just created. For the CDN endpoint settings, use the following values: + + | Setting | Value | + |---------|-------| + | Name | We recommend naming your CDN endpoint like your custom domain name, replacing dots with dashes. For example: **login-mydomain-com.azureedge.net**. | + | Origin type | Select **Custom Origin** | + | Origin hostname | Enter `${account.tenant}..edge.tenants.auth0.com`, making sure to replace `` with the custom domain ID from the **Origin Domain Name** you received from Auth0. If your tenants are not in the US region, use one of the following:
        • EU: `${account.tenant}..edge.tenants.eu.auth0.com`
        • AU: `${account.tenant}..edge.tenants.au.auth0.com`
        | + | Origin path | Leave blank. | + | Origin host header | Use the name you provided for the Origin hostname. | + | Protocol | Disable HTTP so that only HTTPS is enabled. | + +5. [Add your custom domain to your Azure CDN endpoint](https://docs.microsoft.com/en-us/azure/cdn/cdn-map-content-to-custom-domain). +6. [Configure HTTPS for your Azure CDN custom domain](https://docs.microsoft.com/en-us/azure/cdn/cdn-custom-ssl?tabs=option-1-default-enable-https-with-a-cdn-managed-certificate). This process requires you to verify ownership of the domain. Once done, it may take up to 6 hours to deploy the certificate to all of the CDN pop locations. +7. Set up the configuration for the custom domain communication with Auth0 using the [Azure CDN Rules Engine](https://docs.microsoft.com/en-us/azure/cdn/cdn-verizon-premium-rules-engine). Create [a new Azure CDN Rule](https://docs.microsoft.com/en-us/azure/cdn/cdn-verizon-premium-rules-engine#tutorial) with the following settings: + + | Setting | Value | + |---------|-------| + | Name/Description | Auth0 Custom Domain | + | Type of requests | Select the **Edge CName** option, then select your custom domain name from the list. | + +8. Add the following **Features** to your Azure CDN Rule: + + | Setting | Value | + |---------|-------| + | Bypass Cache | **Enabled** | + | Modify Client Request Header | Select **Override**, enter **cname-api-key** for the name, and enter the CNAME API Key provided by Auth0 as the value. + +::: note +We recommend creating another Azure CDN Rule to deny the usage of the **azureedge.net** CNAME. +::: + +9. Once the Azure CDN Rule is approved, the status will change from Pending XML to Active XML. At this point, Azure CDN will be publishing the rules and certificates. When Azure finishes processing all changes, you can use your custom domain. + +## Keep reading + +* [Troubleshooting Custom Domains](/custom-domains/troubleshoot) +* [Configure Custom Domains with Self-Managed Certificates](/custom-domains/self-managed-certificates) diff --git a/articles/custom-domains/set-up-cloudflare.md b/articles/custom-domains/set-up-cloudflare.md new file mode 100644 index 0000000000..8f03e3c4c0 --- /dev/null +++ b/articles/custom-domains/set-up-cloudflare.md @@ -0,0 +1,61 @@ +--- +name: Configure Cloudflare for Use as Reverse Proxy +description: Learn how to set up Cloudflare for use as the custom domain proxy for Auth0. +topics: + - custom-domains + - cloudflare + - reverse-proxy +contentType: how-to +useCase: + - customize-domains + - self-managed-certificates +--- + +# Configure Cloudflare for Use as Reverse Proxy + +<%= include('./_subscription') %> + +To set up Cloudflare as a reverse proxy, a Cloudflare Enterprise Plan with the following features is required: + +* Host Header Override: [Using Page Rules to Re-Write Host Headers (Cloudflare Support)](https://support.cloudflare.com/hc/en-us/articles/206652947-Using-Page-Rules-to-Re-Write-Host-Headers) +* True-Client-IP Header: [What is True-Client-IP? (Cloudflare Support)](https://support.cloudflare.com/hc/en-us/articles/206776727-What-is-True-Client-IP-) + +<%= include('./_cloudflare-cname-flattening') %> + +1. Complete the steps on [Configure Custom Domains with Self-Managed Certificates](/custom-domains/self-managed-certificates) if you haven't already. Make note of the **Origin Domain Name** and **cname-api-key** values since you'll need these later. +2. [Configure a CNAME setup](https://support.cloudflare.com/hc/en-us/articles/360020615111-Configuring-a-CNAME-setup) with Cloudflare. +3. Once Cloudflare has verified your domain, log in to the [Cloudflare Dashboard](https://dash.cloudflare.com/login). +4. [Create a new Cloudflare Page Rule](https://support.cloudflare.com/hc/en-us/articles/200172336-Creating-Page-Rules) with the following settings: + + | Setting | Value | + |---------|-------| + | Host Header Override | Enter `${account.tenant}..edge.tenants.auth0.com`, replacing `` with the custom domain ID from the **Origin Domain Name** you received from Auth0. If your tenants are not in the US region, use one of the following:
        • EU: `${account.tenant}..edge.tenants.eu.auth0.com`
        • AU: `${account.tenant}..edge.tenants.au.auth0.com`
        | + | True-Client-IP | Select **Enable**. | + +5. Next, create and deploy a new [Cloudflare Worker](https://developers.cloudflare.com/workers/) for the configured CNAME using the following script. Replace `` below with the **cname-api-key** you received from Auth0: + + ```js + addEventListener('fetch', event => { + event.respondWith(handleRequest(event.request)) + }) + + async function handleRequest(request) { + request = new Request(request) + request.headers.set('cname-api-key', '') + return await fetch(request) + } + ``` + +## Configure Auth0 + +Once you've configured Cloudflare, you'll need to Enable **True-Client-IP** header using the management API [/api/v2/custom-domains/{id}](https://auth0.com/docs/api/management/v2#!/Custom_Domains/patch_custom_domains_by_id) +```curl +curl -X PATCH -H "Content-Type: application/json" -d '{"custom_client_ip_header":"true-client-ip"}' https://login.auth0.com/api/v2/custom-domains/{id} + +``` + + +## Keep reading + +* [Troubleshooting Custom Domains](/custom-domains/troubleshoot) +* [Configure Custom Domains with Self-Managed Certificates](/custom-domains/self-managed-certificates) diff --git a/articles/custom-domains/set-up-cloudfront.md b/articles/custom-domains/set-up-cloudfront.md new file mode 100644 index 0000000000..54fbcfcf7b --- /dev/null +++ b/articles/custom-domains/set-up-cloudfront.md @@ -0,0 +1,73 @@ +--- +name: Configure AWS CloudFront for Use as Reverse Proxy +description: Learn how to configure AWS CloudFront for use as the custom domain proxy for Auth0. +topics: + - custom-domains + - aws + - cloudfront + - reverse-proxy +contentType: how-to +useCase: + - customize-domains + - self-managed-certificates +--- +# Configure AWS CloudFront for Use as Reverse Proxy + +<%= include('./_subscription') %> + +You can configure AWS CloudFront for use as the reverse proxy with custom domain names for your Auth0 tenant. + +1. Log in to AWS, and navigate to [CloudFront](https://console.aws.amazon.com/cloudfront). + + ![Cloudfront Getting Started](/media/articles/custom-domains/aws/cloudfront.png) + +2. Click **Create Distribution**. + +3. You can choose the delivery method for your content. Click **Get Started** under the **Web** section. + + ![Select Delivery Method](/media/articles/custom-domains/aws/delivery-method.png) + +4. Configure your distribution settings. Under **Origin Settings**, here are the values you'll need to change: + + | Setting | Value | + | - | - | + | Origin Domain Name | Set this to the **Origin Domain Name** value obtained from the Auth0 Dashboard during the Custom Domains setup process | + | Origin ID | A description for the origin. This value lets you distinguish between multiple origins in the same distribution and therefore must be unique. | + | Origin Protocol Policy | Set to `HTTPS Only` | + | Alternate Domain Names (CNAMEs) | Set to your custom domain name (the same one your configured in the Auth0 Dashboard) | + | SSL Certificate | Set to the SSL Certificate for your custom domain stored in AWS Certificate Manager (ACM) in the US East(N. Virginia) Region or in IAM. | + + ![Create Distribution](/media/articles/custom-domains/aws/create-distribution.png) + +5. Provide information on the **Origin Custom Headers** (the **Header Name** and **Value** fields appear only after you've provided an **Origin Domain Name**): + + | Setting | Value | + | - | - | + | Header Name | Set to `cname-api-key` | + | Value | Set to the CNAME API Key value that you were given immediately after you verified ownership of your domain name with Auth0 | + + ![Origin Custom Headers](/media/articles/custom-domains/aws/origin-custom-headers.png) + +6. Configure the **Default Cache Behavior Settings**. Here are the values you'll need to change: + + | Setting | Value | + | - | - | + | Viewer Protocol Policy | Select **Redirect HTTP to HTTPS** | + | Allowed HTTP Methods | Select **GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE** | + | Cache Based on Selected Request Headers | Select **Whitelist** | + | Whitelist Headers | Enter `User-Agent` and click **Add Custom >>** to add the custom whitelist header. Do the same for `Authorization`, `Origin`, `Referer` and `Accept` headers. | + | Forward Cookies | Select **All** | + | Query String Forwarding and Caching | Select **Forward all, cache based on all** | + +7. Scroll to the bottom of the page and click **Create Distribution**. + + You'll see your newly-created distribution in your CloudFront Distributions list. Note that the Status will reflect `In progress` until the distribution is Deployed. + + ![Cloudfront Distributions](/media/articles/custom-domains/aws/distributions.png) + +8. Add a new CNAME record to your DNS for your custom domain pointing to the CloudFront Domain Name for your Distribution. This can be found by clicking on your Distribution ID, under the General tab, Domain Name (for example, `e2zwy42nt1feu7.cloudfront.net`). + +## Keep reading + +* [Troubleshooting Custom Domains](/custom-domains/troubleshoot) +* [Configure Custom Domains with Self-Managed Certificates](/custom-domains/self-managed-certificates) diff --git a/articles/custom-domains/troubleshoot.md b/articles/custom-domains/troubleshoot.md new file mode 100644 index 0000000000..d9139d3eb9 --- /dev/null +++ b/articles/custom-domains/troubleshoot.md @@ -0,0 +1,64 @@ +--- +title: Troubleshoot Custom Domains +description: Learn how to troubleshoot issues with custom domains. +topics: + - custom-domains + - certificates +contentType: reference +useCase: + - configure-customize-domains + - configure-auth0-managed-certificates +--- + +# Troubleshoot Custom Domains + +If you are seeing errors, take a look at this video on common issues with Custom Domains, or refer to the below sections for troubleshooting steps for specific scenarios. + + + +## Custom domain is still pending verification + +It can take up to 48 hours for the DNS to be propagated. + +If you continue to see this error in the Dashboard, make sure that the CNAME record is properly configured in your domain management service. You can confirm the configuration of your CNAME record using: + +* A tool like [Mxtoolbox](https://mxtoolbox.com/DNSLookup.aspx) or [Google](https://dns.google.com) +* The `dig` command in your terminal + +Ensure that the domain name is not already associated with an A record. + +Make sure that no errors were made when typing or copying the CNAME record's domain name or value. + +## Cloudflare CNAME Flattening + +CNAME Flattening affects the Auth0 verification and certificate renewal processes due to the way it handles DNS records. We recommend turning off CNAME Flattening unless it's strictly necessary, according to the [Cloudflare documentation](https://support.cloudflare.com/hc/en-us/articles/200169056-Understand-and-configure-CNAME-Flattening). + +## "You should not be hitting this endpoint" +If you see this error when configuring a custom domain, you must perform [additional configuration](/custom-domains/additional-configuration), which varies depending on your setup. + +## "Service not found" + +If your application issues an `/authorize` request with `audience=https://login.northwind.com/userinfo`, the server will return a `Service not found: https://login.northwind.com/userinfo` error. This is because even if you set a custom domain the API identifier for the `/userinfo` endpoint remains `https://{YOUR_ORIGINAL_AUTH0_DOMAIN}/userinfo`. + +Similarly, using your custom domain in calls to the [Management API](/api/management/v2) will error for the same reason. + +To fix this your app should instead use `audience=https://{YOUR_ORIGINAL_AUTH0_DOMAIN}/userinfo`. You can also remove this `audience=[...]/userinfo` parameter altogether if your application is flagged as **OIDC-Conformant** in the **OAuth2** tab of the application's **Advanced Settings**. + +## Errors related to Internet Explorer + +If you are using Internet Explorer, you may see any of the following error messages: + +* "No verifier returned from client" +* "Origin header required" +* "Failed cross origin authentication" + +When both the Auth0 domain and the app domain are in the same trusted or local intranet zone, Internet Explorer does *not* treat the request as a cross-domain request and therefore does not send the cross-origins header. + +If you see any of these errors and you are using Embedded Login, you can move one of the sites out of the trusted or local intranet zone. To do this: + +1. Go to **Internet Options > Security**. +2. Select the **Local Intranet Zone** tab and go to Sites > Advanced. Add your domain. +3. Return to the **Security** tab, and make sure the proper zone has been selected. +4. Click **Custom Level** and look for **Access data sources across domains** under the **Miscellaneous** section. Check the radio button next to **Enable.**. + +Alternatively, you can remove reliance on cross-origin authentication by implementing [Universal Login](/universal-login). diff --git a/articles/dashboard/guides/apis/add-permissions-apis.md b/articles/dashboard/guides/apis/add-permissions-apis.md new file mode 100644 index 0000000000..5a2387069f --- /dev/null +++ b/articles/dashboard/guides/apis/add-permissions-apis.md @@ -0,0 +1,57 @@ +--- +title: Add API Permissions +description: Learn how to add permissions to APIs using the Auth0 Management Dashboard. +topics: + - authorization + - dashboard + - RBAC + - scopes + - permissions +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# Add API Permissions + +This guide will show you how to add permissions to an API using Auth0's Dashboard. This task can also be performed [using the Management API](/api/management/guides/apis/update-permissions-apis). + +::: 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). +::: + +1. Navigate to the [APIs](${manage_url}/#/apis) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the API to view. + +![View APIs](/media/articles/authorization/api-list.png) + +2. Click the **Permissions** tab, enter a permission name and description for the permission you want to add, and click **Add**. + +![Delete Permissions](/media/articles/authorization/api-def-permissions.png) + +## Reserved names + +The following permission names are reserved and cannot be set as custom API permissions: + +* address +* created_at +* email +* email_verified +* family_name +* given_name +* identities +* name +* nickname +* offline_access +* openid +* phone +* picture +* profile + +## Keep reading + +- [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) +- [Role-Based Access Control (RBAC)](/authorization/concepts/rbac) +- [Enable Role-Based Access Control for APIs](/dashboard/guides/apis/enable-rbac) diff --git a/articles/dashboard/guides/apis/delete-permissions-apis.md b/articles/dashboard/guides/apis/delete-permissions-apis.md new file mode 100644 index 0000000000..5cf655a78b --- /dev/null +++ b/articles/dashboard/guides/apis/delete-permissions-apis.md @@ -0,0 +1,34 @@ +--- +title: Delete API Permissions +description: Learn how to delete permissions from APIs using the Auth0 Management Dashboard. +topics: + - authorization + - dashboard + - RBAC + - scopes + - permissions +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# Delete API Permissions + +This guide will show you how to delete permissions from an API using Auth0's Dashboard. This task can also be performed [using the Management API](/api/management/guides/apis/update-permissions). + +1. Navigate to the [APIs](${manage_url}/#/apis) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the API to view. + +![View APIs](/media/articles/authorization/api-list.png) + +2. Click the **Permissions** tab, then click the trashcan icon next to the permission you want to remove, and confirm. + +![Delete Permissions](/media/articles/authorization/api-def-permissions.png) + +## Keep reading + +- [How to Customize the Consent Prompt](/scopes/current/guides/customize-consent-prompt) +- [How to Represent Multiple APIs Using a Single Logical API in Auth0](/api-auth/tutorials/represent-multiple-apis) +- [Role-Based Access Control (RBAC)](/authorization/concepts/rbac) +- [Enable Role-Based Access Control for APIs](/dashboard/guides/apis/enable-rbac) \ No newline at end of file diff --git a/articles/dashboard/guides/apis/enable-rbac.md b/articles/dashboard/guides/apis/enable-rbac.md new file mode 100644 index 0000000000..c45e598467 --- /dev/null +++ b/articles/dashboard/guides/apis/enable-rbac.md @@ -0,0 +1,39 @@ +--- +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 Dashboard. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - dashboard + - 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 Dashboard. This task can also be performed [using the Management API](/api/management/guides/apis/enable-rbac). This effectively enables the API Authorization Core feature set. + +1. Navigate to the [APIs](${manage_url}/#/apis) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the API to view. + +![View APIs](/media/articles/authorization/api-list.png) + +2. Scroll to **RBAC Settings** and enable the **Enable RBAC** toggle. + +![View APIs](/media/articles/authorization/api-settings-rbac.png) + +3. If you want to include all permissions assigned to the user in the `permissions` claim of the Access Token, enable the **Add Permissions in the Access Token** toggle, and click **Save**. + +::: note +Including permissions in the Access Token allows you to make minimal calls to retrieve permissions, but increases token size. As long as RBAC is enabled, the `scope` claim of the Access Token includes an intersection of the requested permissions and the permissions assigned to the user, regardless of whether permissions are also included in the Access Token. + +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/dashboard/guides/apis/update-token-lifetime.md b/articles/dashboard/guides/apis/update-token-lifetime.md new file mode 100644 index 0000000000..44db6613d2 --- /dev/null +++ b/articles/dashboard/guides/apis/update-token-lifetime.md @@ -0,0 +1,37 @@ +--- +title: Update Access Token Lifetime +description: Learn how to update the Access Token lifetime for an API using the Auth0 Dashboard. +topics: + - applications + - access-token + - dashboard +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# Update Access Token Lifetime + +You can change the Access Token lifetime using Auth0's Dashboard. + +1. Navigate to the [APIs](${manage_url}/#/apis) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the API to view. + +2. Locate the **Token Expiration (Seconds)** field, and enter the appropriate Access Token lifetime (in seconds) for the API. + + ::: note + The **Token Expiration For Browser Flows (Seconds)** field refers to Access Tokens issued for the API via implicit and hybrid flows and does not cover all flows initiated from browsers. For example the PKCE flow (used in auth0-js-spa SDK) can be initiated from the browser, but it refers to the Token Expiration not the Token Expiration For Browser Flows value. + ::: + + ![Update Token Expiration](/media/articles/tokens/tokens-expiration-api.png) + + Here are some examples of token expiration values: + + | **Value** | **Description** | + |------------|-----------------| + | Default | 86400 seconds (24 hours) | + | Maximum | 2592000 seconds (30 days) | + +3. Click **Save Changes**. + diff --git a/articles/dashboard/guides/applications/_includes/_register-app-next-steps.md b/articles/dashboard/guides/applications/_includes/_register-app-next-steps.md new file mode 100644 index 0000000000..24e1f21fca --- /dev/null +++ b/articles/dashboard/guides/applications/_includes/_register-app-next-steps.md @@ -0,0 +1,19 @@ +::: note +After creating your first application, you should [set the environment for your tenant](/dev-lifecycle/setting-up-env#set-the-environment). Options include development, staging, or production. +::: + +## Next Steps + +Once you have registered and configured your Application, some common next steps are: + +- Configure a [Connection](/connections) and enable it for your Application + +- Modify your app code to use your Auth0-registered Application. See our [quickstarts](/quickstarts), where you'll find detailed instructions and samples for a variety of technologies. You'll also learn how to implement login and logout, handle your user sessions, retrieve and display user profile information, add [Rules](/rules) to customize your [authentication flow](/application-auth), and more. + +- Call an API using our [API Authorization](/api-auth) feature set. + +- Use [Auth0 APIs](/api/info). + + - The [Authentication API](/api/authentication) handles all primary identity-related functions (for example: login, logout, get user profile). 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. + + - The [Management API](/api/management/v2) allows you to automate various tasks that can also be accessed via the Dashboard in Auth0 (for example: creating users, setting application grant types). \ No newline at end of file diff --git a/articles/dashboard/guides/applications/_includes/_register-app-part1.md b/articles/dashboard/guides/applications/_includes/_register-app-part1.md new file mode 100644 index 0000000000..8003b553ab --- /dev/null +++ b/articles/dashboard/guides/applications/_includes/_register-app-part1.md @@ -0,0 +1,5 @@ +1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}), and click **+ Create Application**. + +2. Enter a descriptive name for your Application, select ${application_type_create}, and click **Create**. + +![Select Application Name and Type](/media/articles/applications/create-client-popup.png) \ No newline at end of file diff --git a/articles/dashboard/guides/applications/_includes/_register-app-part2-m2m.md b/articles/dashboard/guides/applications/_includes/_register-app-part2-m2m.md new file mode 100644 index 0000000000..3338104ec6 --- /dev/null +++ b/articles/dashboard/guides/applications/_includes/_register-app-part2-m2m.md @@ -0,0 +1,5 @@ +Once the new ${application_type} Application is created, you will be redirected to the Application's settings. Available tabs include: + +* **Settings**: Shows all available [settings](/dashboard/reference/settings-application#advanced-settings) for your application. By default, most of the settings will be created for you. +* **Quick Start**: Shows all the available examples for ${application_type} applications. It also shows you how you can call your API using various technologies. To learn how to accept and validate Access Tokens in your API, see our [Backend/API Quickstarts](/quickstart/backend). +* **APIs**: Allows you to authorize additional APIs for use with your Application. \ No newline at end of file diff --git a/articles/dashboard/guides/applications/_includes/_register-app-part2.md b/articles/dashboard/guides/applications/_includes/_register-app-part2.md new file mode 100644 index 0000000000..f26b21ba62 --- /dev/null +++ b/articles/dashboard/guides/applications/_includes/_register-app-part2.md @@ -0,0 +1,6 @@ +Once the new ${application_type} Application is created, you will be redirected to the Application's settings. Available tabs include: + +* **Settings**: Shows all available [settings](/dashboard/reference/settings-application#advanced-settings) for your application. By default, most of the settings will be created for you. +* **Quick Start**: Shows all the available examples for ${application_type} applications. +* **Add-ons**: Allows you to enable [Add-ons](/addons) for your Application. Add-ons are extensions and usually are third-party APIs used with Applications for which Auth0 generates Access Tokens. +* **Connections**: Allows you to enable [Connections](/connections) for your Application. Connections are sources of users; they can be enabled and shared between multiple Applications. diff --git a/articles/dashboard/guides/applications/enable-android-app-links.md b/articles/dashboard/guides/applications/enable-android-app-links.md new file mode 100644 index 0000000000..9db6cbdf03 --- /dev/null +++ b/articles/dashboard/guides/applications/enable-android-app-links.md @@ -0,0 +1,65 @@ +--- +title: Enable Android App Links Support +description: Learn how to enable Android App Links support for your Auth0 application using the Auth0 Dashboard. +topics: + - applications + - android + - app-links + - dashboard +contentType: how-to +useCase: + - build-an-app + - enable-mobile-auth +--- +# Enable Android App Links Support + +[Android App Links](https://developer.android.com/training/app-links/index.html) 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. This guide will show you how to enable Android App links support for your Auth0-registered application using Auth0's Dashboard. + +## Provide Your App's Package Name and Certificate Fingerprint + +1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}), and click the name of the Application to view. + +![View Applications](/media/articles/dashboard/guides/app-list.png) + +2. Scroll to the bottom of the **Settings** page, and click **Show Advanced Settings**. + +![Show Advanced Settings](/media/articles/applications/advanced-settings.png) + +3. Select the **Device Settings** tab, 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, and click **Save Changes**. + +You can use the following command to generate the fingerprint using the Java keytool in your terminal: + +```bash +keytool -list -v -keystore my-release-key.keystore +``` + +::: note +For more info about signing certificates, see Android's [Sign Your App](https://developer.android.com/studio/publish/app-signing.html) developer doc. +::: + +![Add Device Settings](/media/articles/applications/device-settings.png) + + +## Test Your App Link + +1. Navigate to the following URL in 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 +For more info about testing your app link, see Android's [Verify Android App Links](https://developer.android.com/training/app-links/verify-site-associations.html#testing) developer doc. +::: diff --git a/articles/dashboard/guides/applications/enable-sso-app.md b/articles/dashboard/guides/applications/enable-sso-app.md new file mode 100644 index 0000000000..a2877d7ec3 --- /dev/null +++ b/articles/dashboard/guides/applications/enable-sso-app.md @@ -0,0 +1,31 @@ +--- +title: Enable Single Sign-On for Applications +description: Learn how to enable Single Sign-on (SSO) for an application using the Auth0 Management Dashboard. Only for use with legacy tenants. +toc: true +topics: + - sso + - dashboard +contentType: + - how-to +useCase: + - integrate-saas-sso + - configure-sso + - build-an-app +--- +# Enable Single Sign-On for Applications + +By default, seamless Single Sign-on (SSO) is enabled for all new Auth0 tenants; however, **legacy tenants** may [choose whether to enable this feature at the tenant level](/dashboard/guides/tenants/enable-sso-tenant). If you have not enabled tenant-level SSO, you may enable it per application. + +This guide will show you how to enable Single Sign-On (SSO) for your application using Auth0's Dashboard. + +::: warning +Before enabling SSO for an [application](/applications), you must first create and configure a connection for each [Identity Provider](/identityproviders) you want to use. For social identity providers, make sure the connection is not using [developer keys](/connections/social/devkeys) if you use the [Classic Universal Login Experience](/universal-login/classic). +::: + +1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the application to view. + +![Select Application](/media/articles/applications/app-list.png) + +2. Scroll to the bottom of the Settings page, locate **Use Auth0 instead of the IdP to do Single Sign-on**, enable the toggle, and click **Save Changes**. + +![Enable SSO](/media/articles/applications/app-settings-danger-zone-legacy.png) \ No newline at end of file diff --git a/articles/dashboard/guides/applications/enable-universal-links.md b/articles/dashboard/guides/applications/enable-universal-links.md new file mode 100644 index 0000000000..d0e23998b9 --- /dev/null +++ b/articles/dashboard/guides/applications/enable-universal-links.md @@ -0,0 +1,63 @@ +--- +title: Enable Universal Links Support in Apple Xcode +description: Learn how to enable universal links support for your Auth0 app in Apple Xcode using the Auth0 Dashboard. +topics: + - applications + - ios + - universal-links + - dashboard +contentType: how-to +useCase: + - build-an-app + - enable-mobile-auth +--- +# Enable Universal Links Support in Apple Xcode + +Universal links establish a *verified relationship between domains and applications*, so 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`. + +This guide will show you how to enable universal links support for your Auth0-registered application using Auth0's Dashboard. + +## 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 + +1. Navigate to the [Applications](${manage_url}/#/clients) page of the [Auth0 Dashboard](${manage_url}), and click the name of the Application to view. + +![View Applications](/media/articles/dashboard/guides/app-list.png) + +2. Scroll to the bottom of the *Settings* page, and click *Show Advanced Settings.* + +![Show Advanced Settings](/media/articles/applications/advanced-settings.png) + +3. Select the *Device Settings* tab, provide the **Team ID** and the **App bundler identifier** values for your iOS application, and click **Save Changes**. + +![](/media/articles/applications/device-settings.png) + +## Test Your Universal Link + +To check whether the universal links `apple-app-site-association` file is available for your application, navigate to the following URL in your browser: + +`${account.namespace}/apple-app-site-association`. + +If the link is successful, you will see 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/dashboard/guides/applications/register-app-m2m.md b/articles/dashboard/guides/applications/register-app-m2m.md new file mode 100644 index 0000000000..2420df9da6 --- /dev/null +++ b/articles/dashboard/guides/applications/register-app-m2m.md @@ -0,0 +1,37 @@ +--- +title: Register Machine-to-Machine Applications +description: Learn how to register and configure a machine-to-machine (M2M) application using the Auth0 Management Dashboard. These may include non-interactive applications, such as command-line tools, daemons, IoT devices, or services running on your back-end. +topics: + - applications + - m2m + - dashboard +contentType: + - how-to +useCase: + - build-an-app + - add-login + - call-api +--- +# Register Machine-to-Machine Applications + +To integrate Auth0 with a [machine-to-machine (M2M) application](/applications), you must first register your app with Auth0. This guide will show you how to register an M2M application using Auth0's Dashboard. + +::: note +M2M applications are linked to an API and its [scopes](/scopes/current/api-scopes), which are selected from pre-defined values. Make sure you have already [registered the associated API](/apis#how-to-configure-an-api-in-auth0) with Auth0 and [defined scopes for the API](scopes/current#define-scopes-using-the-dashboard) before beginning this guide. + +If you want to authorize your application to access only Auth0's [Management API](/api/info#management-api-v2), you do not need to do anything; the Management API is pre-populated for you. +::: + +<%= include('./_includes/_register-app-part1', { application_type: 'M2M', application_type_create: 'Machine-to-Machine App' }) %> + +3. Select the API you want to be able to call from your Application. + +![Select API](/media/articles/applications/m2m-select-api.png) + +4. Select the [scopes](/scopes/current/api-scopes) you want to be issued as part of your Application's Access Token, and click **Authorize**. + +![Select Scopes](/media/articles/applications/m2m-select-scopes.png) + +<%= include('./_includes/_register-app-part2-m2m', { application_type: 'M2M', application_type_create: 'Machine-to-Machine App' }) %> + +<%= include('./_includes/_register-app-next-steps') %> \ No newline at end of file diff --git a/articles/dashboard/guides/applications/register-app-native.md b/articles/dashboard/guides/applications/register-app-native.md new file mode 100644 index 0000000000..591ab3d0eb --- /dev/null +++ b/articles/dashboard/guides/applications/register-app-native.md @@ -0,0 +1,31 @@ +--- +title: Register Native Applications +description: Learn how to register and configure a native application using the Auth0 Management Dashboard. These may include mobile, desktop, or hybrid apps running natively in a device (e.g., i0S, Android). +topics: + - applications + - native-app + - mobile-app + - dashboard +contentType: + - how-to +useCase: + - build-an-app + - add-login + - call-api +--- +# Register Native Applications + +To integrate Auth0 with a [native application](/applications), you must first register your app with Auth0. This guide will show you how to register a native application using Auth0's Dashboard. + +<%= include('./_includes/_register-app-part1', { application_type: 'native', application_type_create: 'Native App' }) %> + +<%= include('./_includes/_register-app-part2', { application_type: 'native', application_type_create: 'Native App' }) %> + +3. If you're developing a mobile app, provide the necessary iOS/Android parameters in the **Advanced Settings** area, and click **Save Changes**. + +- For iOS apps, [provide your **Team ID** and **App Bundle Identifier**](/dashboard/guides/applications/enable-universal-links). + +- For Android apps, [provide your **App Package Name** and your **Key Hashes**](/dashboard/guides/applications/enable-android-app-links). + +<%= include('./_includes/_register-app-next-steps') %> + diff --git a/articles/dashboard/guides/applications/register-app-regular-web.md b/articles/dashboard/guides/applications/register-app-regular-web.md new file mode 100644 index 0000000000..f7fdc55ca8 --- /dev/null +++ b/articles/dashboard/guides/applications/register-app-regular-web.md @@ -0,0 +1,25 @@ +--- +title: Register Regular Web Applications +description: Learn how to register and configure a regular web application using the Auth0 Management Dashboard. These may include traditional web applications that perform most of their application logic on the server (e.g., Express.js, ASP.NET). +topics: + - applications + - regular-web-app + - dashboard +contentType: + - how-to +useCase: + - build-an-app + - add-login + - call-api +--- +# Register Regular Web Applications + +To integrate Auth0 with a [regular web app](/applications), you must first register your app with Auth0. This guide will show you how to register a regular web application using Auth0's Dashboard. + +<%= include('./_includes/_register-app-part1', { application_type: 'regular web', application_type_create: 'Regular Web App' }) %> + +<%= include('./_includes/_register-app-part2', { application_type: 'regular web', application_type_create: 'Regular Web App' }) %> + +3. Scroll down and locate the **Trust Token Endpoint IP Header** setting, enable it, and click **Save Changes**. When enabled, this protects against brute-force attacks. + +<%= include('./_includes/_register-app-next-steps') %> \ No newline at end of file diff --git a/articles/dashboard/guides/applications/register-app-spa.md b/articles/dashboard/guides/applications/register-app-spa.md new file mode 100644 index 0000000000..cb411d7a50 --- /dev/null +++ b/articles/dashboard/guides/applications/register-app-spa.md @@ -0,0 +1,22 @@ +--- +description: Learn how to register and configure a Single-Page Application (SPA) using the Auth0 Management Dashboard. These may include JavaScript applications that perform most of their user interface logic in a web browser, communicating with a web server primarily using APIs (e.g., AngularJS + Node.js, React). +topics: + - applications + - single-page-app + - dashboard +contentType: + - how-to +useCase: + - build-an-app + - add-login + - call-api +--- +# Register Single-Page Applications + +To integrate Auth0 with a [single-page app](/applications), you must first register your app with Auth0. This guide will show you how to register a single-page application using Auth0's Dashboard. + +<%= include('./_includes/_register-app-part1', { application_type: 'single-page', application_type_create: 'Single-Page Web App' }) %> + +<%= include('./_includes/_register-app-part2', { application_type: 'single-page', application_type_create: 'Single-Page Web App' }) %> + +<%= include('./_includes/_register-app-next-steps') %> \ No newline at end of file diff --git a/articles/dashboard/guides/applications/remove-app.md b/articles/dashboard/guides/applications/remove-app.md new file mode 100644 index 0000000000..fa7b667d50 --- /dev/null +++ b/articles/dashboard/guides/applications/remove-app.md @@ -0,0 +1,25 @@ +--- +title: Remove Application +description: Learn how to remove an Auth0-registered application using the Auth0 Management Dashboard. +toc: false +topics: + - applications + - dashboard +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 Dashboard. This task can also be performed [using the Management API](/api/management/guides/applications/remove-app). + +1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}), and click the name of the Application to view. + +![View Applications](/media/articles/dashboard/guides/app-list.png) + +2. Scroll to the bottom of the **Settings** page, locate the *Danger Zone*, click **Delete Application**, and confirm. Once confirmed, this operation cannot be undone. + +![Remove Application](/media/articles/dashboard/guides/app-settings-danger-zone.png) diff --git a/articles/dashboard/guides/applications/rotate-client-secret.md b/articles/dashboard/guides/applications/rotate-client-secret.md new file mode 100644 index 0000000000..4e97711caf --- /dev/null +++ b/articles/dashboard/guides/applications/rotate-client-secret.md @@ -0,0 +1,33 @@ +--- +title: Rotate Client Secret +description: Learn how to rotate an application's client secret using the Auth0 Management Dashboard. +topics: + - applications + - client-secrets + - dashboard +contentType: + - how-to +useCase: + - build-an-app +--- +# Rotate Client Secret + +This guide will show you how to change an application's client secret using Auth0's Dashboard. This task can also be performed [using the Management API](/api/management/guides/applications/rotate-client-secret). + +::: note +The global client secret can also be rotated via the Dashboard. Your global client ID and secret can be found in your [Advanced Tenant Settings](${manage_url}/#/tenant/advanced). +::: + +1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the Application to view. + +![View Applications](/media/articles/dashboard/guides/app-list.png) + +2. Scroll to the bottom of the Application Settings page and under **Danger Zone**, you will see the Rotate secret option. Click the **Rotate** button to rotate the client's secret. + +![Rotate Client Secret](/media/articles/dashboard/guides/rotate-client-secret.png) + +You can view your new secret by selecting the **Reveal client secret** checkbox. + +3. Update authorized applications + +After you rotate your client secret, you must update any authorized applications with the new value. diff --git a/articles/dashboard/guides/applications/set-up-addon-saml2-aws.md b/articles/dashboard/guides/applications/set-up-addon-saml2-aws.md new file mode 100644 index 0000000000..4b152aeae2 --- /dev/null +++ b/articles/dashboard/guides/applications/set-up-addon-saml2-aws.md @@ -0,0 +1,47 @@ +--- +title: Set Up the SAML2 Web App Add-On with AWS for Applications +description: Learn how to set up the SAML2 Web App add-ons with Amazon Web Services (AWS) for an application registered with Auth0 using the Auth0 Management Dashboard. +topics: + - applications + - add-ons + - AWS + - SAML + - dashboard +contentType: + - how-to +useCase: + - integrate-third-party-apps +--- +# Set Up the SAML2 Web App Add-On with AWS for Applications + +This guide will show you how to set up the SAML2 Web App [add-on](/addons) with Amazon Web Services (AWS) for an application using Auth0's Dashboard. + +::: warning +This is just one step in the process of integrating Auth0 with AWS. For complete steps, choose an integration from [Integrate Auth0 with Amazon Web Services (AWS)](/integrations/aws). +::: + +1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the Application to update. + +2. Click **Add-ons**, and enable the toggle for the **SAML2 Web App** add-on. + +3. Locate **Application Callback URL** and enter `https://signin.aws.amazon.com/saml`, then paste the following SAML configuration code into **Settings**, then click **Enable**. + +```js +{ + "audience": "https://signin.aws.amazon.com/saml", + "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:2.0:nameid-format:persistent", + "nameIdentifierProbes": [ + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" + ] +} +``` + +4. Click the **Usage** tab, locate **Identity Provider Metadata**, and download the metadata file. You'll need this when you configure Auth0 as the identity provider (IdP) for AWS in the next step. diff --git a/articles/dashboard/guides/applications/set-up-addons.md b/articles/dashboard/guides/applications/set-up-addons.md new file mode 100644 index 0000000000..b88a678135 --- /dev/null +++ b/articles/dashboard/guides/applications/set-up-addons.md @@ -0,0 +1,37 @@ +--- +title: Set Up Add-ons +description: Learn how to set up add-ons, like Amazon Web Services and Azure Blob Storage, for an application registered with Auth0 using the Auth0 Management Dashboard. +topics: + - applications + - add-ons + - dashboard +contentType: + - how-to +useCase: + - integrate-third-party-apps +--- +# Set Up Add-ons + +<%= include('../../../_includes/_uses-delegation') %> + +This guide will show you how to set up an [add-on](/addons) for an application using Auth0's Dashboard. + +1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the Application to view. + +![View Applications](/media/articles/dashboard/guides/app-list.png) + +2. Click **Add-ons**, and enable the toggle for the add-on you want to set up. + +![View Add-ons](/media/articles/applications/addons-dashboard-list.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 integrate with it. + +For more info about using Auth0 to authenticate and authorize add-ons, see: +- [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) + +For more info on how to use delegation with the Amazon Web Services (AWS) API Gateway, see the [AWS API Gateway Tutorial](/integrations/aws-api-gateway/delegation). \ No newline at end of file diff --git a/articles/dashboard/guides/applications/set-up-cors.md b/articles/dashboard/guides/applications/set-up-cors.md new file mode 100644 index 0000000000..a8773f13ba --- /dev/null +++ b/articles/dashboard/guides/applications/set-up-cors.md @@ -0,0 +1,27 @@ +--- +title: Set Up Cross-Origin Resource Sharing (CORS) +description: Learn how to set up Cross-Origin Resource Sharing (CORS) for an application registered with Auth0 using the Auth0 Management Dashboard. +topics: + - applications + - cors + - dashboard +contentType: + - how-to +useCase: + - build-app +--- +# Set Up Cross-Origin Resource Sharing (CORS) + +::: warning +Auth0 strongly recommends that authentication transactions be handled via [Universal Login](/universal-login). Doing so offers the easiest and most secure way to authenticate users. However, some situations may require that login be directly embedded in an application. When embedded login is required, an application must be set up for cross-origin resource sharing (CORS). +::: + +This guide will show you how to set up cross-origin resource sharing (CORS) for an application using Auth0's Dashboard. + +For security purposes, your app's origin URL must be listed as an approved URL. If you have not already added it to the **Allowed Callback URLS** for your application, you will need to add it to the list of **Allowed Origins (CORS)**. + +1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the Application to view. + +![View Applications](/media/articles/dashboard/guides/app-list.png) + +2. Scroll down and locate **Allowed Origins (CORS)**, enter your app's [origin URL](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin), and click **Save Changes**. diff --git a/articles/dashboard/guides/applications/update-app-connections.md b/articles/dashboard/guides/applications/update-app-connections.md new file mode 100644 index 0000000000..7ad369dcfd --- /dev/null +++ b/articles/dashboard/guides/applications/update-app-connections.md @@ -0,0 +1,20 @@ +--- +title: Update Application Connections +description: Learn how to update an application's enabled connections using the Auth0 Management Dashboard. +topics: + - applications + - connections + - dashboard +contentType: how-to +useCase: + - build-an-app +--- +# Update Application Connections + +This guide will show you how to change your application's enabled connections using Auth0's Dashboard. + +1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the Application to view. + +![View Applications](/media/articles/dashboard/guides/app-list.png) + +2. Click the **Connections** tab, and enable or disable the appropriate connections for the application. diff --git a/articles/dashboard/guides/applications/update-grant-types.md b/articles/dashboard/guides/applications/update-grant-types.md new file mode 100644 index 0000000000..6a3ad79181 --- /dev/null +++ b/articles/dashboard/guides/applications/update-grant-types.md @@ -0,0 +1,40 @@ +--- +title: Update Grant Types +description: Learn how to update an application's grant types using the Auth0 Management Dashboard. +topics: + - applications + - grant-types + - dashboard +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 Dashboard. This task can also be performed [using the Management API](/api/management/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. +::: + +::: panel Troubleshooting +* The device code grant type is only available for native apps. + +* 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. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the Application to view. + +![View Applications](/media/articles/dashboard/guides/app-list.png) + +2. Scroll to the bottom of the page, and click **Advanced Settings**. + +![View Advanced Settings](/media/articles/clients/client-grant-types/client-advanced-settings.png) + +3. Click the **Grant Types** tab, and enable or disable the appropriate grants for the application. When finished, click **Save Changes**. + +![Select Grant Types](/media/articles/clients/client-grant-types/grant-types.png) diff --git a/articles/dashboard/guides/applications/update-signing-algorithm.md b/articles/dashboard/guides/applications/update-signing-algorithm.md new file mode 100644 index 0000000000..3011b2493a --- /dev/null +++ b/articles/dashboard/guides/applications/update-signing-algorithm.md @@ -0,0 +1,28 @@ +--- +title: Update the Signing Algorithm for an Application +description: Learn how to update an application's signing algorithm using the Auth0 Dashboard. +toc: true +topics: + - tokens + - id-tokens + - signing-algorithms + - dashboard +contentType: + - how-to +useCase: + - build-an-app + - invoke-api +--- +# Update the Signing Algorithm for an Application + +This guide will show you how to change your application's [signing algorithm](/tokens/concepts/signing-algorithms) using Auth0's Dashboard. + +1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the Application to view. + +![View Applications](/media/articles/dashboard/guides/app-list.png) + +2. Scroll to the bottom of the page, click **Advanced Settings**, and click the **OAuth** tab. + +![View OAuth Advanced Settings](/media/articles/dashboard/guides/applications/app-settings-advanced-oauth.png) + +3. Locate **JsonWebToken Signature Algorithm**, and select the appropriate signing algorithm for the application. When finished, click **Save Changes**. diff --git a/articles/dashboard/guides/applications/update-token-lifetime.md b/articles/dashboard/guides/applications/update-token-lifetime.md new file mode 100644 index 0000000000..cd79494dfc --- /dev/null +++ b/articles/dashboard/guides/applications/update-token-lifetime.md @@ -0,0 +1,24 @@ +--- +title: Update ID Token Lifetime +description: Learn how to update the ID token lifetime for an application using the Auth0 Dashboard. +topics: + - applications + - id-token + - dashboard +contentType: + - how-to +useCase: + - build-an-app + - add-login +--- +# Update ID Token Lifetime + +You can change the ID Token lifetime using Auth0's Dashboard. + +1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the Application to view. + +![View Applications](/media/articles/dashboard/guides/app-list.png) + +2. Scroll to the bottom of the Application Settings page, locate the **ID Token Expiration** field, and enter the appropriate ID Token lifetime (in seconds) for the application. When finished, click **Save Changes**. + +![ID Token Expiration](/media/articles/dashboard/guides/rotate-client-secret.png) diff --git a/articles/dashboard/guides/applications/view-addons.md b/articles/dashboard/guides/applications/view-addons.md new file mode 100644 index 0000000000..cb93b08916 --- /dev/null +++ b/articles/dashboard/guides/applications/view-addons.md @@ -0,0 +1,25 @@ +--- +title: View Add-ons +description: Learn how to view available and configured add-ons for an application registered with Auth0 using the Auth0 Management Dashboard. +topics: + - applications + - add-ons + - dashboard +contentType: + - how-to +useCase: + - build-an-app + - integrate-third-party-apps +--- + +# View Add-ons + +This guide will show you how to view all of the available and configured [add-ons](/addons) for an application using Auth0's Dashboard. + +1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the Application to view. + +![View Applications](/media/articles/dashboard/guides/app-list.png) + +2. Click **Add-ons**. + +![View Add-ons](/media/articles/applications/addons-dashboard-list.png) diff --git a/articles/dashboard/guides/applications/view-app-type-confidential-public.md b/articles/dashboard/guides/applications/view-app-type-confidential-public.md new file mode 100644 index 0000000000..6f46d90493 --- /dev/null +++ b/articles/dashboard/guides/applications/view-app-type-confidential-public.md @@ -0,0 +1,35 @@ +--- +title: View Application Type - Confidential or Public +description: Learn how to check whether an application is registered with Auth0 as a confidential or public app using the Auth0 Management Dashboard. +topics: + - applications + - application-types + - dashboard +contentType: how-to +useCase: + - build-an-app +--- +# View Application Type: Confidential or Public + +This guide will show you how to use Auth0's Dashboard to check whether an application is registered with Auth0 as a [confidential or public application](/applications/concepts/app-types-confidential-public). + +Auth0 determines this based on the **Token Endpoint Authentication Method** setting, which defines how an application authenticates against the [token endpoint](/api/authentication#get-token). + +1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the Application to view. + +![View Applications](/media/articles/dashboard/guides/app-list.png) + +3. Locate the **Token Endpoint Authentication Method**. + +Its valid values are: + +* `None`, for a public application without a client secret +* `Post`, for an application using HTTP POST parameters +* `Basic`, for an application using HTTP Basic parameters + +These values map to confidential and public applications as follows: + +| Application Type | Token Endpoint Authentication Method | +| - | - | +| Public | **None** | +| Confidential | **Basic**, **Post**, unspecified | diff --git a/articles/dashboard/guides/connections/configure-connection-sync.md b/articles/dashboard/guides/connections/configure-connection-sync.md new file mode 100644 index 0000000000..3b0c41a15a --- /dev/null +++ b/articles/dashboard/guides/connections/configure-connection-sync.md @@ -0,0 +1,36 @@ +--- +title: Configure Connection Sync with Auth0 +description: Learn how to allow updates to the Auth0 normalized user profile from a connection using the Auth0 Dashboard. +topics: + - connections + - identity-providers + - user-profile + - dashboard +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 Dashboard. This task can also be performed [using the Management API](/api/management/guides/connections/configure-connection-sync). + +::: warning +<%= include('../../../_includes/_users_update_normalized_profile_attributes') %> +::: + +1. Navigate to the [Auth0 Dashboard](${manage_url}/#/), and click **Authentication** in the left nav. + +2. Select a connection type: + +- [Database](${manage_url}/#/connections/database) +- [Social](${manage_url}/#/connections/social) +- [Enterprise](${manage_url}/#/connections/enterprise) + +3. Click the name of a connection to see its settings. + +4. Toggle **Sync user profile attributes at each login** to the desired setting, and click **Save**. + + ![Sync user profile attributes at each login](/media/articles/connections/dashboard-connections-social-edit_sync-user-profile-attributes.png) \ No newline at end of file diff --git a/articles/dashboard/guides/connections/disable-cache-ad-ldap.md b/articles/dashboard/guides/connections/disable-cache-ad-ldap.md new file mode 100644 index 0000000000..1f3793be92 --- /dev/null +++ b/articles/dashboard/guides/connections/disable-cache-ad-ldap.md @@ -0,0 +1,20 @@ +--- +title: Disable Credential Caching +description: Learn how to disable credential caching at the connection level for an AD/LDAP enterprise connection using the Auth0 Management Dashboard. +topics: + - connections + - dashboard + - ad-ldap +contentType: + - how-to +useCase: + - build-an-app + - customize-connections +--- +# Disable Credential Caching + +This guide will show you how to disable credential caching at the [connection](/identityproviders) level for an [AD/LDAP connection](/connector/overview) using Auth0's Dashboard. + +1. Navigate to [Auth0 Dashboard > Authentication > Enterprise](${manage_url}/#/connections/enterprise), and click the **Active Directory/LDAP** connection. + +2. Enable the **Disable Cache** switch. \ No newline at end of file diff --git a/articles/dashboard/guides/connections/enable-connections-enterprise.md b/articles/dashboard/guides/connections/enable-connections-enterprise.md new file mode 100644 index 0000000000..bebe428379 --- /dev/null +++ b/articles/dashboard/guides/connections/enable-connections-enterprise.md @@ -0,0 +1,32 @@ +--- +description: Learn how to enable enterprise connections for applications using the Auth0 Management Dashboard. +topics: + - connections + - dashboard + - enterprise + - applications +contentType: + - how-to +useCase: + - build-an-app + - customize-connections +--- +# Enable Enterprise Connections + +This guide will show you how to enable enterprise [connections](/connections) for applications using Auth0's Dashboard. + +::: warning +To enable your enterprise connection, you should have already [set it up](/connections/identity-providers-enterprise). +::: + +1. Navigate to [Auth0 Dashboard > Authentication > Enterprise](${manage_url}/#/connections/enterprise), and click on the connection type to view. + + ![Select Connection Type](/media/articles/connections/dashboard-connections-enterprise-list.png) + +2. Select the name of the connection to view. + + ![Select Connection](/media/articles/connections/criipto/adfs-connections-dk.png) + +3. Select the **Applications** view, and enable or disable the connection for the appropriate application(s). + + ![Enable Connection for Applications](/media/articles/connections/dashboard-connections-enterprise-edit_adfs_view-applications.png) diff --git a/articles/dashboard/guides/connections/set-up-connections-database.md b/articles/dashboard/guides/connections/set-up-connections-database.md new file mode 100644 index 0000000000..857764b819 --- /dev/null +++ b/articles/dashboard/guides/connections/set-up-connections-database.md @@ -0,0 +1,32 @@ +--- +description: Learn how to set up database connections for applications using the Auth0 Management Dashboard. +topics: + - connections + - dashboard + - database + - configuration +contentType: + - how-to +useCase: + - build-an-app + - customize-connections +--- +# Set Up Database Connections + +This guide will show you how to set up database [connections](/connections) for applications using Auth0's Dashboard. The configured database connections can be used to log in to your application. + +1. Navigate to [Auth0 Dashboard > Authentication > Database](${manage_url}/#/connections/database), and select **+ Create DB Connection**. + + ![Create Database Connection](/media/articles/connections/database/dashboard-connections-database-list-hbms.png) + +2. Enter a name for your connection, and select **Create**. + + ![Enter Details](/media/articles/connections/database/dashboard-connections-database-create_user-password-auth.png) + +3. Select the **Applications** view, enable the switch for each of your Auth0 applications that should be able to use this connection, and select **Save**. + + ![Enable Applications](/media/articles/connections/database/dashboard-connections-database-edit_view-applications.png) + +## Keep reading + +- [Test Database Connections](/dashboard/guides/connections/test-connections-database) diff --git a/articles/dashboard/guides/connections/set-up-connections-social.md b/articles/dashboard/guides/connections/set-up-connections-social.md new file mode 100644 index 0000000000..083069b3e0 --- /dev/null +++ b/articles/dashboard/guides/connections/set-up-connections-social.md @@ -0,0 +1,39 @@ +--- +description: Learn how to set up social connections for applications using the Auth0 Management Dashboard. +topics: + - connections + - dashboard + - social + - configuration +contentType: + - how-to +useCase: + - build-an-app + - customize-connections +--- +# Set Up Social Connections + +This guide will show you how to set up social [connections](/connections) for applications using Auth0's Dashboard. The configured social connections can be used to log in to your application. + +::: warning +You should already have set up credentials for your application in the social identity provider with which you want to allow users to log in to your application. To learn how to do so, select your identity provider from our list of [social connections](/connections#social). +::: + +1. Navigate to [Auth0 Dashboard > Authentication > Social](${manage_url}/#/connections/social), and select **Create Connection**. + +2. Choose the connection you want to set up. + +3. Copy and paste the `Client ID` and `Client Secret` from your social identity provider, select the **Attributes** (and **Permissions**, where applicable), and click **Save**. + + * **Attributes**: User data you want your app to be able to access. + * **Permissions**: Features you want your app to be able to access on the user's behalf. + + ![Configure Connection](/media/articles/connections/social/dashboard-connections-social-create_google.png) + +4. Select the **Applications** view, enable the switch for each of your Auth0 applications that should be able to use this connection, and select **Save**. + + ![Enable Applications](/media/articles/connections/social/dashboard-connections-social-edit_view-applications.png) + +## Keep reading + +- [Test Social Connections](/dashboard/guides/connections/test-connections-social) diff --git a/articles/dashboard/guides/connections/test-connections-database.md b/articles/dashboard/guides/connections/test-connections-database.md new file mode 100644 index 0000000000..3036272a53 --- /dev/null +++ b/articles/dashboard/guides/connections/test-connections-database.md @@ -0,0 +1,28 @@ +--- +description: Learn how to test database connections for applications using the Auth0 Management Dashboard. +topics: + - connections + - dashboard + - database + - testing +contentType: + - how-to +useCase: + - build-an-app + - customize-connections +--- +# Test Database Connections + +This guide will show you how to test database [connections](/connections) for applications using Auth0's Dashboard. The configured database connections can be used to log in to your application. + +::: warning +To properly test, you should have already [set up your database connection](/dashboard/guides/connections/set-up-connections-database) and [created a user](/dashboard/guides/users/create-users) for your database connection. +::: + +1. Navigate to [Auth0 Dashboard > Authentication > Database](${manage_url}/#/connections/database), and select the Try arrow next to the connection you want to test. + + ![Try Connection](/media/articles/connections/database/dashboard-connections-database-try.png) + +2. Enter your test user's username and password. If you have configured everything correctly, you will see the **It Works!** page: + + ![Success](/media/articles/connections/social/connection-social-try-success.png) \ No newline at end of file diff --git a/articles/dashboard/guides/connections/test-connections-enterprise.md b/articles/dashboard/guides/connections/test-connections-enterprise.md new file mode 100644 index 0000000000..1ff7ce8a7d --- /dev/null +++ b/articles/dashboard/guides/connections/test-connections-enterprise.md @@ -0,0 +1,32 @@ +--- +description: Learn how to test enterprise connections for applications using the Auth0 Management Dashboard. +topics: + - connections + - dashboard + - enterprise + - testing +contentType: + - how-to +useCase: + - build-an-app + - customize-connections +--- +# Test Enterprise Connections + +This guide will show you how to test enterprise [connections](/connections) for applications using Auth0's Dashboard. + +::: warning +To properly test, you should have already [set up your enterprise connection](/connections/identity-providers-enterprise). +::: + +1. Navigate to [Auth0 Dashboard > Authentication > Enterprise](${manage_url}/#/connections/enterprise), and select the connection type to view. + + ![Select Connection Type](/media/articles/connections/dashboard-connections-enterprise-list.png) + +2. Select the Try arrow next to the connection you want to test. + + ![Select Connection](/media/articles/connections/dashboard-connections-enterprise_adfs_try.png) + +3. Log in and consent to allow access to your app. If you have configured everything correctly, you will see the **It Works!** page. + + ![Success](/media/articles/connections/social/connection-social-try-success.png) diff --git a/articles/dashboard/guides/connections/test-connections-social.md b/articles/dashboard/guides/connections/test-connections-social.md new file mode 100644 index 0000000000..011b80a3a4 --- /dev/null +++ b/articles/dashboard/guides/connections/test-connections-social.md @@ -0,0 +1,28 @@ +--- +description: Learn how to test social connections for applications using the Auth0 Management Dashboard. +topics: + - connections + - dashboard + - social + - testing +contentType: + - how-to +useCase: + - build-an-app + - customize-connections +--- +# Test Social Connections + +This guide will show you how to test social [connections](/connections) for applications using Auth0's Dashboard. The configured social connections can be used to log in to your application. + +::: warning +To properly test, you should have already [set up your social connection](/dashboard/guides/connections/set-up-connections-social). +::: + +1. Navigate to [Auth0 Dashboard > Authentication > Social](${manage_url}/#/connections/social), locate the connection you want to test, expand the More Options menu (**...**), and select **Try Connection**. + + ![Try Connection](/media/articles/connections/social/dashboard-connections-social-try.png) + +2. Log in and consent to allow access to your app. If you have configured everything correctly, you will see the **It Works!** page: + + ![Success](/media/articles/connections/social/connection-social-try-success.png) diff --git a/articles/dashboard/guides/connections/view-connections.md b/articles/dashboard/guides/connections/view-connections.md new file mode 100644 index 0000000000..24b6f76229 --- /dev/null +++ b/articles/dashboard/guides/connections/view-connections.md @@ -0,0 +1,33 @@ +--- +title: View Connections +description: Learn how to view enabled connections in the Auth0 Management Dashboard. +crews: crew-2 +topics: + - applications + - connections + - dashboard +contentType: how-to +useCase: + - build-an-app + - customize-connections +--- +# View Connections + +This guide will show you how to view all of the available and configured [connections](/connections) using Auth0's Dashboard. The configured connections can be used to log in to your applications. + +1. Navigate to the [Auth0 Dashboard](${manage_url}/#/), and select **Authentication** in the left nav. + +2. Select a connection type: + +- [Database](${manage_url}/#/connections/database) +- [Social](${manage_url}/#/connections/social) +- [Enterprise](${manage_url}/#/connections/enterprise) +- [Passwordless](${manage_url}/#/connections/passwordless) + + +## Keep reading + +- [Set Up Social Connections](/dashboard/guides/connections/set-up-connections-social) +- [Identity Providers Supported by Auth0](/identityproviders) +- [Create Multiple Tenants](/dashboard/guides/tenants/create-multiple-tenants) +- [Using Auth0 with Multi-Tenant Applications](/design/using-auth0-with-multi-tenant-apps) \ No newline at end of file diff --git a/articles/dashboard/guides/extensions/delegated-admin-create-app.md b/articles/dashboard/guides/extensions/delegated-admin-create-app.md new file mode 100644 index 0000000000..ffa2b3bae3 --- /dev/null +++ b/articles/dashboard/guides/extensions/delegated-admin-create-app.md @@ -0,0 +1,57 @@ +--- +description: Learn how to create an application to use with the Delegated Admin 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. +topics: + - extensions + - delegated-admin + - dae +contentType: + - how-to +useCase: + - extensibility-extensions + - create-delegated-admin-application +--- +# Create Delegated Admin Applications + +Use the [Delegated Admin Extension](/extensions/delegated-admin), 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. + +Before you [add the Delegated Admin extension](/dashboard/guides/extensions/delegated-admin-install-extension), you need to create the Delegated Admin application in Auth0. + +1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click **+Create Application**. + +2. Enter a descriptive name for your Application (for example, *Users Dashboard*), select an application type of **Single-Page Web Application**, and click **Create**. + +3. On the **Settings** tab, set the **Allowed Callback URLs** and **Allowed Logout URLs** based on your location, and click **Save Changes**: + + 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` | + + | 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 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` | + + | 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` | + +Next, you will need to [install the Delegated Admin Extension](/dashboard/guides/extensions/delegated-admin-install-extension). + +## Keep reading + +- [Troubleshoot Extensions](/extensions/troubleshoot) diff --git a/articles/dashboard/guides/extensions/delegated-admin-install-extension.md b/articles/dashboard/guides/extensions/delegated-admin-install-extension.md new file mode 100644 index 0000000000..18d081ae1e --- /dev/null +++ b/articles/dashboard/guides/extensions/delegated-admin-install-extension.md @@ -0,0 +1,47 @@ +--- +description: Learn how to install the 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. +topics: + - extensions + - delegated-admin + - dae +contentType: + - how-to +useCase: + - extensibility-extensions + - setup-delegated-admin + - install-delegated-admin-extension +--- +# Install the Delegated Admin Extension + +This guide will show you how to install the [Delegated Admin Extension](/extensions/delegated-admin), 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. + +::: warning +Before you install and configure the Delegated Admin extension, you need to [create a Delegated Admin Dashboard application](/dashboard/guides/extensions/delegated-admin-create-app) in Auth0. +::: + +1. Go to [Dashboard > Extensions](${manage_url}/#/extensions) and filter for `Delegated Admin`. + +2. Click on the **Delegated Administration Dashboard** box in the list of provided extensions. The **Install Extension** window will open. + +3. Set the following configuration variables: + + | Variable | Description | + | --- | --- | + | **EXTENSION_CLIENT_ID** | **Client ID** of the application with which you plan to use this extension. | + | **TITLE** | Custom title that will appear at the top of the Delegated Administration Dashboard page. | + | **CUSTOM_CSS** | (*Optional*) Link to a custom CSS you can use to style the look of your Delegated Administration Dashboard page. | + | **FAVICON_PATH** | (*Optional*) Path to custom favicon. | + | **AUTH0_CUSTOM_DOMAIN** | (*Optional*) If you have a custom domain name configured, enter it here (e.g., `login.example.com`). This will change the authorization endpoint to `https://login.example.com/login`. | + | **FEDERATED_LOGOUT** | (*Optional*) Indicates whether to sign out from the connection when users log out. | + +::: note +Setting the `AUTH0_CUSTOM_DOMAIN` variable does not affect the extension URL, it only changes the authorization endpoint. When a custom domain is used, users that are logging into the extension will be navigated to `https://AUTH0_CUSTOM_DOMAIN/login` instead of the default `https://tenant-name.us.auth0.com/login`. +::: + +4. Click **Install**. + + If you navigate back to the [Applications](${manage_url}/#/applications) view, you will see that there has been an additional application created by the extension. This application is authorized to access the [Management API](/api/management/v2), so you shouldn't modify it. + + ![](/media/articles/extensions/delegated-admin/two-clients.png) + +Next, learn how to [use the Delegated Admin Extension](/dashboard/guides/extensions/delegated-admin-use-extension). \ No newline at end of file diff --git a/articles/dashboard/guides/extensions/delegated-admin-use-extension.md b/articles/dashboard/guides/extensions/delegated-admin-use-extension.md new file mode 100644 index 0000000000..2947940e9b --- /dev/null +++ b/articles/dashboard/guides/extensions/delegated-admin-use-extension.md @@ -0,0 +1,32 @@ +--- +description: Learn how to use the 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. +topics: + - extensions + - delegated-admin + - dae +contentType: + - how-to +useCase: + - extensibility-extensions + - setup-delegated-admin + - use-delegated-admin +--- +# Use the Delegated Admin Extension + +This guide will show you how to use the [Delegated Admin Extension](/extensions/delegated-admin), 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. + +::: warning +Before you can use the Delegated Admin extension, you need to [create a Delegated Admin Dashboard application](/dashboard/guides/extensions/delegated-admin-create-app) in Auth0 and [install the Delegated Admin extension](/dashboard/guides/extensions/delegated-admin-install-extension). +::: + +1. Navigate to the [Extensions](${manage_url}/#/extensions) page and click on the **Installed Extensions** tab. + +2. Click on the row for the **Delegated Administration Dashboard** extension. A new tab will open to display the login prompt. + + ![](/media/articles/extensions/delegated-admin/login-prompt.png) + + Because we disabled signups for the database connection while configuring it, the login screen will not display a Sign Up option. + + Once you provide valid credentials, you will be directed to your custom **Delegated Administration 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. + + ![](/media/articles/extensions/delegated-admin/standard-dashboard.png) diff --git a/articles/dashboard/guides/extensions/sso-dashboard-add-apps.md b/articles/dashboard/guides/extensions/sso-dashboard-add-apps.md new file mode 100644 index 0000000000..a7ae60501c --- /dev/null +++ b/articles/dashboard/guides/extensions/sso-dashboard-add-apps.md @@ -0,0 +1,70 @@ +--- +description: Learn how to add applications to the SSO Dashboard Extension to enable SSO login for your applications. +topics: + - extensions + - sso-dashboard + - sso +contentType: + - how-to +useCase: + - extensibility-extensions + - setup-multiple-applications + - setup-sso-dashboard +--- + +# Add Applications to the SSO Dashboard + +Use the [SSO Dashboard Extension](/extensions/sso-dashboard) to manage SSO login for your users on multiple enterprise applications. + +Before you add the applications to the SSO Dashboard, you need to: + +* [Create the SSO Dashboard application](/dashboard/guides/extensions/sso-dashboard-create-app) +* [Install the SSO Dashboard Extension](/dashboard/guides/extensions/sso-dashboard-install-extension) + +1. Go to [Dashboard > Extensions](${manage_url}/#/extensions) and click on your new SSO Dashboard extension. + +::: note +If you are an administrator, you can also login to the SSO Dashboard using `https://${account.tenant}.8.webtask.io/auth0-sso-dashboard/admins/login`. +::: + +2. In the upper right corner, select **Settings** from the dropdown below your tenant name. + +3. Click **CREATE APP** to add a new application. + + ![Dashboard Settings](/media/articles/extensions/sso-dashboard/settings.png) + + The **New Application** form appears. + + ![Create a new application](/media/articles/extensions/sso-dashboard/new-app.png) + +4. Complete the following fields for the new application: + + | Field | Description | + | --- | --- | + | **Type** | A dropdown where you select SAML, OpenID-Connect, or WS-Federation depending on the type of application. | + | **Application** | A dropdown where you select the application that you wish to add. | + | **Name** | The name is automatically populated based on the application you selected. You can change the name or use the default. | + | **Logo** | The url of the logo you wish to user as an icon for the application. | + | **Callback** | One of the **Allowed Callback URLs** under your [Application Settings](${manage_url}/#/applications) for the application. | + | **Connection** | (*Optional*) The connection type. You can add or 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. | + | **Custom URL** | (*Optional*) Checkbox to use a custom URL rather than the Auth0 URL. If you check the box, a field appears where you can enter your custom URL. | + | **Enabled** | Checkbox for this application to be visible (published) to your users. | + +5. Click **CREATE**. + + 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) + +6. Click on an application to test the connection. + +## Keep reading + +- [Update Applications on the SSO Dashboard](/dashboard/guides/extensions/sso-dashboard-update-apps) +- [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/dashboard/guides/extensions/sso-dashboard-create-app.md b/articles/dashboard/guides/extensions/sso-dashboard-create-app.md new file mode 100644 index 0000000000..32fe012956 --- /dev/null +++ b/articles/dashboard/guides/extensions/sso-dashboard-create-app.md @@ -0,0 +1,89 @@ +--- +description: Learn how to create an application to use with the SSO Dashboard Extension to enable SSO login for your applications. +topics: + - extensions + - sso-dashboard + - sso +contentType: + - how-to +useCase: + - extensibility-extensions + - setup-multiple-sso-applications + - create-sso-dashboard-application +--- + +# Create a SSO Dashboard Application + +Use the [SSO Dashboard Extension](/extensions/sso-dashboard) to manage SSO login for your users on multiple enterprise applications. + +Before you [add the SSO Dashboard extension](/dashboard/guides/extensions/sso-dashboard-install-extension), you need to create the SSO Dashboard application in Auth0. + +1. Navigate to the [Applications](${manage_url}/#/applications) page in the [Auth0 Dashboard](${manage_url}/), and click **+Create Application**. + +2. Enter a descriptive name for your Application (for example, *SSO Dashboard*), select an application type of **Single-Page Web Application**, and click **Create**. + + ![](/media/articles/extensions/sso-dashboard/create-client.png) + +3. On the **Settings** tab, set the **Allowed Callback URLs** based on your location. + + For **Admins**: + + If you are using Node 8: + + | 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` | + + If you are using Node 12: + + | 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` | + + For **Users**: + + If you are using Node 8: + + | 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` | + + If you are using Node 12: + + | 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` | + +4. Select and copy the **Client ID** value. + +5. Scroll to the bottom of the page, and click **Show Advanced Settings**. + +6. Click the **OAuth** tab, and paste the **Client ID** value into the **Allowed APPs / APIs** field. + +7. Make sure that the **JsonWebToken Signature Algorithm** is set to **RS256**. + +8. Click **Save Changes**. + + Next, you will need to [install the SSO Dashboard Extension](/dashboard/guides/extensions/sso-dashboard-install-extension) and [add applications](/dashboard/guides/extensions/sso-dashboard-add-apps) to the dashboard. + +::: note +By default all the connection types are enabled for users to be able to login into the SSO Dashboard. If you would like to change this, navigate to the **Connections** tab for the Application. +::: + +## 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) +- [Enable SSO in Auth0](/dashboard/guides/tenants/enable-sso-tenant) +- [Understand Session Lifetime](/sessions/concepts/session-lifetime) +- [Configure Session Lifetime Settings](/dashboard/guides/tenants/configure-session-lifetime-settings) +- [Log Users Out](/logout) diff --git a/articles/dashboard/guides/extensions/sso-dashboard-install-extension.md b/articles/dashboard/guides/extensions/sso-dashboard-install-extension.md new file mode 100644 index 0000000000..63334cdce9 --- /dev/null +++ b/articles/dashboard/guides/extensions/sso-dashboard-install-extension.md @@ -0,0 +1,80 @@ +--- +description: Learn how to install the SSO Dashboard Extension to enable SSO login for your applications. +topics: + - extensions + - sso-dashboard + - sso +contentType: + - how-to +useCase: + - extensibility-extensions + - setup-multiple-applications + - setup-sso-dashboard + - install-sso-dashboard-extension +--- + +# Install the SSO Dashboard Extension + +Use the [SSO Dashboard Extension](/extensions/sso-dashboard) to manage SSO login for your users on multiple enterprise applications. + +Before you install and configure the SSO Dashboard extension, you need to [create a SSO Dashboard application](/dashboard/guides/extensions/sso-dashboard-create-app) in Auth0. + +::: note +Make sure you have copied the **Client ID** value from your SSO Dashboard application. +::: + +1. Go to [Dashboard > Extensions](${manage_url}/#/extensions) and click on your new SSO Dashboard extension. + +2. Click on the **SSO Dashboard** box in the list of provided extensions. The **Install Extension** window will open. + + ![Install SSO Dashboard Extension](/media/articles/extensions/sso-dashboard/install-extension.png) + +3. Set the following configuration variables: + + | Variable | Description | + | --- | --- | + | **EXTENSION_CLIENT_ID** | The **Client ID** of the application you have created in the [Applications](${manage_url}/#/applications) that you wish to use this extension with. | + | **TITLE** | The custom title that will appear at the top of the SSO Dashboard page. | + | **CUSTOM_CSS** | (*Optional*) A link to a custom CSS you can use to style the look of your SSO Dashboard page. | + | **FAVICON_PATH** | (*Optional*) Path to custom favicon. | + | **AUTH0_CUSTOM_DOMAIN** | (*Optional*) If you have a custom domain name configured, enter it here (for example: `login.example.com`). This will change the authorization endpoint to `https://login.example.com/login`. | + +::: note +Setting the `AUTH0_CUSTOM_DOMAIN` variable does not affect the extension URL, it only changes the authorization endpoint. When a custom domain is used, users that are logging into the extension will be navigated to `https://AUTH0_CUSTOM_DOMAIN/login` instead of the default `https://tenant-name.us.auth0.com/login`. +::: + +4. 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) + +::: note +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. +::: + +5. To use the extension, navigate to the [Extensions](${manage_url}/#/extensions) page and click on the **Installed Extensions** tab. + +6. 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) + +7. To login into the dashboard: + + For **Admins** use `https://${account.tenant}.8.webtask.io/auth0-sso-dashboard/admins/login` or through the Dashboard. + + For **Users** use `https://${account.tenant}.8.webtask.io/auth0-sso-dashboard/login`. + +## Keep reading + +- [Add Applications to the SSO Dashboard](/dashboard/guides/extensions/sso-dashboard-add-apps) +- [Update Applications on the SSO Dashboard](/dashboard/guides/extensions/sso-dashboard-update-apps) +- [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/dashboard/guides/extensions/sso-dashboard-update-apps.md b/articles/dashboard/guides/extensions/sso-dashboard-update-apps.md new file mode 100644 index 0000000000..5bced365a9 --- /dev/null +++ b/articles/dashboard/guides/extensions/sso-dashboard-update-apps.md @@ -0,0 +1,49 @@ +--- +description: Learn how to update applications on the SSO Dashboard Extension to enable SSO login for your applications. +topics: + - extensions + - sso-dashboard + - sso +contentType: + - how-to +useCase: + - extensibility-extensions + - setup-multiple-applications + - update-sso-dashboard-applications +--- + +# Update Applications on the SSO Dashboard + +Use the [SSO Dashboard Extension](/extensions/sso-dashboard) to manage SSO login for your users on multiple enterprise applications. + +Before you can update the applications to the SSO Dashboard, you need to + +* [Create the SSO Dashboard application](/dashboard/guides/extensions/sso-dashboard-create-app) in Auth0 +* [Install the SSO Dashboard Extension](/dashboard/guides/extensions/sso-dashboard-install-extension) +* [Add applications to the SSO Dashboard](/dashboard/guides/extensions/sso-dashboard-add-apps) + +1. Go to [Dashboard > Extensions](${manage_url}/#/extensions) and click on your new SSO Dashboard extension. + +::: note +If you are an administrator, you can also login to the SSO Dashboard using `https://${account.tenant}.8.webtask.io/auth0-sso-dashboard/admins/login`. +::: + +2. In the upper right corner, select **Settings** from the dropdown below your tenant name. + +3. Click **Publish** or **Unpublish** to change whether users can see the application (if it is enabled). + +4. Click the gear icon to update an application's settings. + + ![Change Application Settings](/media/articles/extensions/sso-dashboard/change-settings.png) + +5. Delete an application with the **X** button. A confirmation box will popup to confirm the deletion. + +## 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/dashboard/guides/roles/add-permissions-roles.md b/articles/dashboard/guides/roles/add-permissions-roles.md new file mode 100644 index 0000000000..b475db3a84 --- /dev/null +++ b/articles/dashboard/guides/roles/add-permissions-roles.md @@ -0,0 +1,35 @@ +--- +title: Add Permissions to Roles +description: Learn how to add permissions to roles for Auth0's API Authorization Core feature using the Auth0 Management Dashboard. +topics: + - authorization + - dashboard + - 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 Dashboard. This task can also be performed [using the Management API](/api/management/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') %> + +<%= include('../../../authorization/_includes/_predefine-roles') %> +<%= include('../../../authorization/_includes/_predefine-permissions') %> + +1. Navigate to the [Users & Roles > Roles](${manage_url}/#/roles) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the role to view. + +![Click Create Role](/media/articles/authorization/role-list-added.png) + +2. Click the **Permissions** tab, then click **Add Permissions**. + +![Add Permissions](/media/articles/authorization/role-def-empty-permissions.png) + +3. Select the API from which you want to assign permissions, then select the permissions to add to the role, and click **Add Permissions**. + +![Add Permissions to Roles](/media/articles/authorization/role-select-add-permissions.png) \ No newline at end of file diff --git a/articles/dashboard/guides/roles/create-roles.md b/articles/dashboard/guides/roles/create-roles.md new file mode 100644 index 0000000000..fd7d58683f --- /dev/null +++ b/articles/dashboard/guides/roles/create-roles.md @@ -0,0 +1,37 @@ +--- +title: Create Roles +description: Learn how to create a role using the Auth0 Management Dashboard. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - dashboard + - roles +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 Dashboard. This task can also be performed [using the Management API](/api/management/guides/roles/create-roles). The roles can be used with the API Authorization Core feature set. + +<%= include('../../../authorization/_includes/_enable-authz-core') %> + +<%= include('../../../authorization/_includes/_predefine-permissions') %> + +1. Navigate to the [Users & Roles > Roles](${manage_url}/#/roles) page in the [Auth0 Dashboard](${manage_url}/), and click **Create Role**. + +![Click Create Role](/media/articles/authorization/role-list.png) + +2. Name the role and add a description, then click **Create**. + +![Add Role](/media/articles/authorization/role-name-role.png) + +3. Click **Add Permissions**. + +![Add Permissions](/media/articles/authorization/role-def-empty-permissions.png) + +4. Select the API from which you want to add permissions, then select the permissions to add to the role, and click **Add Permissions**. + +![Add Permissions to Roles](/media/articles/authorization/role-select-add-permissions.png) \ No newline at end of file diff --git a/articles/dashboard/guides/roles/delete-roles.md b/articles/dashboard/guides/roles/delete-roles.md new file mode 100644 index 0000000000..26a4221716 --- /dev/null +++ b/articles/dashboard/guides/roles/delete-roles.md @@ -0,0 +1,28 @@ +--- +title: Delete Roles +description: Learn how to delete a role using the Auth0 Management Dashboard. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - dashboard + - 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 Dashboard. This task can also be performed [using the Management API](/api/management/guides/roles/delete-roles). Roles are used with the API Authorization Core feature set. + +<%= include('../../../authorization/_includes/_enable-authz-core') %> + +1. Navigate to the [Users & Roles > Roles](${manage_url}/#/roles) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the Role to view. + +![Select Role](/media/articles/authorization/role-list.png) + +2. Click **Remove this Role**, and confirm. + +![Delete Role](/media/articles/authorization/role-def-settings.png) \ No newline at end of file diff --git a/articles/dashboard/guides/roles/edit-role-definitions.md b/articles/dashboard/guides/roles/edit-role-definitions.md new file mode 100644 index 0000000000..64a5b4ebad --- /dev/null +++ b/articles/dashboard/guides/roles/edit-role-definitions.md @@ -0,0 +1,28 @@ +--- +title: Edit Role Definitions +description: Learn how to edit a role definition using the Auth0 Management Dashboard. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - dashboard + - 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 Dashboard. This task can also be performed [using the Management API](/api/management/guides/roles/edit-role-definitions). Roles are used with the API Authorization Core feature set. + +<%= include('../../../authorization/_includes/_enable-authz-core') %> + +1. Navigate to the [Users & Roles > Roles](${manage_url}/#/roles) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the role to view. + +![Select Role](/media/articles/authorization/role-list.png) + +2. Edit the role name and description, then click **Update Role**. + +![Edit Role Definition](/media/articles/authorization/role-def-settings.png) \ No newline at end of file diff --git a/articles/dashboard/guides/roles/remove-role-permissions.md b/articles/dashboard/guides/roles/remove-role-permissions.md new file mode 100644 index 0000000000..87caa7464c --- /dev/null +++ b/articles/dashboard/guides/roles/remove-role-permissions.md @@ -0,0 +1,28 @@ +--- +title: Remove Permissions from Roles +description: Learn how to remove permissions added to a role using the Auth0 Management Dashboard. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - dashboard + - 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 Dashboard. This task can also be performed [using the Management API](/api/management/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. Navigate to the [Users & Roles > Roles](${manage_url}/#/roles) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the role to view. + +![Select Role](/media/articles/authorization/role-list.png) + +2. Click the **Permissions** view, then click the trashcan icon next to the permission you want to remove, and confirm. + +![Remove Permissions](/media/articles/authorization/role-def-permissions.png) diff --git a/articles/dashboard/guides/roles/remove-role-users.md b/articles/dashboard/guides/roles/remove-role-users.md new file mode 100644 index 0000000000..54197358ec --- /dev/null +++ b/articles/dashboard/guides/roles/remove-role-users.md @@ -0,0 +1,29 @@ +--- +title: Remove Users from Roles +description: Learn how to remove users assigned to a role using the Auth0 Management Dashboard. 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 +--- +# Remove Users from Roles + +This guide will show you how to remove the users assigned to a [role](/authorization/concepts/rbac) using Auth0's Dashboard. This task can also be performed [using the Management API](/api/management/guides/roles/remove-role-users). Roles are used with the API Authorization Core feature set. + +<%= include('../../../authorization/_includes/_enable-authz-core') %> + +1. Navigate to the [Users & Roles > Roles](${manage_url}/#/roles) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the role to view. + +![Select Role](/media/articles/authorization/role-list.png) + +2. Click the **Users** tab, then click the trashcan icon next to the user you want to remove, and confirm. + +![View Users](/media/articles/authorization/role-def-users.png) diff --git a/articles/dashboard/guides/roles/view-role-permissions.md b/articles/dashboard/guides/roles/view-role-permissions.md new file mode 100644 index 0000000000..6edaba94e5 --- /dev/null +++ b/articles/dashboard/guides/roles/view-role-permissions.md @@ -0,0 +1,36 @@ +--- +title: View Role Permissions +description: Learn how to view permissions added to a role using the Auth0 Management Dashboard. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - dashboard + - 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 Dashboard. This task can also be performed [using the Management API](/api/management/guides/roles/view-role-permissions). The assigned permissions and roles are used with the API Authorization Core feature set. + +<%= include('../../../authorization/_includes/_enable-authz-core') %> + +1. Navigate to the [Users & Roles > Roles](${manage_url}/#/roles) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the role to view. + +![Select Role](/media/articles/authorization/role-list.png) + +2. Click the **Permissions** view. + +![View Permissions](/media/articles/authorization/role-def-permissions.png) + +The following information is displayed for each permission: + +| **Column** | **Description** | +|----------------|-----------------| +| Name | Name of the permission from the permission definition. | +| Description | Description of the permission from the permission definition. | +| API | Name of the API to which the permission is attached. | \ No newline at end of file diff --git a/articles/dashboard/guides/roles/view-role-users.md b/articles/dashboard/guides/roles/view-role-users.md new file mode 100644 index 0000000000..6cf40ff358 --- /dev/null +++ b/articles/dashboard/guides/roles/view-role-users.md @@ -0,0 +1,37 @@ +--- +title: View Role Users +description: Learn how to view users assigned to a role using the Auth0 Management Dashboard. 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](/authorization/concepts/rbac) using Auth0's Dashboard. This task can also be performed [using the Management API](/api/management/guides/roles/view-role-users). Roles are used with the API Authorization Core feature set. + +<%= include('../../../authorization/_includes/_enable-authz-core') %> + +1. Navigate to the [Users & Roles > Roles](${manage_url}/#/roles) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the role to view. + +![Select Role](/media/articles/authorization/role-list.png) + +2. Click the **Users** view. + +![View Users](/media/articles/authorization/role-def-users.png) + +The following information is displayed for each user: + +| **Attribute** | **Description** | +|---------------|-----------------| +| Picture | User's picture from the user profile. | +| Name | User's name from the user profile. | +| Email address | User's email address from the user profile. | \ No newline at end of file diff --git a/articles/dashboard/guides/rules/configure-variables.md b/articles/dashboard/guides/rules/configure-variables.md new file mode 100644 index 0000000000..746106ce23 --- /dev/null +++ b/articles/dashboard/guides/rules/configure-variables.md @@ -0,0 +1,33 @@ +--- +title: Configure Global Variables for Rules +description: Learn how to configure global variables for rules using the Auth0 Management Dashboard. Global variables are available to all rules via the configuration object. +topics: + - rules + - variables + - dashboard +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# Configure Global Variables for Rules + +This guide will show you how to configure global variables for [rules](/rules) using Auth0's Dashboard. + +1. Navigate to the [Rules](${manage_url}/#/rules) page in the [Auth0 Dashboard](${manage_url}/), and locate the **Settings** section. + +::: note +To see the **Settings** section, you must have already created at least one rule. +::: + +![View Rules](/media/articles/dashboard/rules/rules-list-with-rules.png) + +2. Enter a variable key/value pair, and click **Add**. + +![Add Global Variable](/media/articles/dashboard/rules/rules-settings-add-variable.png) + +The entered value is now available to all rules via the global `configuration` object and can be referenced using the value in the **Code Snippet** column. + +![View Variables](/media/articles/dashboard/rules/rules-list-with-rules-variables.png) diff --git a/articles/dashboard/guides/rules/create-rules.md b/articles/dashboard/guides/rules/create-rules.md new file mode 100644 index 0000000000..053087ca0f --- /dev/null +++ b/articles/dashboard/guides/rules/create-rules.md @@ -0,0 +1,33 @@ +--- +title: Create Rules +description: Learn how to create a rule using the Auth0 Management Dashboard. You can use rules to customize and extend Auth0's capabilities. +topics: + - dashboard + - 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 Dashboard. This task can also be performed [using the Management API](/api/management/guides/rules/create-rules). + +::: warning +If you plan to use global variables in your rule, be sure to [configure your rules variables](/dashboard/guides/rules/configure-variables) first. +::: + +1. Navigate to the [Rules](${manage_url}/#/rules) page in the [Auth0 Dashboard](${manage_url}/), and click **Create Rule**. + +![View Rules](/media/articles/dashboard/rules/rules-list-empty.png) + +2. Select a rule template. + +![Select Rules Template](/media/articles/dashboard/rules/rules-templates.png) + +3. Name the rule, modify the script to suit your needs, and click **Save Changes**. + +![Edit Rules Template](/media/articles/dashboard/rules/rules-edit-rule.png) \ No newline at end of file diff --git a/articles/dashboard/guides/tenants/configure-device-user-code-settings.md b/articles/dashboard/guides/tenants/configure-device-user-code-settings.md new file mode 100644 index 0000000000..94d7ca387d --- /dev/null +++ b/articles/dashboard/guides/tenants/configure-device-user-code-settings.md @@ -0,0 +1,34 @@ +--- +title: Configure Device User Code Settings +description: Learn how to configure the user code generated by your applications during the device authorization flow using the Auth0 Management Dashboard. +topics: + - device-auth + - api-authentication + - device-flow + - native-apps + - desktop-apps + - mobile-apps + - devices + - dashboard +contentType: + - how-to +useCase: + - secure-api + - call-api +--- +# Configure Device User Code Settings + +This guide will show you how to configure settings for the user code generated by your applications during the [Device Authorization Flow](/flows/concepts/device-auth) using Auth0's Dashboard. + +1. Navigate to the [Tenant Settings](${manage_url}/#/tenant) page in the [Auth0 Dashboard](${manage_url}/), and click the [**Advanced**](${manage_url}/#/tenant/advanced) tab. + +![View Advanced Tenant Settings](/media/articles/dashboard/tenants/tenant-settings.png) + +2. Scroll to the **Device Flow User Code Format** section, locate **User Code Character Set** and **User Code Mask**, enter the desired settings, and click **Save**. + +![View Device User Code Settings](/media/articles/dashboard/tenants/tenant-settings-advanced-device-user-code.png) + +| Setting | Description | +| ------- | ----------- | +| **Device Flow User Code Format** | Character set used to when randomly generating a user code. | +| **User Code Mask** | Mask used to define length and format of a randomly-generated user code. Its purpose is to increase the user code's readability and ease of input. | diff --git a/articles/dashboard/guides/tenants/configure-session-lifetime-settings.md b/articles/dashboard/guides/tenants/configure-session-lifetime-settings.md new file mode 100644 index 0000000000..68438a77f0 --- /dev/null +++ b/articles/dashboard/guides/tenants/configure-session-lifetime-settings.md @@ -0,0 +1,31 @@ +--- +title: Configure Session Lifetime Settings +description: Learn how to configure session lengths and limits for a tenant using the Auth0 Management Dashboard. +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 Dashboard. This task can also be performed [using the Management API](/api/management/guides/tenants/configure-session-lifetime-settings). + +1. Navigate to the [Tenant Settings](${manage_url}/#/tenant) page in the [Auth0 Dashboard](${manage_url}/), and click the [**Advanced**](${manage_url}/#/tenant/advanced) tab. + +![View Advanced Tenant Settings](/media/articles/dashboard/tenants/tenant-settings.png) + +2. Scroll to the **Log In Session Management** section, locate **Inactivity timeout** and **Require log in after**, enter the desired settings, and click **Save**. + +![View Log In Session Management Settings](/media/articles/dashboard/tenants/tenant-settings-advanced-login-session-management.png) + +| Setting | Description | +| ------- | ----------- | +| **Inactivity timeout** | Timeframe (in minutes) 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 4,320 minutes (3 days) for Developer or Developer Pro or 144,000 minutes (100 days) for enterprise plans. | +| **Require log in after** | Timeframe (in minutes) after which a user will be required to log in again, regardless of their activity. Will be superseded by system limits if over 43,200 minutes (30 days) for Developer or Developer Pro or 525,600 minutes (365 days) for enterprise plans. | \ No newline at end of file diff --git a/articles/dashboard/guides/tenants/create-multiple-tenants.md b/articles/dashboard/guides/tenants/create-multiple-tenants.md new file mode 100644 index 0000000000..89732892af --- /dev/null +++ b/articles/dashboard/guides/tenants/create-multiple-tenants.md @@ -0,0 +1,28 @@ +--- +description: Learn how to create an additional tenant using the Auth0 Management Dashboard. +topics: + - dashboard + - tenants +contentType: + - how-to +useCase: + - build-an-app +--- +# Create Multiple Tenants + +You can configure multiple [tenants](/getting-started/the-basics#account-and-tenants) in the Auth0 Dashboard to allow for more complex configurations. + +For instance, if you have two separate domains (for example, one internal and one public-facing) or would like to allow users to log in differently for different applications, the best solution is to create more than one Auth0 tenant. This will allow you to have separate sets of applications, connections, and users for the applications and groups of users you need to support. + +1. Open the [Auth0 Dashboard](${manage_url}/), click your tenant name, and select **+ Create Tenant**. + +![Create New Tenant](/media/articles/connections/dashboard-create-tenant.png) + +2. Enter your desired domain name, select a region, and click **Create**. + +![Save New Tenant](/media/articles/connections/tenant-create.png) + +## Keep reading + +* [Using Auth0 to Secure Your Multi-Tenant Applications](/design/using-auth0-with-multi-tenant-apps) +* [Delete or Reset Tenants](/support/delete-reset-tenant) diff --git a/articles/dashboard/guides/tenants/enable-sso-tenant.md b/articles/dashboard/guides/tenants/enable-sso-tenant.md new file mode 100644 index 0000000000..6443be4bcd --- /dev/null +++ b/articles/dashboard/guides/tenants/enable-sso-tenant.md @@ -0,0 +1,37 @@ +--- +title: Enable Single Sign-On +description: Learn how to enable Single Sign-on (SSO) for a tenant using the Auth0 Management Dashboard. Only for use with legacy tenants. +toc: true +topics: + - sso + - dashboard +contentType: + - how-to +useCase: + - integrate-saas-sso + - configure-sso + - build-an-app +--- +# Enable Single Sign-On + +By default, seamless Single Sign-on (SSO) is enabled for all new Auth0 tenants; however, legacy tenants may choose whether to enable this feature. + +This guide will show you how to enable Single Sign-on (SSO) for your tenant using Auth0's Dashboard. + +::: note +If you do not choose to enable tenant-level SSO, you may [enable it per application](/dashboard/guides/applications/enable-sso-app). +::: + +1. Navigate to the [Tenant Settings](${manage_url}/#/tenant) page in the [Auth0 Dashboard](${manage_url}/), and click the [**Advanced**](${manage_url}/#/tenant/advanced) tab. + +![View Advanced Tenant Settings](/media/articles/dashboard/tenants/tenant-settings.png) + +2. Scroll to the **Log In Session Management** section, locate **Enable Seamless SSO**, and enable the toggle. + +![View Log In Session Management Settings](/media/articles/dashboard/tenants/tenant-settings-advanced-login-session-management.png) + +::: warning +If you do not see this setting available in the Dashboard, you already have Seamless SSO enabled; this toggle is strictly for legacy tenants. +::: + +Once finished, you should also [configure your session lifetime settings](/dashboard/guides/tenants/configure-session-lifetime-settings). diff --git a/articles/dashboard/guides/tenants/revoke-signing-keys.md b/articles/dashboard/guides/tenants/revoke-signing-keys.md new file mode 100644 index 0000000000..e1f64dda5d --- /dev/null +++ b/articles/dashboard/guides/tenants/revoke-signing-keys.md @@ -0,0 +1,95 @@ +--- +title: Revoke Signing Keys +description: Learn how to revoke your tenant's application signing key using the Auth0 Dashboard and Auth0 Management API. Application signing keys are 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 + - dashboard + - mgmt-api +contentType: + - how-to +useCase: + - secure-api + - add-login + - call-api +--- + +# Revoke Signing Keys + +You can revoke your tenant's application signing key using the Auth0 Dashboard and Auth0 Management API. The application signing key is used to sign ID Tokens, Access Tokens, SAML assertions, and WS-Fed assertions sent to your application. To learn more, see [Manage Signing Keys](/tokens/guides/manage-signing-keys). + +::: warning +Before you can revoke a previously-used application signing key, you must first have rotated the key. To learn how, see [Rotate Signing Keys](/dashboard/guides/tenants/rotate-signing-keys), or learn how to [rotate and revoke signing keys at the same time](/dashboard/guides/tenants/revoke-signing-keys#rotate-and-revoke-signing-key). + +Make sure you have updated your application with the new key before you revoke the previous key. +::: + +
        +
        + +
        +
        +
        + +## Revoke signing key + +1. Navigate to the [Tenant Settings](${manage_url}/#/tenant) page in the [Auth0 Dashboard](${manage_url}/), and click the [**Signing Keys**](${manage_url}/#/tenant/signing_keys) tab. + +![View Advanced Tenant Settings](/media/articles/dashboard/tenants/tenant-settings.png) + +2. Scroll to the **List of Valid Keys** section, locate the **Previously Used** key, click its more options (**...**) menu, and select **Revoke Key**. + +![View Signing Key Tenant Settings](/media/articles/dashboard/tenants/tenant-settings-signing-keys-revoke.png) + +3. Confirm revocation by clicking **Revoke**. + +![Confirm Revoking Signing Key](/media/articles/dashboard/tenants/tenant-settings-signing-keys-revoke-confirm.png) + +## Rotate and revoke signing key + +1. Navigate to the [Tenant Settings](${manage_url}/#/tenant) page in the [Auth0 Dashboard](${manage_url}/), and click the [**Signing Keys**](${manage_url}/#/tenant/signing_keys) tab. + +![View Advanced Tenant Settings](/media/articles/dashboard/tenants/tenant-settings.png) + +2. In the **Rotation Settings** section, locate the **Rotate & Revoke Signing Key** section, and select **Rotate & Revoke Key**. + +![View Signing Key Tenant Settings](/media/articles/dashboard/tenants/tenant-settings-signing-keys.png) + +3. Confirm rotation and revocation by clicking **Rotate & Revoke**. + +![Confirm Revoking Signing Key](/media/articles/dashboard/tenants/tenant-settings-signing-keys-rotate-revoke-confirm.png) +
        +
        + +::: warning +You may only revoke the previously used signing key. +::: + +1. Make a `PUT` call to the [Revoke Signing Key endpoint](/api/management/v2#!/signing_keys/post_signing_key). Be sure to replace the `YOUR_KEY_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your signing key's ID and Management API Access Token, respectively. + +```har +{ + "method": "PUT", + "url": "https://${account.namespace}/api/v2/keys/signing/YOUR_KEY_ID/revoke", + "headers": [ + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" } + ] +} +``` + +| **Value** | **Description** | +| - | - | +| `YOUR_KEY_ID` | ID of the signing key to be revoked. To learn how to find your signing key ID, see [Locate JSON Web Key Sets](/tokens/guides/locate-jwks). | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `update:signing_keys`. | + +
        +
        +
        diff --git a/articles/dashboard/guides/tenants/rotate-signing-keys.md b/articles/dashboard/guides/tenants/rotate-signing-keys.md new file mode 100644 index 0000000000..f2f29730c9 --- /dev/null +++ b/articles/dashboard/guides/tenants/rotate-signing-keys.md @@ -0,0 +1,76 @@ +--- +title: Rotate Signing Keys +description: Learn how to rotate your tenant's application signing key using the Auth0 Dashboard and Auth0 Management API. Application signing keys are 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 + - dashboard + - mgmt-api +contentType: + - how-to +useCase: + - secure-api + - add-login + - call-api +--- + +# Rotate Signing Keys + +You can rotate your tenant's application signing key using the Auth0 Dashboard and Auth0 Management API. The application signing key is used to sign ID Tokens, Access Tokens, SAML assertions, and WS-Fed assertions sent to your application. To learn more, see [Manage Signing Keys](/tokens/guides/manage-signing-keys). + +::: warning +To allow you time to update your application with the new key, all tokens signed with the previous key will still be valid until you revoke the previous key. To learn more, see [Revoke Signing Keys](/dashboard/guides/tenants/revoke-signing-keys), or learn how to [rotate and revoke signing keys at the same time](/dashboard/guides/tenants/revoke-signing-keys#rotate-and-revoke-signing-key). +::: + +
        +
        + +
        +
        +
        + +1. Navigate to the [Tenant Settings](${manage_url}/#/tenant) page in the [Auth0 Dashboard](${manage_url}/), and click the [**Signing Keys**](${manage_url}/#/tenant/signing_keys) tab. + +![View Advanced Tenant Settings](/media/articles/dashboard/tenants/tenant-settings.png) + +2. Scroll to the **Rotation Settings** section, locate **Rotate Signing Key**, and click **Rotate Key**. + +![View Signing Key Tenant Settings](/media/articles/dashboard/tenants/tenant-settings-signing-keys.png) + +3. Confirm rotation by clicking **Rotate**. + +![Confirm Signing Key Rotation](/media/articles/dashboard/tenants/tenant-settings-signing-keys-rotate-confirm.png) +
        +
        + +1. Make a `POST` call to the [Rotate Signing Keys endpoint](/api/management/v2#!/signing_keys/post_signing_key). Be sure to replace the `MGMT_API_ACCESS_TOKEN` placeholder value with your Management API Access Token. + +```har +{ + "method": "POST", + "url": "https://${account.namespace}/api/v2/keys/signing/rotate", + "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 scopes `create:signing_keys` and `update:signing_keys`. | + +
        +
        +
        + + + + diff --git a/articles/dashboard/guides/tenants/view-signing-keys.md b/articles/dashboard/guides/tenants/view-signing-keys.md new file mode 100644 index 0000000000..81e5575528 --- /dev/null +++ b/articles/dashboard/guides/tenants/view-signing-keys.md @@ -0,0 +1,99 @@ +--- +title: View Signing Keys +description: Learn how to view your tenant's application signing keys using the Auth0 Dashboard and Auth0 Management API. Application signing keys are 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 + - dashboard + - mgmt-api +contentType: + - how-to +useCase: + - secure-api + - add-login + - call-api +--- + +# View Signing Keys + +You can view your tenant's application signing keys using the Auth0 Dashboard and Auth0 Management API. The application signing key is used to sign ID Tokens, Access Tokens, SAML assertions, and WS-Fed assertions sent to your application. To learn more, see [Manage Signing Keys](/tokens/guides/manage-signing-keys). + +::: note +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 learn more, see [SAML Identity Provider Configuration: Signed Assertions](/protocols/saml/samlp#signed-assertions). +::: + +
        +
        + +
        +
        +
        + +1. Navigate to the [Tenant Settings](${manage_url}/#/tenant) page in the [Auth0 Dashboard](${manage_url}/), and click the [**Signing Keys**](${manage_url}/#/tenant/signing_keys) tab. + +![View Advanced Tenant Settings](/media/articles/dashboard/tenants/tenant-settings.png) + +2. Scroll to the **Settings** section, and locate **List of Valid Keys** and **List of Revoked Keys**. + +![View Signing Key Tenant Settings](/media/articles/dashboard/tenants/tenant-settings-signing-keys.png) + +The **List of Valid Keys** section lists the current signing key being used by your tenant, plus the next signing key that will be assigned should you choose to rotate your signing keys. If you have previously rotated signing keys, this section also lists the previously used keys. + +The **List of Revoked Keys** section lists the last three revoked keys for your tenant. +
        +
        + +## Get all signing keys + +1. Make a `GET` call to the [Get All Signing Keys endpoint](/api/management/v2#!/signing_keys/get_signing_keys). Be sure to replace the `MGMT_API_ACCESS_TOKEN` placeholder value with your Management API Access Token. + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/api/v2/keys/signing", + "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:signing_keys`. | + +## Get a single signing key + +1. Make a `GET` call to the [Get a Signing Key endpoint](/api/management/v2#!/signing_keys/get_signing_key). Be sure to replace the `YOUR_KEY_ID` and `MGMT_API_ACCESS_TOKEN` placeholder values with your signing key's ID and Management API Access Token, respectively. + +```har +{ + "method": "GET", + "url": "https://${account.namespace}/api/v2/keys/signing/YOUR_KEY_ID", + "headers": [ + { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" } + ] +} +``` + +| **Value** | **Description** | +| - | - | +| `YOUR_KEY_ID` | ID of the signing key to be viewed. To learn how to find your signing key ID, see [Locate JSON Web Key Sets](/tokens/guides/locate-jwks). | +| `MGMT_API_ACCESS_TOKEN` | [Access Token for the Management API](/api/management/v2/tokens) with the scope `read:signing_keys`. | + +
        +
        +
        + + + + diff --git a/articles/dashboard/guides/universal-login/configure-login-page-passwordless.md b/articles/dashboard/guides/universal-login/configure-login-page-passwordless.md new file mode 100644 index 0000000000..d522958afc --- /dev/null +++ b/articles/dashboard/guides/universal-login/configure-login-page-passwordless.md @@ -0,0 +1,73 @@ +--- +title: Configure Universal Login with Passwordless +description: Learn how to configure your login page for use with passwordless authentication using the Auth0 Management Dashboard. +topics: + - universal-login + - passwordless + - login-page + - lock + - dashboard + - auth0-js +contentType: + - how-to +useCase: + - build-an-app +--- +# Configure Universal Login with Passwordless + +[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. + +This guide will show you how to set up a login page for use with [passwordless authentication](/connections/passwordless) using Auth0's Dashboard. + +::: warning +For passwordless authentication to work properly when previewing your login page, you must first have [configured a passwordless connection](/connections/passwordless#implement-passwordless) for your application. +::: + +When setting up a login page for passwordless, you have a few options. To learn how to configure your universal login page to use passwordless, select your implementation: + +
        +
        + +
        +
        +
        + +## Universal Login + Lock (passwordless) + +This login page uses the [Classic](/universal-login/classic) [Universal Login](/universal-login) experience with the **Lock (passwordless)** template. To authenticate users, this template uses the [Auth0 Lock widget with Passwordless mode](/libraries/lock/v11#passwordless) and can be customized accordingly. + +1. Navigate to the [Universal Login](${manage_url}/#/login_settings) page in the [Auth0 Dashboard](${manage_url}/), and click the **Login** tab. + +2. Enable the **Custom Login Page** toggle, and select the **Lock (passwordless)** template. + +The HTML template will update with code using the Lock widget with passwordless customization options. + +3. Customize the template, and click **Save Changes**. + +You can use HTML and CSS to customize the login form. To learn more about how to customize the **Lock (passwordless)** template, see [Lock: Passwordless](/libraries/lock/v11#passwordless). + +You can preview customization changes. Make sure to select the correct application for which you want to preview the login page. +
        +
        + +## Universal Login + Custom UI + Auth0.js + +This login page uses the [Classic](/universal-login/classic) [Universal Login](/universal-login) experience with the **Custom Login Form** template. To authenticate users, this template uses the [Auth0.js SDK](/libraries/auth0js) and can be customized accordingly. + +1. Navigate to the [Universal Login](${manage_url}/#/login_settings) page in the [Auth0 Dashboard](${manage_url}/), and click the **Login** tab. + +2. Enable the **Custom Login Page** toggle, and select the **Custom Login Form** template. + +The HTML template will update with code using CSS and the Auth0.js SDK. + +3. Customize the template, and click **Save Changes**. + +You can use HTML and CSS to customize the login form. To learn more about how to use the Auth0.js SDK with the **Custom Login Form** template, see [Auth0.js SDK: Passwordless Login](/libraries/auth0js/v9#passwordless-login). + +You can preview customization changes. Make sure to select the correct application for which you want to preview the login page. +
        +
        +
        \ No newline at end of file diff --git a/articles/dashboard/guides/users/assign-permissions-users.md b/articles/dashboard/guides/users/assign-permissions-users.md new file mode 100644 index 0000000000..895504e56f --- /dev/null +++ b/articles/dashboard/guides/users/assign-permissions-users.md @@ -0,0 +1,53 @@ +--- +title: Assign Permissions to Users +description: Learn how to assign permissions to a user using the Auth0 Management Dashboard. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - dashboard + - 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 Dashboard. This task can also be performed [using the Management API](/api/management/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') %> + +<%= include('../../../authorization/_includes/_predefine-permissions') %> + +1. Navigate to the [Users & Roles > Users](${manage_url}/#/users) page in the [Auth0 Dashboard](${manage_url}/). + +![View Users](/media/articles/authorization/user-list.png) + +2. Click **`...`** next to the user you want to modify, and select **Assign Permissions**. + +![Select Assign Permissions](/media/articles/authorization/user-list-assign-permissions.png) + +3. Select the API from which you want to assign permissions, then select the permissions to assign to the user, and click **Add Permissions**. + +![Assign Permissions](/media/articles/authorization/user-add-permissions.png) + +You can also assign permissions to users from their individual profile page. + +1. Navigate to the [Users & Roles > Users](${manage_url}/#/users) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the user to view. + +![Select User](/media/articles/authorization/user-list.png) + +2. Click the **Permissions** tab, and click **Assign Permissions**. + +![View Roles](/media/articles/authorization/user-prof-empty-permissions.png) + +3. Select the API from which you want to assign permissions, then select the permissions to assign to the user, and click **Add Permissions**. + +![Assign Permissions](/media/articles/authorization/user-add-permissions.png) \ No newline at end of file diff --git a/articles/dashboard/guides/users/assign-roles-users.md b/articles/dashboard/guides/users/assign-roles-users.md new file mode 100644 index 0000000000..273a365afc --- /dev/null +++ b/articles/dashboard/guides/users/assign-roles-users.md @@ -0,0 +1,50 @@ +--- +title: Assign Roles to Users +description: Learn how to assign roles to a user using the Auth0 Management Dashboard. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - dashboard + - 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 Dashboard. This task can also be performed [using the Management API](/api/management/guides/users/assign-roles-users). The assigned roles can be used with the API Authorization Core feature set. + +<%= include('../../../authorization/_includes/_enable-authz-core') %> + +<%= include('../../../authorization/_includes/_predefine-roles') %> + +1. Navigate to the [Users & Roles > Users](${manage_url}/#/users) page in the [Auth0 Dashboard](${manage_url}/). + +![View Users](/media/articles/authorization/user-list.png) + +2. Click **`...`** next to the user you want to modify, and select **Assign Roles**. + +![Select Assign Roles](/media/articles/authorization/user-list-assign-roles.png) + +3. Choose the role(s) you wish to assign, then click **Assign**. + +![Assign Role](/media/articles/authorization/user-assign-roles.png) + + +You can also assign roles to users from their individual profile page. + +1. Navigate to the [Users & Roles > Users](${manage_url}/#/users) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the user to view. + +![Select User](/media/articles/authorization/user-list.png) + +2. Click the **Roles** view, and click **Assign Role**. + +![View Roles](/media/articles/authorization/user-prof-empty-roles.png) + +3. Choose the role you wish to assign, then click **Assign**. + +![Assign Role](/media/articles/authorization/user-assign-roles.png) \ No newline at end of file diff --git a/articles/dashboard/guides/users/create-users.md b/articles/dashboard/guides/users/create-users.md new file mode 100644 index 0000000000..1ba0374261 --- /dev/null +++ b/articles/dashboard/guides/users/create-users.md @@ -0,0 +1,23 @@ +--- +title: Create Users +description: Learn how to create a user using the Auth0 Management Dashboard. +topics: + - dashboard + - users + - user-profile +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# Create Users + +This guide will show you how to create a user using Auth0's Dashboard. + +1. Navigate to the [Users & Roles > Users](${manage_url}/#/users) page in the [Auth0 Dashboard](${manage_url}/), and click **+ Create User**. + +![View Users](/media/articles/authorization/user-list.png) + +2. Enter your user's **Email**, **Password**, and **Repeat Password**, then select the **Connection**, and click **Create**. \ No newline at end of file diff --git a/articles/dashboard/guides/users/remove-user-permissions.md b/articles/dashboard/guides/users/remove-user-permissions.md new file mode 100644 index 0000000000..94353eef5c --- /dev/null +++ b/articles/dashboard/guides/users/remove-user-permissions.md @@ -0,0 +1,29 @@ +--- +title: Remove Permissions from Users +description: Learn how to remove permissions directly assigned to a user using the Auth0 Management Dashboard. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - dashboard + - 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 Dashboard. This task can also be performed [using the Management API](/api/management/guides/users/remove-user-permissions). The assigned permissions are used with the API Authorization Core feature set. + +<%= include('../../../authorization/_includes/_enable-authz-core') %> + +1. Navigate to the [Users & Roles > Users](${manage_url}/#/users) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the user to view. + +![Select User](/media/articles/authorization/user-list.png) + +2. Click the **Permissions** view, then click the trashcan icon next to the permission you want to remove, and confirm. + +![Remove Permissions](/media/articles/authorization/user-prof-permissions.png) diff --git a/articles/dashboard/guides/users/remove-user-roles.md b/articles/dashboard/guides/users/remove-user-roles.md new file mode 100644 index 0000000000..c231371b98 --- /dev/null +++ b/articles/dashboard/guides/users/remove-user-roles.md @@ -0,0 +1,30 @@ +--- +title: Remove Roles from Users +description: Learn how to remove roles assigned to a user using the Auth0 Management Dashboard. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - dashboard + - permissions + - roles + - users + - user-profile +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 Dashboard. This task can also be performed [using the Management API](/api/management/guides/users/remove-user-roles). The assigned roles are used with the API Authorization Core feature set. + +<%= include('../../../authorization/_includes/_enable-authz-core') %> + +1. Navigate to the [Users & Roles > Users](${manage_url}/#/users) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the user to view. + +![Select User](/media/articles/authorization/user-list.png) + +2. Click the **Roles** view, then click the trashcan icon next to the role you want to remove. + +![Remove Roles](/media/articles/authorization/user-prof-roles.png) diff --git a/articles/dashboard/guides/users/unlink-user-devices.md b/articles/dashboard/guides/users/unlink-user-devices.md new file mode 100644 index 0000000000..d7c4a8f478 --- /dev/null +++ b/articles/dashboard/guides/users/unlink-user-devices.md @@ -0,0 +1,30 @@ +--- +title: Unlink Devices from Users +description: Learn how to unlink devices assigned to a user using the Auth0 Management Dashboard. This effectively revokes the Refresh Token for the device. +topics: + - authorization + - dashboard + - devices + - native-apps + - desktop-apps + - mobile-apps + - users + - user-profile +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# Unlink Devices from Users + +This guide will show you how to unlink the devices assigned to a user using Auth0's Dashboard. This effectively revokes the Refresh Token for the selected device. + +1. Navigate to the [Users & Roles > Users](${manage_url}/#/users) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the user to view. + +![Select User](/media/articles/dashboard/guides/users-roles/users-list.png) + +2. Click the **Devices** view, then click the trashcan icon next to the device you want to unlink, and confirm. + +![Unlink Device](/media/articles/dashboard/guides/users-roles/users-prof-devices.png) diff --git a/articles/dashboard/guides/users/view-user-permissions.md b/articles/dashboard/guides/users/view-user-permissions.md new file mode 100644 index 0000000000..58e589c006 --- /dev/null +++ b/articles/dashboard/guides/users/view-user-permissions.md @@ -0,0 +1,38 @@ +--- +title: View User Permissions +description: Learn how to view permissions assigned to a user using the Auth0 Management Dashboard. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - dashboard + - permissions + - users + - user-profile +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# View User Permissions + +This guide will show you how to view the [permissions](/authorization/concepts/rbac) assigned to a user using Auth0's Dashboard. This task can also be performed [using the Management API](/api/management/guides/users/view-user-permissions). The assigned permissions are used with the API Authorization Core feature set. + +<%= include('../../../authorization/_includes/_enable-authz-core') %> + +1. Navigate to the [Users & Roles > Users](${manage_url}/#/users) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the user to view. + +![Select User](/media/articles/authorization/user-list.png) + +2. Click the **Permissions** view. + +![View Permissions](/media/articles/authorization/user-prof-permissions.png) + +The following information is displayed for each permission: + +| **Column** | **Description** | +|------------|-----------------| +| Name | Name of the permission from the permission definition. | +| Description | Description of the permission from the permission definition. | +| API | Name of the API to which the permission is attached. | +| Assignment | Indicates whether the permission is directly assigned to the user or is assigned via a role. | diff --git a/articles/dashboard/guides/users/view-user-roles.md b/articles/dashboard/guides/users/view-user-roles.md new file mode 100644 index 0000000000..3e9f0d7ace --- /dev/null +++ b/articles/dashboard/guides/users/view-user-roles.md @@ -0,0 +1,37 @@ +--- +title: View User Roles +description: Learn how to view roles assigned to a user using the Auth0 Management Dashboard. For use with Auth0's API Authorization Core feature set. +topics: + - authorization + - dashboard + - permissions + - roles + - users + - user-profile +contentType: + - how-to +useCase: + - build-an-app + - call-api + - secure-api +--- +# View User Roles + +This guide will show you how to view the [roles](/authorization/concepts/rbac) assigned to a user using Auth0's Dashboard. This task can also be performed [using the Management API](/api/management/guides/users/view-user-roles). The assigned roles are used with the API Authorization Core feature set. + +<%= include('../../../authorization/_includes/_enable-authz-core') %> + +1. Navigate to the [Users & Roles > Users](${manage_url}/#/users) page in the [Auth0 Dashboard](${manage_url}/), and click the name of the user to view. + +![Select User](/media/articles/authorization/user-list.png) + +2. Click the **Roles** view. + +![View Roles](/media/articles/authorization/user-prof-roles.png) + +The following information is displayed for each role: + +| **Column** | **Description** | +|------------|-----------------| +| Name | Name of the role from the role definition. | +| Description | Description of the role from the role definition. | diff --git a/articles/dashboard/index.md b/articles/dashboard/index.md new file mode 100644 index 0000000000..a0742835c4 --- /dev/null +++ b/articles/dashboard/index.md @@ -0,0 +1,47 @@ +--- +title: Dashboard +description: Working with the Dashboard +classes: topic-page +topics: + - dashboard +contentType: + - index + - how-to +useCase: manage-accounts +--- + +
        +
        +

        Dashboard

        +

        + When working in the Dashboard, you may find the following articles helpful. +

        +
        + + + diff --git a/articles/dashboard/manage-dashboard-admins.md b/articles/dashboard/manage-dashboard-admins.md new file mode 100644 index 0000000000..9231bdb8f4 --- /dev/null +++ b/articles/dashboard/manage-dashboard-admins.md @@ -0,0 +1,88 @@ +--- +description: Learn how to manage tenant administrators in the Auth0 Dashboard. +topics: + - dashboard + - admins +contentType: how-to +useCase: + - manage-users + - manage-accounts +--- +# Manage Tenant Administrators in the Dashboard + +::: note +Please see [Reset Your Auth0 Account Password](/tutorials/reset-account-password) if you're having issues logging in. +::: + +You can add, edit, and remove tenant administrators from the Dashboard by going to **Tenant Settings** > [Dashboard Admins](${manage_url}/#/tenant/admins). + +![Change Dashboard Admins](/media/articles/tutorials/manage-admins.png) + +::: warning +You are responsible for managing your tenant administrators, **including revoking privileges from users as necessary**. You are responsible for all activities that occur under your account/tenant. +::: + +## Add administrators + +To add an administrator, enter their email and select the applications to which you would like this user to have administrative access in the **Application** box. Click **ADD**. + +When the recipient opens and accepts the invitation, the current Auth0 account in the browser will be added as a Dashboard Admin (as long as the user is logged in with an account linked to the email address to which the invitation was sent; if not, the user will be prompted to log in with an account linked to the invitation email address). If there is no current session, the recipient will be prompted to log in or create an Auth0 account. + +::: note +If the invited administrator has not created an Auth0 admin user account, they will need to do so in order to be able to accept the invitation and log into the Management Dashboard. Auth0 admin users are managed separately from tenant users; accounts can be created by following the invitation URL or signing up through [auth0.com/signup](https://auth0.com/signup). +::: + +Administrators are application-specific, so areas to which the admin doesn't have access rights (e.g., APIs, Rules, Hooks, Universal Login Pages, and so on) will appear as blank pages. Administrators will also *not* be allowed to manage users, create rules, and perform other functions for applications to which they don't have access. + +::: panel Application-Specific Access +Application-specific access includes the following: + +* Read and write access to the specific application configuration +* Read access to enabled connections for the application +* Ability to configure add-ons for the specific application +* Read (not write) access to all user records + +In addition, a user can be invited to be an administrator for multiple applications, but each application invite must be sent and accepted individually. +::: + +## Update administrators + +To update the email address associated with an existing tenant administrator, send an invite using the new email address. Once they accept the invite, you can remove the tenant administrator associated with the old email address. + +### Remove administrators + +You can remove administrators by clicking **REMOVE** after they have been added. + +## Add, change or remove MFA + +The administrator can self-enroll for [Multi-factor Authentication](/mfa). The MFA indicator will indicate whether an administrator has enabled their account for MFA, which they can do in their Account Settings. + +### Add MFA + +![Dashboard Admins with MFA Indicator](/media/articles/tutorials/dashboard-admins.png) + +To self-enroll for MFA, the administrator should click on their user name in the top right and going to **View Profile** in the dropdown menu. + +Click **Enroll your device now.** + +![Admin Profile](/media/articles/tutorials/your-profile.png) + +Follow the on-screen instructions to complete the enrollment. + +### Remove or change MFA + +You can remove or change factors if they are lost. + +If you are changing devices and will no longer have your device, remove it by verifying MFA with that device. You will be prompted for it, and then it will be removed. If you no longer have access to your device, you can use your recovery code to do this process with the same results. Then, you can add a new device. + +If you no longer have access to your device or recovery code, another admin should file an Auth0 [support ticket](/support/tickets) on your behalf so Auth0 can verify the request and proceed with an MFA reset. This only applies for Dashboard Admin accounts. **Auth0 will not process end-user accounts MFA resets**, as we do not have control over our customer's tenants. + +## Add Support-Only Users + +If you want to allow employees of your organization to have access to our [Support Center](https://support.auth0.com), but you don't want to give them complete Administrator access over the tenant or a particular application, you can alternatively add them as Support-Only users. If that's the case, please follow the instructions described in our [Support Options](/support#add-support-only-users) documentation. + +## Find missing tenants + +We've occasionally found that Dashboard administrations inadvertently create multiple Auth0 accounts. For example, they might sign up with a social provider (e.g., Google, GitHub), then sign up again using the email address. If you have a Dashboard administrator that reports that they cannot see all of their tenants after logging in, check to see if they have multiple Auth0 accounts. + +You can confirm the signup method used by the Dashboard adminsitrator by going to **Tenant Settings** > [**Dashboard Admins**](${manage_url}/#/tenant/admins). diff --git a/articles/dashboard/reference/settings-api.md b/articles/dashboard/reference/settings-api.md new file mode 100644 index 0000000000..9173b77738 --- /dev/null +++ b/articles/dashboard/reference/settings-api.md @@ -0,0 +1,30 @@ +--- +title: API Settings +description: Learn about the settings related to APIs available in the Auth0 Dashboard. +topics: + - api-authentication + - oidc + - apis + - dashboard +contentType: reference +useCase: + - secure-api + - call-api +--- +# API Settings + +On the [APIs](${manage_url}/#/apis) page of the [Auth0 Dashboard](${manage_url}/), locate your API and click its name to view the available settings. + +- **Id**: A unique alphanumeric string generated by Auth0. This 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 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 this is enabled, the User Consent dialog will not be shown to the end user when a first-party application requests authorized access against your API. Please 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 Offline Access**: When this is enabled, Auth0 will allow applications to ask for Refresh Tokens for your API. + +- **Signing Algorithm**: The algorithm with which to sign the tokens. The available values are `HS256` and `RS256`. When selecting `RS256` (recommended), the token will be signed with your tenant's private key. This value is set when your API is created and cannot be modified afterwards. To learn more about signing algorithms, see [Signing Algorithms](/tokens/concepts/signing-algorithms). diff --git a/articles/dashboard/reference/settings-application.md b/articles/dashboard/reference/settings-application.md new file mode 100644 index 0000000000..3d7c8c4e10 --- /dev/null +++ b/articles/dashboard/reference/settings-application.md @@ -0,0 +1,112 @@ +--- +title: Application Settings +description: Learn about the settings related to applications available in the Auth0 Dashboard. +topics: + - api-authentication + - oidc + - applications + - dashboard +contentType: reference +useCase: + - add-login +--- +# Application Settings + +On the [Applications](${manage_url}/#/applications) page of the [Auth0 Dashboard](${manage_url}/), locate your Application and click its name to view the available settings. + +## Basic Settings + +![Application Settings Page](/media/articles/applications/settings.png) + +- **Name**: The name of your application. Editable, and will be seen in the portal, emails, logs, and so on. + +- **Domain**: Your Auth0 tenant name. You choose this when you create a new Auth0 tenant, and it cannot be changed. If you need a different domain, you must register for a new tenant by selecting **+ Create Tenant** in the top-right menu. + +- **Client ID**: The unique identifier for your application. You will use this when configuring authentication with Auth0. Generated by the system when you create a new application and 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 it. + +::: 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 be able to access. +::: + +- **Description**: A free-text description of the Application's purpose. Maximum of 140 characters. + +- **Application Logo**: The URL to a logo (recommended size: 150x150 pixels) to be displayed for the application. Appears in several areas, including the list of applications in the Dashboard and customized consent forms. + +- **Application Type**: The [Auth0 application type](/applications). Determines which settings you can configure using the Dashboard. Not editable for M2M Apps. Sometimes disabled for other Auth0 application types if the selected grant types are only allowed for the currently selected application type. + +- **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), and `Basic` (client uses HTTP Basic). Only editable for Regular Web Apps and M2M Apps. + +::: 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 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](/applications/reference/wildcard-subdomains) (`*.google.com`). Make sure to specify the protocol, `http://` or `https://`; otherwise, the callback may fail in some cases. + +- **Application Login URI**: In some scenarios Auth0 will need your application to start the OIDC login flow. This URI should point to a route in your application that starts the flow, by redirecting to the `/authorize` endpoint. It would usually take the form of 'https://myapp.org/login'. [Learn more](/universal-login/default-login-url). + +- **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**: List of URLs to which you can redirect users after they log out from Auth0. Use the `returnTo` query parameter to redirect them. 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](/applications/reference/wildcard-subdomains) (`*.google.com`). Querystrings and hash information are not taken into account when validating these URLs. For more info, see [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](/applications/reference/wildcard-subdomains) (`*.google.com`). 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`, which maps to 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 or ADFS). **Legacy tenants only.** + +## Advanced Settings + +The **Advanced Settings** section allows you to: + +* Manage or add Application Metadata, Device, 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. + +### 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**. + +### 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. For more info, see [Signing Algorithms](/tokens/concepts/signing-algorithms). + +* 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. This setting is only available for Regular Web Apps and M2M Apps. + +* Toggle the switch to indicate if your application is **OIDC Conformant** or not. Applications flagged as OIDC Conformant will strictly follow the OIDC specification. + +* Set the location URL for **Cross-Origin Verification Fallback**. This is the location of the page that will be rendered inside an iframe to perform the token verification when third-party cookies are not enabled in the browser. Must be in the same domain where the embedded login form is hosted and must have an `https` scheme. + +### Grant Types + +Select grant types to enable or disable for your application. Available grant types are based on the application type. + +### WS-Federation + +Manage or add WS-Federation settings. + +### Certificates + +Manage or add the signing certificate, and its fingerprint and thumbprint. + +### Endpoints + +View endpoint information for OAuth, SAML, and WS-Fed. + diff --git a/articles/dashboard/reference/settings-tenant.md b/articles/dashboard/reference/settings-tenant.md new file mode 100644 index 0000000000..baed139bae --- /dev/null +++ b/articles/dashboard/reference/settings-tenant.md @@ -0,0 +1,173 @@ +--- +title: Tenant Settings +description: Learn about the settings related to tenants available in the Auth0 Dashboard. +toc: true +topics: + - dashboard + - tenants +contentType: reference +useCase: manage-accounts +--- + +# Tenant Settings + +The [Tenant Settings](${manage_url}/#/tenant) page of the [Auth0 Dashboard](${manage_url}/) allows you to configure various settings related to your Auth0 tenant. + +## General + +The **General** tab contains settings that are typically set for tenants. Use this section to customize general tenant settings that will be used in the [Lock](https://auth0.com/lock) widget, emails, and various other pages displayed to your users. + +### Basic Settings + +![Tenant Settings: Basic Settings](/media/articles/tutorials/tenant-settings/settings.png) + +* **Friendly Name**: Name you want displayed to your users, usually the name of your company or organization. +* **Logo URL**: URL of your logo; it should be a square. This image will appear to your users on various screens and pages. +* **Support Email**: Email address used to contact your support team. +* **Support URL**: Link to your company/organization support page. + +### API Authorization Settings + +* **Default Audience**: API Identifier that should be the default audience when using [API Authorization](/api-auth) flows. If you enter a value, all [Access Tokens](/tokens/access-token) issued by Auth0 will specify this API Identifier as an audience. + +The Default Audience setting does not affect the [Client Credentials flow](/api-auth/tutorials/client-credentials). Clients will still need to provide an `audience` for these requests. + +::: note +Setting the Default Audience is equivalent to appending this audience to every authorization request made to your tenant for every application. This will cause new behavior that might result in breaking changes for some of your applications. Please contact support if you require assistance. +::: + +* **Default Directory**: Name of the connection to be used for [Password Grant exchanges](/api-auth/tutorials/password-grant). Its value should be the exact name of an existing [connection](/connections) for one of the following strategies: `auth0-adldap`, `ad`, `auth0`, `email`, `sms`, `waad`, or `adfs`. + +### Error Pages + +![Tenant Settings: Error Pages](/media/articles/tutorials/tenant-settings/error-pages.png) + +In the event of an authorization error, you can either display a generic error page to your users or you can redirect users to your own custom error page. To learn more, see [Custom Error Pages](/universal-login/custom-error-pages). + +### Languages + +* **Default Language**: Language your tenant will use by default. + +* **Supported Languages**: Languages also supported by your tenant. + +## Subscription + +![Tenant Settings: Subscription](/media/articles/tutorials/tenant-settings/billing.png) + +The **Subscription** tab allows you to review your current subscription and compare features of your current plan to other Auth0 subscription plans. You may also change your subscription plan. To learn more, see [Changing Your Subscription](/support/subscription). + +## Payment + +The **Payment** tab allows you to enter or update your billing details. + +## Active Users + +**Active Users** functionality has been moved to the [Quota Utilization Report](https://support.auth0.com/reports/quota) in the Support Center. + +## Dashboard Admins + +The **Dashboard Admin** tab lists administrators assigned to your tenant. You may also add or remove tenant administrators and review whether administrator accounts have multi-factor authentication (MFA) enabled. To learn more, see [Manage Dashboard Admins](/tutorials/manage-dashboard-admins). + +## Webtasks + +<%= include('../../_includes/_webtask') %> + +The **Webtasks** tab describes how to build apps and extensions on top of [webtask.io](https://webtask.io/), which is used by the Auth0 rules engine. + +## Custom Domains + +The **Custom Domains** tab allows you to configure a custom domain, which allows you to maintain a consistent user experience. When a custom domain is configured, users will remain in your domain for login rather than being redirected to your *auth0.com* domain. To learn more, see [Custom Domains](/custom-domains). + +::: note +Custom domains are not available for free plans. To configure a custom domain, you must upgrade your account to any paid plan. +::: + +## Signing Keys + +The **Signing Keys** tab allows you to securely manage the signing key and certificate used to sign ID Tokens, Access Tokens, SAML assertions, and WS-Fed assertions that are sent to your applications. + +![Signing Key Tenant Settings](/media/articles/dashboard/tenants/tenant-settings-signing-keys.png) + + +**Rotate Settings**: Settings that allow you to rotate the application signing key and certificate. You may choose whether or not to revoke the signing key upon rotation. To learn more, see [Manage Signing Keys](/tokens/guides/manage-signing-keys). + **Rotate Signing Key**: Rotates the signing key without revoking it; effectively, moves the current key to the previous key. All tokens signed with the previous key will still be valid until it is revoked. + **Rotate & Revoke Signing Key**: Rotates the signing key and then revokes it; effectively, moves the current key to the previous key and then invalidates the previous key. Make sure you have updated your application with the next key in queue before you rotate and revoke the current key. + +**List of Valid Keys**: List of valid application signing keys for your tenant, which are also available at the metadata endpoint for your application. Valid keys include: + * **Next in queue**: Key that will be used when the signing key is next rotated. + * **Currently used**: Key that is currently in use. + * **Previously used**: Key that was previously used. Its appearance indicates that the signing key has been rotated, but the previously-used key has not yet been revoked. + +**List of Revoked Keys**: List of the last three revoked keys for your tenant. More data about revoked keys is available via tenant logs. + +## Advanced + +The **Advanced** tab contains advanced settings that are sometimes set for tenants. On this tab, you can also delete your tenant and cancel all associated subscriptions. + +::: warning +Deleted tenants cannot be restored and the tenant name cannot be used again when creating new tenants. If you want to change ownership of your tenant, see [Update Tenant Admin](/dashboard/manage-dashboard-admins#update-admin). If you want to reset your tenant configuration, see [Reset Tenants](/support/delete-reset-tenant#reset-tenants). +::: + +### Login and Logout + +![Advanced Tenant Settings: Login and Logout](/media/articles/tutorials/tenant-settings/login-logout.png) + +* **Allowed Logout URLs**: URLs that Auth0 can redirect to after logout when no `client_id` is specified on the logout endpoint invocation. Useful as a global list when Single Sign-on (SSO) is enabled. To learn more, see [Logout](/logout). + +* **Tenant Login URI**: URI that points to a route in your application that starts the OIDC login flow by redirecting to the `/authorize` endpoint; it should take the form of `https://mytenant.org/login`. This will only be used in scenarios where Auth0 needs your tenant to start the OIDC login flow. To learn more, see [Tenant Default Login URI](/universal-login/default-login-url). + +### Login Session Management + +These settings configure the login session lifetime, which represents the Auth0 Authorization Server session layer. The Authorization Server session layer drives Single Sign-on (SSO). To learn more, see [Single Sign-on](/sso). + +::: note +Timeouts for tokens issued by Auth0 can be configured elsewhere. Token timeouts are often used to drive the Application session layer and appear in token claims, such as in the expiration claim for OpenID Connect (OIDC) ID Tokens or the lifetime assertion for SAML. +::: + +![Advanced Tenant Settings: Login Session Management](/media/articles/tutorials/tenant-settings/session-timeout.png) + +* **Enable Seamless SSO**: When enabled, users will not be prompted to confirm log in before Single Sign-on (SSO) redirection. + +* **Inactivity Timeout**: Timeframe (in minutes) 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 4,320 minutes (3 days) for Developer or Developer Pro or 144,000 minutes (100 days) for enterprise plans. To learn more, see [Single Sign-On](/sso). + +* **Require Login After**: Timeframe (in minutes) after which a user will be required to log in again, regardless of their activity. Will be superseded by system limits if over 43,200 minutes (30 days) for Developer or Developer Pro or 525,600 minutes (365 days) for enterprise plans. + +### Device Flow User Code Format + +If you are using the [Device Authorization Flow](/flows/concepts/device-auth), these settings configure the randomly-generated user code. To learn more, see [Call Your API from an Input-Constrained Device](/microsites/call-api/call-api-device#how-it-works). + +![Advanced Tenant Settings: Device Flow User Code Format](/media/articles/tutorials/tenant-settings/device-flow-user-code-format.png) + +* **User Code Character Set**: Character set used to generate the user code. + +* **User Code Mask**: Mask used to format the user code. The mask defines the length of the user code and formats it into a friendly, readable value, allowing spaces or hyphens for readability. + +### Global Client Information + +![Advanced Tenant Settings: Global Client Information](/media/articles/tutorials/tenant-settings/global-client-information.png) + +The **Global Client ID** and **Global Client Secret** are used to generate tokens for legacy Auth0 APIs. Typically, you will not need these values. If you need to have the global client secret changed, please [contact support](https://support.auth0.com). + +### Settings + +![Advanced Tenant Settings: Miscellaneous Settings](/media/articles/tutorials/tenant-settings/tenant-advanced-settings.png) + +* **Change Password Flow v2**: When enabled, the newest version of the Change Password Flow will be used. The previous version has been deprecated, and we strongly recommend enabling v2. This flag is presented only for backwards compatibility, and once enabled, you can no longer disable it. You can customize the user interface for the Change Password widget on the [Universal Login](${manage_url}/#/login_settings) > [Password Reset](${manage_url}/#/password_reset) tab in the [Auth0 Dashboard](${manage_url}). + +* **OIDC Dynamic Application Registration**: When enabled, third-party developers will be able to dynamically register applications for your APIs. You can also update this flag using the [Update tenant settings endpoint](/api/management/v2#!/Tenants/patch_settings) of the Auth0 Management API. By default, this feature is disabled. To learn more, see [Dynamic Client Registration](/api-auth/dynamic-client-registration). + +* **Enable Application Connections**: When enabled, all current [connections](/connections) will be enabled for any new [Application](${manage_url}/#/applications) that is created. + +* **Use a Generic Response in Public Signup API Error Message**: When enabled, errors generated while using the public signup API will return a generic response. This helps protect against user registration enumeration by preventing bad actors from being able to guess previously-registered email addresses or usernames from reading error response codes, such as `user_exists`. + +### Extensibility + +![Advanced Tenant Settings: Extensibility](/media/articles/tutorials/tenant-settings/tenant-advanced-extensibility.png) + +* **Runtime**: NodeJS version environment used to execute custom scripts that allow you to extend parts of Auth0's functionality; these include [Rules](/rules), [Hooks](/hooks), and [Database Connections](/connections#database-and-custom-connections). Choose the `node.js` version environment you will use to execute your custom scripts. If you are migrating from an older version of `node.js` that is no longer supported, see the [migration guide](/migrations/guides/extensibility-node12). + +### Migrations + +![Advanced Tenant Settings: Migrations](/media/articles/tutorials/tenant-settings/tenant-advanced-migrations.png) + +* **Disable Clickjacking Protection for Classic Universal Login**: When enabled, additional HTTP security headers will not be included in the response to prevent embedding of [Universal Login](/universal-login) prompts in an IFRAME. diff --git a/articles/dashboard/reference/views-api.md b/articles/dashboard/reference/views-api.md new file mode 100644 index 0000000000..efcd46026b --- /dev/null +++ b/articles/dashboard/reference/views-api.md @@ -0,0 +1,25 @@ +--- +title: Auth0 Dashboard API Views +description: Learn about the API Views available through the Auth0 Dashboard. +topics: + - api-authentication + - oidc + - apis + - dashboard +contentType: reference +useCase: + - secure-api + - call-api +--- + +# Dashboard Views for APIs + +Available views for your API include: + +- **Settings**: lists the settings for your API, some of which are editable. In this section, you can change the token expiration time and enable offline access (so that Auth0 will allow applications to ask for Refresh Tokens for this API). For details, see [API Settings](/api-auth/references/dashboard/api-settings). + +- **Scopes**: allows you to [define the scopes](/scopes/current/guides/define-scopes-using-dashboard) for your API by setting scope names and descriptions. For more details, see [API Scopes](/scopes/current/api-scopes). + +- **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 listed application to request Access Tokens for your API. Optionally, you can select a subset of the defined scopes to limit an authorized application's access to your API. + +- **Test**: allows you to execute a sample Client Credentials flow with any of the authorized applications so you can check that everything is working as expected. diff --git a/articles/deploy/checklist.md b/articles/deploy/checklist.md new file mode 100644 index 0000000000..2be26ecd1b --- /dev/null +++ b/articles/deploy/checklist.md @@ -0,0 +1,27 @@ +--- +title: Deploy Checklist +description: Deployment checklists for your implementation. +topics: + - SDLC + - checklists + - best practices + - implementation checklist +contentType: reference +useCase: + - implementation +--- +# Deploy Checklist + +Auth0 has provided the following deployment checklist for your use. You may not find that every item is applicable, so please modify the checklist based on the needs of your implementation. + +## How to use the checklist + +1. Click the links below to download each checklist. +2. Open the checklist in any spreadsheet application. +3. Customize the checklist to suit your needs. + +![](/media/articles/architecture-scenarios/checklists/file_type_icons-02.png) [Deploy Checklist](/media/articles/architecture-scenarios/checklists/Deploy-Checklist.xlsx) + +In the Deploy phase, you will 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. \ No newline at end of file diff --git a/articles/deploy/index.md b/articles/deploy/index.md new file mode 100644 index 0000000000..deabc126f6 --- /dev/null +++ b/articles/deploy/index.md @@ -0,0 +1,29 @@ +--- +classes: topic-page +title: Deploy +description: Information about deploying Auth0 +topics: + - deploy +contentType: + - index +--- +# Deploy + +The following pages will cover everything you need to know about deploying Auth0. In addition to covering deployment models, we'll provide you with pre-deployment tips, tricks, and tests, as well as an extension to make multi-environment deployments easier. + +
          +
        • + Deployment Models +
          • +

          + Learn about the four different deployment models that Auth0 offers and the differences between them. +

          +
        • + Pre-Deployment Tips and Testing +
          • +

          Get pre-launch tips and tricks, and learn how to use Auth0's pre-deployment testing suite to make sure that you've completed all necessary tasks prior to go live.

          +
        • + Deploy CLI Extension +
          • +

          The Deploy CI Extension is helpful for multi-environment deployments and can be used to support integration into existing CI/CD pipelines.

          +
        \ No newline at end of file diff --git a/articles/design/browser-based-vs-native-experience-on-mobile.md b/articles/design/browser-based-vs-native-experience-on-mobile.md new file mode 100644 index 0000000000..1fba03742b --- /dev/null +++ b/articles/design/browser-based-vs-native-experience-on-mobile.md @@ -0,0 +1,81 @@ +--- +title: Browser-Based vs. Native Login Flows on Mobile Devices +description: This article covers the pros and cons between a browser-based vs. native experience when implementing Auth0 on a mobile device +toc: true +topics: + - design + - mobile +contentType: reference +useCase: strategize +--- +# Browser-Based vs. Native Login Flows on Mobile Devices + +When developing a native mobile application, such as an iOS or Android application, you can choose between the following login flows: **native**, or **browser-based**. + +![Native vs. browser-based UX](/media/articles/tutorials/mobile-ux.png) + +When using a **browser-based** login flow, the user is shown a web browser and redirected to the Auth0 login page, where they can either sign up or log in. For example, an iOS application opens a SafariViewController or Android application opens a Custom Chrome Tab. + +When using a **native** login flow, the user signs up or enters their credentials directly into the app. + +The rest of this article discusses more things to consider, before you decide on a browser-based, or a native login flow. + +## Single Sign-on across native applications + +If you have several mobile applications (such as Google Drive, Google Docs/Sheets, YouTube, and so on), you might want to automatically log the user into all of them if they log into any one app. + +If your applications use a wholly native experience, your users have to enter their credentials for each application. However, if you use a browser-based login flow you can implement Single Sign-on (SSO), reducing the number of times the user has to log in. + +::: note +You can implement SSO with native apps by storing Refresh Tokens on a shared keychain, but this technique is not compliant with the OAuth 2.0 specifications. +::: + +## SSO across devices/desktops/laptops + +Google is currently investing in the ability to synchronize sessions across devices called [Google SmartLock](https://get.google.com/smartlock/). This allows users to sign in using one device or desktop/laptop computer and automatically sync their session across all of their devices. + +While SmartLock is not yet universal, using browser-based login flows allows you to take advantage of this tool. + +## Phishing and security issues + +With a native login flow, an unauthorized party could decompile or intercept traffic to/from your application to get the Client ID and authentication URL. With this information the unauthorized party could create a rogue application, upload it to an application store, and use it to phish for usernames, passwords, and Access Tokens. + +Using a browser-based flow protects you from this, since the callback URL is linked to the application through [universal app links](https://developer.apple.com/ios/universal-links/) (iOS) or [App Links](/dashboard/guides/applications/enable-android-app-links) (Android). Note, however, that this is **not** a universally supported feature. + +## Implementation time + +Using browser-based flows reduces the implementation time required, since everything is handled by the hosted login page (including multi-factor authentication and anomaly detection). + +By default, [Lock](/libraries/lock) provides the user experience, but you can customize it with your own templates written in HTML and CSS, then integrate it with [auth0.js](libraries/auth0js) + +## Automatic improvements + +By relying on a Universal Login experience, you will automatically receive new features without requiring you to make any changes to your native application. For example, if Auth0 adds support for [FIDO/U2F](https://www.yubico.com/solutions/fido-u2f/), you would not need to make any code changes to your application before you can use this functionality. + +## Load time and user experience + +When using a native login flow, the login UI and logic is included in the application. With a browser-based login flow, the user sees some loading time as the page loads. + +However, it's worth noting that the number of times a user logs in with the mobile devices is low. Once the user logs in, your application should only log them out if you revoke their access or if the user opts to log out. + +## Compliance with best practices + +As explained in the [RFC 8252 OAuth 2.0 for Native Apps](https://tools.ietf.org/html/rfc8252), OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. The specification details the security and usability reasons why this is the case. + +## Conclusion + +If your platform supports it, you should use a **browser-based** login flow where your application presents an in-application (embedded) browser for login and signup. Using an in-application browser gives your application the benefits of browser-based authentication, such as shared authentication state and security context, without disrupting the user experience by switching applications. + +Regardless of which option you choose, Auth0 supports either. + +## Implementation examples + +You can find instructions on how to implement a browser-based login flow in our Quickstarts: +- [iOS (Swift)](/quickstart/native/ios-swift/00-login) +- [Android](/quickstart/native/android/00-login) +- [iOS (Objective-C)](/quickstart/native/ios-objc/00-login) + +For native login flows, you can find samples in the following GitHub repos: +- [iOS Swift](https://github.com/auth0-samples/auth0-ios-swift-sample/tree/embedded-login/01-Embedded-Login) +- [Android](https://github.com/auth0-samples/auth0-android-sample/tree/embedded-login/01-Embedded-Login) +- [iOS Objective-C](https://github.com/auth0-samples/auth0-ios-objc-sample) diff --git a/articles/design/creating-invite-only-applications.md b/articles/design/creating-invite-only-applications.md new file mode 100644 index 0000000000..d07173f3c6 --- /dev/null +++ b/articles/design/creating-invite-only-applications.md @@ -0,0 +1,73 @@ +--- +description: Describes how to customize the signup process for an invite-only application with Auth0. +toc: true +crews: crew-2 +topics: + - design +contentType: how-to +useCase: invite-only +--- +# User Invitation Applications + +You can restrict users signups to an application. One way to do this is with user invitations as a provisioning workflow, either in conjunction with or as an alternative to self-provisioning. In this case, an administrator creates the user accounts then invites users to complete the signup process by creating passwords for those accounts. The user experience consists of the following steps: + +1. User receives an email inviting them to register. +2. User follows a link to the **Set Up Password** page. +3. User creates and verifies a password. +4. User signs in. +5. User has access to the target application. + +A user invitation is basically a change password link repurposed as an invitation. There are two common approaches for this: + +* Send an Auth0 [change password email](/email/custom#change-password-confirmation-email) using a [customized email template](/email/templates) +* Create a password change ticket + +## Generate invitations + +You can allow a user to access an existing account that you have created on their behalf. Then, send the user a unique link to set their password. You generate the unique link by creating a Password Change ticket where your invitation app calls the /password-change Management API endpoint. You will need to: + +* Create an [Auth0 database](/connections/database) user with the `user.email_verified` parameter set to `false` +* Have access to an [external email service](/email/providers) +* Obtain a [Management API access token](/api/management/v2/tokens) + +### Create Password Change tickets + +1. Specify the user using `user_id` or `email` and `connection_id`. +2. Specify where the user will be redirected. The `result_url` parameter is the location the user will be redirected to once they have set their password. In this case, this should be back to the target app login page. See [Redirect Users to other URLs](/users/guides/redirect-users-after-login#redirect-users-to-other-urls) for details. +3. Specify the lifespan of the invitation link. Use the `ttl_sec` parameter to set how long the invitation link will remain active. This should align with your relevant security concerns. The link is one time use, so once the user has set their password, it is not vulnerable to reuse. +4. Verify the email address. As long as this invitation is being sent to the email registered to the account, you should set the email as `verified` once the user has set their password. Use the `mark_email_as_verified` parameter as `true`. If this invitation is sent to anywhere other than the user's registered email address, you **should not** set the email verification to `true`. A successful request to this endpoint will result in a ticket URL to be returned. The URL will then be used to create the user invitation. + +### Add query parameters to the ticket URL + +The query parameters are used to customize the password reset UI. The returned URL will have the unique code value that allows the user to set their password followed by a `#`. For the link to work, you do not want to edit anything before the hash. + +1. Add hash parameters to the generated password ticket URL. +2. Add a parameter to identify that the UI should represent a set password workflow rather than a change password workflow. +3. Add a parameter to identify the target app in the case that invites might be sent for more than one app. + +### Create an email template + +The email invitation needs to be sent with your existing email service provider. The language in the email should align with your use case. Include the link generated from the steps above. The text in the email should explain: +* The next steps to claiming the user account. +* The expiration of the link. +* Steps to generate a new invite if it has expired. + +## Customize the Password Reset UI + +Once the user clicks the link in the invitation they will be brought to the [Universal Login Password Reset](/universal-login/password-reset) page. Here they will set a password for their account. Since this page is used both for the forgot password workflow and for your user invitations, you will want to use the query parameters you defined earlier to identify the invite workflow and customize the UI accordingly. + +## Complete the user experience + +In most cases, once the user has set their password, you grant them access to the target app. The target app initiates the login sequence with the following steps: + +1. User submits password. +2. Change password screen redirects return URL. +3. Target app redirects to /authorize. +4. User submits their credentials. +5. User is authenticated into the app. + +The workflow involves redirects but it is possible for the transition from the set password form to the login form to appear seamless to the end user. + +The `return_url` you set when you created the Password Change ticket is where the user will be redirected after creating their password. In this case you want the URL to be on the site the user has been invited to so that it can initiate the login workflow. Your target app will need to parse the `success` parameter to confirm no errors occurred then immediately initiate the redirect back to Auth0 to log the user in. + +To optimize the user experience, you can have the target app parse the `email` parameter and include it with the authentication request as the `login_hint` parameter. This will prefill the user's email in the login form. \ No newline at end of file diff --git a/articles/design/index.md b/articles/design/index.md new file mode 100644 index 0000000000..83015636a5 --- /dev/null +++ b/articles/design/index.md @@ -0,0 +1,48 @@ +--- +title: Design Your Auth0 Implementation +description: Guidance for designing your Auth0 implementation +classes: topic-page +topics: + - design +contentType: + - index + - how-to +useCase: strategize +--- + +
        +
        +

        Design Your Auth0 Implementation

        +

        + There are many things to consider when setting up your Auth0 implementation. This page links to articles you might find useful as you do so. +

        +
        + +

        Auth0 Implementation Design

        + + \ No newline at end of file diff --git a/articles/design/using-auth0-with-multi-tenant-apps.md b/articles/design/using-auth0-with-multi-tenant-apps.md new file mode 100644 index 0000000000..3aa8e483a1 --- /dev/null +++ b/articles/design/using-auth0-with-multi-tenant-apps.md @@ -0,0 +1,72 @@ +--- +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 to Secure Your Multi-Tenant Applications + +This article provides a high-level overview of how Auth0 can help you manage your multi-tenant applications. + +## What is multi-tenancy + +[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. + +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. + +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 + +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: + +* [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 + +You can use multiple connections to handle your tenants. Each connection would represent and contain a different pool of users. + +::: warning +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. +::: + +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 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 +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 new file mode 100644 index 0000000000..534c8d6a6f --- /dev/null +++ b/articles/design/web-apps-vs-web-apis-cookies-vs-tokens.md @@ -0,0 +1,28 @@ +--- +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**. + +* **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). + +* **Token-based authentication** is implemented by generating a token when the user authenticates and then setting that token in the `Authorization` header of each subsequent request to your API. You want that token to be something standard, like JSON Web Tokens since you will find libraries in most of the platforms and you don't want to do your own crypto. + +* 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 (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. + +<%= include('../_includes/_samesite_none') %> \ No newline at end of file diff --git a/articles/dev-centers/index.md b/articles/dev-centers/index.md deleted file mode 100644 index b0178a50ac..0000000000 --- a/articles/dev-centers/index.md +++ /dev/null @@ -1,4 +0,0 @@ ---- -sitemap: false -title: Auth0 Developer Centers ---- diff --git a/articles/dev-centers/java.md b/articles/dev-centers/java.md new file mode 100644 index 0000000000..7d3e89fcb1 --- /dev/null +++ b/articles/dev-centers/java.md @@ -0,0 +1,80 @@ +--- +title: Java Developer Center +description: Resources and documentation for Java developers +logo: java +topics: + - java +contentType: reference +useCase: strategize +--- + +# Java SDK Developer Center + +Here at Auth0 we try to offer as many libraries as needed to ensure we make your life as easy as possible. We understand when it comes to Java technologies things can get a bit confusing, especially given the number of prominent third party frameworks, libraries, and topologies to cover. In this document you can find a listing of the Java technologies for which we currently offer guides, libraries and sample projects. If you can’t find something you need then please let us know, and where possible we’ll make every effort to have it covered. + +## 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. + +- [Documentation](/server-platforms/java) +- [Library](https://github.com/auth0/auth0-servlet) +- [Sample Project](https://github.com/auth0-samples/auth0-servlet-sample) + +## Java Spring MVC + +A modern Java Spring library that allows you to use Auth0 with Java Spring for server-side MVC web apps. This is the right choice if you are using Spring / Spring Boot but don't want to use Spring Security. + +- [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): 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 + +A modern Java Spring library that allows you to use Auth0 with Spring Security for server-side MVC web apps. This provides full integration with Spring Security. + +- [Documentation](/server-platforms/java-spring-security-mvc) +- [Library](https://github.com/auth0/auth0-spring-security-mvc) +- [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. +::: + +## 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. + +- [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): 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) + +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 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) 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. +- Use 100% Java Configuration (Annotations). +- Secure one or more URL endpoints with Role / Authority based permissions (ROLE_USER, ROLE_ADMIN, and so on). +- Secure Java Services using method level security annotations for role based access control. + +You can find more details on how to setup and use this sample application [here](https://github.com/auth0-samples/auth0-spring-security-api-resource-server-sample). + +## More libraries + +- [auth0-java](https://github.com/auth0/auth0-java): This is an application (client) library to make calls to our Authentication and Management APIs. + +- [java-jwt](https://github.com/auth0/java-jwt): This library is used for performing JWT Token related actions (JWT creation, verification, and so on) diff --git a/articles/dev-centers/java/index.md b/articles/dev-centers/java/index.md deleted file mode 100644 index 9afe0e9302..0000000000 --- a/articles/dev-centers/java/index.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: Java Developer Center -subtitle: Resources and documentation for Java developers -description: Resources and documentation for Java developers -logo: java -url: /dev-centers/java -tutorials: - - native-platforms/ios-objc - - native-platforms/ios-swift -scenarios: - - apps-apis -resources: - - - title: ASP.NET - subtitle: Libraries and Samples - type: sample - link: https://github.com/auth0/auth0-aspnet - ---- - -# Java SDK Developer Center - -Here at Auth0 we try to offer as many libraries as needed to ensure we make your life as easy as possible. We understand when it comes to Java technologies things can get a bit confusing, especially given the number of prominent third party frameworks, libraries, and topologies to cover. In this document you can find a listing of the Java technologies for which we currently offer guides, libraries and sample projects. If you can’t find something you need then please let us know, and where possible we’ll make every effort to have it covered. - -## 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. - -- [Documentation](/server-platforms/java) -- [Library](https://github.com/auth0/auth0-servlet) -- [Sample Project](https://github.com/auth0-samples/auth0-servlet-sample) - -## Java Spring MVC - -A modern Java Spring library that allows you to use Auth0 with Java Spring for server-side MVC web apps. This is the right choice if you are using Spring / Spring Boot but don't want to use Spring Security. - -- [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 at 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-boot-web-jsp-passwordless): 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 at the _README_ of the [GitHub repository](https://github.com/auth0-samples/auth0-spring-boot-web-jsp-passwordless). - -## Java Spring Security MVC - -A modern Java Spring library that allows you to use Auth0 with Spring Security for server-side MVC web apps. This provides full integration with Spring Security. - -- [Documentation](/server-platforms/java-spring-security-mvc) -- [Library](https://github.com/auth0/auth0-spring-security-mvc) -- [Sample Project](https://github.com/auth0-samples/auth0-spring-security-mvc-sample) - -> 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. - -- [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 Client 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. - 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) - -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. - -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. - -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. - -This sample application shows you how to: -- Configure and run Java based Spring API server with Auth0 and Spring Security. -- Use 100% Java Configuration (Annotations). -- Secure one or more URL endpoints with Role / Authority based permissions (ROLE_USER, ROLE_ADMIN, etc). -- Secure Java Services using method level security annotations for role based access control. - -You can find more details on how to setup and use this sample application [here](https://github.com/auth0-samples/auth0-spring-security-api-resource-server-sample). - -## More libraries - -- [auth0-java](https://github.com/auth0/auth0-java): This is a Client library to make calls to our Authentication and Management APIs. - -- [java-jwt](https://github.com/auth0/java-jwt): This library is used for performing JWT Token related actions (JWT creation, verification, etc.) diff --git a/articles/dev-lifecycle/child-tenants.md b/articles/dev-lifecycle/child-tenants.md index 65846eb5b9..3c2bdba948 100644 --- a/articles/dev-lifecycle/child-tenants.md +++ b/articles/dev-lifecycle/child-tenants.md @@ -1,46 +1,61 @@ --- -description: How to request to have a child tenant +description: How to request child tenants for your Auth0 tenant +topics: + - child-tenants + - dev-tools +contentType: how-to +useCase: + - support + - development --- -# Child account request process +# Child Tenant Request Process -This process is for self service customers that request a test/dev/staging account to be linked to their paid production account. It is not applicable for accounts that have a free plan. +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**. -The test/dev/staging accounts are called child accounts. +Free tenants do not include a child tenant. -## Child account policy +::: 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}). +::: -* Accounts that pay 167 US$ per month or more are eligible for one free test account, with the same plan/features. -* The child account will be subject to Auth0’s [Operational Policies](/policies). -* If the child account is downgraded to a free plan and a paid plan subscription is terminated, all the additional features that it had will be removed or restricted as outlined in [pricing](https://auth0.com/pricing). -* **The child account must not be used in a production environment.** +## Child Tenant Policy +* If you're billed $167 USD/month (or more), you're eligible for one free child tenant with the same plan/features as the production tenant. +* Your child tenant is subject to Auth0’s [Operational Policies](/policies). +* If you cancel your paid subscription plan and Auth0 downgrades your child tenant to the free plan, you'll lose access to features (as outlined in [pricing](https://auth0.com/pricing)) available to paid plans. -## How to request a child account? +::: warning +Child tenants **must not** be used in production environments. +::: -Requests for a child account must be made via the [Auth0 Support Center](${env.DOMAIN_URL_SUPPORT}), at least 5 business days in advance of the desired implementation date. +## Request a Child Tenant -You must include the following information in your request: -* The name of the Auth0 paying account for which the child account will be linked to. -* The name of the new Auth0 child account. +Please use the [Auth0 Support Center](${env.DOMAIN_URL_SUPPORT}) to request that a child tenant be assigned for you. The new child tenant has to be created before the request is submitted. Requests must be made at least five business days in advance of your desired implementation date. -## How to alter the plan of my account? +Please include the following information with your request: -If you are upgrading your account, your child accounts will be upgraded too. Please note that before downgrading your plan, you have to contact us via the [Auth0 Support Center](${env.DOMAIN_URL_SUPPORT}), otherwise there might be collateral effects on both of your accounts. +* The name of the paid Auth0 tenant to which the child tenant will be linked +* The name of the new Auth0 child tenant -## Does the child account need to belong to the same region as the master account? +## Alter Your Tenant's Subscription Plan -No, there is no limitation regarding this. +If you are upgrading the subscription plan associated with your paid tenant, your child tenant will be upgraded as well. If you downgrade, your child tenant will also be affected -- please contact the Auth0 Support team using the [Support Center](${env.DOMAIN_URL_SUPPORT}) for additional details. -## Can I have more than one child account for my master account? +## Child Tenant Cloud Region -The default answer is no. However, this will be decided for each case. Please contact us via the [Auth0 Support Center](${env.DOMAIN_URL_SUPPORT}) and inform us the following: -* The name of the Auth0 paying account for which the child account will be linked to. -* The number of child accounts that you need. -* The name of each of the new Auth0 child accounts. +The child tenant does **not** have to be located in the same cloud environment as your production tenant. -Note that you can ask up to 3 child accounts. So you can have one for development, one for staging and one for testing. We encourage you to keep things simple and have only one child account. +## Additional Child Tenants -## Usage considerations +Generally speaking, we only permit one child tenant per paid production tenant. However, if you need additional tenants, please contact us via the [Support Center](${env.DOMAIN_URL_SUPPORT}) and include the following information with your request: -Please notice that usage on child accounts counts towards the master's account usage. +* The name of the paid Auth0 tenant to which the additional child tenant will be linked +* The number of new child tenants needed +* A name for each of the new child tenants + +In limited circumstances, you may have up to three child tenants associated with a paid tenant. However, we encourage you to use as few child tenants as possible. + +## Usage + +Activity and usage on child tenants count toward the master's tenant activity and usage limitations. 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 9cad966949..128c09eb32 100644 --- a/articles/dev-lifecycle/local-testing-and-development.md +++ b/articles/dev-lifecycle/local-testing-and-development.md @@ -1,42 +1,45 @@ --- description: How to develop and test Auth0 applications. +topics: + - dev-tools + - local-env +contentType: how-to +useCase: development --- +# Work with Auth0 Locally -# Running and Developing 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. -Authenticating users through Auth0 in most cases requires an Internet connection, but it's still possible to develop and test applications that use Auth0 locally, even without Internet access in some cases. +::: note +See [Setting Up Multiple Environments](/dev-lifecycle/setting-up-env) for information on structuring your development, test, and production environments when using Auth0. +::: -> For more information about structuring separate Auth0 environments for development, testing and production, [please refer to this document](/dev-lifecycle/setting-up-env). +## Use JSON Web Tokens (JWT) with client-side applications -## Client-side applications and JWT +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. -This is usually the easiest scenario to test. -One of the benefits of [JSON Web Tokens](/jwt) is that they are stateless, which means that an application that consumes them only cares about the JWT's contents and not any previous state such as a session cookie. +You can obtain JWTs for testing using any of the following methods: -There are mainly three approaches to obtaining JWTs for testing: +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). -1. Manually generate a JWT with the needed data, and sign it with your Auth0 application's client secret. - If you omit the `exp` claim from a token, most JWT libraries will interpret it as a token which never expires, though it's possible some libraries might reject it. - The benefit of this approach is that it does not require Internet access or intervention from Auth0 at all. +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. -2. Create a dummy user in a database connection, and programatically log in with this user through the [resource owner endpoint](/api/authentication/reference#resource-owner). - In order to get a JWT back, [make sure to set the correct `scope` value](/scopes). - The benefit of this approach is that it will [execute any rules](/rules) that you have configured on your Auth0 account. +## Use sessions with server-side applications -3. Use a browser bot (e.g. Selenium) which logs a dummy user in and retrieves a JWT. - This approach may take some effort to develop and maintain, but it will also execute any [redirection rules](/rules/redirect) or [MFA prompts](/multifactor-authentication) that you have configured on your Auth0 account. +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. -## Server-side applications and sessions +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). -Unless your server-side application provides a way to generate "fake" sessions for testing, you will need to perform an actual login through Auth0. -The easiest way to do this is through the [resource owner endpoint](/api/authentication/reference#resource-owner). +## Use local domains with Auth0 -## Logging in as any user for testing +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. -If you need to simulate a user logging in to your application but don't have access to their credentials, you can use the [impersonation endpoint](/api/authentication/reference#impersonation) to generate a link which will log you in as any given user to your application. +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. -## Auth0 and `localhost` +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. -If you need to develop an application locally, it's possible to use `localhost` or other domains which Auth0 cannot access (e.g. intranets) as callback URLs. -Since Auth0 [uses OpenID Connect](/protocols) as its main identity protocol, it never makes a call directly to your application's server. -Instead, it redirects users in a browser to an endpoint of your application (which must be listed in the "Allowed Callback URLs" list) with specific information in the query string or hash fragment, depending on the type of application. +## 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 27534b7325..f3ec26e81b 100644 --- a/articles/dev-lifecycle/setting-up-env.md +++ b/articles/dev-lifecycle/setting-up-env.md @@ -1,47 +1,99 @@ --- -description: Use multiple Auth0 accounts to manage various environments. +description: Use multiple Auth0 tenants to manage various environments. +topics: + - dev-tools + - local-env +contentType: how-to +useCase: development --- +# Set Up Multiple Environments -# Setting Up Multiple Environments +__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. -__Development__, __Test__, __Q&A__ environments are easy to setup in Auth0. Simply create a new account for each to guarantee the maximum isolation between these environments. You can easily switch between accounts using the account chooser from the top right menu on the dashboard. You can also configure different administrators for each. +::: warning +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) +You can name your multiple environments any way you prefer. For production environments, we strongly recommend using [custom domains](/custom-domains). -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. +::: 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 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. + +::: 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`. + +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 (e.g. rules, database connections, etc.) between accounts. +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 settings in the dashboard instead of hardcoded into your __rules__ or __db connections__ scripts. +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. -For example, in this __rule__ it is always better to write: +For example, let's say you want to set a URL for logs. One way to do it is to hardcode it in the rule: -``` +```js function(user, context, callback){ - var log_url = configuration.log_url; -... + var log_url = 'https://someurl/log'; + ... } ``` -than: +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. + +![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) + +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){ - var log_url = ‘https://someurl/log’; -... + var log_url = configuration.log_url; + ... } ``` -Since this URL will likely change from development to production, this method will make your code more portable. +![Write Rule Code](/media/articles/lifecycle/rules-rule-code.png) -## AD/LDAP Connectors - -Since an AD/LDAP Connector is tied to a specific Connection within an Auth0 account, if you setup multiple Auth0 accounts, you will need to create an AD/LDAP Connection and setup an AD/LDAP Connector for each account that requires this form of authentication. +This code is portable, and when you migrate to production, you only need to change this setting instead of searching your scripts. -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 account. +## AD/LDAP Connectors -If you have multiple AD/LDAP directories against which users will authenticate, (to support different departments or customers, each with their own directory, for example), you can setup multiple AD/LDAP Connectors within each Auth0 account. +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. +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 d2016978f0..904c232284 100644 --- a/articles/email/custom.md +++ b/articles/email/custom.md @@ -1,31 +1,36 @@ --- 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. -![](/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) { - user.app_metadata = user.app_metadata || {}; - if (user.email_verified || user.app_metadata.verification_email_sent) { + + 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){ @@ -42,8 +47,8 @@ function (user, context, callback) { return callback(new Error(err)); // Email sent flag persisted in the user's profile. - user.app_metadata.verification_email_sent = true; - auth0.users.updateUserMetadata(user.user_id, user.app_metadata) + user.user_metadata.verification_email_sent = true; + auth0.users.updateUserMetadata(user.user_id, user.user_metadata) .then(function() { callback(null, user, context); }) @@ -61,9 +66,7 @@ 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. -::: panel-info Using the Verification Email endpoint -You could call the [post_verification_email](/api/v2#!/Jobs/post_verification_email) endpoint to send a verification email directly from Auth0, even when automatic emails are disabled. However, this endpoint will redirect all users to the same URL that is specified in the `Redirect To` field under the **Verification Email** tab on the [Email Templates](${manage_url}/#/emails) page of the Auth0 dashboard. Since you are already implementing your own email service, this endpoint may not provide all the functionality your app requires. -::: +We recommend whitelisting the url through the dashboard. ## Welcome Email @@ -71,6 +74,9 @@ A welcome email is sent to users once they have verified their email address. Th ```js function (user, context, callback) { + + const request = require('request'); + if (!user.email_verified || user.welcome_email_sent) { return callback(null, user, context); } @@ -88,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); }); } @@ -102,10 +108,12 @@ You can now send an email to the user containing this link. Only when the user c Alternatively, if you invoke the [change password ticket](/api/management/v2#!/Tickets/post_password_change) endpoint without specifying the `new_password` parameter, the link at the email will redirect the user to a page prompting to set a new password. -![](/media/articles/email/custom/change-password.png) +![Change Password](/media/articles/email/custom/change-password.png) -## Additional Information +## Keep Reading +::: next-steps * [Emails in Auth0](/email) * [Customizing Your Emails](/email/templates) * [Using your own SMTP provider (SendGrid/Amazon SES/Mandrill)](/email/providers) + ::: diff --git a/articles/email/index.md b/articles/email/index.md index 9829e2189f..2f3fec2e0d 100644 --- a/articles/email/index.md +++ b/articles/email/index.md @@ -1,29 +1,44 @@ --- url: /email -description: Auth0 provides built-in email services to easily communicate with your users. +description: Auth0 built-in email services. +topics: + - email +contentType: + - index + - reference + - how-to +useCase: customize-emails --- # Emails in Auth0 -::: panel-danger Notice -Auth0's built-in email provider is not supported for use in a production environment. +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. -[Click here to learn more about Email Delivery Changes](/migrations#email-delivery-changes) +::: warning +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. ::: -Auth0 provides built-in email services to easily communicate with your users. This includes verification emails, welcome emails, change password emails, and blocked account emails. - -When you first create your application Auth0 provides a built-in email provider to send emails. This is meant to be used for testing purposes only. When using this, it is important to note: +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. -* You will be restricted to sending no more than ten emails per minute, regardless of email type. +* All emails will be sent from a predefined **from** address (`no-reply@auth0user.net`). + +* You will be restricted to sending no more than **ten emails per minute**, regardless of email type. + +* Your ability to send email from your tenant may be reduced (or even temporarily blocked) if your emails result in high bounce rates. -* Your ability to send email from your account may be reduced (or even temporarily blocked) if your emails result in high bounce rates. +![Test Email](/media/articles/email/index/email-notification.png) -To remove these restrictions in your testing or to setup your production level emails, please consult the following resources for information on setting up your own email provider: +To remove these restrictions in your testing or to setup your production level emails, you have to set up your own email provider: * [Use your own SMTP Email Provider](/email/providers) * [Custom Email Handling](/email/custom) -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. For more information, see: [Customizing Your Emails](/email/templates). +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 more information see [Customizing Your Emails](/email/templates). diff --git a/articles/email/liquid-syntax.md b/articles/email/liquid-syntax.md index b6acb70fb3..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. +--- +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 @@ -24,12 +31,53 @@ There are two types of markup in Liquid: **output** and **tag**. `Hello {{ name }}!` -You can further customize the appearance of the output by using [filters](https://github.com/Shopify/liquid/wiki/Liquid-for-Designers#standard-filters), which are simple methods. +::: note +For more information on supported output attributes and their usage, see [Customizing Your Emails](/email/templates). +::: + +You can further customize the appearance of the output by using filters, which are simple methods. For example, the `upcase` filter will convert the text which is passed to the filter to upper case: -`Hello {{name | upcase}}!` +`Hello {{ name | upcase }}!` Multiple filters are separated by `|` and are processed from left to right, applying the subsequent filter to the result of the previous one. The template will render the final result. +The following filters are supported: + + +Filter | Description | Example +---------|----------|--------- +`append` | Append a string | `{{ 'foo' | append:'bar' }} #=> 'foobar'` +`capitalize` | Capitalize words in the input sentence | `{{ "my great title" | capitalize }} #=> My great title` +`date` | Reformat a date ([syntax reference](http://docs.shopify.com/themes/liquid-documentation/filters/additional-filters#date)) | +`default` | Returns the given variable unless it is null or the empty string, when it will return the given value | `{{ undefined_variable | default: "Default value" }} #=> "Default value"` +`divided_by` | Integer division | `{{ 10 | divided_by:3 }} #=> 3` +`downcase` | Convert an input string to lowercase, | `{{ "Parker Moore" | downcase }} #=> parker moore` +`escape` | HTML escape a string | `{{ "Have you read 'James & the Giant Peach'?" | escape }} #=> Have you read 'James & the Giant Peach'?` +`escape_once` | Returns an escaped version of HTML without affecting existing escaped entities | `{{ "1 < 2 & 3" | escape_once }} #=> 1 < 2 & 3` +`first` | Get the first element of the passed in array | +`join` | Join elements of the array with certain character between them | +`last` | Get the last element of the passed in array | +`map` | Map/collect an array on a given property | +`minus` | Subtraction | `{{ 4 | minus:2 }} #=> 2` +`modulo` | Remainder | `{{ 3 | modulo:2 }} #=> 1` +`newline_to_br` | Replace each newline (\n) with HTML break | +`plus` | Addition | `{{ '1' | plus:'1' }} #=> 2`, `{{ 1 | plus:1 }} #=> 2` +`prepend` | Prepend a string | `{{ 'bar' | prepend:'foo' }} #=> 'foobar'` +`remove` | Remove each occurrence | `{{ 'foobarfoobar' | remove:'foo' }} #=> 'barbar'` +`remove_first` | Remove the first occurrence | `{{ 'barbar' | remove_first:'bar' }} #=> 'bar'` +`replace` | Replace each occurrence | `{{ 'foofoo' | replace:'foo','bar' }} #=> 'barbar'` +`replace_first` | Replace the first occurrence | `{{ 'barbar' | replace_first:'bar','foo' }} #=> 'foobar'` +`round` | Rounds input to the nearest integer or specified number of decimals | `{{ 4.5612 | round: 2 }} #=> 4.56` +`size` | Return the size of an array or string | `{{ "Ground control to Major Tom." | size }} #=> 28` +`sort` | Sort elements of the array +`split` | Split a string on a matching pattern | `{{ "a~b" | split:"~" }} #=> ['a','b']` +`strip_html` | Strip HTML from string | `{{ "How are you?" | strip_html }} #=> How are you?` +`strip_newlines` | Strip all newlines (\n) from string | +`times` | Multiplication | `{{ 5 | times:4 }} #=> 20` +`truncate` | Truncate a string down to x characters. It also accepts a second parameter that will append to the string | `{{ 'foobarfoobar' | truncate: 5, '.' }} #=> 'foob.'` +`truncatewords` | Truncate a string down to x words | +`upcase` | Convert an input string to uppercase | `{{ "Parker Moore" | upcase }} #=> PARKER MOORE` + ### Liquid Markup: Tag **Tag** markup does not resolve to text and is surrounded by a pair of matched curly braces and percent signs: @@ -45,7 +93,7 @@ For example: ```HTML {% if user.user_metadata.lang == 'en' %} [email body in English] -{% elseif user.user_metadata.lang == 'de' %} +{% elsif user.user_metadata.lang == 'de' %} [email body in German] {% endif %} ``` diff --git a/articles/email/providers.md b/articles/email/providers.md index c4714752ea..659f40862b 100644 --- a/articles/email/providers.md +++ b/articles/email/providers.md @@ -1,162 +1,227 @@ --- -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 so you can more completely manage, monitor, and troubleshoot your email communications. -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. +::: 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) -* [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) + +You can only configure one email provider, which will be used for all emails. -**Note:** You can only configure one email provider (Amazon SES, Sendgrid, etc.) 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) -3. [Request production access](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/request-production-access.html?icmpid=docs_ses_console). -4. [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). +4. [Request production access](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/request-production-access.html?icmpid=docs_ses_console). - ![](/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. -5. [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": "*" + } + ] +} +``` -6. 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. -7. 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**: -8. 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**. + + ![Enter AWS SMTP Email Provider Values](/media/articles/dashboard/emails/providers/emails-providers-settings-smtp.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. + +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. + +## Configure Mandrill - ![](/media/articles/email/providers/ses-smtp.png) +1. Sign up for a [Mandrill](https://www.mandrill.com/signup/) account, or log in. -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. +2. Navigate to Mandrill [Settings](https://mandrillapp.com/settings), and click **Add API key**. Copy this key value. -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`. +3. Navigate to Auth0 [Custom Email Providers](${manage_url}/#/emails/provider). Activate the **Use my own email provider** toggle, and click the **Mandrill** logo. - ![](/media/articles/email/providers/enter-smtp-data.png) + ![Select Email Provider](/media/articles/dashboard/emails/providers/emails-providers-list.png) -7. Click **Save**. +4. Provide a *From** email address, enter the Mandrill **API Key** you previously copied, 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. If you don't receive an email after a few minutes, please check your [dashboard logs](${manage_url}/#/logs) for any failures. + ![Enter Mandrill Email Provider Values](/media/articles/dashboard/emails/providers/emails-providers-settings-mandrill.png) -The [Amazon SES console](https://console.aws.amazon.com/ses) will now display all emails which have been sent to your users. +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. -## Configure Mandrill for Sending Email +The Mandrill [Outbound Activity](https://mandrillapp.com/activity) page will now display delivery insights for all emails that have been sent to your users. -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. +## Configure SendGrid - ![](/media/articles/email/providers/mandrill-keygen.png) +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.) -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. +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. -3. Enter your previously obtained Mandrill `API Key`: +3. Navigate to Auth0 [Custom Email Providers](${manage_url}/#/emails/provider). Activate the **Use my own email provider** toggle, and click the **SendGrid** logo. - ![](/media/articles/email/providers/mandrill-key.png) + ![Select Email Provider](/media/articles/dashboard/emails/providers/emails-providers-list.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. +4. Provide a **From** email address, enter the SendGrid **API Key** you previously copied, and click **Save**: -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. + ![Enter SendGrid Email Provider Values](/media/articles/dashboard/emails/providers/emails-providers-settings-sendgrid.png) -![](/media/articles/email/providers/email-mandrill-monitoring.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. -## Configure SendGrid for Sending Email +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. -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). +## Configure SparkPost -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**. +1. Sign up for a [SparkPost](https://www.sparkpost.com/) account, or log in. - ![](/media/articles/email/providers/sendgrid-permissions.png) +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. -4. Copy the API key provided. +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. - ![](/media/articles/email/providers/sendgrid-key.png) +4. Navigate to Auth0 [Custom Email Providers](${manage_url}/#/emails/provider). Activate the **Use my own email provider** toggle, and click the **SparkPost** logo. -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. + ![Select Email Provider](/media/articles/dashboard/emails/providers/emails-providers-list.png) -6. Provide a **From** email and enter your previously obtained **SendGrid API Key**: +5. Provide a **From** email address, enter the SparkPost **API Key** you previously copied, select your **Region**, and click **Save**: - ![](/media/articles/email/providers/sendgrid-dashboard.png) + ![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. +::: + +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 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 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. + +## Configure Mailgun + +1. Sign up for a [Mailgun](https://mailgun.com) 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 have configured everything correctly, you will receive a confirmation email: +2. Navigate to Mailgun **Sending > Domains**, and add your custom domain. Mailgun allows sending emails from only verified domains. -![](/media/articles/email/providers/sendgrid-test.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**. -**NOTE:** If you do not receive an email after a few minutes, please check your [dashboard logs](${manage_url}/#/logs) for any failures. +4. Navigate to Auth0 [Custom Email Providers](${manage_url}/#/emails/provider). Activate the **Use my own email provider** toggle, and click the **Mailgun** logo. -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. + ![Select Email Provider](/media/articles/dashboard/emails/providers/emails-providers-list.png) -![](/media/articles/email/providers/email-sendgrid-monitoring.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**: -## Configure a Custom SMTP Server for Sending Email + ![Enter Mailgun Email Provider Values](/media/articles/dashboard/emails/providers/emails-providers-settings-mailgun.png) -You can use your own SMTP server to send email. There are three requirements for the SMTP server: +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. -* 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). +The [Mailgun Dashboard](https://app.mailgun.com/app/dashboard) will now display delivery insights for all emails that have been sent to your users. -To be able to use your own SMTP server: +## Configure a custom SMTP server -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: +When using your own SMTP server to send email, the server must: - ![](/media/articles/email/providers/enter-smtp-data.png) +* 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). -5. Click **Save**. +If your SMTP server meets these criteria, then: -**NOTE:** Common ports include 25, 465, and 587. Please avoid using port 25 if you can, since many providers have limitations on this port. +1. Navigate to Auth0 [Custom Email Providers](${manage_url}/#/emails/provider). Activate the **Use my own email provider** toggle, and click the **SMTP** 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 don't receive an email after a few minutes, please check your [dashboard logs](${manage_url}/#/logs) for any failures. + ![Select Email Provider](/media/articles/dashboard/emails/providers/emails-providers-list.png) -::: panel-info 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) . +2. Provide a **From** email address, then enter your SMTP server **Host**, **Port**, **Username**, and **Password**, and 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 because many providers have limitations on this port. +::: + +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 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). ::: -## Additional Information +## Keep reading -- [Emails in Auth0](/email) -- [Customizing Your Emails](/email/templates) -- [Custom Email Handling](/email/custom) -- [Setting up a Test Provider](/email/testing) +::: next-steps +* [Emails in Auth0](/email) +* [Customizing Your Emails](/email/templates) +* [Custom Email Handling](/email/custom) +* [Setting up a Test Provider](/email/testing) +::: diff --git a/articles/email/spa-redirect.md b/articles/email/spa-redirect.md index 91961ac5c5..ff000c99f5 100644 --- a/articles/email/spa-redirect.md +++ b/articles/email/spa-redirect.md @@ -1,47 +1,60 @@ --- description: How to work around the limitation of single-page application email redirects. ---- - -# Single-Page App Email Redirect Issue - -For single-page applications, the **Redirect To** URL may contain the hash and route for a particular state/view in the app, followed by route parameters. - -This can cause the following issue with the **Redirect To** URL: - -`http://localhost:3000/#/register` - -Which will result in a user getting redirected to following URL: - -`http://localhost:3000/?supportSignUp=true&supportForgotPassword=true&email=ashish.dasnurkar%40gmail.com&message=Your%20email%20was%20verified.%20You%20can%20continue%20using%20the%20application.&success=true#/register` - -This is per the [RFC 3986](https://tools.ietf.org/html/rfc3986#section-3) spec that defines the expected order of a URL as `scheme|authority|path|query|fragment` - -However, single-page application frameworks (such as Angular) typically expect URLs in the `scheme|authority|path|fragment|query` format (with the query string parameters at the end). This causes the application not to enter the expected state. - -For example, with the above URL, the app will be routed to `/` instead of `/#/register`. - -## Using state - -To work around this limitation of single-page application (SPA) frameworks, it is recommended to use a server-side callback URL as the **redirect To** URL with a `state` parameter that preserves the SPA app route for the redirect. Once in this server-side URL, simply redirect to the SPA route saved in `state` parameter along with rest of the query string. - -1. Add a server-side URL as the **redirect To** URL with a `state` parameter that records the SPA route for the redirect. - - `http://localhost:3001/register?state=register` - -2. Next, create a server-side route controller that reads the `state` and other parameters from the URL and redirects to the SPA route specified in `state` parameter. Remember to append the other parameters received from Auth0. - -``` -var express = require('express'); -var router = express.Router(); -var qs = require('qs'); // to read query string params and stringify them - -router.get('/register', function(req, res, next) { - var state = req.query.state; // retrieve the state param that contains the SPA client side route user needs to be redirected to. - - delete req.query.state; // remove it from query params. - res.redirect('http://localhost:3000/#/' + state + '?' + qs.stringify(req.query)); // Send a 302 redirect for the expected route -}); - -module.exports = router; - -``` \ No newline at end of file +topics: + - email + - spa +contentType: how-to +useCase: customize-emails +--- +# Single-Page App Email Redirect Issue + +For single-page applications (SPAs), the **Redirect To** URL may contain the hash and route for a particular state/view in the app, followed by route parameters. + +This can cause the following issue with the **Redirect To** URL: + +```text +http://localhost:3000/#/register +``` + +Which will result in a user getting redirected to following URL: + +```text +http://localhost:3000/?supportSignUp=true + &supportForgotPassword=true + &email=ashish.dasnurkar%40gmail.com + &message=Your%20email%20was%20verified.%20You%20can%20continue%20using%20the%20application. + &success=true#/register +``` + +This is per the [RFC 3986](https://tools.ietf.org/html/rfc3986#section-3) spec that defines the expected order of a URL as `scheme|authority|path|query|fragment`. + +However, SPA frameworks (such as Angular) typically expect URLs in the `scheme|authority|path|fragment|query` format (with the query string parameters at the end). This causes the application not to enter the expected state. + +For example, with the above URL, the app will be routed to `/` instead of `/#/register`. + +## 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. + +1. Add a server-side URL as the **redirect To** URL with a `route` parameter that records the SPA route for the redirect. + +```text +http://localhost:3001/register?route=register +``` + +2. Next, create a server-side route controller that reads the `route` and other parameters from the URL and redirects to the SPA route specified in `route` parameter. Remember to append the other parameters received from Auth0. + +```js +var express = require('express'); +var router = express.Router(); +var qs = require('qs'); // to read query string params and stringify them + +router.get('/register', function(req, res, next) { + var route = req.query.route; // retrieve the route param that contains the SPA client side route user needs to be redirected to. + + delete req.query.route; // remove it from query params. + res.redirect('http://localhost:3000/#/' + route + '?' + qs.stringify(req.query)); // Send a 302 redirect for the expected route +}); + +module.exports = router; +``` diff --git a/articles/email/templates.md b/articles/email/templates.md index fbf6843513..cc7a76a95c 100644 --- a/articles/email/templates.md +++ b/articles/email/templates.md @@ -1,38 +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 -::: panel-warning Notice -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. +::: warning +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 (i.e. only one template for change passsword emails). +::: note +Only one template can be used for each template type (for example, only one template for verify emails). +::: + +At this time, Auth0 does not support plaintext/text-based emails. + +## Configuring email templates + +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. -## Configuring *From*, *Subject*, *Redirect To*, and *URL Lifetime* +::: 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` -For each type of email, you can customize the **From Address**, the **Subject**, the **Redirect To** and the **URL Lifetime**. +See [Configuring the Redirect To URL](#configuring-the-redirect-to-url) for more details. -### *From Address* +### 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. -::: panel-info Domain blacklist -For security purposes, you may not send customized emails from any `@auth0.com` address. If you are an appliance user, you may configure a similar domain blacklist. +::: note +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**: @@ -42,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 @@ -58,151 +116,166 @@ 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 modify the lifetime of this link for security purposes. By default, the lifetime is 432,000 seconds (five days). -You can redirect users to a specific page on the **Allowed Callback URL** using the following: +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 URL**s configured, Auth0 will use the first URL listed. - -#### Dynamic Redirect To URLs +### Configuring the Redirect To URL -You can set up a different Redirect To URLs based on your Client ID. For example: +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. -```text -{% if application.clientID == '${account.clientId}' %} http://jwt.io {% else %} http://auth0.com {% endif %} -``` +::: 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. -::: panel-info SPA Issue -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`. -#### 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: +::: 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). +::: -* `email` -* `email_verified` -* `picture` -* `name` -* `nickname` -* `given_name` -* `family_name` -* `app_metadata` - stores user attributes (such as user preferences) that do not impact a user's core functionality -* `user_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. +### Configuring the Message Body -[Learn more about `app_metadata` and `user_metadata`](/metadata) +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). -For example, you can refer to attributes in the template to control flow as follows: +#### Multilingual Email Templates + +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' %} Hola {{ user.name }}, ... -{% elseif user.user_metadata.lang == 'it' %} +{% elsif user.user_metadata.lang == 'it' %} Ciao {{ user.name }}, ... {% else %} Hi {{ user.name }}, ... {% endif %} ``` -#### Using Markdown Syntax +##### Debugging Liquid Template Variables -> 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. +To assist your template development, we've added a custom `{% debug %}` liquid tag, which outputs a summary of the template variables available to your template when it was rendered. _Remember to remove this tag from any "live" templates._ -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: +#### Using Markdown Syntax + +::: warning +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. +::: -* `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 + +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: + +* `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 target URL handler should be prepared to gracefully handle other possible messages as well. + +### Verification Email (Using Code) + +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. + ### Welcome Email 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). -The following macros are available in the **Welcome Email** template: +### Change Password Email -* `{application.name}` -* `{connection.name}` -* `{user.email}` +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. -### Change Password Confirmation Email +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: -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. +```html +Click here to change your password +``` -The following macros are available in the **Change Password Confirmation** email template: +#### Redirect To Results for the Change Password Template -* `{application.name}` -* `{connection.name}` -* `{user.email}` +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: -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: +* `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 -```text -http://myapplication.com/my_page/ - ?success=true - &message=You%20can%20now%20login%20to%20the%20application%20with%20the%20new%20password. -``` +The target URL handler should be prepared to gracefully handle other possible messages as well. ### Blocked Account Email @@ -210,10 +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` + +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. + +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 +``` + +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 %} +``` + +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 123c2475a5..827791ceba 100644 --- a/articles/email/testing.md +++ b/articles/email/testing.md @@ -1,24 +1,34 @@ ---- -description: Auth0 recommends you setup a fake SMTP server while in development or testing. --- +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 + +While working in your development or testing environment, we recommend that you use a test SMTP server so that you can: -# Set up a Test SMTP Provider +* Check that deliveries are successful +* View how emails you sent appear to recipients prior to go live -Auth0 recommends you setup a fake SMTP server while in development or testing that you can use to check delivery and view how emails will appear without the risk of spamming your users. +You can either: -You can either setup your own SMTP server, or use a services like [mailtrap.io](https://mailtrap.io/) that are designed for this purpose. +* Set up your own SMTP server +* Use a third-party service (see the [Resources to Consider](#resources-to-consider) section for options you might use) -## Fake SMTP Services +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). -* [mailtrap.io](https://mailtrap.io/) -* [debugmail.io](https://debugmail.io/) +<%= include('../_includes/_email-domain-blacklist') %> -## Frameworks & other tools +## Resources to Consider +::: next-steps +* [Debug Mail](https://debugmail.io/) * [FakeSMTP](https://nilhcem.github.io/FakeSMTP/) * [Haraka](https://haraka.github.io/) - -::: panel-info Note -Auth0 has only tested [mailtrap.io](https://mailtrap.io/) in this scenario. +* [MailTrap](https://mailtrap.io/) +* [smtp4dev](https://smtp4dev.codeplex.com/) ::: - diff --git a/articles/errors/deprecation-errors.md b/articles/errors/deprecation-errors.md new file mode 100644 index 0000000000..f3b68bb35f --- /dev/null +++ b/articles/errors/deprecation-errors.md @@ -0,0 +1,94 @@ +--- +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 + +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. This guide will provide assistance with searching your logs for deprecation related messages as well as explanations of potential causes and resolutions for particular items. + +## 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/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}/#/). + +::: 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. +::: + +Navigate to the **Logs** screen in the Dashboard. Search for deprecation related messages by entering `type:depnote` in the query box. + +![Dashboard - Logs](/media/articles/errors/depnotes-logs.png) + +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. Clicking on the link in the **Event** column for each item will show additional information such as the client id which identifies the client application using the deprecated feature. + +Clicking each item and selecting **Context Data** will give you details about the item: + +![Dashboard - Logs](/media/articles/errors/depnotes-legacy-lock-context-data.png) + +![Dashboard - Logs](/media/articles/errors/depnotes-ssodata-context-data.png) + +### Search logs via the Management API + +Customers can also use the Management API to search through logs for such messages by looking for "Type" = "depnote". + +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 get an API token](/api/management/v2/tokens). + +![Management API - Token Setup](/media/articles/errors/libraries/management-api-set-token.png) + +On the left, navigate to **Logs > Search log events** and then scroll down to **Parameters**. + +![Management API - Logs](/media/articles/errors/libraries/management-api-logs.png) + +In the **q** field enter: `type:"depnote"` + +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 + +### up-idp-initiated + +![Management API - Legacy Lock Results](/media/articles/errors/depnotes-mgt-api-legacy-lock.png) + +**Error Description:** "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. | + +### ssodata + +![Management API - getSSOData Results](/media/articles/errors/depnotes-mgt-api-ssodata.png) + +**Error Description:** "SSOdata endpoint: This feature is being deprecated. Please refer to our documentation to learn how to migrate your application." + +| 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/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 new file mode 100644 index 0000000000..fe0a389dc8 --- /dev/null +++ b/articles/extensions/_troubleshoot-webhooks.md @@ -0,0 +1,15 @@ +## How to Troubleshoot Webhooks + +If your webhook isn't working, it can be difficult to troubleshoot and determine what is causing the issue. Webhooks are asynchronous, so testing them can involve you triggering the webhook, waiting, and then checking the response (assuming that you did receive a response). + +However, there are certainly alternatives to the inefficient process we detailed above. While full details of how to troubleshoot a particular webhook is outside the scope of this article, here are some steps you can take to debug: + +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 [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/) + +1. Test your webhook code locally using something like [localtunnel](https://github.com/localtunnel/localtunnel) or [ngrok](https://ngrok.com/) + +1. Use a tool like [Runscope](https://www.runscope.com/) or [Assertible](https://assertible.com/) to watch the whole execution flow \ No newline at end of file diff --git a/articles/extensions/account-link.md b/articles/extensions/account-link.md new file mode 100644 index 0000000000..6c7e6f8a74 --- /dev/null +++ b/articles/extensions/account-link.md @@ -0,0 +1,99 @@ +--- +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 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. + +## Install the Extension + +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. + +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 + +### Changing the Application Name + +We recommend changing the name of the default application used for the extension to something descriptive and easy to read for your customers, like `Account Linking`, since it will appear on the **Login Page** when they authenticate their primary account. + +### Updating the Login Page + +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 **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. + +Toward the bottom of the object configuring the Lock widget, add the following line (after the `closable` setting works well): + +```text +allowSignUp: !config.extraParams.prevent_sign_up, +``` + +![Updating the Login Page](/media/articles/extensions/account-link/hosted-page-code.png) + +Then save your changes and attempt to link an account. You'll notice that the **Sign Up** option is no longer present and your users are safe from an extra level of confusion. + +![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. + +![Account Linking Page](/media/articles/extensions/account-link/extension-page-example.png) + +## Administration Panel + +You can customize your account linking login page and widget using the extension administration panel. + +Go to **Dashboard > Extensions > Installed Extensions > Auth0 Account Link**. + +![Dashboard > Extensions > Installed Extensions](/media/articles/extensions/account-link/installed-extensions.png) + +You will be redirected to the admin site. + +There you can edit the HTML code of your hosted page and change some settings of the account linking widget such as title, logo, color and language. + +![HTML Editor](/media/articles/extensions/account-link/html-editor.png) + +::: warning +Do not remove `{{ ExtensionCSS }}`, `{{ CustomCSS }}`, `{{ Auth0Widget }}`, or `{{ ExtensionScripts }}` from the HTML code of the site. This will cause the extension to not display the account linking widget. +::: + +![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 47833845f5..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 @@ -18,7 +24,9 @@ At that point, a consent dialog will be displayed, requesting access to your acc ![Consent Screen for Extension](/media/articles/extensions/authentication-api-debugger/consent.png) -**NOTE**: The extension will communicate to the Management API on your behalf to retrieve details about the Clients which you have configured in your Auth0 Dashboard, and use this information to call the Authentication API endpoints. +::: note +The extension will communicate to the Management API on your behalf to retrieve details about the Applications which you have configured in your Auth0 Dashboard, and use this information to call the Authentication API endpoints. +::: Once you accept, you will be navigated to the extension's views. @@ -29,8 +37,8 @@ The basic configuration for all flows can be found on the _Configuration_ tab. ![Extension Configuration Screen](/media/articles/extensions/authentication-api-debugger/configuration.png) * **Domain**: The domain for your tenant. This field is read-only and only displayed for informational purposes. -* **Client**: The Client for which you want to initiate any of the authentication flows. You can manage the list of Clients in the [Clients section](${manage_url}/#/clients) of your Auth0 Dashboard. -* **Callback URL**: The callback URL for this extension. It is important that you add this URL to the **Allowed Callback URLs** under the _Settings_ for the Client. +* **Application**: The Application for which you want to initiate any of the authentication flows. You can manage the list of Applications in the [Applications section](${manage_url}/#/applications) of your Auth0 Dashboard. +* **Callback URL**: The callback URL for this extension. It is important that you add this URL to the **Allowed Callback URLs** under the _Settings_ for the Application. * **State**: Optional state information which can be sent with the authentication flow. * **Connection**: Specify the name of the connection which you want to use to log in. You can use this parameter to bypass the main Login screen and go directly for the login screen of the relevant Identity Provider. @@ -38,7 +46,7 @@ The basic configuration for all flows can be found on the _Configuration_ tab. Once you have specified the basic configuration, you can switch to the _OAuth2 / OIDC_ tab to execute any of the flows. For some of the flows you may need to specify more settings which can be found by scrolling down the page. -![OAuth2 / OIDC Settings](/media/articles/extensions/authentication-api-debugger/oauth-oidc-settings.png) +![OAuth2 / OIDC Settings](/media/articles/extensions/authentication-api-debugger/oauth-oidc-settings.png) These settings will depend on the actual flow which is being executed, and it is suggested that you refer to the [Auth0 Authentication API documentation](/api/authentication) for more information on the applicable parameters for each flow. diff --git a/articles/extensions/authentication-api-webhooks.md b/articles/extensions/authentication-api-webhooks.md index 08c5534ed3..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. +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,13 +17,15 @@ 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 -- __Log_Level__: The minimal log level of events that you would like sent to Loggly +- __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 Once you have provided the required pieces of information, click "Install" to finish installing the extension. @@ -25,3 +33,43 @@ Once you have provided the required pieces of information, click "Install" to fi ## Using Your Installed Extension You can view all scheduled jobs by clicking on the Auth0 Management API Webhooks line under the "Installed Extensions" tab. + +## Sample Payload + +Here is an example of the payload that will be sent: + +```json +{ + "date": "2016-02-25T13:42:08.791Z", + "type": "f", + "description": "Wrong email or password.", + "connection": "My-Users", + "client_id": "lIkP1Wn4qQPj56k9bE7fyMrbsaaHXd6c", + "client_name": "Default App", + "ip": "11.22.33.44", + "user_agent": "Chrome 48.0.2564 / Mac OS X 10.11.3", + "details": + { "error": + { "message": "Wrong email or password.", + "oauthError": "Wrong email or password.", + "type": "invalid_user_password" }, + "body": + { "client_id": "lIkP1Wn4qQPj56k9bE7fyMrbsaaHXd6c", + "username": "john@example.com", + "password": "*****", + "connection": "My-Users", + "grant_type": "password", + "scope": "openid", + "device": "" }, + "qs": {}, + "connection": "My-Users" }, + "user_id": "", + "user_name": "Default App", + "strategy": "auth0", + "strategy_type": "database", + "_id": "49556539073893675610923042044589174982043486779166687234", + "isMobile": false +} +``` + +<%= include('./_troubleshoot-webhooks') %> diff --git a/articles/extensions/authorization-extension-v1.md b/articles/extensions/authorization-extension-v1.md deleted file mode 100644 index 48d255d9c2..0000000000 --- a/articles/extensions/authorization-extension-v1.md +++ /dev/null @@ -1,113 +0,0 @@ ---- -description: This page explains how to setup and manage the Authorization Extension v1. ---- - -# Auth0 Authorization Extension v1 - -::: panel-warning Notice -This page explains how to use version 1.x of the Authorization Extension, [click here for documentation of version 2.](/extensions/authorization-extension) -::: - -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 - -To install the Authorization extension, click on the "Auth0 Authorization" box on the main Extensions page of the Management Portal. You will be prompted to install the app. - -![](/media/articles/extensions/authorization/app-install.png) - -Once installed, you will see the app listed under "Installed Extensions." - -![](/media/articles/extensions/authorization/installed-extensions.png) - -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. - -![](/media/articles/extensions/authorization/auth-dashboard.png) - -## Rule Behavior for the Authorization Extension - -The rule that is automatically created when the extension is installed will do the following: - -1. Determine the user's group membership using information provided by the Extension,; -2. Store the user's group membership info as part of the `app_metadata`; -3. Add the user's group membership to the outgoing token (which can be requested via the **OpenID Groups** scope); -4. Verify that the user has been granted access to the current application. - -> Note: Since this 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 will only be reflected within Auth0 after this user logs in again (eg: in the user's `app_metadata` or when calling the `/userinfo` endpoint). - -## Managing Authorizations Using Groups - -To create and manage the Groups with which you will use to manage users' settings, click on the "Groups" link on the Authorization Dashboard. - -When creating a Group, you will provide a **name** for the group, as well as a **description** of what that Group does. - -![](/media/articles/extensions/authorization/create-group.png) - -There are two ways for you to manage users and their Group memberships: - -* Opening the **group** and managing the group's users; - - ![](/media/articles/extensions/authorization/group-membership.png) - -* Opening the **user** and managing the user's group membership. - - ![](/media/articles/extensions/authorization/user-membership.png) - -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. Additionally, you may create nested groups, similar to the following: - -* Example Company - * Accounting - * External Accountants - * Human Resources - * Finance - * Finance IT Support - * Management - -To create nested Groups, you must first create all of the individual groups via the CREATE button on the Groups page of the Authorization Dashboard. - -![](/media/articles/extensions/authorization/add-nested-groups.png) - -To nest the groups: - -1. Open up the top-level Group (in the example above, this would be the Example Company Group); -2. Click on the "Nested Groups" tab; -3. Click on the ADD button in the top right corner. You will be presented with a list of Groups that can be added to the primary Group. To select a particular Group, click on the bright blue "Add Group" button at the end of the row. After each selection, you will be returned to the primary Group page. Continue this process until you have included all the Groups you need. - -With nested Groups, adding a user to a sub-Group also grants the user permissions granted to the Groups that are parents of that Group. For example, adding a user to the External Accountants group automatically makes them a member of the Finance and Company Groups. Please note, however, that the user is only explicitly a member of External Accountants; all other memberships are purely dynamic and are calculated as needed (for example, when loading the user's group memberships). - -![](/media/articles/extensions/authorization/nested-groups.png) - -To prevent confusion, you will be shown both the explicit members AND the "calculated members" that result from nested groups whenever you open a specific Groups page in the Authorization Dashboard. - -## Group Mappings - -Group Mappings allow you to dynamically "add" users to different Groups based on the users' Connections. - -For example, suppose your company has the following Groups of users: - -* **Americas - West**, which consists of users who connect via *google-oauth2*; -* **Europe - West**, which consists of users who connect via *google-oauth2*. - -With Group Mappings, you can consolidate these Groups and the permissions allotted to the included users into one larger group, such as Overall Company Group. Similar to nested Groups, the memberships of the users in Overall Company Group is not explicit, but dynamic, and are calculated at runtime. Such memberships will appear listed as such under the Groups page. - -![](/media/articles/extensions/authorization/group-mapping.png) - -## Controlling Application Access - -Generally, if a user is included in a Connection that is enabled for a specific application, that user is granted access to that application. With the Authorization Extension, you may further specify the users that are allowed access to certain applications. - -To set application access permissions, go to the "Applications" tab of the Authorization Dashboard. You will be presented with an overview of your applications and any security settings that may apply. - -![](/media/articles/extensions/authorization/auth-apps.png) - -The extension sets permissions per application, so you will be presented with specific security details once you click on a listed app. For example, you may specify that only those in the **Management** Group may access an application called "My App." To do so, click on the "Add" button located on the top-right corner. - -![](/media/articles/extensions/authorization/no-groups-auth.png) - -You will be presented with a list of Groups that can be added to this application. Once you do so, users within the group will be allocated authorization access. - -![](/media/articles/extensions/authorization/select-auth-groups.png) - -Users who are not a part of either of these groups are not granted access to the application, and such access (or lack thereof) is enforced through an automatically-created rule when the extension is installed. - -![](/media/articles/extensions/authorization/auth-groups.png) diff --git a/articles/extensions/authorization-extension.md b/articles/extensions/authorization-extension.md deleted file mode 100644 index 7dc2542ab1..0000000000 --- a/articles/extensions/authorization-extension.md +++ /dev/null @@ -1,279 +0,0 @@ ---- -description: This page explains how to setup and manage the Authorization Extension v2. ---- - -# Auth0 Authorization Extension - -::: panel-warning Notice -This page explains how to use version 2 and later of the Authorization Extension, [click here for documentation of version 1.](/extensions/authorization-extension-v1) - -[Click here for information about upgrading your Authorization Extension version](#migration-from-v1-to-v2-of-the-authorization-extension-breaking-changes-) -::: - -The Auth0 Authorization Extension provides user authorization support in Auth0. Currently the extension supports authorizations for Users using Groups, Roles and Permissions. - -## How to Install - -First make sure you have a Client created that can support the Authorization extension. Supported client types for the Authorization extension are: **Native**, **Single Page Web Applications** and **Regular Web Applications**. Clients with no type assigned or non-interactive clients are not supported. - -To install the Authorization extension, click on the "Auth0 Authorization" box on the main [Extensions](${manage_url}/#/extensions) page of the Management Portal. You will be prompted to install the app. - -![Install Authorization Extension](/media/articles/extensions/authorization/app-install-v2.png) - -Once installed, you will see the app listed under **Installed Extensions**. - -![Installed Extensions](/media/articles/extensions/authorization/installed-extensions-v2.png) - -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. Then you will be redirected to the Authorization Dashboard. - -![Authorization Dashboard](/media/articles/extensions/authorization/auth-dashboard-v2.png) - -## Migration from v1 to v2 of the Authorization Extension (breaking changes) - -::: panel-warning Notice -One of the major changes of the v2 of the Authorization Extension is that the **Applications** section has been removed. The driving factor for this change is complexity: Defining a policy when someone can or cannot access an application depends on different factors (roles, groups, time of day, MFA, ...). This is why the desired approach for this use case is [rules](#controlling-application-access). -::: - -### Upgrade the Extension Version - -To upgrade your existing version of the Authorization Extension, go to [Extensions section](${manage_url}/#/extensions) of the dashboard, then click **Installed Extensions**. - -Next to the Authorization Extension, you should see a link to upgrade to the latest version. - -## Configure the Extension - -The extension needs to be configured before it can enforce your authorization logic. - -Click **Configuration** on the dropdown on the top right of the **Authorization Dashboard**. - -![Click Configuration](/media/articles/extensions/authorization/click-configuration.png) - -This will bring you to the **Rule Configuration** section of the **Configuration** page. - -![Configuration page](/media/articles/extensions/authorization/configuration.png) - -Here you can configure: - -### Token Contents - -**Storing Additional Data in Tokens**: - -If you want to store data on Groups, Roles, or Permissions of a user in the token, use the toggle buttons to add the desired data pieces. - -::: panel-warning Notice -Storing too much data in the token can cause performance issues or even prevent the token to be issued. Make sure you only choose to store the data that you'll really need. If this data can grow too large, consider using persistence instead of adding it to the token. -::: - -**Passthroughs**: - -If you have users that receive groups from the Identity Provider (such as Active Directory) then you can merge these groups (in order to preserve them) with the groups defined in your Authorization Extension. Use the toggle buttons to choose which to merge of Groups, Roles and Permissions. - -### Persistence - -You can also store the authorization context information in the user profile. The data will be stored in the [user's `app_metadata`](/metadata) and you can then use the [Management API](/api/management/v2) or the [`/tokeninfo` endpoint](/api/authentication/reference#get-token-info) to retrieve this information after the user has logged in. - -## Setup the Authorization Extension - -Once you have the extension configured you can start to configure Groups, Roles and Permissions for your Users in the Authorization Extension dashboard. - -### Users - -The **Users** section lists all the current users of your applications. Here you can search your users and select a specific user. You can then view their profile, edit or view their groups, and edit or view their roles. - -![Users Section](/media/articles/extensions/authorization/users.png) - -### Groups - -To create and manage the Groups with which you will use to manage users' settings, click on the "Groups" link in the Authorization Dashboard. - -When creating a Group, you will provide a **name** for the group, as well as a **description** of what that Group does. - -![Create a New Group](/media/articles/extensions/authorization/create-group-v2.png) - -There are two ways for you to manage users and their Group memberships: - -* Opening the **group** and managing the group's users; - - ![Open a Group](/media/articles/extensions/authorization/group-membership-v2.png) - -* Opening the **user** and managing the user's group membership. - - ![Open a User](/media/articles/extensions/authorization/user-membership-v2.png) - -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. Additionally, you may create nested groups, similar to the following: - -* Example Company - * Accounting - * External Accountants - * Human Resources - * Finance - * Finance IT Support - * Management - -To create nested Groups, you must first create all of the individual groups via the **CREATE** button on the Groups page of the Authorization Dashboard. - -![Add Nested Groups](/media/articles/extensions/authorization/add-nested-groups-v2.png) - -To nest the groups: - -1. Open up the top-level Group (in the example above, this would be the Example Company Group); -2. Click on the **Nested Groups** tab; -3. Click on the **ADD NESTED GROUP** button. Then you will be presented with a list of Groups that can be added to the primary Group. To select a particular Group, click on the check box to the left of the name. After each selection, you will be returned to the primary Group page. Continue this process until you have included all the Groups you need. - -With nested Groups, adding a user to a sub-Group also grants the user permissions granted to the Groups that are parents of that Group. For example, adding a user to the External Accountants group automatically makes them a member of the Finance and Company Groups. Please note, however, that the user is only explicitly a member of External Accountants; all other memberships are purely dynamic and are calculated as needed (for example, when loading the user's group memberships). - -![View Nested Groups](/media/articles/extensions/authorization/nested-groups-v2.png) - -To prevent confusion, you will be shown both the explicit members AND the "calculated members" that result from nested groups whenever you open a specific Groups page in the Authorization Dashboard. - -### Group Mappings - -Group Mappings allow you to dynamically "add" users to different Groups based on the users' Connections. - -For example, suppose your company has the following Groups of users: - -* **Americas - West**, which consists of users who connect via *google-oauth2*; -* **Europe - West**, which consists of users who connect via *google-oauth2*. - -With Group Mappings, you can consolidate these Groups and the permissions allotted to the included users into one larger group, such as Overall Company Group. Similar to nested Groups, the memberships of the users in Overall Company Group is not explicit, but dynamic, and are calculated at runtime. Such memberships will appear listed as such under the Groups page. - -![Group Mappings](/media/articles/extensions/authorization/group-mapping-v2.png) - -### Roles - -The Roles that you will create will depend on the access to certain permissions in your application. 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](#permissions) and then assigned to a certain Role. - -You can create different types of Roles such as: Expense Admins, Expense Manager, and Expense User for your Expense Management Tool. - -![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. - -![Add a New Role](/media/articles/extensions/authorization/add-role.png) - -Once you have a **Role** created, you can add it to a user so they can then have the associated **Permissions**. To add a role to a user, find the user in the **Users** section, then click the **Roles** tab. Then click **ADD ROLE TO USER** to choose which roles you wish to assign to a user, then click **SAVE**. - -![Add Role to User](/media/articles/extensions/authorization/add-role-to-user.png) - -### Permissions - -Permissions are the actions or functions that can be added to Roles. - -Using the previous example of an Expense application, let's look at possible roles and how they can be associated with certain permissions: - -- Role: Expense User - - Permissions: - - View their own expenses - - Add a new expense - -- Role: Expense Admin - - Permissions: - - Approve expenses - - View all user expenses - - Delete expenses - - Add a new expense - -To create a new permission, go to the **Permissions** section of the Authorization Extension dashboard. - -![Permissions](/media/articles/extensions/authorization/permissions.png) - -Then click the **CREATE PERMISSION** button. Then enter the name of the permission, the ddescription and select the application for which this permission applies. - -![Create Permission](/media/articles/extensions/authorization/create-permission.png) - -Once you have your permissions created, you can associate them with [Roles](#roles). - -## Enable API Access - -At this point the extension might contain some roles, groups, permissions. Your users might also have been assigned to specific roles and groups. - -The Authorization Dashboard can optionally enable API access which will allow you to automate provisioning and query the authorization context of your users in real time. - -To get to **API** section, click **API** on the dropdown on the top right of the **Authorization Dashboard**. - -![Click API](/media/articles/extensions/authorization/click-api.png) - -Under **Settings** you can use the toggle to enable API Access. - -You can also set the Token Expiration, Token Issuer, Token Audience and Url. Click the **SAVE** button when finished editing these field. - -Click the **Explorer** section to see the API endpoints that can be called. - -![Explorer](/media/articles/extensions/authorization/api-explorer.png) - -## Rule Behavior for the Authorization Extension - -In addition to API access, you can also deploy a rule that reaches out to the extension each time a user logs in. Once the rule is enabled, it will do the following: - -1. Determine the user's group membership, roles and permissions using information provided by the Extension; -2. Optionally store the user's groups, roles and permissions info as part of the `app_metadata`, to enable this [see details below](#persistence); -3. Add the user's groups, roles and permissions to the outgoing token (which can be requested via the **OpenID Groups** scope) [see details below](#token-contents); - -> Note: Since this 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 will only be reflected within Auth0 after this user logs in again (eg: in the user's `app_metadata` or when calling the `/userinfo` endpoint). - -### Control Application Access - -In addition, you can write your own rules that are applied after the rule that is published by the extension. For example you can write a rule to control application access. One way to achieve this is to use the [Application Metadata](/rules/metadata-in-rules#reading-metadata) where you can specify on every client that roles are required. - -- For example, you can have **required_roles**: `Timesheet User,Timesheet Admin` - -Then you can write a rule that enforces this logic: - -```js -function (user, context, callback) { - context.clientMetadata = context.clientMetadata || {}; - if (context.clientMetadata.required_roles && context.clientMetadata.required_roles.length){ - if (user.roles) { - var _ = require('lodash'); - var roles = context.clientMetadata.required_roles.split(','); - var matchingRoles =_.filter(user.roles, function(roleName) { - return _.includes(roles, roleName); - }); - - if (matchingRoles && matchingRoles.length) { - return callback(null, user, context); - } - } - - return callback(new UnauthorizedError('You do not have the required role to access ' + context.clientName)); - } - - callback(null, user, context); -} -``` - -> Note: For this to work you must enable "Roles" under the "Token Contents" section and publish the rule. Then add this rule after the generated "auth0-authorization-extension" rule. - -## Import/Export Authorization Data - -You can import new data or export exisiting authorization data with a JSON file. This can be useful when moving over an environment, but remember roles and permissions are linked to specific clients, so you will need to update to the correct `applicationId` when moving environments. - -You can get to the **Import/Export** section by clicking **Configuration** on the dropdown on the top right of the **Authorization Dashboard**. - -![Click Configuration](/media/articles/extensions/authorization/click-configuration.png) - -And then clicking **Import/Export**. - -![Import/Export Section](/media/articles/extensions/authorization/import-export.png) - -Use this form to copy and/or paste, or edit JSON data and then click either the **IMPORT** or **EXPORT** button when finished, depending on your use case. - -## Storage - -The extension uses the internal Webtask storage capabilities, which are limited to 500 KB. Here are some examples of what this means in terms of scenarios: - - - If you have 1000 groups and 3000 users, where each user is member of 3 groups about 475 KB of data would be used. - - If you have 20 groups and 7000 users, where each user is member of 3 groups about 480 KB of data would be used. - -Think you need more? [Contact support.](${env.DOMAIN_URL_SUPPORT}) - -## Troubleshooting - -### An authentication results in a token that contains Groups but not Roles or Permissions - -If this happens, chances are you created roles and permissions for one application (client) but are authenticating with another. For example, you created all your roles/permissions against Website A but create another website client in Auth0 (Website B) and use its `client_id` and `client_secret` in your application. This can also occur 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_, which is not the same as the application you configured in the extension. - -### My application/client is not shown in the dropdown when setting up the extension - -The supported client types for the Authorization extension are: **Native**, **Single Page Web Applications** and **Regular Web Applications**. Clients with no type assigned or non-interactive clients are not supported. - diff --git a/articles/extensions/authorization-extension/index.yml b/articles/extensions/authorization-extension/index.yml new file mode 100644 index 0000000000..262200f160 --- /dev/null +++ b/articles/extensions/authorization-extension/index.yml @@ -0,0 +1,9 @@ +versioning: + baseUrl: extensions/authorization-extension + current: v2 + versions: + - v1 + - v2 + defaultArticles: + v1: index + v2: index diff --git a/articles/extensions/authorization-extension/v1/index.md b/articles/extensions/authorization-extension/v1/index.md new file mode 100644 index 0000000000..eefc569539 --- /dev/null +++ b/articles/extensions/authorization-extension/v1/index.md @@ -0,0 +1,122 @@ +--- +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 + +::: version-warning +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. + +## Setting Up a New Authorization Extension + +To install the Authorization extension, click on the "Auth0 Authorization" box on the main Extensions page of the Management Portal. You will be prompted to install the app. + +![](/media/articles/extensions/authorization/app-install.png) + +Once installed, you will see the app listed under "Installed Extensions." + +![](/media/articles/extensions/authorization/installed-extensions.png) + +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. + +![](/media/articles/extensions/authorization/auth-dashboard.png) + +## Rule Behavior for the Authorization Extension + +The rule that is automatically created when the extension is installed will do the following: + +1. Determine the user's group membership using information provided by the Extension,; +2. Store the user's group membership info as part of the `app_metadata`; +3. Add the user's group membership to the outgoing token (which can be requested via the **OpenID Groups** scope); +4. Verify that the user has been granted access to the current application. + +::: note +Since this 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 will only be reflected within Auth0 after this user logs in again (eg: in the user's `app_metadata` or when calling the `/userinfo` endpoint). +::: + +## Managing Authorizations Using Groups + +To create and manage the Groups with which you will use to manage users' settings, click on the "Groups" link on the Authorization Dashboard. + +When creating a Group, you will provide a **name** for the group, as well as a **description** of what that Group does. + +![](/media/articles/extensions/authorization/create-group.png) + +There are two ways for you to manage users and their Group memberships: + +* Opening the **group** and managing the group's users; + + ![](/media/articles/extensions/authorization/group-membership.png) + +* Opening the **user** and managing the user's group membership. + + ![](/media/articles/extensions/authorization/user-membership.png) + +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. Additionally, you may create nested groups, similar to the following: + +* Example Company + * Accounting + * External Accountants + * Human Resources + * Finance + * Finance IT Support + * Management + +To create nested Groups, you must first create all of the individual groups via the CREATE button on the Groups page of the Authorization Dashboard. + +![](/media/articles/extensions/authorization/add-nested-groups.png) + +To nest the groups: + +1. Open up the top-level Group (in the example above, this would be the Example Company Group); +2. Click on the "Nested Groups" tab; +3. Click on the ADD button in the top right corner. You will be presented with a list of Groups that can be added to the primary Group. To select a particular Group, click on the bright blue "Add Group" button at the end of the row. After each selection, you will be returned to the primary Group page. Continue this process until you have included all the Groups you need. + +With nested Groups, adding a user to a sub-Group also grants the user permissions granted to the Groups that are parents of that Group. For example, adding a user to the External Accountants group automatically makes them a member of the Finance and Company Groups. Please note, however, that the user is only explicitly a member of External Accountants; all other memberships are purely dynamic and are calculated as needed (for example, when loading the user's group memberships). + +![](/media/articles/extensions/authorization/nested-groups.png) + +To prevent confusion, you will be shown both the explicit members AND the "calculated members" that result from nested groups whenever you open a specific Groups page in the Authorization Dashboard. + +## Group Mappings + +Group Mappings allow you to dynamically "add" users to different Groups based on the users' Connections. + +For example, suppose your company has the following Groups of users: + +* **Americas - West**, which consists of users who connect via *google-oauth2*; +* **Europe - West**, which consists of users who connect via *google-oauth2*. + +With Group Mappings, you can consolidate these Groups and the permissions allotted to the included users into one larger group, such as Overall Company Group. Similar to nested Groups, the memberships of the users in Overall Company Group is not explicit, but dynamic, and are calculated at runtime. Such memberships will appear listed as such under the Groups page. + +![](/media/articles/extensions/authorization/group-mapping.png) + +## Controlling Application Access + +Generally, if a user is included in a Connection that is enabled for a specific application, that user is granted access to that application. With the Authorization Extension, you may further specify the users that are allowed access to certain applications. + +To set application access permissions, go to the "Applications" tab of the Authorization Dashboard. You will be presented with an overview of your applications and any security settings that may apply. + +![](/media/articles/extensions/authorization/auth-apps.png) + +The extension sets permissions per application, so you will be presented with specific security details once you click on a listed app. For example, you may specify that only those in the **Management** Group may access an application called "My App." To do so, click on the "Add" button located on the top-right corner. + +![](/media/articles/extensions/authorization/no-groups-auth.png) + +You will be presented with a list of Groups that can be added to this application. Once you do so, users within the group will be allocated authorization access. + +![](/media/articles/extensions/authorization/select-auth-groups.png) + +Users who are not a part of either of these groups are not granted access to the application, and such access (or lack thereof) is enforced through an automatically-created rule when the extension is installed. + +![](/media/articles/extensions/authorization/auth-groups.png) diff --git a/articles/extensions/authorization-extension/v2/api-access.md b/articles/extensions/authorization-extension/v2/api-access.md new file mode 100644 index 0000000000..c724cb1f4c --- /dev/null +++ b/articles/extensions/authorization-extension/v2/api-access.md @@ -0,0 +1,85 @@ +--- +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 + +::: 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 + +Log in to the Management Dashboard, and open up the [Authorization Extension](${manage_url}/#/extensions). + +To get to **API** section, click on your Auth0 tenant name on the top right of the **Authorization Dashboard**. Click **API**. + +![Click API](/media/articles/extensions/authorization/click-api.png) + +On the **Settings** page, use the toggle to enable API Access. + +![Enable API Access](/media/articles/extensions/authorization/enable-api-access.png) + +Once enabled, you'll be able to see or control (within the extension) some of the parameters of the tokens issued by the API. You can control the **time to expiration** of the token, as well as view the token's **audience**, **issuer**, and **URL** to access the API. + +![API Access Enabled](/media/articles/extensions/authorization/api-access-enabled.png) + +## Access the Extension's API + +When you enabled API access to the extension, Auth0 automatically created an API for your use in the [Dashboard]({$manage_url}/#/apis). To access the API, you'll need to create a Machine to Machine Application, which is the entity that interacts with the API itself. + +### Create the Application + +In the [Applications section of the Dashboard](${manage_url}/#/applications), click **Create Application**. Name your new Application, and choose the **Machine to Machine Application** type. Click **Create** to proceed. + +You'll be redirected to the **Quick Start** page of the Application, where you can customize the living documentation based on the API with which you'll use the Application. Select the API that Auth0 created for your extension (it should be called **auth0-authorization-extension-api** or similar). + +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/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/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/client-scopes.png) + +### Get the Access 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 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). + +You can also refer to the **API Explorer**, which documents everything you can do via command line once you've enabled access to your extension via API. + +Click over to the **Explorer** page for the API documentation. + +![Explorer](/media/articles/extensions/authorization/api-explorer.png) + +## Keep Reading + +::: next-steps +* [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) +::: diff --git a/articles/extensions/authorization-extension/v2/implementation/configuration.md b/articles/extensions/authorization-extension/v2/implementation/configuration.md new file mode 100644 index 0000000000..8182bf0e25 --- /dev/null +++ b/articles/extensions/authorization-extension/v2/implementation/configuration.md @@ -0,0 +1,88 @@ +--- +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 + +Open up the Authorization Extension, and click **Configuration** on the drop-down menu in the top right of the **Authorization Dashboard**. + +![Click Configuration](/media/articles/extensions/authorization/click-configuration.png) + +This brings you to the **Rule Configuration** section of the **Configuration** page. + +![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. + +### 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 + +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. + +To add groups, roles, and/or permissions information to the outgoing token, simply enable the slider next to the option you want included. + +![Set token contents](/media/articles/extensions/authorization/user-info.png) + +::: panel-warning Data Limitations +Storing too much data in the token may cause performance issues or even prevent the issuance of the token. Be sure to store only what you need. If you need a large amount of user data readily available, consider using [persistence](#store-authorization-information-in-the-users-profiles) instead of adding the data to the token. +::: + +### Merge Authorization Data from the IdP + +You might have users that receive groups, roles, or permissions from the identity provider (IdP) you're using, such as Active Directory. If you want to merge these items (to preserve them) with the ones defined in the Authorization Extension, make sure you enable the appropriate **Passthrough** options. Simply enable the slider next to the appropriate merges you want enabled. + +![Enable passthroughs](/media/articles/extensions/authorization/passthrough.png) + +### Store Authorization Information in the Users' Profiles + +If your authorization context is large (for example, the user might belong to many groups or have been granted many permissions), you might find it useful to store some of the authorization content in the users' profiles. This allows you to store less information in the token, which means you're less likely to see performance-related issues or even problems with token issuance. **Persistence** is the process by which you store groups, roles, and permissions information in the users' profiles. + +The data will be stored in the user's `app_metadata` field, and you can then use the [Management API](/api/management/v2) or the [Dashboard](${manage_url}/#/users) to retrieve this information after the user has logged in. + +![Enable persistence](/media/articles/extensions/authorization/persistence.png) + +## Save Changes to Your Rule + +Once you've configured your rule, click **Publish Rule**. This creates a rule for your tenant that executes after each user login. + +### View Your Rule + +If you'd like to see the rule you've created, you can do so using the [Dashboard](${manage_url}/#/rules). + +![](/media/articles/extensions/authorization/auth-ext-rule-list.png) + +You can open it up to see the exact rules configuration. + +![](/media/articles/extensions/authorization/edit-rule.png) + +## Keep Reading + +::: next-steps +* [Import and Exporting Data](/extensions/authorization-extension/v2/import-export-data) +* [Enable API Access to the Extension](/extensions/authorization-extension/v2/api-access) +* [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) +::: diff --git a/articles/extensions/authorization-extension/v2/implementation/installation.md b/articles/extensions/authorization-extension/v2/implementation/installation.md new file mode 100644 index 0000000000..5d74a9501f --- /dev/null +++ b/articles/extensions/authorization-extension/v2/implementation/installation.md @@ -0,0 +1,109 @@ +--- +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 + +Applications without an assigned type or Machine to Machine Applications cannot be used with this extension. + +## Install the Extension + +To install the Authorization Extension, click on the **Auth0 Authorization** box located on the [Extensions](${manage_url}/#/extensions) page of the dashboard. + +You will be prompted to install the extension and to choose where you would like to store your data. You can choose between Webtask Storage and an Amazon S3 bucket. + +### Webtask Storage + +The extension will use Webtask Storage by default, and you are limited to 500 KB of data. This is equivalent to: + + - 1000 groups and 3000 users, where each user is member of 3 groups + - 20 groups and 7000 users, where each user is member of 3 groups + +### Amazon S3 + +Alternatively, you can use Amazon S3 as a storage provider. + +::: warning +This extension has limitations in terms of performance and is not meant to be used with large data sets. Before you choose Amazon S3 for data storage, we recommend that you test and see how it performs for your case. Performance degradation is also a possibility as more data is added to S3. +::: + + To use Amazon S3 you need to: + + 1. Create an S3 bucket + 2. Create an IAM user and get the Key ID and Key for that user + 3. Create a policy for the IAM user which allows the user to make changes to the bucket + +```json +{ + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Action": [ + "s3:DeleteObject", + "s3:GetObject", + "s3:ListBucket", + "s3:PutObject" + ], + "Resource": [ + "arn:aws:s3:::NAME-OF-YOUR-BUCKET/*" + ] + }, + { + "Effect": "Allow", + "Action": [ + "s3:ListBucket" + ], + "Resource": [ + "arn:aws:s3:::NAME-OF-YOUR-BUCKET" + ], + "Condition": {} + } + ] +} +``` + +::: 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. +::: + +![Install Authorization Extension](/media/articles/extensions/authorization/app-install-v2.png) + +Once the extension is installed, you will see it listed under **Installed Extensions**. + +![Installed Extensions](/media/articles/extensions/authorization/installed-extensions-v2.png) + +::: warning +Installing this extension creates an `auth0-authz` application for your account. **Do not delete this application!** If you uninstall the extension at a later date, this application will be deleted automatically. +::: + +When you click the link to open the extension for the first time, you will be asked to provide permission for the extension to access your Auth0 account. If you do, you will be redirected to the Authorization Dashboard. + +![Authorization Dashboard](/media/articles/extensions/authorization/auth-dashboard-v2.png) + +## Keep Reading + +::: next-steps +* [Configure the Authorization Extension](/extensions/authorization-extension/v2/implementation/configuration) +* [Set Up the Authorization Extension](/extensions/authorization-extension/v2/implementation/setup) +::: diff --git a/articles/extensions/authorization-extension/v2/implementation/setup.md b/articles/extensions/authorization-extension/v2/implementation/setup.md new file mode 100644 index 0000000000..513be6bc06 --- /dev/null +++ b/articles/extensions/authorization-extension/v2/implementation/setup.md @@ -0,0 +1,159 @@ +--- +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 + +::: 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. + +If you have a large number of users, managing the access rights and permissions each one individually can become unwieldy. The **groups** functionality helps make this process easier. For example, you might have your groups reflect the various departments of your organization: accounting, information technology, engineering, support, and so on. You might also create nested groups, such as dividing the engineering group into two nested groups: internal tools and client-facing applications. Your organization hierarchy therefore looks like this: + +* Corporation + * Accounting + * Information Technology + * Engineering + * Internal Tools + * Client-Facing Applications + * Support + +![Diagram of sample corporation used in the example](/media/articles/extensions/authorization/corporation.png) + +You can add users to your groups manually or dynamically based on the Connection(s) they're using to access your app. For example, if someone logs in using the Active Directory Connection and their AD profile indicates that they're in the Marketing group, the Authorization Extension can also add them to the Marketing group you're managing with the extension. + +Finally, we have permissions and roles, which are groups of permissions. The purpose of the latter is to make it easier to assign several permissions simultaneously to either a user or a group. + +![Diagram showing permissions added to a user](/media/articles/extensions/authorization/roles-permissions.png) + +For example, let's say that you want to grant permissions to: + +* Approve requests for travel +* Approve travel expenses + +Rather than assigning both permissions to groups/users, you can roll the two (along with many others) into a role called **Travel Administrator**. You can then assign Travel Administrator to individual users or to one or more groups. + +![Diagram showing permissions added to a user or group](/media/articles/extensions/authorization/groups-roles-permissions.png) + +## Users + +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) + +## Groups + +To create and manage the groups with which you'll manage users' settings, click **Groups** in the Authorization Dashboard. + +Click **Create Group** to create a new group for your users. You'll be asked to provide a **name** for the group, as well as a **description** for that group. + +![Create a New Group](/media/articles/extensions/authorization/create-group-v2.png) + +You can manage your users and their group affiliations in one of two ways: + +* Opening the **group** and managing the group's users + + ![Open a Group](/media/articles/extensions/authorization/group-membership-v2.png) + +* Opening the **user** and managing the user's group membership(s) + + ![Open a User](/media/articles/extensions/authorization/user-membership-v2.png) + +The groups you'll 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. Additionally, you may create nested groups that are similar to the following: + +* Example Company + * Accounting + * External Accountants + * Human Resources + * Finance + * Finance IT Support + * Management + +To create nested groups, you must first create all of the individual groups via the **CREATE** button on the Groups page of the Authorization Dashboard. + +![Add Nested Groups](/media/articles/extensions/authorization/add-nested-groups-v2.png) + +To nest the groups: + +1. Open up the top-level Group (in the example above, this would be the Example Company Group) +2. Click on the **Nested Groups** tab +3. Click on the **ADD NESTED GROUP** button. You will be presented with a list of Groups that can be added to the primary Group. To select a particular Group, click on the check box to the left of the name. After each selection, you will be returned to the primary group page. Continue this process until you have included all the Groups you need. + +With nested groups, adding a user to a sub-group also grants the user permissions granted to the groups that are parents (and grandparents) of that group. For example, adding a user to the External Accountants group automatically makes them a member of the Finance and Company Groups. However, that the user is only explicitly a member of External Accountants; all other memberships are purely dynamic and are calculated as needed (for example, when loading the user's group memberships). + +![View Nested Groups](/media/articles/extensions/authorization/nested-groups-v2.png) + +To prevent confusion, you will be shown both the explicit members AND the "calculated members" that result from nested groups whenever you open a specific group's page in the Authorization Dashboard. + +### 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 IdP, you can dynamically make the user a member of the group in which you've created the appropriate mapping. + +For example, suppose your users are logging in using their Active Directory (AD) credentials. As part of their identity, AD allows users to have group information associated (such as "Administrative" and "Marketing"). + +You can then configure group mappings to look at a user's profile if they're connecting with the Active Directory connection. When the extension sees that the person is a part of the "Administrative" group, it will automatically make the user a member of your company's Admin group. + +![Group Mappings](/media/articles/extensions/authorization/group-mapping-v2.png) + +## Roles + +The roles that you will create will depend on the access to certain permissions in your application. 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](#permissions) and then assigned to a certain Role. + +You can create different types of Roles such as: Expense Admins, Expense Manager, and Expense User for your Expense Management Tool. + +![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 existing Role. + +![Add a New Role](/media/articles/extensions/authorization/add-role.png) + +Once you have a **Role** created, you can add it to a user so they can then have the associated **Permissions**. To add a role to a user, find the user in the **Users** section, then click the **Roles** tab. Then click **ADD ROLE TO USER** to choose which roles you wish to assign to a user, then click **SAVE**. + +![Add Role to User](/media/articles/extensions/authorization/add-role-to-user.png) + +## Permissions + +Permissions are the actions or functions that can be added to Roles. + +Using the previous example of an Expense application, let's look at possible roles and how they can be associated with certain permissions: + +- Role: Expense User + - Permissions: + - View their own expenses + - Add a new expense + +- Role: Expense Admin + - Permissions: + - Approve expenses + - View all user expenses + - Delete expenses + - Add a new expense + +To create a new permission, go to the **Permissions** section of the Authorization Extension dashboard. + +![Permissions](/media/articles/extensions/authorization/permissions.png) + +Then click the **CREATE PERMISSION** button. Then enter the name of the permission, the description and select the application for which this permission applies. + +![Create Permission](/media/articles/extensions/authorization/create-permission.png) + +Once you have your permissions created, you can associate them with [Roles](#roles). + +## Keep Reading + +::: next-steps +* [Configure the Authorization Extension](/extensions/authorization-extension/v2/implementation/configuration) +::: \ No newline at end of file diff --git a/articles/extensions/authorization-extension/v2/import-export-data.md b/articles/extensions/authorization-extension/v2/import-export-data.md new file mode 100644 index 0000000000..2486b60091 --- /dev/null +++ b/articles/extensions/authorization-extension/v2/import-export-data.md @@ -0,0 +1,109 @@ +--- +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. +::: + +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**. + +![Click Configuration](/media/articles/extensions/authorization/click-configuration.png) + +Click **Import/Export**. + +![Import/Export Section](/media/articles/extensions/authorization/import-export.png) + +Use this form to copy and paste or edit the JSON data. Then, click either the **IMPORT** or **EXPORT** button to begin the import/export process. + +A sample JSON file looks like this: + +```json +{ + "configuration": [ + { + "_id": "v1", + "rolesInToken": true + } + ], + "groups": [ + { + "name": "Admin", + "description": "Administrators of the company", + "_id": "f185e4aa-0c28-4da7-8639-ae998512c838" + }, + { + "_id": "5f5371c6-c8ff-4c7c-825e-c5ef8ac51cad", + "name": "HR", + "description": "Human Resources", + "members": [ + "auth0|59c13f5ed6e34e41877c0810" + ], + "roles": [ + "6ab494d6-2592-4af0-a62f-2c13646143d0" + ], + "nested": [ + "59f2adac-9016-4051-ad02-dd5196b8f99e" + ] + }, + { + "name": "Trainers", + "description": "HR Trainers for New Employees", + "_id": "59f2adac-9016-4051-ad02-dd5196b8f99e" + } + ], + "permissions": [ + { + "applicationType": "client", + "applicationId": "fhginJh46igC6Rj630UeZBhUyDrgvJ08", + "description": "approve company expenditures", + "name": "Approve Expenses", + "_id": "e61f10f4-837e-4011-a52f-53618bd659e7" + }, + { + "applicationType": "client", + "applicationId": "fhginJh46igC6Rj630UeZBhUyDrgvJ08", + "description": "approve hiring of employees", + "name": "Hire employees", + "_id": "03b94d9b-8893-413d-bdb3-451192264594" + } + ], + "roles": [ + { + "applicationType": "client", + "applicationId": "fhginJh46igC6Rj630UeZBhUyDrgvJ08", + "description": "Control over HR-related tasks", + "name": "HR Manager", + "permissions": [ + "e61f10f4-837e-4011-a52f-53618bd659e7", + "03b94d9b-8893-413d-bdb3-451192264594" + ], + "_id": "6ab494d6-2592-4af0-a62f-2c13646143d0" + } + ] +} +``` + +## Keep Reading + +::: next-steps +* [Enable API Access to the Extension](/extensions/authorization-extension/v2/api-access) +* [Use the Authorization Extension's Data in Rules](/extensions/authorization-extension/v2/rules) +* [Troubleshoot Errors](/extensions/authorization-extension/v2/troubleshooting) +::: \ No newline at end of file diff --git a/articles/extensions/authorization-extension/v2/index.md b/articles/extensions/authorization-extension/v2/index.md new file mode 100644 index 0000000000..90af84435f --- /dev/null +++ b/articles/extensions/authorization-extension/v2/index.md @@ -0,0 +1,120 @@ +--- +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 + +::: 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). + +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 + +Before you can use the extension, you'll need to install it, configure the rule controlling its behavior during login, and set up your user management. + + + +## Data Management + +You can easily move data into or out of the Extension. + + + +## Add Functionality + +Once your extension is up and running, you can add additional functionality to it. You can also import/export user-related data. + + + +## Troubleshoot + +Review our tips for troubleshooting commonly-seen issues. + + diff --git a/articles/extensions/authorization-extension/v2/migration.md b/articles/extensions/authorization-extension/v2/migration.md new file mode 100644 index 0000000000..fb2d873770 --- /dev/null +++ b/articles/extensions/authorization-extension/v2/migration.md @@ -0,0 +1,29 @@ +--- +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 +::: + +One of the major changes between versions 1 and 2 of the Authorization Extension is the removal of the **Applications** section. This section was removed to simplify its inherent complexity, such as when it was used to define a policy for access control. The desired approach for such use cases is to use [rules](/extensions/authorization-extension/v2/rules#controlling-application-access). + +## Upgrade the Extension Version + +To upgrade the Authorization Extension, go to [Extensions](${manage_url}/#/extensions) section of the dashboard and click **Installed Extensions**. + +On the Authorization Extension row, you'll see a link that will begin the upgrade process to the latest version. \ No newline at end of file diff --git a/articles/extensions/authorization-extension/v2/rules.md b/articles/extensions/authorization-extension/v2/rules.md new file mode 100644 index 0000000000..5a9fc25412 --- /dev/null +++ b/articles/extensions/authorization-extension/v2/rules.md @@ -0,0 +1,115 @@ +--- +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](/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) + +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. 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. +::: + +```js +function (user, context, callback) { + var namespace = 'http://yourdomain/claims/'; // You can set your own namespace, but do not use an Auth0 domain + + // Add the namespaced tokens. Remove any which is not necessary for your scenario + context.idToken[namespace + "permissions"] = user.permissions; + context.idToken[namespace + "groups"] = user.groups; + context.idToken[namespace + "roles"] = user.roles; + + callback(null, user, context); +} +``` + +This rule must run **after** the Authorization Extension rule. To make sure this happens, make sure that you place it below the Authorization Extension rule. + +::: note +When calling the `/authorize` endpoint or configuring Lock, you'll need to specify the information you want in the `scope` by indicating `groups`, `permissions` and/or `roles`. +::: + +## Control App Access + +You can also write rules that are executed after the Authorization Extension rule to do things like control access to your application. One method of doing this is to specify the roles that are required for each application using the [application metadata](/rules/metadata-in-rules#reading-metadata). + +### Step 1: Set the Application Metadata's `required_roles` + +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). + +This brings you to the application's **Settings**. Scroll down and click **Show Advanced Settings** at the bottom of the page. + +![Click Advanced Settings Link](/media/articles/extensions/authorization/adv-settings-link.png) + +2. Under **Application Metadata** add an item setting the **Key** to `required_roles` and in **Value** field list your roles in comma separated style. Click the **CREATE** button to add the field. + +![Example of required roles](/media/articles/extensions/authorization/required-roles.png) + +3. When finished click **Save Changes**. Now when you login from this application, in `context.clientMetadata` you will have the `required_roles` with the roles value string you entered. + +### Step 2: Create the Rule Enforcing Application Roles + +Now that each Application has a role associated with it, you can create the rule executes with this piece of application information in context. + +::: warning +Before creating this rule, enable **Roles** under the [Token Contents](/extensions/authorization-extension/v2/configuration#token-contents) and [publish the Authorization Extension rule](/extensions/authorization-extension/v2/configuration#publish-the-authorization-extension-rule). Then, add this rule and make sure it is listed *after* the generated "auth0-authorization-extension" rule. +::: + +After setting `required_roles`, create a new [rule](${manage_url}/#/rules) with the following body: + +```js +function (user, context, callback) { + context.clientMetadata = context.clientMetadata || {}; + if (context.clientMetadata.required_roles && context.clientMetadata.required_roles.length){ + if (user.roles) { + var _ = require('lodash'); + var roles = context.clientMetadata.required_roles.split(','); + var matchingRoles =_.filter(user.roles, function(roleName) { + return _.includes(roles, roleName); + }); + + if (matchingRoles && matchingRoles.length) { + return callback(null, user, context); + } + } + + return callback(new UnauthorizedError('You do not have the required role to access ' + context.clientName)); + } + + callback(null, user, context); +} +``` + +## Keep Reading + +::: next-steps +* [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) +::: diff --git a/articles/extensions/authorization-extension/v2/troubleshooting.md b/articles/extensions/authorization-extension/v2/troubleshooting.md new file mode 100644 index 0000000000..2d54316712 --- /dev/null +++ b/articles/extensions/authorization-extension/v2/troubleshooting.md @@ -0,0 +1,32 @@ +--- +title: Troubleshoot the Authorization Extension +description: Learn how to troubleshoot the Authorization Extension, +topics: + - extensions + - authorization_v2 +contentType: + - how-to +useCase: extensibility-extensions +--- + +# 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. + +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. + +## 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 9fe518d428..c597432fed 100644 --- a/articles/extensions/bitbucket-deploy.md +++ b/articles/extensions/bitbucket-deploy.md @@ -1,10 +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 @@ -14,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**. @@ -36,13 +49,24 @@ Copy and paste this value into the **Add Webhook** page for your Bitbucket Repos ![](/media/articles/extensions/bitbucket-deploy/webhook-setup.png) -**NOTE**: You can find details on how to configure a webhook at [Creating Webhooks](https://confluence.atlassian.com/bitbucket/manage-webhooks-735643732.html#Managewebhooks-create_webhookCreatingwebhooks) on Bitbucket. +::: note +You can find details on how to configure a webhook at [Creating Webhooks](https://confluence.atlassian.com/bitbucket/manage-webhooks-735643732.html#Managewebhooks-create_webhookCreatingwebhooks) on Bitbucket. +::: ## Deployment 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. @@ -67,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 { @@ -90,19 +147,19 @@ 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`. -**NOTE**: 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) +::: note +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 control the Rule order, status (`enabled`/`disabled`) and stage (for now, only `login_success` is available) 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`. +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__ ```javascript @@ -115,7 +172,7 @@ function (user, context, callback) { ``` __set-country.json__ -```javascript +```json { "enabled": false, "order": 15, @@ -127,15 +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` -#### Set the Stage +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: -After you deploy a Rule, you cannot change its stage, or the area where the Rule executes. +```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 -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. +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 + } + ... +} +``` -Please note that you may have only a single Rule for the `user_registration` and `login_failure` stages. +![](/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-extensions.md b/articles/extensions/custom-extensions.md deleted file mode 100644 index f022f64f8d..0000000000 --- a/articles/extensions/custom-extensions.md +++ /dev/null @@ -1,132 +0,0 @@ ---- -description: How to create and install a custom extension. ---- - -# Creating and Installing a Custom Extension - -Rather than using one of Auth0's provided extensions, you may choose to create your own. - -## Creating a Custom Extension -To begin creating your custom extension, please feel free to fork/clone any one of Auth0's extension repositories: - -- [Auth0 Extension Boilerplate](https://github.com/auth0/auth0-extension-boilerplate) -- [Auth0 Extension with API Boilerplate](https://github.com/auth0/auth0-extension-boilerplate-with-api) -- [Auth0 Extension with React Boilerplate](https://github.com/auth0/auth0-extension-boilerplate-with-react) -- [Auth0 Extension with Hooks](https://github.com/auth0/auth0-extension-boilerplate-hooks) - -Alternatively, you may follow the _Development Instructions_ provided via the _New Extension_ window that appears when you click on the _+ CREATE EXTENSION_ button. To view the _Development Instructions_, navigate to the [Extensions](${manage_url}/#/extensions) page of the [Management Portal](${manage_url}). Click on the _+ CREATE EXTENSION_ button. On the popup displayed click on the _Check out this command line tool_ link. The _Development Instructions_ popup is displayed. These instructions allow you to create your own extension using the command line. - -Extensions can also be installed using `wt-cli`. The command would look like the following: - -``` -wt create {file} --name {extensionName} --param owner=“{tenant}” --param version="1.0.0" -``` - -Once the extension is installed you can make updates using the following: - -``` -wt update {extensionName} {file} -p {tenant} -``` - -Learn more about `wt-cli` by visiting the [documentation](https://webtask.io/docs/wt-cli) and the [github repository](https://github.com/auth0/wt-cli). - -## Installing a Custom Extension -Once you have created your own extension, you may install it manually via the [Extensions](${manage_url}/#/extensions) page of the [Auth0 Management Portal](${manage_url}). - -Near the top right-hand side of the window, click the _+ CREATE EXTENSION_ button. - -![](/media/articles/extensions/custom/create-extension.png) - -In the _New Extension_ window that pops open, provide the GitHub URL to the repository that contains the files required by your extension. - -![](/media/articles/extensions/custom/new-extension.png) - -> At this time, only repositories hosted by GitHub may be used. - -Alternatively, you may host your files elsewhere and simply provide a link to the `webtask.json` file in the box (e.g. `http://example.com/webtask.json`). - -Once you have provided the link to your files and clicked _Continue_, you will be prompted to install the extension. If you would like to proceed, click _Install_. - -![](/media/articles/extensions/custom/install-custom-ext.png) - -Under the _Installed Extensions_ tab you will find your newly-installed extension listed. - -![](/media/articles/extensions/custom/installed-extensions.png) - -## Extension Lifecycle - -Let's have a look at what happens behind the scenes when installing and uninstalling custom extensions. - -When the user clicks on _Install_, a _Client_ and a _ClientGrant_ are created for the extension with the scopes defined on the `webtask.json`. Also, access is granted to Management APIv2 Resource Server. - -For this `webtask.json`: - -```json -{ - "name": "my-extension"; - "auth0": { - "createClient": true, - "scopes": "create:rules" - } -} -``` - -The following _Client_ and a _ClientGrant_ would be created: - -```javascript -Clients.create({ - name: 'my-extension' -}).then(function (client) { - return Grants.create({ - audience: 'https://jcenturion.auth0.com/api/v2/', - client_id: client.client_id, - scope: "create:rules" - }).then(function () { - return addSecrets(wt, client, wtUrl); - }); -}); -``` - -**NOTE**: If you are creating a Cron, then you can omit the `"createClient": true` from the `webtask.json` file. A Client is always created by default for Cron extensions. - -The installation dialog will warn the user that the extension will have access to certain scopes. In this case: `create:rules`. - -![](/media/articles/extensions/custom/scopes-warning.png) - -The webtask will be created with the `AUTH0_CLIENT_ID` and `AUTH0_CLIENT_SECRET` information set as secrets. - -After the webtask is created, `/.extensions/on-install` (`POST /onInstallUrl`) is called sending a [JWT](/jwt) for validating that Auth0-manage is the one calling it. - -> The expected success status is `204`. Keep in mind that if the hooks fail, then the install (or uninstall) will fail as well. - -Install and uninstall URLs are configurable through `webtask.json`. - -```json -{ - "name": "my-extension"; - "auth0": { - "scopes": "create:rules", - "onInstallUrl": "/my-own-on-install" - } -} -``` - -> _onInstallPath_ and _onUninstallPath_ are mandatory if you want auth0-dashboard to call them. - -In order to edit an extension `/.extensions/on-update` (`PUT /onUpdateUrl`) is called, with a JWT for validating that Auth0-manage is the one calling it. Once the validation is successful the webtask and the client associated to the webtask are updated with the changes. Again, the expected success status is `204`. - -When the user clicks on _Uninstall_, `/.extensions/on-uninstall` (`DELETE /onUninstallUrl`) is called, with a JWT for validating that Auth0-manage is the one calling it. Afterwards, the webtask and the client associated to the webtask are removed. - -The JWT, used for authenticating the calls to the hooks for both `/.extensions/on-install` and `/.extensions/on-uninstall`, looks like the following: - -```json -{ - aud: {extensionUrl + hookPath}, - iss: {auth0Domain}, - iat: timespan -} -``` - -The extension should validate the JWT. See [this](https://github.com/auth0/auth0-extension-boilerplate-hooks/blob/master/hooks/index.js#L11) for the validation applied. - - diff --git a/articles/extensions/custom-social-extensions.md b/articles/extensions/custom-social-extensions.md index 43c0997fa2..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" + // ... } ``` @@ -56,20 +59,20 @@ After you have provided values for the required fields, click **Save**. #### New Connection: Apps -Once you have successfully configured the connection, you will be presented with a list of apps associated with your Auth0 account under the **Apps** tab of the **New Connection** window. +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,6 +102,10 @@ If the identity provider requires Basic Authentication, you can be use the __Cus ``` { - "Authorization" : "Basic MTIzNDU2OmFiY2RlZg==" + "Authorization" : "Basic MTIzNDU2OmFiY2RlZg==" } -``` \ No newline at end of file +``` + +## Additional Steps + +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.md b/articles/extensions/delegated-admin.md deleted file mode 100644 index e594820c17..0000000000 --- a/articles/extensions/delegated-admin.md +++ /dev/null @@ -1,515 +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. -toc: true ---- - -# Delegated Administration - v2 - -The **Delegated Administration** extension allows you to expose the [Users Dashboard](${manage_url}/#/users) to a group of users, without having to provide access to them to the [dashboard](${manage_url}/#/). Instead the [Users Dashboard](${manage_url}/#/users) is exposed as an Auth0 client. Let's see how this is done. - -**NOTE**: This extension is currently available only for the public cloud. It is not yet supported in the [appliance](/appliance). - -## Create a Client - -Let's start with creating a new client application. Navigate to [Clients](${manage_url}/#/clients) and click on the **+Create Client** button. Set a name (we will name ours *Users Dashboard*) and choose *Single Page Web Applications* as client type. Click on **Create**. - -![Create a Client](/media/articles/extensions/delegated-admin/create-client.png) - -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` | - -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*. - -![Change JsonWebToken Signature Algorithm](/media/articles/extensions/delegated-admin/set-rs256.png) - -Save your changes. - -### Enable Connections on the Client - -When you create a new client, by default all the connections are enabled. This is something you want to change in this case, for security reasons. The approach we follow in this tutorial is to disable all connections, create a new Database Connection and enable only this one for our new client application. But you could do the same with another type of connection, like AD, ADFS, and so forth. - -Navigate to the *Connections* tab and disable all the connections using the switch. - -Following that, navigate to [Database Connections](${manage_url}/#/connections/database) and click on **+Create DB Connection**. Set a name for your connection, we will name ours *Helpdesk*. - -![Create DB Connection](/media/articles/extensions/delegated-admin/create-connection.png) - -Navigate to the *Settings* tab of the new connection and enable the **Disable Sign Ups** option. This way we avoid another security concern: if some malicious user gets hold of the link, signing up will not be possible. - -![Disable Sign Ups](/media/articles/extensions/delegated-admin/disable-signup.png) - -Enable this new connection for your client (*Users Dashboard* in our case) and add at least one user. - -### Assign the right Roles to your Users - -Access to the extension requires your users to have the right roles: - - - `Delegated Admin - User`: These users can search for users, create users, open users and execute actions on these users (like Delete, Block, and so forth). - - `Delegated Admin - Administrator`: These users can additional see all logs in an account and configure Hooks. - -Only users that have these roles defined in `user.roles`, `user.app_metadata.roles` or `user.app_metadata.authorization.roles` will be able to use the extension. You could manually set these roles in your users or use a rule in order to do this. The following rule shows how users from the `IT Department` are given the `Delegated Admin - Administrator` role while `Department Managers` are given 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 - -We are now ready to setup our new extension. Before we do so head back to your new Client and copy the **Client ID** value. - -To install and configure this extension, click on the **Delegated Administration** box in the list of provided extensions on the [Extensions](${manage_url}/#/extensions) page of the dashboard. 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 Client you will use. -- **TITLE**: Optionally, you can set a title for your Client. It will be displayed at the header of the page. -- **CUSTOM_CSS**: Optionally, you can set a css file, to customize the look and feel of your Client. - -Once you have provided this information, click **Install**. Your extension is now ready to use! - -If you navigate back to the [Clients](${manage_url}/#/clients) view, you will see that there is an additional client created. - -![](/media/articles/extensions/delegated-admin/two-clients.png) - -The `auth0-delegated-admin` client is created automatically when you install the extension. It's a client authorized to access the [Management API](/api/management/v2) and you shouldn't modify it. - -## Use the Extension - -To access your newly created dashboard, navigate to *[Extensions](${manage_url}/#/extensions) > Installed Extensions* and click on the **Delegated Administration Dashboard**. A new tab will open and display the login prompt. - -![](/media/articles/extensions/delegated-admin/login-prompt.png) - -Notice that there is no Sign Up option. That's because we disabled it earlier. - -Once you provide valid credentials you are navigated to the *Delegated Administration Dashboard*. - -![](/media/articles/extensions/delegated-admin/standard-dashboard.png) - -### Configure Hooks - -Users with the `Delegated Admin - Administrator` role will see a *Configure* option in the top-right dropdown. On the Configuration page you can manage the different hooks and queries in the dashboard, which allows you to customize the behavior of the dashboard. - -![](/media/articles/extensions/delegated-admin/dashboard-configuration.png) - -#### 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. - -**Logging** - -In order to log a message to the Webtask logs (which you can view using the Realtime Webtask Logs extension) you can call the `log` method: - -```js -ctx.log('Hello there', someValue, otherValue); -``` - -**Caching** - -If at some point you need to cache something (like a long list of departments), you can store this list 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 also store custom data within the extension. This is currently limited to around 400kb. - -```js -var data = { - departments: [ 'IT', 'HR', 'Finance' ] -}; - -ctx.write(data) - .then(function() { - ... - }) - .catch(function(err) { - ... - }); -``` - -And then to read the data: - -```js -ctx.read() - .then(function(data) { - ... - }) - .catch(function(err) { - ... - }); -``` - -**Payload and Request** - -Every hook exposes the current payload and/or request with specific information. The request will always contain the user that is logged in to the dashboard: - -```js -var currentUser = ctx.request.user; -``` - -**Remote Calls** - -At some point you might want to call an external service to validate data, to load memberships from a remote location (an API), ... This is possible 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); - } - - ... - }); -} -``` - -#### Filter Hook - -By default, users with the `Delegated Admin - User` role will see all users in an Auth0 account. This could be fine if the dashboard is used by your Helpdesk department. But if you want to delegate administration to your departments (Finance, HR, IT, and so forth) or to your customers, your vendors, or your offices you'll want to filter the data users can see. With the **Filter Hook** you can decide how the list of users is filtered. - -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) which should be 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. So we'll filter the users based on 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 Quotes may lead to errors -Do not use single or double quotes, or any other special characters such as `+` or `-` in your department or group name, on which you'll want to filter. This might cause issues with the Lucene query, resulting in unexpected behavior. -::: - -If this hook is not configured, **all users** will be returned. - -#### 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, unblock, etc a specific user. - -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 the same department she's in. - -```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] - } - }); -} -``` - -**NOTE**: Creating users is only supported in Database Connections - -#### Memberships Query - -When creating a new user the UI will show a picklist where you can choose the memberships you want to assign to a user. These memberships are defined using the **Memberships Query**. - -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 see their own department. - -```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 ]); -} -``` - -**NOTE**: This query is only used in the UI. If assigning users to specific departments needs to be enforced, this will happen in the Create Hook. If only 1 membership is returned, the membership field in the UI will not be displayed. - -You can also allow the end user to enter any value they wish for the 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 ] - }); -} -``` - -#### Settings Query - -The **Settings Query** allows you to customize the look and feel of the extension. - -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' - }); -} -``` - -### Manage Users - -There are two available views, *Users* and *Logs*. At the *Users* view you can see the users displayed and perform certain actions on them. - -Keep in mind that by default all users are displayed, but you can constrain that by configuring a [filter hook](#filter-hook). - -In the table below you can see all the options you can perform on a user, which ones are available via the [dashboard](${manage_url}/#/) and which via the extension. Once more, keep in mind that this is the superset of the actions a user can perform using the extension. It can always be constrained by configuring an [access hook](#access-hook). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
        Action Available via Dashboard Available via Extension
        Create userYesYes
        Contact userYesNo
        Sign in as 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. - -At the *Logs* view you can see log data 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), which also displays data for the actions taken in the dashboard by the administrators. - -### Create Users - -You can create a new user by selecting the **+ Create User** button at the *Users* view. The information you need to specify are email and password. Depending on your role you may or may not be able to set the *Department* that the new user belongs to. - -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 will create will be automatically assigned to the Finance department. - -![](/media/articles/extensions/delegated-admin/create-user-kelly.png) - -## Customize the dashboard - -You can use the **Title** and **Custom_CSS** variables to customize the look and feel of your dashboard. - -Navigate to the [Extensions](${manage_url}/#/extensions) page and go to the settings of the **Delegated Administration** extension. We are going to set a custom title and a custom css file: - -- Set the **TITLE** to `Finance User Management`. -- Set the **CUSTOM_CSS** to `https://rawgit.com/auth0-extensions/auth0-delegated-administration-extension/master/docs/theme/fabrikam.css`. - -Save your changes, navigate to the extension and login. The dashboard now looks like that: - -![](/media/articles/extensions/delegated-admin/custom-dashboard.png) 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/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 c76638ca7b..b12669f988 100644 --- a/articles/extensions/github-deploy.md +++ b/articles/extensions/github-deploy.md @@ -1,10 +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 @@ -14,10 +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. -- **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**. @@ -37,23 +56,34 @@ Copy these values into the **Add Webhook** page for your GitHub repository: ![Add Webhook](/media/articles/extensions/github-deploy/add-webhook.png) -**NOTE**: You can find details on how to configure a webhook at [Creating Webhooks](https://developer.github.com/webhooks/creating/) on GitHub. +::: note +You can find details on how to configure a webhook at [Creating Webhooks](https://developer.github.com/webhooks/creating/) on GitHub. +::: ## 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 WARNING: Deleting Rules and Scripts from GitHub +::: 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: @@ -70,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 { @@ -93,19 +156,19 @@ 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`. -__NOTE__: 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) +::: note +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 control the rule order, status (`enabled`/`disabled`) and stage (`login_success`, `login_failure`, `user_registration`) 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`. +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__ ```javascript @@ -118,7 +181,7 @@ function (user, context, callback) { ``` __set-country.json__ -```javascript +```json { "enabled": false, "order": 15, @@ -132,9 +195,156 @@ 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`. -#### Set the stage +### 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 + } + ... +} +``` -After you deploy a rule, you cannot change its stage. You would have to create a new rule with a new name and updated stage, and then delete the original rule. For the `user_registration` and `login_failure` stages, only a single rule is allowed. +![](/media/articles/extensions/deploy-extensions/mappings.png) ## Track deployments diff --git a/articles/extensions/gitlab-deploy.md b/articles/extensions/gitlab-deploy.md index f283e15fd9..48909fdc18 100644 --- a/articles/extensions/gitlab-deploy.md +++ b/articles/extensions/gitlab-deploy.md @@ -1,61 +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_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. +::: + +3. Once you have provided this information, click **Install**. -### Configure a GitLab Token +### Configure a GitLab token -Log in to your [GitLab](https://about.gitlab.com/) account and navigate to [Profile Settings > Access Tokens](https://gitlab.auth0.com/profile/personal_access_tokens). +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). -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. +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) +![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. @@ -64,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 one of these folders: +- `clients` +- `grants` +- `emails` +- `resource-servers` +- `connections` +- `database-connections` +- `rules-configs` +- `rules` +- `pages` -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. - -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` @@ -100,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` @@ -108,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 { @@ -123,19 +181,19 @@ To enable the page the `error_page.json` would contain the following: } ``` -### 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. +<%= include('./_includes/_use-default-error') %> -For example, if you create the file `rules/set-country.js`, the extension will create a Rule in Auth0 with the name `set-country`. +### Deploy rules -**NOTE**: 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. +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. -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. +For example, if you create the file `rules/set-country.js`, the extension will create a Rule in Auth0 with the name `set-country`. -![Mark rules as manual](/media/articles/extensions/gitlab-deploy/manual-rule.png) +::: note +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 also control the Rule order, status (`enabled`/`disabled`) and stage (for now, only `login_success` is available) 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`. +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__ ```javascript @@ -148,7 +206,7 @@ function (user, context, callback) { ``` __set-country.json__ -```javascript +```json { "enabled": false, "order": 15, @@ -158,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 544b55c105..fdfa06a1bd 100644 --- a/articles/extensions/index.md +++ b/articles/extensions/index.md @@ -1,80 +1,79 @@ --- -url: /extensions -title: Auth0 Extensions -description: Auth0 Extensions enable you to install applications or run commands/scripts that extend the functionality of the Auth0 base product. +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`. -When creating extensions, you have two options: -- [building off of one of Auth0's provided extensions](#using-an-auth0-provided-extension) in the Management Portal; -- [creating and installing your own](#creating-your-own-extension). +## Pre-defined extensions -## Using an Auth0-Provided Extension +Auth0 provides a selection of pre-defined extensions, which you can install via the [Dashboard](${manage_url}/extensions). -Auth0 provides the following pre-defined extensions, and they are available for installation via the Management Portal. They have not, however, been fully installed. To use one or more of the following apps, you must provide the required configuration information and finish installing the extensions. +### Authorization -![](/media/articles/extensions/auth0-provided-extensions.png) +- [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). -## What types of actions can I do with extensions? +- [Delegated Administration](/extensions/delegated-admin): Allow a select group of people to manage users without providing access to any other area of the Dashboard. -### Manage the authorizations for Users using Groups, Roles and Permissions -- [Auth0 Authorization Extension](/extensions/authorization-extension) +### Connections -### Easily manage custom social connections -- [Custom Social Connections Extension](/extensions/custom-social-extensions) +- [Custom Social Connections Extension](/extensions/custom-social-extensions): Configure and manage custom social identity providers. -### 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) +- [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. -### Test various endpoints of the Auth0 Authentication API -- [Authentication API Debugger Extension](/extensions/authentication-api-debugger) +### Manage users -### Monitor your AD/LDAP connectors -- [Auth0 AD/LDAP Connector Health Monitor](/extensions/adldap-connector) +- [Users Import / Export](/extensions/user-import-export): Bulk import and export database users. -### Import or Export exisiting users -- [Users Import / Export](/extensions/user-import-export) +### Extend and integrate -### Export Auth0 logs to an external service -- [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) +Use your own custom webhooks in conjunction with Auth0 APIs: + +- [Auth0 Management API Webhooks](/extensions/management-api-webhooks) +- [Auth0 Authentication API Webhooks](/extensions/authentication-api-webhooks) -### Access to real-time webtask logs -- [Real-time Webtask Logs](/extensions/realtime-webtask-logs) +### Deployment and source control -### Expose the Users dashboard to a group of users without allowing them access to the dashboard -- [Delegated Administration](/extensions/delegated-admin) +Keep history and deploy [rules](/rules), [database connection](/connections/database) scripts and other assets from external repositories: -### Deploy 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) +- [Deploy CLI Tool Extension](/extensions/deploy-cli) + +### Troubleshoot + +Test Auth0 API endpoints: + +- [Authentication API Debugger Extension](/extensions/authentication-api-debugger) + +### Monitor -### Create a SSO dashboard with multiple enterprise applications -- [SSO Dashboard Extension](extensions/sso-dashboard) +- [Auth0 AD/LDAP Connector Health Monitor](/extensions/adldap-connector): Monitor your [AD/LDAP Connectors](/connector/overview). -## Creating Your Own Extension +- [Real-time Webtask Logs](/extensions/realtime-webtask-logs): Access real-time Webtask logs. -If you would like to [create your own extension](/extensions/custom-extensions), Auth0 provides the following sample code to help you get started: +### Logs export -- [Auth0 Extension Boilerplate](https://github.com/auth0/auth0-extension-boilerplate) -- [Auth0 Extension with API Boilerplate](https://github.com/auth0/auth0-extension-boilerplate-with-api) -- [Auth0 Extension with React Boilerplate](https://github.com/auth0/auth0-extension-boilerplate-with-react) +Export Auth0 logs to external services: -Alternatively, you may follow the Development Instructions provided via the "New Extension" window that appears when you click on the "+ Extension" button. This allows you to create your own extension using the command line. +- [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) -For instructions on how to install your custom extension, please see [Installing a Custom Extension](/extensions/custom-extensions#installing-a-custom-extension). 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 fd9878dc65..d2d5f5d778 100644 --- a/articles/extensions/loggly.md +++ b/articles/extensions/loggly.md @@ -1,7 +1,12 @@ --- 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 The *Auth0 Logs to Loggly* is a scheduled job that takes all of your Auth0 logs and exports them to [Loggly](https://www.loggly.com/). @@ -15,11 +20,13 @@ To install and configure this extension, click on the __Auth0 Logs to Loggly__ b At this point you should set the following configuration variables: - __Schedule__: The frequency with which logs should be exported. -- __Auth0_Domain__: The domain of your Auth0 client. You can find this information at the [__Settings__ view of your client](https://${manage_url}/#/applications/${account.clientId}/settings). -- __Auth0_Global_Client_ID__: The Global Client ID of your Auth0 client. -- __Auth0_Global_Client_Secret__: The Global Client Secret of your Auth0 client. +- __Auth0_Domain__: The domain of your Auth0 application. You can find this information at the [__Settings__ view of your application](${manage_url}/#/applications/${account.clientId}/settings). +- __Auth0_Global_Client_ID__: The Global Client ID of your Auth0 application. +- __Auth0_Global_Client_Secret__: The Global Client Secret of your Auth0 application. -__NOTE__: You can find the _Global Client ID_ and _Global Client Secret_ information at the __Global Client information__ section of [your Account Advanced Settings](${manage_url}/#/account/advanced). +::: note +You can find the __Global Client ID__ and __Global Client Secret__ information at the __Global Application information__ section of [your Tenant Advanced Settings](${manage_url}/#/tenant/advanced). +::: - __Loggly_Customer_Token__: The identifying token assigned to you by Loggly at set-up. - __Loggly_Subdomain__: The Loggly account name. @@ -28,11 +35,15 @@ __NOTE__: You can find the _Global Client ID_ and _Global Client Secret_ informa 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. -__NOTE__: We assume that you already know your __Loggly_Subdomain__ since it's part of your URL. For example, if your account's URL is `https://mylogs.loggly.com` then the __Loggly_Subdomain__ should be set to `mylogs`. +::: note +We assume that you already know your __Loggly_Subdomain__ since it's part of your URL. For example, if your account's URL is `https://mylogs.loggly.com` then the __Loggly_Subdomain__ should be set to `mylogs`. +::: 1. Login to your [Loggly](https://www.loggly.com/) account. diff --git a/articles/extensions/logstash.md b/articles/extensions/logstash.md index 596e8b653d..ba02d1b161 100644 --- a/articles/extensions/logstash.md +++ b/articles/extensions/logstash.md @@ -1,36 +1,77 @@ --- 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 -The _Auth0 Logs to Logstash_ is a scheduled job that takes all of your Auth0 logs and exports them to [Logstash](https://www.elastic.co/products/logstash). Logstash is an open source log management tool that is most often used as part of the ELK stack along with ElasticSearch and Kibana. +The **Auth0 Logs to Logstash** is a scheduled job that takes all of your Auth0 logs and exports them to [Logstash](https://www.elastic.co/products/logstash). Logstash is an open source log management tool that is most often used as part of the ELK stack along with ElasticSearch and Kibana. -## Configuring the Extension +## Configure the Extension -To install and configure this extension, click on the _Auth0 Logs to Logstash_ 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. +To install and configure this extension, click on the **Auth0 Logs to Logstash** 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. -![](/media/articles/extensions/logstash/extension-mgmt-logstash.png) +![Dashboard > Logstash Extension](/media/articles/extensions/logstash/extension-mgmt-logstash.png) 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. -- **LOGSTASH_URL**: Your Logstash URL as defined for use with `logstash-input-http` plugin. -- **LOGSTASH_INDEX**: Your Logstash Index to which the logs will be routed. -- **LOG_LEVEL**: The minimal log level of events that you would like sent to Logstash. -- **LOG_TYPES**: The events for which logs should be exported. +| 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`. | +| **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. | +| **LOGSTASH_USER** | The Logstash user. | +| **LOGSTASH_PASSWORD** | The password associated with your Logstash user. | +| **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 Logstash. | +| **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. -## Using Your Installed Extension +<%= include('./_includes/_batch-size') %> - 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. 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. +### Using extension with ElasticSearch -![](/media/articles/extensions/logstash/view-cron-jobs.png) +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. + +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/logstash/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/logstash/view-cron-details.png) +![View Cron Job Details](/media/articles/extensions/logstash/view-cron-details.png) + +## Replay Logs + +In the event of a Logstash 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 Logstash 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 Logstash [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. -That's it, you are done! Have fun analyzing and visualizing those logs! +![Slack Message](/media/articles/extensions/logstash/slack-message.png) diff --git a/articles/extensions/management-api-webhooks.md b/articles/extensions/management-api-webhooks.md index 1f57ee47c5..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,16 +16,71 @@ 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. ## Using Your Installed Extension You can view all scheduled jobs by clicking on the Auth0 Management API Webhooks line under the "Installed Extensions" tab. + +## Sample Payload + +Here is an example of the payload that will be sent: + +```json +{ + "date":"2017-09-06T07:33:10.424Z", + "request":{ + "method":"post", + "path":"/api/v2/clients", + "query":{ + + }, + "body":{ + "name":"auth0-webhooks" + }, + "channel":"https://manage.auth0.com/", + "ip":"127.0.0.1", + "auth":{ + "user":{ + "user_id":"auth0|56541aaa73ec334341338bbe", + "name":"John Doe", + "email":"johndoe@gmail.com" + }, + "strategy":"jwt", + "credentials":{ + "jti":"0615b65ee0b5b29f4517153d2a943463", + "scopes":[ + "read:clients", + "create:clients", + "update:clients", + "delete:clients" + ] + } + } + }, + "response":{ + "statusCode":201, + "body":{ + "callback_url_template":false, + "client_id":"vRrHLFDHKSMEVLBmyV3UCoBBgsIPZBr5", + "custom_login_page_on":true, + "global":false, + "name":"auth0-webhooks", + "tenant":"test-tenant" + } + } +} +``` + +<%= include('./_troubleshoot-webhooks') %> diff --git a/articles/extensions/mixpanel.md b/articles/extensions/mixpanel.md index 1270015863..681af41310 100644 --- a/articles/extensions/mixpanel.md +++ b/articles/extensions/mixpanel.md @@ -1,43 +1,54 @@ --- -description: How to configure and use the Auth0 Logs to Mixpanel extension. +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 [Management Portal](${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 100. +- **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 +Once you have provided this information, click the **Install** button to finish installing 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 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). -![](/media/articles/extensions/mixpanel/auth0-logs-at-mixpanel.png) \ No newline at end of file +![](/media/articles/extensions/mixpanel/auth0-logs-at-mixpanel.png) diff --git a/articles/extensions/papertrail.md b/articles/extensions/papertrail.md index 1e1cd3e265..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. +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,50 +18,46 @@ 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 - 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 Papertrail* 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. + 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 Papertrail* 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. ![](/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) - -> 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. +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**. -![](/media/articles/extensions/papertrail/auth0-logs-at-papertrail-02.png) \ No newline at end of file +::: 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`. This is how Auth0's logs will be displayed and referred to in the Papertrail dashboard. +::: 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 5836b962e0..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,21 +21,26 @@ 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. -- **SPLUNK_URL**: Your Splunk Cloud URL. +- **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: -> This tutorial follows the step for Splunk Cloud. In case this is the first HEC you will configure for your account make sure that the Event Collector is enabled. You can find details on how to do this [here](http://docs.splunk.com/Documentation/Splunk/latest/Data/UsetheHTTPEventCollector). +::: note +This tutorial follows the step for Splunk Cloud. In case this is the first HEC you will configure for your account make sure that the Event Collector is enabled. You can find details on how to do this [here](http://docs.splunk.com/Documentation/Splunk/latest/Data/UsetheHTTPEventCollector). +::: 1. Navigate to your _Splunk Cloud URL_. You must have received this information via email upon signup. From the system menu select _Settings > Data Inputs_. @@ -59,9 +70,11 @@ The HTTP Event Collector (HEC) is an endpoint that lets you send application eve curl -k https://:8088/services/collector -H 'Authorization: Splunk ' -d '{"event":"Hello, World!"}' ``` -> 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). +::: panel URL prefixes +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 { @@ -70,11 +83,13 @@ As a response you should receive the followins JSON: } ``` -Navigate to your _Splunk Cloud URL_. Click on _Search & Reporting_. Click on _Data Summary_ and select your host at the popup window. +Navigate to your _Splunk Cloud URL_. Click on _Search & Reporting_. Click on _Data Summary_ and select your host at the popup window. ![](/media/articles/extensions/splunk/splunk-search.png) -> Splunk uses the Splunk Search Processing Language (SPL). For the search we executed above the search value would be `host="input-:8088"`, where the `` value is your _Splunk Cloud URL_. Click [here](http://docs.splunk.com/Documentation/Splunk/latest/Search/WhatsinSplunkSearch) for more info. +::: note +Splunk uses the Splunk Search Processing Language (SPL). For the search we executed above the search value would be `host="input-:8088"`, where the `` value is your _Splunk Cloud URL_. Click [here](http://docs.splunk.com/Documentation/Splunk/latest/Search/WhatsinSplunkSearch) for more info. +::: When the results of the search are displayed you should be able to see at least one entry, for our Hello World example. @@ -82,7 +97,7 @@ When the results of the search are displayed you should be able to see at least Now that we have confirmed our Splunk setup we can finish the Auth0 side configuration and start pushing logs. -8. Head back to the Auth0 Dashboard and go to the _Settings_ of the Splunk Extension. Set the following values: +8. Head back to the Auth0 Dashboard and go to the _Settings_ of the Splunk Extension. Set the following values: - **SPLUNK_TOKEN**: the value of the Splunk Token you created, same one you used for our Hello World example. - **SPLUNK_URL**: Your Splunk HTTP Collector Endpoint. It should like the following: `https://-:8088/services/collector`. The `` is your _Splunk Cloud URL_. The `` is either `input-` or `http-inputs-` (see note at previous step). - **SPLUNK_COLLECTOR_PORT**: The Port of your HTTP Collector Endpoint. Default is `8088`. @@ -90,7 +105,7 @@ Save your changes. A new CRON job is created and will be executed according to t ## Using Your Installed 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 Splunk* 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. + 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 Splunk* 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. ![](/media/articles/extensions/splunk/view-cron-jobs.png) @@ -101,5 +116,3 @@ You can view more details by clicking on the job you created. In this page you c That's it, you are done! When the CRON job has executed at least one you can now navigate to your _Splunk Cloud URL_ and view your [Auth0 Logs](${manage_url}/#/logs). Follow the same steps as before to search for the data associated with your host (Search & Reporting > Data Summary > select host). ![](/media/articles/extensions/splunk/auth0-logs-at-splunk.png) - - diff --git a/articles/extensions/sso-dashboard.md b/articles/extensions/sso-dashboard.md index c68ae02e9a..3d732fd70d 100644 --- a/articles/extensions/sso-dashboard.md +++ b/articles/extensions/sso-dashboard.md @@ -1,137 +1,45 @@ --- -description: This page explains how to configure and utilize the SSO Dashboard Extension. +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 A Client +To setup and configure this extension, do the following steps: -Let's start with creating a new client application. Navigate to [Clients](${manage_url}/#/applications) and click on the **+Create Client** button. Set a name and choose **Single Page Web Applications** client 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. - -### Client 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 Client. - -## Install the Extension - -We are now ready to setup our new extension. But first, head back to your newly created Client 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 [Clients](${manage_url}/#/clients) 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 [Clients](${manage_url}/#/clients) view, you will see that there has been an additional client created. - -![New created Client](/media/articles/extensions/sso-dashboard/new-client.png) - -The `auth0-sso-dashboard` client is created automatically when you install the extension. It's a client 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**: - -`https://${account.tenant}..webtask.io/auth0-sso-dashboard/admins/login` or through the Auth0 Management Dashboard. - -For **Users**: - -`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 [Client Settings](${manage_url}/#/clients) 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 db3c130c12..5e6a1cef8e 100644 --- a/articles/extensions/sumologic.md +++ b/articles/extensions/sumologic.md @@ -1,72 +1,100 @@ --- 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) -Once you have provided this information, click the *Install* button to finish installing the extension. +4. Select **HTTP Source** as the way to collect the logs. -## Retrieve the required information from Sumo Logic +![Select HTTP source](/media/articles/extensions/sumologic/sumologic-setup-collection.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_. +5. Modify the **Source Category** and select a time zone for your log file. Click **Continue**. -![](/media/articles/extensions/sumologic/sumologic-setup-wizard.png) +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. -2. On the next screen click _Set Up Streaming Data_. -3. At the _Select Data Type_ page, select _Your Custom App_. +![Get the HTTP source](/media/articles/extensions/sumologic/sumologic-http-source.png) -![](/media/articles/extensions/sumologic/sumologic-data-type.png) +7. Now head back to the Auth0 Dashboard to set the value you copied as the value for **SUMOLOGIC_URL**. -4. Select _HTTP Source_ as the way to collect the logs. +## Step 2: Configure the Extension -![](/media/articles/extensions/sumologic/sumologic-setup-collection.png) +To install and configure this extension, go to [Dashboard > Extensions](${manage_url}/#/extensions) and click on the **Auth0 Logs to Sumo Logic** box. -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. +The **Install Extension** window pops open. -![](/media/articles/extensions/sumologic/sumologic-http-source.png) +![Install Auth0 extension](/media/articles/extensions/sumologic/extension-mgmt-sumologic.png) -7. Now head back to the Auth0 Dashboard and set the value you copied as the value for **SUMOLOGIC_URL**. +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. -## Using Your Installed Extension +Once you have provided this information, click the **Install** button to finish installing 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 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. +The integration between Auth0 and Sumo Logic is now in place! -![](/media/articles/extensions/sumologic/view-cron-jobs.png) +<%= include('./_includes/_batch-size') %> + +## How to view the results + +The integration you just setup, created a scheduled job that will be responsible to export the logs. + +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. + +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 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/07Sumo-Logic-Apps/20SAML/Auth0/Auth0-App-Dashboards) -If you're a Sumo Logic customer and are interested in trying out this dashboard, just let us know via [Support Center](${env.DOMAIN_URL_SUPPORT}) and we will gladly share it with you. Make sure to include your Sumo Logic account name in your request. 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. +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. -Have fun analyzing and visualizing those logs! \ No newline at end of file +Have fun analyzing and visualizing those logs! 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 3f5fd6bdd6..45528fde69 100644 --- a/articles/extensions/user-import-export.md +++ b/articles/extensions/user-import-export.md @@ -1,40 +1,97 @@ --- title: User Import / Export Extension -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. +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 -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. Please note that you need to be a Dashboard Admin in order to use this 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 + +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 + +To install this extension, click on **User Import / Export** in the list of provided extensions on the [Extensions page](${manage_url}/#/extensions) of the [Dashboard](${manage_url}). + +The extension does not require any additional configuration before it can be installed, so click **Install** in the informational pop-up window to proceed. + +![](/media/articles/extensions/user-import-export/install-extension.png) + +## Use the Extension + +After you've installed your extension, you'll see it listed in your list of installed extensions. Click on **Import / Export Extension** to launch. + +![](/media/articles/extensions/user-import-export/installed-extensions-list.png) + +You'll be asked to grant permission for the extension to access your Auth0 account for the listed activities the first time you launch the extension. + +![](/media/articles/extensions/user-import-export/permissions.png) + +Click the **check mark** to proceed. + +There are two ways of using this extension: + +* Bulk import your existing database users into Auth0 +* Search for and export some (or all) of you Auth0 database users + +Both use cases are explained in further detail below. + +### Import Users + +By default, any time you open the extension, you'll see the **User Import** screen (if you're on the export screen, you can return to this screen by click **Import** in the left-hand navigation bar). + +![](/media/articles/extensions/user-import-export/import.png) + +To import your users, drag and drop a valid JSON file ([schema and examples here](/tutorials/bulk-importing-users-into-auth0)) onto the area that says **Drop your file here, or click to select**. Alternatively, you can click on this area to browse your files and select the appropriate JSON file. The JSON file should contain the list of users that you are planning to import. + +Select the database connection for which your users will be imported. Please make sure that the connection you choose has been enabled for at least one application. + +![](/media/articles/extensions/user-import-export/ready-for-import.png) + +Click **Start Importing Users** to begin the import process. + +When done, you'll see the following **Completed** message. + +![](/media/articles/extensions/user-import-export/import-complete.png) + +Once you've imported your users, you can manage them individually using the [Users section of the Dashboard](${manage_url}/#/users) + +### Export Users -## Configuring the Extension +::: 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 install this extension, click on `User Import / Export` in the list of provided extensions on the [Extensions page](${manage_url}/#/extensions) of the [Management Portal](${manage_url}). When authorizing the application, you will be asked to provide the following information about your Auth0 account: +To export your existing Auth0 users associated with database connections, select **Export** in the left-hand navigation bar. - - __Users__: create and read your users - - __Connections__: read your connections - - __Profile__: access to your profile +![](/media/articles/extensions/user-import-export/export-users.png) -Once you have provided the appropriate values for the above fields, click on "Install" to proceed. +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. -## Using Your Installed Extension +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). -There are two ways of using this extension, they are described below: +You can remove extraneous attributes/expressions by clicking on its associated **trash can** icon. -### Import of users +Under **Settings**, you can: -1. Select the Import option in the menu from the left. -2. You may drop a valid JSON file ([schema and examples here](/tutorials/bulk-importing-users-into-auth0)) in the square area or click there to browse your files and search for a valid JSON file. This JSON file should contain the list of users that you are planning to import. -3. Select the database connection where these users will be imported. -4. Click on the `Start importing users` blue button. +* 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) +* Choose your **Export Format**; you can choose between JSON and CSV files -### Export of users +![](/media/articles/extensions/user-import-export/settings.png) -1. Select the Export option in the menu from the left. -2. You can query the users that you want to export by using the [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 `user_metadata` attribute you can use: `_exists_:user_metadata`. -3. In the columns section you can decide which attributes should be included in the export. The user attribute can be a static value like `user.app_metadata.name` or a Javascript expression like `user.app_metadata.name || user.name` which will then be evaluated during the export. The column name is how the value will be represented in the export. A good way of seeing an example of this is by clicking on the `Add default columns` blue button on the right. -4. In the settings section you can configure the sorting options of the output by writing a `User Attribute` in the text field, and the sorting order (descending or ascending) by toggling the button on and off respectively. You can also choose between two output formats, either a `.csv` or `.json` file. +When you're ready, click **Export X Users** (where `X` is the number of users you're exporting). -### Observations +You can download the file containing your users when the export is complete. -This extension is not supported in the Appliance. +![](/media/articles/extensions/user-import-export/export-complete.png) 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 bb50a1dba7..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 @@ -33,17 +45,17 @@ Once you have provided this information, click **Install**. ![Profile drop down](/media/articles/extensions/visual-studio-ts/profile-menu.png) -3. This will bring up the **Personal access tokens** page, click **Add**. +3. This will bring up the **Personal Access Tokens** page, click **Add**. -![Add personal access token](/media/articles/extensions/visual-studio-ts/add-token.png) +![Add personal Access Token](/media/articles/extensions/visual-studio-ts/add-token.png) 4. Add a description for the new token, select the desired lifetime, and the account the token will be associated with. Then choose the scopes you wish to authorize and then click **Create Token**. -![Creating the access token](/media/articles/extensions/visual-studio-ts/create-token.png) +![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) +![Copy Access Token](/media/articles/extensions/visual-studio-ts/copy-token.png) ## Authorize Access @@ -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 these predefined directories. +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` -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,41 +129,75 @@ 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 } ``` -### 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. +<%= include('./_includes/_use-default-error') %> -For example, if you create the file `rules/set-country.js`, the extension will create a Rule in Auth0 with the name `set-country`. +### Deploy Rules -**NOTE**: 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. +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. -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. +For example, if you create the file `rules/set-country.js`, the extension will create a Rule in Auth0 with the name `set-country`. -![Mark rules as manual](/media/articles/extensions/visual-studio-ts/manual-rule.png) +::: note +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 also control the Rule order, status (`enabled`/`disabled`) and stage (for now, only `login_success` is available) 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`. +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__ ```javascript @@ -160,7 +210,7 @@ function (user, context, callback) { ``` __set-country.json__ -```javascript +```json { "enabled": false, "order": 15, @@ -172,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. @@ -191,4 +392,3 @@ To track your deployments, navigate to the [Extensions](${manage_url}/#/extensio If a deployment fails, you can examine the details of the deployment to determine why. Details are also available for successful deployments. If you configured a **Slack Incoming Webhook**, you will be notified on Slack anytime a deployment occurs. - 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 new file mode 100644 index 0000000000..b8d018dc5a --- /dev/null +++ b/articles/getting-started/_list-processes.md @@ -0,0 +1,41 @@ +<% 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 === "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](/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](/api-auth). +<% } else if (screen === "sso") { %> + 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](/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 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") { %> + In this page you can view log data of both actions taken in the dashboard by the administrators, as well as authentications made by your users. [More info on logs](/logs). +<% } else if (screen === "anomaly") { %> + Here you can configure extra layers of security by enabling shields​ that protect you and your users against different types of attacks and user access anomalies. This is not available for free accounts and does require the purchase of an addon to your Auth0 subscription. [More info on anomaly detection](/anomaly-detection). +<% } 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 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 new file mode 100644 index 0000000000..3528b0a344 --- /dev/null +++ b/articles/getting-started/dashboard-overview.md @@ -0,0 +1,107 @@ +--- +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 + +The [Dashboard](${manage_url}) is where you manage all aspects of your Auth0 account and configuration. + +![Auth0 Dashboard Homepage](/media/articles/getting-started/auth0-dashboard.png) + +It consists of several sections which you can navigate using the sidebar menu on your left. + +## Configure your implementation + +The following table contains a brief overview of the different dashboard pages and what you can do on each. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        ScreenWhat can I do here?
         Dashboard<%= include('./_list-processes', {"screen": "dashboard"}) %>
         Applications<%= include('./_list-processes', {"screen": "applications"}) %>
         APIs<%= include('./_list-processes', {"screen": "apis"}) %>
         SSO Integrations<%= include('./_list-processes', {"screen": "sso"}) %>
         Connections<%= include('./_list-processes', {"screen": "connections"}) %>
         Universal Login<%= include('./_list-processes', {"screen": "universal-login"}) %>
         Users & Roles<%= include('./_list-processes', {"screen": "users-roles"}) %>
         Rules<%= include('./_list-processes', {"screen": "rules"}) %>
         Hooks<%= include('./_list-processes', {"screen": "hooks"}) %>
         Multi-factor Auth<%= include('./_list-processes', {"screen": "mfa"}) %>
         Emails<%= include('./_list-processes', {"screen": "emails"}) %>
         Logs<%= include('./_list-processes', {"screen": "logs"}) %>
         Anomaly Detection<%= include('./_list-processes', {"screen": "anomaly"}) %>
         Extensions<%= include('./_list-processes', {"screen": "extensions"}) %>
         Get Support<%= include('./_list-processes', {"screen": "support"}) %>
        + +## Manage your account + +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. +- **View profile**: Use this to view information about your [account profile](${manage_url}/#/profile). +- **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 new file mode 100644 index 0000000000..3f9a81a6cf --- /dev/null +++ b/articles/getting-started/deployment-models.md @@ -0,0 +1,201 @@ +--- +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 the following deployment models: + + + + + + + + + + + + + + + + + + +
        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
        + +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. + +## Operational Differences + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        Where It RunsAuth0's InfrastructureAuth0's InfrastructureAuth0's Infrastructure or Customer's AWS Cloud
        How It RunsPublic Cloud (Multi-Tenant)Standard Private CloudManaged Private Cloud
        Public FacingYesYesAuth0's Cloud: Yes
        Customer's AWS Cloud: Configurable*
        UpdatesAutomatic UpdatesAutomatic Monthly UpdatesMonthly, bi-monthly, or quarterly as coordinated with Auth0. Excludes critical updates (e.g., security patches), which will be applied as soon as possible
        Deployment ConfigurationsN/AHigh Availability (HA);
        High Capacity +         		High Availability (HA);
        Geo HA;
        High Capacity;
        Geo HA and High Capacity
        Isolated Non-Production EnvironmentNoYesYes
        Service & Uptime Reportinghttps://status.auth0.com
        http://uptime.auth0.com        		Monitored by Auth0Auth0's Cloud: Auth0
        Customer's AWS Cloud: Customer
        Infrastructure and Backup ResponsibilityAuth0Auth0Auth0's Cloud: Auth0
        Customer's AWS Cloud: Customer
        Uptime SLA Provided99.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 SecondSee Rate Limit Policy for Auth0 APIs500 requests per second with optional upgrade to 1500 requests per second500 requests per second with optional upgrade to 1500 requests per second
        Data ResidencyNot applicableRegion of Choice*** ****Region of Choice***
        PCI ComplianceNoAdd-on availableAdd-on available for Auth0-Hosted Private Cloud
        Support Channels & LevelsSame across all modelsSame across all modelsSame 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 RunsPublic Cloud (Multi-Tenant)Standard Private CloudManaged Private Cloud
        Tenant Log Searchv3v3
        Code SandboxWebtask (Node.js version 8 and C#)Webtask (Node.js version 8)Webtask (Node.js version 8)
        WebtaskMulti-TenantDedicatedDedicated
        Anomaly DetectionBrute Force and Breached PasswordsBrute Force and Breached PasswordsBrute Force and Breached Passwords
        Connecting IP Address Filtering RestrictionsNoNoAuth0's Cloud: No
        Customer's AWS Cloud: Yes
        Custom DomainsYesYes*Yes*
        Shared Resources Among Multiple CustomersYesNoNo
        MFAYesAvailable 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 [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 new file mode 100644 index 0000000000..82bc9567db --- /dev/null +++ b/articles/getting-started/faq.md @@ -0,0 +1,12 @@ +--- +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 new file mode 100644 index 0000000000..28e11867a5 --- /dev/null +++ b/articles/getting-started/hello-world.md @@ -0,0 +1,12 @@ +--- +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 new file mode 100644 index 0000000000..a033710ec9 --- /dev/null +++ b/articles/getting-started/index.md @@ -0,0 +1,53 @@ +--- +description: If you are new to Auth0 start here for a list of resources that can get you started +title: Get Started +classes: topic-page +topics: + - auth0-101 +contentType: + - concept + - index +useCase: + - strategize + - get-started +--- +
        +
        +

        Get Started

        +

        + Learn the basics of Auth0. +

        +
        + +Welcome! If you are new to Auth0, you are in the right place. Here we will cover how to get started using Auth0. + + diff --git a/articles/getting-started/overview.md b/articles/getting-started/overview.md new file mode 100644 index 0000000000..738d3bbd98 --- /dev/null +++ b/articles/getting-started/overview.md @@ -0,0 +1,59 @@ +--- +title: Auth0 Overview +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 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. + +## Why 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 (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 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 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 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 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: + +- **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 (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 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 new file mode 100644 index 0000000000..b91140b4c8 --- /dev/null +++ b/articles/getting-started/the-authentication-flow.md @@ -0,0 +1,13 @@ +--- +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 new file mode 100644 index 0000000000..ed84b63202 --- /dev/null +++ b/articles/getting-started/the-basics.md @@ -0,0 +1,129 @@ +--- +title: Learn the Basics +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. 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. + +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](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. *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. + +Tenant characteristics: + +- 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). + +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**. + +## Domains + +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. + +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)). + +When you create an application in the [Dashboard](${manage_url}/#/applications), the first piece of information we ask for is its type. This can be one of the following. + +![Application Types](/media/articles/getting-started/client-types.png) + +Each application is assigned a **Client ID** upon creation. This is an alphanumeric string and it's the unique identifier for your application (such as `q8fij2iug0CmgPLfTfG1tZGdTQyGaTUA`). It cannot be modified and you will be using it in your application's code when you call Auth0 APIs. + +Another important piece of information is the **Client Secret**. Think of it as your application's password which **must be kept confidential at all times**. If anyone gains access to your Client Secret they can impersonate your application and access protected resources. + +In our example, `ExampleCo` has two apps: a web app (running on a server) and a mobile app. Hence, they would create two applications: one of type `Regular Web Applications`, and one of type `Native`. + +::: note +We won't get into details on how to create an application, since this article is meant to provide a high level overview. However, if you want to know more, refer to the [Applications](/applications) documentation. +::: + +## Connection + +Now that you have set up your **Applications**, you are ready to configure how your users will login. + +Auth0 sits between your app and the identity provider that authenticates your users (such as Google or Facebook). Through this level of abstraction, Auth0 keeps your app isolated from any changes of the provider's implementation. + +This relationship between Auth0 and the identity provider is referred to as a **Connection**. + +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](/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. + +In our example, `ExampleCo` wants their users to be able to login with username/password, Google, and GitHub, both from the web app and from the mobile app. Therefore, the steps to follow would be: +1. [Configure a GitHub connection](/connections/social/github) +1. [Configure a Google connection](/connections/social/google) +1. [Configure a database connection](/connections/database) +1. Enable all three connections for the web app +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 [Connections](/connections). +::: + +## Where to go from here + +In this article you familiarized yourself with several core concepts of Auth0. We used a simple example that added authentication to a couple of different apps. + +If you wish to learn more about the next steps in setting up Auth0, you can read more: + +- **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/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 + +- [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 new file mode 100644 index 0000000000..832eefbc0f --- /dev/null +++ b/articles/getting-started/the-implementation-process.md @@ -0,0 +1,28 @@ +--- +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 (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. + +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. diff --git a/articles/getting-started/whats-next.md b/articles/getting-started/whats-next.md new file mode 100644 index 0000000000..a2ed17b47d --- /dev/null +++ b/articles/getting-started/whats-next.md @@ -0,0 +1,24 @@ +--- +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 + +## An Extensible Platform + +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 (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 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 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 new file mode 100644 index 0000000000..beb5e5dd35 --- /dev/null +++ b/articles/guides/login/_includes/_centralized_webapp.md @@ -0,0 +1,40 @@ +3. In the web server, handle the callback, usually using a platform-specific OAuth library. This is what you would do in Node & [Passport](http://www.passportjs.org). + +```js +router.get('/callback', + passport.authenticate('auth0', { failureRedirect: '/failure' }), + function(req, res) { + res.redirect(req.session.returnTo || '/user'); + }); +``` +## 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: + +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: + +```html +Log In +``` + +2. Create a server-side route to handle `/login` that redirects to Auth0's `/authorize` endpoint. You can usually do that with a platform-specific OAuth library. The example below is for Node.js and Passport. + +```js +router.get('/login', passport.authenticate('auth0', { + clientID: '${account.clientId}', + domain: '${account.namespace}' , + redirectUri: ${account.callback}, + responseType: 'code', + scope: 'openid profile email'}), + function(req, res) { + res.redirect("/"); +}); +``` + +After authentication is done, it will redirect to the `/callback` url as in the Lock-based implementation. + +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). + +<%= include('_customizing-login-page') %> diff --git a/articles/guides/login/_includes/_customizing-login-page.md b/articles/guides/login/_includes/_customizing-login-page.md new file mode 100644 index 0000000000..92d0bd121b --- /dev/null +++ b/articles/guides/login/_includes/_customizing-login-page.md @@ -0,0 +1,17 @@ +## 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. + +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. + +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. + +![Login Page](/media/articles/hosted-pages/hlp-lock.png) diff --git a/articles/guides/login/migrating-lock-v10-spa.md b/articles/guides/login/migrating-lock-v10-spa.md new file mode 100644 index 0000000000..f24d3acc12 --- /dev/null +++ b/articles/guides/login/migrating-lock-v10-spa.md @@ -0,0 +1,112 @@ +--- +title: Moving SPAs 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). + +When you use Lock, your code does basically this: + +1. Initialize Lock: + +```js +var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', { + auth: { + redirectUrl: '${account.callback}', + responseType: 'token id_token', + audience: 'https://' + '${account.namespace}' + '/userinfo', + params: { + scope: 'openid' + } + } +}); +``` + +2. Set the session and update the UI in the `authenticated` event: + +```js +lock.on('authenticated', function (authResult) { + if (authResult && authResult.accessToken && authResult.idToken) { + setSession(authResult); // set the local session + } + displayButtons(); // refresh the UI to indicated a ‘logged-in’ state. +}); +``` + +3. Handle errors in the `authorization_error` event: + +```js +// Handle authorization errors +lock.on('authorization_error', function (err) { + console.log(err); + alert('Error: ' + err.error + '. Check the console for further details.'); + displayButtons(); +}); +``` + +4. Show Lock when a login is required: +```js +function login() { + lock.show(); +} +``` + +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: + +```js +var webAuth = new auth0.WebAuth({ + domain: '${account.namespace}', + clientID: '${account.clientId}', + responseType: 'token id_token', + audience: 'https://' + ${account.namespace} + '/userinfo', + scope: 'openid', + redirectUri: '${account.callback}' +}); +``` + +2. Create a `handleAuthentication` function that processes successful and failed authentication attempts calling `parseHash`: + +```js +function handleAuthentication() { + webAuth.parseHash(function(err, authResult) { + if (authResult && authResult.accessToken && authResult.idToken) { + setSession(authResult); + } else if (err) { + console.log(err); + alert( + 'Error: ' + err.error + '. Check the console for further details.' + ); + } + displayButtons(); + }); +} +``` + +3. Invoke the `handleAuthentication()` function on page load so it tries to parse the hash if it's present. + +4. Redirect to the `/authorize` endpoint when you need to log the user in your app. + +```js +function login() { + webAuth.authorize(); +} +``` + +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). + +<%= 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 new file mode 100644 index 0000000000..b2378e8a08 --- /dev/null +++ b/articles/guides/login/migrating-lock-v10-webapp.md @@ -0,0 +1,41 @@ +--- +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). + +When you use Lock in a Web Application, your code does basically this: + +1. Initialize Lock using `responseType = 'code'`: + +```js +var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', { + auth: { + redirectUrl: '${account.callback}', + responseType: 'code', + params: { + scope: 'openid profile email' + } + } +}); +``` +2. Show Lock when a login is required: + +```js +function login() { + lock.show(); +} +``` + +<%= include('_includes/_centralized_webapp') %> diff --git a/articles/guides/login/migrating-lock-v8.md b/articles/guides/login/migrating-lock-v8.md new file mode 100644 index 0000000000..62c9674b41 --- /dev/null +++ b/articles/guides/login/migrating-lock-v8.md @@ -0,0 +1,20 @@ +--- +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: + +- [Migrating Web Applications using Lock 9](/guides/login/migrating-lock-v9-webapp) + +- [Migrating SPA using Lock 9 Redirect Mode](/guides/login/migrating-lock-v9-spa) + +- [Migrating SPA using Lock 9 Popup Mode](/guides/login/migrating-lock-v9-spa-popup) diff --git a/articles/guides/login/migrating-lock-v9-spa-popup.md b/articles/guides/login/migrating-lock-v9-spa-popup.md new file mode 100644 index 0000000000..0e4fdeac6d --- /dev/null +++ b/articles/guides/login/migrating-lock-v9-spa-popup.md @@ -0,0 +1,89 @@ +--- +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). + +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: + +```js +var lock = new Auth0Lock('${account.clientId}', '${account.namespace}'); +``` + +2. Show lock specifying `responseType: token` when a login is required, and a callback function that will be called after authentication transaction finishes: + +```js +function login() +{ + lock.show({ + responseType : "token", + authParams: { + scope: 'openid email offline_access' + } + }, + function (err, profile, id_token) { + if (!err) { + setSession(profile, id_token); + lock.getProfile(hash.id_token, function(err, userInfo) { + if (!err) { + /// use the userInfo + } + }); + } + } + }) +} +``` + +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(). + +```js +var webAuth = new auth0.WebAuth({ + domain: '${account.namespace}', + clientID: '${account.clientId}', + responseType: 'token id_token', + scope: 'openid', + redirectUri: '${account.callback}' +}); +``` + +2. Redirect to the `/authorize` endpoint when you need to log the user in your application. + +```js +function login() { + webAuth.authorize(); +} +``` + +3. Call parseHash to retrieve the authentication results, when the page loads, after being redirected to your callback page: + +```js +webAuth.parseHash(function(err, authResult) { + if (authResult && authResult.accessToken && authResult.idToken) { + setSession(authResult.idTokenPayload, authResult.idToken, authResult.accessToken); + } else if (err) { + // handle errors + } +} +``` + +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). + +<%= 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 new file mode 100644 index 0000000000..ced825aa61 --- /dev/null +++ b/articles/guides/login/migrating-lock-v9-spa.md @@ -0,0 +1,96 @@ +--- +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 + +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: + +1. Initialize Lock: + +```js +var lock = new Auth0Lock('${account.clientId}', '${account.namespace}'); +``` + +2. Show lock specifying `responseType: token` when a login is required: + +```js +function login() { + lock.show({ + callbackURL: '${account.callback}', + responseType : 'token', + authParams: { + scope: 'openid profile' + } + }); +} +``` + +3. When the page loads, attempt to parse the hash with the authentication results: + +```js + var hash = lock.parseHash(); + + if (hash) { + if (!hash.error) { + setSession(hash.profile, hash.id_token, hash.access_token); + + lock.getProfile(hash.id_token, function(err, profile) { + if (!err) { + // use the profile + } + }); + } + } +``` + +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(): + +```js +var webAuth = new auth0.WebAuth({ + domain: '${account.namespace}', + clientID: '${account.clientId}', + responseType: 'token id_token', + scope: 'openid', + redirectUri: '${account.callback}' +}); +``` + +2. When the page loads, attempt to parse the hash with the authentication results: + +```js +webAuth.parseHash(function(err, authResult) { + if (authResult && authResult.accessToken && authResult.idToken) { + setSession(authResult.idTokenPayload, authResult.idToken, authResult.accessToken); + } else if (err) { + // handle errors + } +} +``` + +3. Redirect to the `/authorize` endpoint when you need to log the user in your application. + +```js +function login() { + webAuth.authorize(); +} +``` + +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). + +<%= 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 new file mode 100644 index 0000000000..1df0f0a1e4 --- /dev/null +++ b/articles/guides/login/migrating-lock-v9-webapp.md @@ -0,0 +1,41 @@ +--- +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). + +When you use Lock v9 in a Web Application, your code does basically this: + +1. Initialize Lock: + +```js +var lock = new Auth0Lock('${account.clientId}', '${account.namespace}'); +``` +2. Show Lock specifying `responseType: code` when a login is required: + +```js +function login() { + lock.show({ + auth: { + redirectUrl: '${account.callback}', + responseType: 'code', + params: { + scope: 'openid profile email' + } + } + }); +} +``` + +<%= include('_includes/_centralized_webapp') %> diff --git a/articles/guides/login/migration-embedded-universal.md b/articles/guides/login/migration-embedded-universal.md new file mode 100644 index 0000000000..6bd0804496 --- /dev/null +++ b/articles/guides/login/migration-embedded-universal.md @@ -0,0 +1,36 @@ +--- +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. + +- 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](/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). + +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). + +## Migration Guides per Application Type + +:::next-steps +- [Migrating SPA Applications using Lock 10+](/guides/login/migrating-lock-v10-spa) +- [Migrating Web Applications using Lock 10+](/guides/login/migrating-lock-v10-webapp) +- [Migrating Web Applications using Lock 9](/guides/login/migrating-lock-v9-webapp) +- [Migrating SPA using Lock 9 Redirect Mode](/guides/login/migrating-lock-v9-spa) +- [Migrating SPA using Lock 9 Popup Mode](/guides/login/migrating-lock-v9-spa-popup) +- [Migrating from Lock v8](/guides/login/migrating-lock-v8) +::: diff --git a/articles/guides/login/migration-sso.md b/articles/guides/login/migration-sso.md new file mode 100644 index 0000000000..b309d94aa7 --- /dev/null +++ b/articles/guides/login/migration-sso.md @@ -0,0 +1,35 @@ +--- +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 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](/universal-login) in most cases. + +## 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). + +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). + +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. + +## Web Apps + +Web Applications using embedded login that require SSO need to [migrate to Universal Login](/guides/login/migration-embedded-universal). + +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). diff --git a/articles/guides/login/universal-vs-embedded.md b/articles/guides/login/universal-vs-embedded.md new file mode 100644 index 0000000000..73fe301b7c --- /dev/null +++ b/articles/guides/login/universal-vs-embedded.md @@ -0,0 +1,88 @@ +--- +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 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) + +On the other hand, an embedded login flow does not redirect the user somewhere central. The login widget is served from the same page without redirecting the user to another domain. The credentials are then sent to the authentication provider for authentication. In a web app this is a **cross-origin** request. + +Universal vs Embedded login flow + +In this article, we will evaluate the pros and cons of these two options and see how you can use Auth0 to implement them. + +## 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. + +- **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 [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 (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 + +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, 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. + +Note that if the incoming authentication request uses an external identity provider (for example, Facebook), the login page will not be displayed. Instead, Auth0 will direct the user to the identity provider's login page. + +::: note +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 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 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 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 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 +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. + +## 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) +- [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 new file mode 100644 index 0000000000..ba6f220bab --- /dev/null +++ b/articles/guides/migration-legacy-flows.md @@ -0,0 +1,179 @@ +--- +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 + +When using Lock versions below 11 and Auth0.js version below 9, you could use legacy authentication flows that are deprecated. This document describes how to migrate code from older versions of Auth0.js and Lock to the new OIDC-conformant APIs. + +## Renewing Tokens + +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 + refresh_token = localStorage.getItem('refresh_token'); + auth0.refreshToken(refresh_token, function (err, delegationResult) { + if (!err) + { + 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); + localStorage.setItem('id_token', delegationResult.id_token); + } + ); +} +``` + +In auth0.js v9 and Lock 11 you need to use [Silent Authentication](/api-auth/tutorials/silent-authentication) and `checkSession()`(an example of this is below). + +```js +function renewToken() { + auth0.checkSession({}, function(err, result) { + if (!err) { + var expiresAt = JSON.stringify( + authResult.expiresIn * 1000 + new Date().getTime() + ); + // Assumes you want to store Access Token, ID Token and expiration time in local Storage + localStorage.setItem('access_token', authResult.accessToken); + localStorage.setItem('expires_at', expiresAt); + } + }); +} +``` + +Check the [Silent Authentication documentation](/api-auth/tutorials/silent-authentication) for more information on how to fully implement it in different SPA frameworks. + +## Calling APIs + +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', + } +}); +``` + +If you specify an audience, then the OIDC flow will be triggered and the user profile data returned by Auth0 in ID Tokens or from `/userinfo` will be OIDC conformant. If your application is using any non-standard claim from the user profile, it will break. For more information on how to deal with this issue, refer to the [User Profiles](#user-profiles) section. + +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 + +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. + +```json +{ + "email": "demo@user.com", + "picture": "https://s.gravatar.com/avatar/1a9b4fabea79ed763b435793887fb67b?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fde.png", + "nickname": "demo", + "name": "demo@user.com", + "user_metadata": { + "favorite_color": "blue" + }, + "app_metadata": { + "roleName": "foobar" + }, + "roleName": "foobar", + "email_verified": false, + "user_id": "auth0|59df6364209a29662e321756", + "clientID": "tkQfyt2o4uy5RJwhJ3g651BSY4Fwegex", + "identities": [ + { + "user_id": "59df6364209a29662e321756", + "provider": "auth0", + "connection": "Local-Users", + "isSocial": false + } + ], + "updated_at": "2017-12-13T14:43:01.575Z", + "created_at": "2017-10-12T12:43:16.682Z", + "sub": "auth0|59df6364209a29662e321756" +} +``` + +The new user profile conforms to the OIDC specification, which allows for certain [standard claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) to be available in the response. + +```json +{ + "sub": "auth0|59df6364209a29662e321756", + "nickname": "demo", + "name": "demo@user.com", + "picture": "https://s.gravatar.com/avatar/1a9b4fabea79ed763b435793887fb67b?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fde.png", + "updated_at": "2017-12-13T14:44:51.788Z" +} +``` + +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. + +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/`, + scope: 'read:current_user' + }, + function(err, result) { + if (!err) { + var auth0Manage = new auth0.Management({ + domain: AUTH0_DOMAIN, + token: result.accessToken + }); + auth0Manage.getUser(result.idTokenPayload.sub, function(err, userInfo) { + if (!err) { + // use userInfo + } + else { + // handle error + } + }); + } + else { + // handle error + } + } + ); + } + ``` + +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` + +You could get a `consent_required` error when calling `checkSession()`. If you do, make sure you have "Allow Skipping User Consent" enabled for the Management API and that you are not running from localhost. Check the [consent documentation](/api-auth/user-consent) for more information. 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/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/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/index.md b/articles/hooks/extensibility-points/index.md new file mode 100644 index 0000000000..c39ebc9aa5 --- /dev/null +++ b/articles/hooks/extensibility-points/index.md @@ -0,0 +1,27 @@ +--- +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 + +Extensibility points are places in the Auth0 platform where [Hooks](/hooks) can be executed. + +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 new file mode 100644 index 0000000000..694ee52253 --- /dev/null +++ b/articles/hooks/extensibility-points/post-user-registration.md @@ -0,0 +1,127 @@ +--- +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 +--- + +# Post-User Registration + +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. + +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-User Registration extensibility point is available for [Database Connections](/connections/database) and [Passwordless Connections](/connections/passwordless). + +::: 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). +::: + +To learn about other extensibility points, see [Extensibility Points](/hooks/extensibility-points). + +## Starter code and parameters + +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 - 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'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 - 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, response) +*/ + +module.exports = function (user, context, cb) { + // Perform any asynchronous actions, such as 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-User Registration extensibility point ignore any response object. + +### 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": { + "tenant": "my-tenant", + "username": "user1", + "email": "user1@foo.com", + "emailVerified": true, + "phoneNumber": "1-000-000-0000", + "phoneNumberVerified": true, + "user_metadata": { + "hobby": "surfing" + }, + "app_metadata": { + "plan": "full" + } + }, + "context": { + "requestLanguage": "en-us", + "connection": { + "id": "con_xxxxxxxxxxxxxxxx", + "name": "Username-Password-Authentication", + "tenant": "my-tenant" + } + } +} +``` + +## 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) { + + // Read more about incoming webhooks at https://api.slack.com/incoming-webhooks + var SLACK_HOOK = 'YOUR SLACK HOOK URL'; + + // 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.username || user.email) + ' (' + user.email + ')'; + var channel = '#some_channel'; + + slack.success({ + text: message, + channel: channel + }); + + // Return immediately; the request to the Slack API will continue on the sandbox + cb(); +}; +``` diff --git a/articles/hooks/extensibility-points/pre-user-registration.md b/articles/hooks/extensibility-points/pre-user-registration.md new file mode 100644 index 0000000000..6291fd715e --- /dev/null +++ b/articles/hooks/extensibility-points/pre-user-registration.md @@ -0,0 +1,205 @@ +--- +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 +topics: + - hooks + - extensibility-points + - pre-user-registration +contentType: + - how-to +useCase: extensibility-hooks +v2: true +--- + +# Pre-User Registration + +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. + +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. + +The Pre-User Registration extensibility point is available for [Database Connections](/connections/database) and [Passwordless Connections](/connections/passwordless). + +::: 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). +::: + +To learn about other extensibility points, see [Extensibility Points](/hooks/extensibility-points). + +## Starter code and parameters + +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 - user being created +@param {string} user.tenant - Auth0 tenant name +@param {string} user.username - user's username +@param {string} user.password - user's password +@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 - 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 + // response.user = { + // user_metadata: { foo: 'bar' }, + // app_metadata: { vip: true, score: 7 } + // }; + + response.user = user; + + cb(null, response); +}; +``` + +Please note: + +* The callback function (`cb`) at the end of the sample code signals completion and *must* be included. + +### Default response + +When you run a Hook executed at the Pre-User Registration extensibility point, the default response object is: + +```json +{ + "user": { + "tenant": "my-tenant", + "username": "user1", + "password": "xxxxxxx", + "email": "user1@foo.com", + "emailVerified": false, + "phoneNumber": "1-000-000-0000", + "phoneNumberVerified": false, + "user_metadata": { + "hobby": "surfing" + }, + "app_metadata": { + "plan": "full" + } + } +} +``` + +If you specify `app_metadata` and `user_metadata` in the response object, Auth0 adds this information to the new user. + +::: note +Metadata property names must not start with the `$` character or contain the `.` character. +::: + +::: note +Hooks executed at the Pre-User Registration extensibility point do not pass error messages to any Auth0 APIs. +::: + +### 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": { + "tenant": "my-tenant", + "username": "user1", + "password": "xxxxxxx", + "email": "user1@foo.com", + "emailVerified": false, + "phoneNumber": "1-000-000-0000", + "phoneNumberVerified": false, + "user_metadata": { + "hobby": "surfing" + }, + "app_metadata": { + "plan": "full" + } + }, + "context": { + "request": { + "language": "en-us", + "ip": "123.123.123.123" + }, + "connection": { + "id": "con_xxxxxxxxxxxxxxxx", + "name": "Username-Password-Authentication", + "tenant": "my-tenant" + } + } +} +``` + +## 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) { + var response = {}; + + response.user = { + user_metadata: { foo: 'bar' }, + app_metadata: { vip: true, score: 7 } + }; + + cb(null, response); +}; +``` + +### Response + +When we run this Hook, the response object is: + +```json +{ + "user": { + "user_metadata": { + "foo": "bar" + }, + "app_metadata": { + "vip": true, + "score": 7 + } + } +} +``` + +## 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 new file mode 100644 index 0000000000..ee230d7323 --- /dev/null +++ b/articles/hooks/index.md @@ -0,0 +1,46 @@ +--- +title: Hooks +description: Learn about Auth0 Hooks for Database Connections and Passwordless Connections. +topics: + - hooks + - extensibility-points +contentType: + - index + - concept +useCase: extensibility-hooks +--- +# Hooks + +<%= 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/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 e1aed8eb36..0000000000 --- a/articles/hosted-pages/custom-error-pages.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -description: How to setup a custom error page for authorization error events. ---- - -# 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. - -This document begins by covering the configuration options available to you via the Management Portal and ends with information on performing the same actions by making the appropriate calls to the Management API. If you choose to make updates via the Management API, you may use the APIv2 Explorer Page to make test calls and help generate the required HTTP PATCH call. - -## Customizing Error Pages via the Management Portal - -To get to the error page settings: - -1. Go to the top right-hand side of the Auth0 Management Portal -2. Click on your user name/icon -3. Choose "Account Settings" in the menu the pops open. - -![Account Settings](/media/articles/error-pages/account-settings.png) - -### The Auth0 Default Error Page - -You can choose to display to your users the default Auth0 error page. This page can be minimally customized with the following pieces of information (all fields optional): - -- Friendly Name: a user-friendly version of your company's name; -- Logo URL: the path to the logo you want to show to users; -- Support Email: the email address for your Support team; -- Support URL: the URL of your Support team's webpage. - -![Error Page Settings](/media/articles/error-pages/error-page-settings.png) - -### Customized Error Pages - -If you choose to display a custom error page, you have two options: - -- You may redirect the user to a custom error page; -- You may configure Auth0 to render a custom error page on your behalf (please note that this feature is only available via the Management API). - -#### Redirecting Users to a Custom Error Page - -To redirect users to a custom error page: - -1. On the Account Settings page, scroll down to the Error Pages section. -2. Select the option "redirect users to your own error page." -3. 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) - -## Customizing Error Pages via the Management API - -Instead of using the Management Portal, you may configure your error pages by making a `PATCH /api/v2/tenants/settings` call to the Management API. - -To assist you in creating the appropriate request, you may use the [Update Tenant Settings](/api/v2#!/Tenants/patch_settings) section of the [Management APIv2 Explorer Page](/api/v2). - -Prior to beginning, please ensure that you are logged in to an account that is permitted to make changes to your Auth0 configuration. This will allow the API Explorer to dynamically generate the required [API token](/api/v2/tokens) with the necessary API Key and Secret. - -### Making a Test Call or Generating the cURL Command via the API Explorer Page - -1. Under Scopes, click on "update:tenant_settings" to add the scope required for this particular endpoint to the [API token](/api/v2/tokens). -2. Populate the `body` field with the JSON snippet that contains the information that will be used to update your configuration. -3. Click on "TRY" to get a test response to your input. -4. If you are satisfied with the results of your test call to the API, click "get curl command" to get the constructed call. - -Sample cURL command: - -```text -curl -H "Authorization: Bearer YOUR_TOKEN" -X PATCH -H "Content-Type: application/json" -d '{REQUEST BODY}' https://${account.namespace}/api/v2/tenants/settings -``` - -To assist you in customizing the required JSON snippet that you would include as the `body` parameter, the "Show samples" link in the upper right corner of the API Explorer Window will display the following sample code: - -```json -{ - "error_page": { - "html": "", - "show_log_link": false, - "url": "https://www.example.com/error" - }, - "friendly_name": "Example Company", - "picture_url": "https://example.com/logo.png", - "support_email": "support@example.com", - "support_url": "https://example.com/support" -} -``` - -### The Auth0 Default Error Page - -Even if you choose to display the default Auth0 error page, you may customize the following fields: - -- Friendly Name: a user-friendly version of your company's name; -- Logo URL: the path to the logo you want to show to users; -- Support Email: the email address for your Support team; -- Support URL: the URL of your Support team's webpage. - -HTTP Request: - -```har -{ - "method": "PATCH", - "url": "https://${account.namespace}/api/v2/tenants/settings", - "httpVersion": "HTTP/1.1", - "cookies": [], - "headers": [ - { "name": "Authorization", "value": "Bearer YOUR_TOKEN" } - ], - "queryString" : [], - "postData" : { - "mimeType": "application/json", - "text": "{\"friendly_name\": \"My Company\", \"picture_url\": \"https://example.com/logo.png\", \"support_email\": \"support@example.com\", \"support_url\": \"https://example.com/support\"}}" - }, - "headersSize" : -1, - "bodySize" : -1, - "comment" : "" -} -``` - -### Customized Error Pages - -#### Redirecting 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. - -HTTP Request: - -```har -{ - "method": "PATCH", - "url": "https://${account.namespace}/api/v2/tenants/settings", - "httpVersion": "HTTP/1.1", - "cookies": [], - "headers": [ - { "name": "Authorization", "value": "Bearer YOUR_TOKEN" } - ], - "queryString" : [], - "postData": { - "mimeType": "application/json", - "text": "{\"error_page\": {\"html\": \"\", \"show_log_link\":false, \"url\": \"http://www.example.com\"}}" - }, - "headersSize" : -1, - "bodySize" : -1, - "comment" : "" -} -``` - -#### Rendering a Custom Error Page - -To provide the appropriate HTML, pass in a string containing the appropriate Liquid syntax to the "html" element: - -HTTP Request: - -```har -{ - "method": "PATCH", - "url": "https://login.auth0.com/api/v2/tenants/settings", - "httpVersion": "HTTP/1.1", - "cookies": [], - "headers": [ - { "name": "Authorization", "value": "Bearer YOUR_TOKEN" } - ], - "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 2b131b9afa..0000000000 --- a/articles/hosted-pages/error-pages.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -description: Guide on how to use the hosted error pages for authorization error events ---- - -# 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 instead to use the generic error page that Auth0 provides to alert the user of said errors. - -![Hosted Error Page](/media/articles/hosted-pages/error-pages.png) - -By going into the Account Settings 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. \ No newline at end of file diff --git a/articles/hosted-pages/guardian.md b/articles/hosted-pages/guardian.md deleted file mode 100644 index 9dc0902dea..0000000000 --- a/articles/hosted-pages/guardian.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -description: Guide on how to use the hosted Guardian MFA page ---- - -# Guardian Multifactor Login Page - -In your [Auth0 Dashboard](${manage_url}/#/guardian_mfa_page), you can enable your Hosted Guardian Multifactor Login Page by simply flipping the toggle switch. - -![Hosted Guardian MFA Page](/media/articles/hosted-pages/guardian.png) - -If you want to change some of the options in the Change Password Widget, you may do so _right on this page_, just make your changes and make sure to remember to hit the _Save_ button. The options have comments to help document their uses. - -The added protection of Guardian Multifactor Authentication is no small matter. It's quite customizable, allowing you to require MFA on logins which meet certain criteria, or just across the board. Take a look at our documentation on [Guardian MFA](/multifactor-authentication/guardian) for more details! - diff --git a/articles/hosted-pages/index.md b/articles/hosted-pages/index.md deleted file mode 100644 index bee91b4ca4..0000000000 --- a/articles/hosted-pages/index.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -description: Overview of hosted pages with Auth0, and how to use them ---- - -# How to Use Hosted Pages with Auth0 - -Auth0 provides you the ability to create beautiful hosted pages to which you can redirect to provide functionality for your users. These pages include [Login](/hosted-pages/login), [Password Reset](/hosted-pages/password-reset), [Guardian Multifactor](/hosted-pages/guardian), and [Error pages](/hosted-pages/error-pages). - -## Security Considerations - -Using Auth0 hosted pages for your authentication, rather than externally hosting them, provides seamless XSRF protection, preventing third party impersonation or hijacking of sessions. The use of hosted pages provides a significantly easier to implement, secure solution for authentication, allowing you to worry about other things, like the security of your application. - -## How to Customize Hosted Pages - -You can customize your hosted pages from within your [Auth0 Dashboard](${manage_url}). See the following pages for specific instructions about each type of hosted page: - -* [Login Page](/hosted-pages/login) -* [Password Reset Page](/hosted-pages/password-reset) -* [Guardian Multifactor Authentication Page](/hosted-pages/guardian) -* [Error Pages](/error-pages) - -## How to Use Version Control to Manage Your Hosted Pages - -It is possible to use version control software to manage the source code of the hosted pages discussed here. Auth0 provides extensions for the following tools which can be used to manage the source of your hosted pages: - -* [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) - -You should take a look at the documentation for the extension that you would like to use, to learn the details about implementing source control for your hosted pages with that specific extension. However, in general, deploying hosted pages with these tools will require just a few steps: - -1. Create a folder within your version control repository with the appropriate name (`pages`). -1. Create an HTML page (`login.html`, `password_reset.html`, `guardian_multifactor.html`, or `error_page.html`). -1. Create a JSON file (with the same name, but with the `.json` file extension) for each hosted page that you wish to source control. To enable the page, the JSON file would contain the following: - -```json -{ - "enabled": true -} -``` - -**File Naming Example:** -```text -your-repo/pages/error_page.html -your-repo/pages/error_page.json -``` \ No newline at end of file diff --git a/articles/hosted-pages/login.md b/articles/hosted-pages/login.md deleted file mode 100644 index f0385736ce..0000000000 --- a/articles/hosted-pages/login.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -description: Guide on how to use the hosted login page ---- - -# Hosted Login Page - -Auth0 hosts a login page that is shown whenever an authentication request is triggered, such as when using the `/authorize` endpoint (OIDC/OAuth) or when sending a SAML login request. - -This login page will be a basic login page for your client, and will use Lock to provide your users with a beautiful and smooth authentication process. The hosted login page is both one of your most secure authentication options as well as one of the easiest to implement. - -> Note that if the authentication request includes a specific connection, and that connection is for an external identity provider, the hosted login page might not be displayed and the user will be directed to the identity provider's login page. - -## Custom Hosted Login Page - -In your [Auth0 Dashboard](${manage_url}/#/login_page), you can enable a custom Hosted Login Page by simply flipping the toggle switch, that allows you to customize the look and feel and behavior of the Hosted Login Page. - -![Hosted Login Page](/media/articles/hosted-pages/login.png) - -If you want to change some of the [configuration options](/libraries/lock/v10/customization) within Lock, you may do so _right on this page_, just make your changes and make sure to remember to hit the _Save_ button. - -Auth0 provides a whole set of configuration values in the `@@config@@` string that you can decode and use to adjust the hosted login page behavior: - -```javascript -// Decode configuration options -var config = JSON.parse(decodeURIComponent(escape(window.atob('@@config@@')))); - -// now use the config object to tailor the behavior of the hosted login page -... -``` - -Take a look at the default custom login page code to get a glimpse of the available configuration options. diff --git a/articles/hosted-pages/login/index.md b/articles/hosted-pages/login/index.md new file mode 100644 index 0000000000..91c88f8d46 --- /dev/null +++ b/articles/hosted-pages/login/index.md @@ -0,0 +1,134 @@ +--- +title: Universal Login +description: How to use Universal Login +toc: true +crews: crew-2 +--- +# Universal Login + +## 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. + +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. + +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. + +::: warning +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) + +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 (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 +For more details about how SSO works, see the [SSO documentation](/sso). +::: + +### Why Use Universal Login + +Why use universal login rather than embedding your login functionality within your application? + +Security is the primary reason, followed by ease of setup. Cross-origin authentication is inherently more dangerous, and more likely to be vulnerable to [man-in-the-middle attacks](/security/common-threats#man-in-the-middle-mitm-attacks). Using universal login for the authentication process with Auth0 prevents that from ever being a concern. Additionally, universal login is very easy to implement, especially if a custom UI is not required in your login page. + +### What Universal Login is Not Intended For + +An important thing to remember is that the login page is intended to be only for signups and authentication. Attempting to host any significant amount of application logic in the login page is not advised. + +The login page is truly a single page constructed within the editor, so all custom styling and includes will need to be put into the single editor window. Hosting other files or images along with the login page is not possible, so those will need to be hosted in the application itself, or elsewhere. + +### Passwordless on Native Platforms + +Currently, universal login is the **only** way to use [Passwordless](/connections/passwordless) authentication on Native platforms. So if your use case is a native iOS or Android application, for example, and you intend to implement Passwordless, you will need to use the universal login. + +## How to Customize Your Login Page + +### 1. Enable Customization on the Login Page + +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) + +### 2. Choose a Technology + +In order to get started customizing the login page, you'll first want to choose the technology that you'd like to use to power it. Click one of the links below to get started. + +- [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. + +### 3. Customization + +You can customize the login page at will right from the editor. If you use Lock, you can alter its behavior and appearance with [configuration options](/libraries/lock/configuration). If you are building a custom UI, you can style the login page to your own specifications. + +All changes to the page's appearance and/or behavior will apply to **all** users shown this login page, regardless of the application or connection. Remember that the login page customizations are per **tenant** rather than per application. When necessary, you can provide different pages to different applications via a method discussed later in this document. + +#### 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 [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: + +```js +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. + +##### Callback URL + +Once authentication has been performed using universal login, your user will then be redirected to the default callback URL set in your [Application's settings page](${manage_url}/#/applications/${account.clientId}/settings). You can also pass a specific `redirect_uri` option to `authorize`, and access it within the login page editor by referring to `config.callbackURL`. + +::: note +Make sure that you've added any redirect URLs you're using to the **Allowed Redirect URLs** field on the [Application's settings page](${manage_url}/#/applications/${account.clientId}/settings). +::: + +```js +webAuth.authorize({ + redirect_uri: "http://example.com/foo" +}); +``` + +## 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 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 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 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 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. +- Create a third tenant, configure a new application for `app5`, and configure the login page for this application. + +To create a new tenant go to the [Dashboard](${manage_url}), and using the top right menu, click on the __New Account__ option. + +![Create new tenant](/media/articles/hosted-pages/create-new-tenant.png) + +You can easily switch between tenants using the top right menu on the [Dashboard](${manage_url}). You can also [configure different administrators for each](/tutorials/manage-dashboard-admins). + +## Incorrect Implementations of the Login Page + +The login page should not be implemented by calling its URL directly. This circumvents the Universal Login approach, does not allow for SSO (as the correct endpoint is not hit), and is not supported. Note that this also applies to users who bookmark the login page itself. diff --git a/articles/hosted-pages/password-reset.md b/articles/hosted-pages/password-reset.md deleted file mode 100644 index 0df4b00d06..0000000000 --- a/articles/hosted-pages/password-reset.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -description: Guide on how to use the hosted password reset page ---- - -# Password Reset Page - -In your [Auth0 Dashboard](${manage_url}/#/password_reset), you can enable your Hosted Password Reset Page by simply flipping the toggle switch. - -![Hosted Password Reset Page](/media/articles/hosted-pages/password-reset.png) - -If you want to change some of the options in the Change Password Widget, you may do so _right on this page_, just make your changes and make sure to remember to hit the "save" button. The options have comments to help document their uses. - -Using this page for password resets will allow your users to maintain consistency in appearance. From the login page, users will simply be able to click the forgot password link, see this easy to use widget, and send themselves a link to begin the password reset process. - diff --git a/articles/i18n/i18n-custom-login-page.md b/articles/i18n/i18n-custom-login-page.md deleted file mode 100644 index 255715ed46..0000000000 --- a/articles/i18n/i18n-custom-login-page.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -description: Instruction on how to display the login page using the user's browser preferred language. ---- - -## Internationalize (i18n) the default login page - -Below you will find instruction on how to display the login page using the user's browser preferred language: - -1) Turn on the "Customize Login Page" toggle in Login Page section of your auth0 dashboard. - -![](/media/articles/i18n/i18n-custom-login-page/i18n-custom-login-page-1.png) - -2) In your login page HTML, inside the script tag add following JavsScript snippet (before you initialize Lock) to detect browser language: - -```js -// getFirstBrowserLanguage taken -// from http://stackoverflow.com/questions/1043339/javascript-for-detecting-browser-language-preference - -var getFirstBrowserLanguage = function () { - var nav = window.navigator, - browserLanguagePropertyKeys = ['language', 'browserLanguage', 'systemLanguage', 'userLanguage'], - i, - language; - - // support for HTML 5.1 "navigator.languages" - if (Array.isArray(nav.languages)) { - for (i = 0; i < nav.languages.length; i++) { - language = nav.languages[i]; - if (language && language.length) { - return language; - } - } - } - - // support for other well known properties in browsers - for (i = 0; i < browserLanguagePropertyKeys.length; i++) { - language = nav[browserLanguagePropertyKeys[i]]; - if (language && language.length) { - return language; - } - } - - return null; -}; - -var language = getFirstBrowserLanguage(); -``` - -3) Now, if not `undefined` or `null`, pass language variable to the `dict` option while showing Lock like below: - - -```js -lock.show({ - // icon: '{YOUR_LOGO_URL}', - callbackURL: config.callbackURL, - responseType: config.callbackOnLocationHash ? 'token' : 'code', - dict: language || config.dict, - connections: connection ? [connection] : null, - rememberLastLogin: !prompt, - container: 'widget-container', - authParams: config.internalOptions -}); -``` - -Test it customization by setting desired/preferred language in the browser Content setting as below: - -![](/media/articles/i18n/i18n-custom-login-page/i18n-custom-login-page-2.png) - -View `Login Page` by clicking on Preview tab under `Customize Login Page` toggle: - -![](/media/articles/i18n/i18n-custom-login-page/i18n-custom-login-page-3.png) \ No newline at end of file diff --git a/articles/i18n/i18n-guide-android.md b/articles/i18n/i18n-guide-android.md index 19ae298f91..c415958ffe 100644 --- a/articles/i18n/i18n-guide-android.md +++ b/articles/i18n/i18n-guide-android.md @@ -1,8 +1,12 @@ --- 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 +# Android guide to i18n Follow the official [Android documentation](http://developer.android.com/guide/topics/resources/localization.html) on how to localize. It will cover setting up locale resources in an Android development environment. The Auth0 key value pairs that can be localized are found [here](https://github.com/auth0/Auth0.Android/blob/master/auth0/src/main/res/values/strings.xml). diff --git a/articles/i18n/i18n-guide-ios.md b/articles/i18n/i18n-guide-ios.md index 7c5166f391..d691be0649 100644 --- a/articles/i18n/i18n-guide-ios.md +++ b/articles/i18n/i18n-guide-ios.md @@ -1,18 +1,22 @@ --- description: This page is themguide to internationalizing an iOS application. +topics: + - i18n + - ios +contentType: how-to +useCase: localize --- - -## iOS guide to i18n +# iOS guide to i18n Here are the instructions to internationalize your iOS application. Please follow the steps below: -1) Add a file named `Lock.strings`, which is the format for i18n in iOS, included in the bundle of the app when is built. The easier way to do it is using Xcode, just go to `File -> New File`, then `iOS -> Strings File`. The name will be Auth0 and make sure it's added to your application target by checking the box. +1. Add a file named `Lock.strings`, which is the format for i18n in iOS, included in the bundle of the app when is built. The easier way to do it is using Xcode, just go to `File -> New File`, then `iOS -> Strings File`. The name will be Auth0 and make sure it's added to your application target by checking the box. ![](/media/articles/i18n/i18n-guide-mobile/i18n-guide-mobile-1.png) ![](/media/articles/i18n/i18n-guide-mobile/i18n-guide-mobile-2.png) -2) Then the file contents should be something like this: +2. Then the file contents should be something like this: ``` "Email" = "Email"; @@ -22,12 +26,10 @@ Here are the instructions to internationalize your iOS application. Please follo Where the key is the text you see in screen and the value is the translation. -3) To have multiple languages you'll need to add them in your project settings: +3. To have multiple languages you'll need to add them in your project settings: ![](/media/articles/i18n/i18n-guide-mobile/i18n-guide-mobile-1.png) -4) Then you will see different files per language you can customize: +4. Then you will see different files per language you can customize: ![](/media/articles/i18n/i18n-guide-mobile/i18n-guide-mobile-3.png) - - diff --git a/articles/i18n/index.md b/articles/i18n/index.md index 15c06d0bd7..924045f31e 100644 --- a/articles/i18n/index.md +++ b/articles/i18n/index.md @@ -1,16 +1,18 @@ --- url: /i18n description: Links to documentation on internationalizing an application. +topics: + - i18n +contentType: index +useCase: localize --- - -## Internationalization and Multilingual settings +# 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) -- [Internationalize (i18n) the default login page](/i18n/i18n-custom-login-page) - [iOS guide to i18n](/i18n/i18n-guide-ios) -- [Android guide to i18n](/i18n/i18n-guide-android) - +- [Android guide to i18n](/i18n/i18n-guide-android) \ No newline at end of file diff --git a/articles/i18n/password-options.md b/articles/i18n/password-options.md index eb5f908dba..f1bbff1601 100644 --- a/articles/i18n/password-options.md +++ b/articles/i18n/password-options.md @@ -1,8 +1,13 @@ --- description: How to customize the translation of Lock password features. +topics: + - i18n + - lock + - password +contentType: how-to +useCase: localize --- - -## Password Options Translation +# Password Options Translation You can customize the translation of the following Lock password features in your own code: @@ -16,19 +21,20 @@ To customize any of these features, you must include version 1.1 or higher of th To translate the text of each of the Lock password features, include the following code, replacing all strings with text in the desired language: + ### Password Strength ```js dict: { passwordStrength: { containsAtLeast: "Contain at least %d of the following %d types of characters:", - identicalChars: "No more than %d identical characters in a row (e.g., \"%s\" not allowed)", + identicalChars: "No more than %d identical characters in a row (such as, \"%s\" not allowed)", nonEmpty: "Non-empty password required", - numbers: "Numbers (i.e. 0-9)", + numbers: "Numbers (such as 0-9)", lengthAtLeast: "At least %d characters in length", lowerCase: "Lower case letters (a-z)", shouldContain: "Should contain:", - specialCharacters: "Special characters (e.g. !@#$%^&*)", + specialCharacters: "Special characters (such as !@#$%^&*)", upperCase: "Upper case letters (A-Z)" } } @@ -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/_template.md b/articles/integrations/_template.md deleted file mode 100644 index 2103411649..0000000000 --- a/articles/integrations/_template.md +++ /dev/null @@ -1,23 +0,0 @@ -## ${meta.title} integration - -In this tutorial, you will learn how to add Single Sign On (SSO) to ${meta.title} using Auth0. Your users will be able to log in using any of our [Social Identity Providers](/identityproviders#social) (Facebook, Twitter, Github, etc.), [Enterprise Identity Providers](/identityproviders#enterprise) (LDAP, Active Directory, ADFS, etc.) or with a username and password. - -### 1. Create a new application - -Navigate to the [SSO Integrations](${manage_url}/#/externalapps/create) section of the dashboard and choose ${meta.title} from the list of apps: - -![](/media/articles/integrations/third-party-apps/create.png) - -### 2. Name your app and click **Save**: - -![](/media/articles/integrations/third-party-apps/save.png) - -### 3. Follow the live documentation - -Now you will be directed to a tutorial for this integration containing information customized for your account. You may need to enter information from ${meta.title}. Simply follow each of the steps as shown: - -![](/media/articles/integrations/third-party-apps/${image1}) - -### 4. Configuration complete - -You have successfully configured ${meta.title} to use Auth0 as the SSO broker. diff --git a/articles/integrations/ad-rms.md b/articles/integrations/ad-rms.md deleted file mode 100644 index 7aa0bee2ff..0000000000 --- a/articles/integrations/ad-rms.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: AD RMS -description: How to add Single Sign On (SSO) integration with AD RMS. ---- -<%= include('./_template', { - image1: "tutorial-adrms.png" -}) %> 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 new file mode 100644 index 0000000000..98fa54a29c --- /dev/null +++ b/articles/integrations/authenticating-a-tessel-device.md @@ -0,0 +1,137 @@ +--- +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 + +[Tessel](https://tessel.io) is an amazing board. Not only it has a great hardware spec and a great extensibility story, you can program it in Javascript! When it was announced on Kickstarter we immediately supported it and waited long weeks to get hold of one. + +![](/media/articles/scenarios/tessel/TM-00-04-ports.png) + +It finally arrived and were able to write our first program: get a token from Auth0 and call an API. + +::: note +Tessel aims for full compatibility with Javascript. Most of core node modules also work, but not all of them. See [the docs for full details](https://github.com/tessel/docs/blob/master/compatibility.md). +::: + +## The sample + +This example is straight-forward: + +1. We call the `Resource Owner` endpoint on Auth0 with device credentials +1. Get a token back +1. We use the token to call an API + +![](/media/articles/scenarios/tessel/tessel-flow.png) + +```js +var http = require('https'); +var tessel = require('tessel'); + +tessel.syncClock(function () { + + var device_id = 'tessel-01'; + var password = 'THE TESSEL PASSWORD'; + + authenticate(device_id, password, function(e,token){ + + if(e) return console.log("Error:" + e); + + getDeviceProfile(token.access_token, function(e, profile){ + console.log("Device profile:"); + console.log(profile); + }); + }); + + function getDeviceProfile(token, done){ + request('${account.namespace}', + '/userinfo', + 'GET', + { + "Content-type": "application/json", + "Authorization": "Bearer " + token + }, + null, + function(e,response){ + if(e) return done(e); + done(null, JSON.parse(response)); + }); + } + + function authenticate(device_id, password, done) + { + request('${account.namespace}', + '/oauth/ro', + 'POST', + { + "Content-type": "application/json", + }, + JSON.stringify({ + client_id: '${account.clientId}', + username: device_id, + password: password, + connection: 'devices', + grant_type: "password", + scope: 'openid' + }), + function(e,response){ + if(e) return done(e); + done(null, JSON.parse(response)); + }); + } + + function request(host, path, method, headers, body, done){ + var options = { + hostname: host, + path: path, + method: method, + headers: headers + }; + + var req = http.request(options, function(res) { + res.setEncoding('utf8'); + + var response = ""; + + res.on('data', function (chunk) { + response += chunk; + }); + + res.on('end', function(){ + done(null, response); + }); + }); + + req.on('error', function(e) { + done(e); + }); + + if( body ) req.write(body); + req.end(); + } +}); +``` + +Noteworthy highlights of the code: + +1. This is 99% compatible with node (the only device specific module.is `tessel` that we only use to make sure all SSL calls happen with adequate time references. +1. The `request` function, is a simple wrapper on `http` module functions. The `request` module doesn't currently work in Tessel. + +The `Resource Owner` endpoint requires credentials (such as username/password), so the backend user store connected to Auth0 needs to support this (like a Database connection or Active Directory). + +## Tessel Setup + +* Run `tessel update` to make sure you install the latest firmware with SSL support. +* You will obviously need connection to the web. You can setup WiFi with the `tessel wifi` command. + +## Summary + +Tessel is awesome. We see a lot of potential. This sample shows how easy it is to connect it with Auth0. + +::: warning +Always send credentials (such as `username`/`password`) over secured networks. +::: \ No newline at end of file diff --git a/articles/integrations/authenticating-devices-using-mqtt.md b/articles/integrations/authenticating-devices-using-mqtt.md new file mode 100644 index 0000000000..4484950046 --- /dev/null +++ b/articles/integrations/authenticating-devices-using-mqtt.md @@ -0,0 +1,262 @@ +--- +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 + +[MQTT](http://en.wikipedia.org/wiki/MQ_Telemetry_Transport) is a lightweight protocol often used for devices to communicate with other systems. It is designed for the __publish/subscribe__ messaging pattern. + +Generally speaking there are 3 components: + +1. A `publisher` of messages. +2. A `subscriber` to messages. +3. A `broker` that connects one and the other. + +There's a notion of `topics` (a.k.a. as `channels` or `subjects`) which messages are associated with. Topics are used to route messages between publishers and subscribers. + +The MQTT protocol supports a basic authentication mechanism based on `usernames` & `passwords`. These credentials are sent with the `CONNECT` message. + +This article shows an integration between nodejs based MQTT broker: [mosca](https://github.com/mcollina/mosca) and [Auth0](http://auth0.com). In this example, Auth0 is used to __authenticate__ `publishers` and `subscribers` to the broker, and then __authorize__ routing of messages. + +::: note +mosca is a nodejs based messaging broker that implements other protocols besides MQTT. It offers great extensibility features. It is surprisingly simple to integrate with Auth0. +::: + +![](/media/articles/scenarios/mqtt/mqtt-dataflow.png) + +## Components of the solution + +### The Broker + +__mosca__ is straightforward to host and can be embedded in other servers. For the purpose of this sample, we simply self-host a __mosca__ server: + + +```js +var mosca = require('mosca') +var Auth0Mosca = require('auth0mosca'); + +var settings = { + port: 9999, +}; + +//'Thermostats' is a Database connection where all devices are registered. +var auth0 = new Auth0Mosca('https://eugeniop.auth0.com', '{Your Auth0 ClientID}', '{Your Auth0 Client Secret}','Thermostats'); + +//Setup the Mosca server +var server = new mosca.Server(settings); + +//Wire up authentication & authorization to mosca +server.authenticate = auth0.authenticateWithCredentials(); +server.authorizePublish = auth0.authorizePublish(); +server.authorizeSubscribe = auth0.authorizeSubscribe(); + +server.on('ready', setup); + +// Fired when the mqtt server is ready +function setup() { + console.log('Mosca server is up and running'); +} + +server.on('clientConnected', function(client) { + console.log('New connection: ', client.id ); +}); +``` + +This creates a server listening for MQTT messages on port 9999. __mosca__ allows you to override the 3 functions used to authenticate and authorize operations. + +In this sample, we are using a very simple module `auth0mosca` to perform these functions. Auth0 is wired up to __mosca__. + +### The Auth0Mosca module + +This little [module](https://www.npmjs.org/package/auth0mosca) provides the 4 functions used by __mosca__, `authenticateWithCredentials`, `authenticateWithJWT`, `authorizePublish` and `authorizeSubscribe`: + +```js +var request = require('request'); +var jwt = require('jsonwebtoken'); + +function Auth0Mosca(auth0Namespace, clientId, clientSecret, connection) +{ + this.auth0Namespace = auth0Namespace; + this.connection = connection; + this.clientId = clientId; + this.clientSecret = clientSecret; +} + +Auth0Mosca.prototype.authenticateWithJWT = function(){ + + var self = this; + + return function(client, username, password, callback) { + + if( username !== 'JWT' ) { return callback("Invalid Credentials", false); } + + // console.log('Password:'+password); + + jwt.verify(password, self.clientSecret, function(err,profile){ + if( err ) { return callback("Error getting UserInfo", false); } + console.log("Authenticated client " + profile.user_id); + console.log(profile.topics); + client.deviceProfile = profile; + return callback(null, true); + }); + } +} + +Auth0Mosca.prototype.authenticateWithCredentials = function(){ + + var self = this; + + return function(client, username, password, callback) { + + var data = { + client_id: self.clientId, // {client-name} + username: username.toString(), + password: password.toString(), + connection: self.connection, + grant_type: "password", + scope: 'openid name email' //Details: https:///scopes + }; + + request.post({ + headers: { + "Content-type": "application/json" + }, + url: self.auth0Namespace + '/oauth/ro', + body: JSON.stringify(data) + }, function(e,r,b){ + if(e){ + console.log('Error in Authentication'); + return callback(e,false); + } + var r = JSON.parse(b); + + if( r.error ) { return callback( r, false); } + + jwt.verify(r.id_token, self.clientSecret, function(err,profile){ + if( err ) { return callback("Error getting UserInfo", false); } + client.deviceProfile = profile; + return callback(null, true); + }); + }); + } +} + +Auth0Mosca.prototype.authorizePublish = function() { + return function (client, topic, payload, callback) { + callback(null, client.deviceProfile && client.deviceProfile.topics && client.deviceProfile.topics.indexOf(topic) > -1); + } +} + +Auth0Mosca.prototype.authorizeSubscribe = function() { + return function(client, topic, callback) { + callback(null, client.deviceProfile && client.deviceProfile.topics && client.deviceProfile.topics.indexOf(topic) > -1); +} + +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 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: + +![](/media/articles/scenarios/mqtt/7JNZP.png) + +Notice that the Device Profile also has a property `topics`. This is an array with all topics this particular device is allowed to. In the screenshot above, `thermostat-1a` will be allowed publishing (or subscribing) to topics `temperature` and `config`. + +The `authorizePublish` and `authorizeSubscribe` functions simply check that a particular requested topic is present in this list. + +The `authenticateWithJWT` expects a JWT in the `password` field. The flow in this case is slightly different: + +1. The publisher & subscriber will obtain a token +1. They connect to `mosca` submitting the JWT +1. `mosca` validates the JWT +1. Messages are sent and re-transmitted to subscribers + +![](/media/articles/scenarios/mqtt/mqtt-dataflow2.png) + +Publishers and subscribers will obtain the JWT through some means. Notice that the broker doesn't need to communicate with Auth0 anymore. JWTs are self-contained artifacts that can be validated with the secret used to sign them. + +### The Publisher + +For this sample, the publisher is a simple nodejs program that uses the `mqtt` module, and adds the right credentials: + +```js +var mqtt = require('mqtt') + , host = 'localhost' + , port = '9999'; + +var settings = { + keepalive: 1000, + protocolId: 'MQIsdp', + protocolVersion: 3, + clientId: 'Thermostat 1a', + username:'thermostat-1a', + password:'the password' +} + +// client connection +var client = mqtt.createClient(port, host, settings); + +setInterval(sendTemperature, 2000, client); + +function sendTemperature(client){ + var t = { + T: Math.random() * 100, + Units: "C" + }; + + client.publish('temperature', JSON.stringify(t)); +} +``` + +Of course `username` & `password` here will have to match whatever is stored in Auth0. + +### The subscriber +The subscriber is very similar to the publisher: + +```js +var mqtt = require('mqtt') + , host = 'localhost' + , port = '9999'; + +var settings = { + keepalive: 1000, + protocolId: 'MQIsdp', + protocolVersion: 3, + clientId: 'Reader-X1', + username:'reader-X1', + password:'the password' +} + +// client connection +var client = mqtt.createClient(port, host, settings); + + +client.subscribe('temperature'); + +client.on('message', function(topic, message) { + + if(topic ==='temperature') + { + console.log('New reading', message); + } +}); +``` + +## Summary + +This shows how easy it is to use Auth0 in various scenarios. Auth0's user store is being used to manage devices. Of course much more sophisticated authorization rules could be written based on other conditions: time, location, device_id, and so on All these would be very simple to implement, either through additional profile attributes or through [Auth0 Rules](/rules). This also shows how the flexible Auth0 Profile can be extended to support arbitrary artifacts (such as `topics` in the example). + +::: note +Ιt is never a good idea to send credentials (`username`/`password`) over unsecured networks. There are other implementations that provide transport level security that would prevent message contents to be revealed. __mosca__ supports TLS as an example. Likely a production deployment would favor this, unless all traffic happens in a closed network. +::: + +### Acknowledgements + +Many thanks to [Matteo Collina](http://www.matteocollina.com/) for the review of this article, and for building the awesome __mosca__. 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/_stepnav.html b/articles/integrations/aws-api-gateway/custom-authorizers/_stepnav.html new file mode 100644 index 0000000000..8e021cac76 --- /dev/null +++ b/articles/integrations/aws-api-gateway/custom-authorizers/_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/articles/integrations/aws-api-gateway/custom-authorizers/index.md b/articles/integrations/aws-api-gateway/custom-authorizers/index.md new file mode 100644 index 0000000000..cfa8e782f6 --- /dev/null +++ b/articles/integrations/aws-api-gateway/custom-authorizers/index.md @@ -0,0 +1,70 @@ +--- +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/) 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. + +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](/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). +::: + +To that end, this tutorial will be divided into the following sections. + +* [Step 1 - Configure Auth0](/integrations/aws-api-gateway/part-1) +* [Step 2 - Set up and Deploy the AWS API Gateway](/integrations/aws-api-gateway/part-2) +* [Step 3 - Create the Custom Authorizers](/integrations/aws-api-gateway/part-3) +* [Step 4 - Secure the API Using Custom Authorizers](/integrations/aws-api-gateway/part-4) + +## 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." + +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](/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). + +## Before You Begin + +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. + +<%= include('./_aws-dev-guide-link') %> + +## Next steps + +* [API Authorization](/api-auth) +* [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"] +}) %> \ No newline at end of file diff --git a/articles/integrations/aws-api-gateway/custom-authorizers/part-1.md b/articles/integrations/aws-api-gateway/custom-authorizers/part-1.md new file mode 100644 index 0000000000..2c6c36ed24 --- /dev/null +++ b/articles/integrations/aws-api-gateway/custom-authorizers/part-1.md @@ -0,0 +1,41 @@ +--- +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 + +You will need to configure the APIs consumed by the applications that successfully authorize. You can do so using the [APIs section of the Management Dashboard](${manage_url}/#/apis). + +Click **Create API** to create a new API for your integration. + +![](/media/articles/integrations/aws-api-gateway-2/api-1.png) + +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. To learn more, see [Signing Algorithms](/tokens/concepts/signing-algorithms). | + +Click **Create** to proceed. + +![](/media/articles/integrations/aws-api-gateway-2/api-2.png) + +You can refer to the **Settings** page for the details of your newly-created API. + +![](/media/articles/integrations/aws-api-gateway-2/api-3.png) + +Creating an API also creates a Machine to Machine Application for use with the API. You can see this application listed as **Authorized** under the **Machine to Machine Application** tab. Additionally, you might want to make note of the Client ID, since you will need it in [Part 3](/integrations/aws-api-gateway/custom-authorizers/part-3) of this tutorial. + +<%= include('./_stepnav', { + prev: ["Introduction", "/integrations/aws-api-gateway/custom-authorizers"], + next: ["Import and Deploy the API Gateway API", "/integrations/aws-api-gateway/custom-authorizers/part-2"] +}) %> \ No newline at end of file diff --git a/articles/integrations/aws-api-gateway/custom-authorizers/part-2.md b/articles/integrations/aws-api-gateway/custom-authorizers/part-2.md new file mode 100644 index 0000000000..115172a1dd --- /dev/null +++ b/articles/integrations/aws-api-gateway/custom-authorizers/part-2.md @@ -0,0 +1,150 @@ +--- +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 + +::: warning +This portion of the tutorial has been adapted from the [official AWS example](http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-create-api-from-example.html). Please refer to this example for in-depth notes and discussion. +::: + +In this part of the AWS API Gateway tutorial, we will show you how to import and manage an API using API Gateway. More specifically, we will: + +* Import an API into API Gateway +* Test an API import +* Deploy an API for use with any front-end applications +* Test an API deployment + +In later parts of this tutorial, we will show how to secure the endpoints of this API using custom authorizers that accept Auth0 Access Tokens, as well as how we can integrate this API with our front-end JavaScript application. + +## Import and Configure the Pets API + +Log in to your AWS account, and using the **Services** drop down located in the top navigation bar, go to the **API Gateway** Console. + +::: note +If you've previously created an API, simply navigate to the API Gateway Console and click **Create API**. You'll be given the option to create the **Example API** on the **Create new API** form. +::: + +If you've never created an API using API Gateway, you'll see the following screen. Click **Get Started** to proceed. + +![](/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-1.png) + +You'll see a pop-up message welcoming you to API Gateway. Click **OK** to proceed. + +![](/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-3.png) + +On the **Create new API** form, you'll see that **Example API** is selected by default, and there's an example API defined in the editor. We'll use this API for the rest of our tutorial, so begin the API creation process by clicking **Import**. + +![](/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-4.png) + +When done, AWS will display a message indicating that your API created and populated with the provided data. + +![](/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5.png) + +Notice that the API already has methods associated with it (namely, `GET` and `POST`). You can view the details of a method, modify its setup, or test the method invocation by clicking the method name from the resource tree. + +![](/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5a.png) + +### Test Your API + +Now that you've successfully imported your API, let's run some tests to ensure that everything works as expected. This exercise will also demonstrate some of the features of the API itself. + +As an example, click **POST** under `/pets`. This brings up the **Method Execution** window that provides an overview of the `POST` method's structure and behaviors: + +* **Method Request** and **Method Response**: the API's interface with the front-end +* **Integration Request** and **Integration Response**: the API's interface with the back-end + +We can use this area to test the API we've created. + +Click **Test** (shown on the **Application** sliver located in the middle of the page). + +![](/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5b.png) + +You'll be redirected to the `/pets - POST - Method Test` page. + +![](/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5c.png) + +Scroll to the bottom of the page, and provide the following snippet as the **Request Body**: + +```json +{"type": "dog", "price": 249.99} +``` + +The request body indicates the attributes of the pet we want to add to the database, as well as the cost for the pet. + +![](/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5d.png) + +Click **Test** to proceed. + +You'll see the results of the test at the right side of the page. + +![](/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5e.png) + +## Deploy the API + +The test we just completed was done using the API Gateway console. To use the API with a different application, you'll need to deploy the API to a stage. You can do this via the **Actions** menu, which offers the **Deploy API** option. + +You'll be asked to provide the following values: + +| **Parameter** | **Value** | +| - | - | +| **Deployment stage** | Choose `[New Stage]` | +| **Stage name** | Provide a name for your stage | +| **Stage description** | Provide a description for your stage | +| **Deployment description** | Provide a description for your API deployment | + +Once you've provided the appropriate values, click **Deploy** to proceed. + +![](/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-6.png) + +### Test the Deployment + +When the API has successfully deployed, you'll be redirected to the **Test Stage Editor**. You can, at this point, test the API to see if it deployed correctly. + +At the top of the **Test Stage Editor** window is a blue banner with your **Invoke URL**. This is the URL used to invoke the `GET` endpoint of your API. + +![](/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-7.png) + +Click on the link to submit the `GET / method` request in a browser. This should result in the following success response: + +![](/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**. Click **GET** under `/pets/{petId}`. + +![](/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-9.png) + +You'll see an **Invoke URL** displayed in the blue banner at the top of the window. The final portion, `{petID}`, stands for a path variable. Replace this variable with `1`, and navigate to the new URL using your browser. You should receive an HTTP 200 request with the following JSON payload: + +```json +{ + "id": 1, + "type": "dog", + "price": 249.99 +} +``` + +![](/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-10.png) + +## Summary + +In Part 2 of the AWS API Gateway tutorial, we covered how to: + +* Import an API into API Gateway +* Test an API import +* Deploy an API for use with any front-end applications +* Test an API deployment + +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"] +}) %> diff --git a/articles/integrations/aws-api-gateway/custom-authorizers/part-3.md b/articles/integrations/aws-api-gateway/custom-authorizers/part-3.md new file mode 100644 index 0000000000..0e2584b436 --- /dev/null +++ b/articles/integrations/aws-api-gateway/custom-authorizers/part-3.md @@ -0,0 +1,217 @@ +--- +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: + +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. +3. If the authorization token is valid, the custom authorizer returns the appropriate AWS Identity and Access Management (IAM) policies. +4. API Gateway uses the policies returned in step 3 to authorize the request. + +## Prepare the Custom Authorizer + +You can [download a sample custom authorizer](https://github.com/auth0-samples/jwt-rsa-aws-custom-authorizer) that supports Auth0-issued tokens. Afterward, you'll need to customize the files so that the custom authorizer works for your environment. + +1. Unzip the folder containing the sample files you downloaded above to the location of your choice, and navigate to the folder using the command line. + +2. Within the sample folder, run `npm install` to install the Node.js packages required for deployment; AWS requires that these files be included in the bundle you will upload to AWS during a later step. + +3. Configure your local environment with a `.env` file. You can copy the `.env.sample` file (while simultaneously renaming it `.env`) using `cp .env.sample .env`. Make the following changes: + +| **Parameter** | **Value** | +| - | - | +| **`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 **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=https://your-api-gateway +TOKEN_ISSUER=https://${account.namespace}/ +``` + +4. Test the custom authorizer locally. + +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 [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. + +To get the `methodArn`: + +1. Using the API Gateway Console, open the **PetStore** API. +2. Click **Resources** in the left-hand navigation panel. +3. In the middle **Resources** panel, expand the resource tree. Underneath `/pets`, click **GET**. +4. In the **Method Request** box, you'll see the **ARN**. + +c. Run the test using `npm test`. The test uses the [lambda-local](https://www.npmjs.com/package/lambda-local) package to test the custom authorizer using your token. If the test was successful, you'll see output similar to the following: + +```text +Message +------ +{ + "principalId": "C8npTEMVnBrILsBTI91MOh6dfuZbPVAU@clients", + "policyDocument": { + "Version": "2012-10-17", + "Statement": [ + { + "Action": "execute-api:Invoke", + "Effect": "Allow", + "Resource": "arn:aws:execute-api:us-east-1:1234567890:apiId/stage/method/resourcePath" + } + ] + }, + "context": { + "scope": "FULL_LIST_OF_SCOPES" + } +} +``` + +If the value of `Effect` is `Allow`, your authorizer would've allowed the call to API Gateway. + +## Create the IAM Role + +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**. +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. +7. On the **Summary** page for the role you've just created, click on to the **Trust relationships** tab. +8. Click **Edit trust relationship**, and populate the **Policy Document** field with the following JSON snippet: + + ```json + { + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Principal": { + "Service": [ + "apigateway.amazonaws.com", + "lambda.amazonaws.com" + ] + }, + "Action": "sts:AssumeRole" + } + ] + } + ``` + + ![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-9.png) + + Click **Update Trust Policy**. + +9. You'll be redirected back to the **Summary** page. Copy down the **Role ARN** value for later use. + +![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-10.png) + +## Create the Lambda Function and Deploy the Custom Authorizer + +Now that you've configured your custom authorizer for your environment and tested it to see it works, you'll deploy it to AWS. + +1. First, you'll need to create a bundle that you can upload to AWS by running `npm run bundle`. This generates a `custom-authorizer.zip` bundle containing the source, configuration, and node modules required by AWS Lambda. + +2. Navigate to the [Lambda console](https://console.aws.amazon.com/lambda), and click **Create function**. + +![](/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. 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 10.x` | + +![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-12.png) + +4. Click **Create Function** to continue. + +![](/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 **identifier** value of the API you created in [part 1](/integrations/aws-api-gateway/custom-authorizers/part-1) | + +9. In the **Execution role** section, select **Use an existing role** then select the IAM role you created previously as the **Existing role**. + +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) + +## Configure API Gateway Custom Authorizer + +Return to API Gateway Console. + +![](/media/articles/integrations/aws-api-gateway-2/part-2/pt2-21.png) + +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** and select **Create New Authorizer** then set the following parameters: + +| **Parameter** | **Value** | +| - | - | +| **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, 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) + +## Summary + +In this part of the API Gateway tutorial, we configured the custom authorizer we'll use to handle access requests. To do this, we: + +1. Prepared a bundle containing the code that will be used by the Lambda function using the Auth0 sample +1. Created the IAM role that will call the Lambda function +1. Created the Lambda function using the custom bundle created in step 1 +1. Created the API Gateway custom authorizer using the Lambda function we created in step 3 + +In the next part of the tutorial, we will use the custom authorizer we created. + +<%= include('./_stepnav', { + prev: ["Import and Deploy the API Gateway API", "/integrations/aws-api-gateway/custom-authorizers/part-2"], + next: ["Secure the API Using Custom Authorizers", "/integrations/aws-api-gateway/custom-authorizers/part-4"] +}) %> diff --git a/articles/integrations/aws-api-gateway/custom-authorizers/part-4.md b/articles/integrations/aws-api-gateway/custom-authorizers/part-4.md new file mode 100644 index 0000000000..148a41cca0 --- /dev/null +++ b/articles/integrations/aws-api-gateway/custom-authorizers/part-4.md @@ -0,0 +1,74 @@ +--- +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 + +In [part 1](/integrations/aws-api-gateway/custom-authorizers/part-1), you configured Auth0 for use with API Gateway, in [part 2](/integrations/aws-api-gateway/custom-authorizers/part-2), you configured an API using API Gateway, and in [part 3](/integrations/aws-api-gateway/custom-authorizers/part-3), you created the custom authorizer that can be used to retrieve the appropriate policies when your API receives an access request. In this part of the tutorial, we will show you how to use the custom authorizer to secure your API's endpoints. + +## Configure API Gateway Resources to use the Custom Authorizer + +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/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) + +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/part-3). + +![](/media/articles/integrations/aws-api-gateway-2/part-3/pt3-4.png) + +Click the **check mark** icon to save your choice of custom authorizer. Make sure the **API Key Required** field is set to `false`. + +![](/media/articles/integrations/aws-api-gateway-2/part-3/pt3-5.png) + +## Deploy the API + +To make your changes public, you'll need to [deploy your API](/integrations/aws-api-gateway/custom-authorizers/part-2#deploy-the-api). + +If successful, you'll be redirected to the **Test Stage Editor**. Copy down the **Invoke URL** provided in the blue ribbon at the top, since you'll need this to test your deployment. + +![](/media/articles/integrations/aws-api-gateway-2/part-3/pt3-8.png) + +## Test Your Deployment + +You can test your deployment by making a `GET` call to the **Invoke URL** you copied in the previous step. + +```har +{ + "method": "GET", + "url": "https://YOUR_INVOKE_URL/pets" +} +``` + +## Summary + +In this tutorial, you have + +1. Configured Auth0 for use with API Gateway +2. Imported an API for use with API Gateway +3. Created a custom authorizer to secure your API's endpoints, which required working with AWS IAM and Lambda +4. Secured your API with your custom authorizer + +<%= include('./_stepnav', { + prev: ["Create the Custom Authorizer", "/integrations/aws-api-gateway/custom-authorizers/part-3"] +}) %> 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/_stepnav.html b/articles/integrations/aws-api-gateway/delegation/_stepnav.html new file mode 100644 index 0000000000..8e021cac76 --- /dev/null +++ b/articles/integrations/aws-api-gateway/delegation/_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/articles/integrations/aws-api-gateway/delegation/index.md b/articles/integrations/aws-api-gateway/delegation/index.md new file mode 100644 index 0000000000..64c61344ab --- /dev/null +++ b/articles/integrations/aws-api-gateway/delegation/index.md @@ -0,0 +1,40 @@ +--- +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 + +<%= 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/) 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). + +You will be taken through the following steps: + +* [Step 1 - Set up the AWS API Gateway](/integrations/aws-api-gateway/delegation/part-1) +* [Step 2 - Secure and Deploy the Amazon API Gateway](/integrations/aws-api-gateway/delegation/part-2) +* [Step 3 - Build the Application](/integrations/aws-api-gateway/delegation/part-3) +* [Step 4 - Use Multiple Roles with Amazon API Gateway](/integrations/aws-api-gateway/delegation/part-4) +* [Step 5 - Use Identity Tokens to Flow Identity](/integrations/aws-api-gateway/delegation/part-5) + +<%= include('./_stepnav', { + next: ["1. Setup", "/integrations/aws-api-gateway/delegation/part-1"] +}) %> diff --git a/articles/integrations/aws-api-gateway/delegation/part-1.md b/articles/integrations/aws-api-gateway/delegation/part-1.md new file mode 100644 index 0000000000..145d08c4e6 --- /dev/null +++ b/articles/integrations/aws-api-gateway/delegation/part-1.md @@ -0,0 +1,338 @@ +--- +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 + +<%= include('./_delegation-version-warning') %> + +## Step 1 - Set up the Amazon API Gateway + +After completing this step, you will have: + +* Set up Amazon API Gateway using AWS Lambda functions to execute your service logic that stores and retrieves pets from an [Amazon DynamoDB](https://aws.amazon.com/dynamodb) table; +* Created two unauthenticated REST service methods for getting and updating a list of pets. + +::: note +Prior to beginning, please have [Node.js](https://nodejs.org/) installed. +::: + +### 1. Create the Amazon DynamoDB Table + +In the [Amazon DynamoDB Console](https://console.aws.amazon.com/dynamodb), click on **Create Table**. + +![Create DB Table](/media/articles/integrations/aws-api-gateway/part-1/dynamodb-create-table.png) + +Configure the variables associated with the table: + +* **Table name**: Pets +* **Primary key**: username +* **Primary key type**: String +* **Use default settings**: *unchecked* +* **Read capacity units**: 3 +* **Write capacity units**: 3 + +![Create Table Settings](/media/articles/integrations/aws-api-gateway/part-1/configure-newly-created-table.png) + +Click **Create** to create the table with your provided settings. + +While the table is being created, take note of the *Amazon Resource Name (ARN)* under the *Table details* section. You will need the table's ARN in the next step. + +![ARN value](/media/articles/integrations/aws-api-gateway/part-1/table-arn.png) + +### 2. Create the Policy that Grants AWS Lambda Functions Access to the DynamoDB Pets Table + +Navigate to the [AWS IAM Console](https://console.aws.amazon.com/iam). + +Click on **Roles** in the left menu, and then click the **Create New Role** button. + +![IAM Landing](/media/articles/integrations/aws-api-gateway/part-1/roles.png) + +Name the role `APIGatewayLambdaExecRole` and click **Next Step**. + +![Set Role Name](/media/articles/integrations/aws-api-gateway/part-1/set-role-name.png) + +Select the Role Type. Under *AWS Service Roles*, select *AWS Lambda*. + +![Select Role Type](/media/articles/integrations/aws-api-gateway/part-1/select-role-type.png) + +On the Attach Policy screen, skip this step by clicking **Next Step**. At this point, review the information you provided. If all looks correct, click **Create Role**. When finished, you should see your role listed on the IAM homepage. + +![Roles List](/media/articles/integrations/aws-api-gateway/part-1/iam-roles-list.png) + +Select the role you just created, **APIGatewayLambdaExecRole**. Click the down arrow for *Inline Policies* and click the **Click Here** link. + +![Create Policy](/media/articles/integrations/aws-api-gateway/part-1/create-inline-policies.png) + +Select *Custom Policy*, and then click **Select**. Name the policy `LogAndDynamoDBAccess` and add the following code as the policy document (be sure to first update the Amazon Resource Name (ARN) for your DynamoDB table). Click **Apply Policy**. + +```json +{ + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "AccessCloudwatchLogs", + "Action": ["logs:*"], + "Effect": "Allow", + "Resource": "arn:aws:logs:*:*:*" + }, + { + "Sid": "PetsDynamoDBReadWrite", + "Effect": "Allow", + "Action": [ + "dynamodb:DeleteItem", + "dynamodb:GetItem", + "dynamodb:PutItem", + "dynamodb:UpdateItem" + ], + "Resource": ["DYNAMODB_TABLE_ARN_VALUE_FROM_PREVIOUS_STEP"] + } + ] +} +``` + +![Create Custom Policy](/media/articles/integrations/aws-api-gateway/part-1/custom-policy.png) + +### 2. Create the AWS Lambda Functions + +The next three steps create the AWS Lambda functions for retrieving and updating pet information in the DynamoDB table. + +#### Create the Lambda Function for `GetPetInfo` + +In the [AWS Lambda Console](https://console.aws.amazon.com/lambda), select **Create a Lambda Function** (if you have not created an AWS Lambda function before, you will click **Get Started Now**). + +![Get Started with Lambda](/media/articles/integrations/aws-api-gateway/part-1/lambda-get-started-now.png) + +On the *Select blueprint* screen, click **Blank Function**. + +![Blank function template](/media/articles/integrations/aws-api-gateway/part-1/lambda-blank-function.png) + +You will then be prompted to *Configure triggers*. Click **Next** to proceed. You do not have to do so at this point. + +Finally, you will be asked to *Configure function*. + +![Configure Lambda function](/media/articles/integrations/aws-api-gateway/part-1/configure-function.png) + +Populate the appropriate fields with the following information: + +* **Name**: `GetPetInfo` +* **Runtime**: Node.js 6.10 + +Paste the following code to read pet information from the DynamoDB table into the **Lambda function code** area. + +```js +var AWS = require('aws-sdk'); +var DOC = require('dynamodb-doc'); +var dynamo = new DOC.DynamoDB(); + +exports.handler = function(event, context) { + var cb = function(err, data) { + if(err) { + console.log('error on GetPetsInfo: ',err); + context.done('Unable to retrieve pet information', null); + } else { + if(data.Item && data.Item.pets) { + context.done(null, data.Item.pets); + } else { + context.done(null, {}); + } + } + }; + + dynamo.getItem({TableName:"Pets", Key:{username:"default"}}, cb); +}; +``` + +For *Role*, select **Choose an existing role**. Next, choose **APIGatewayLambdaExecRole** as the *Existing Role*. Leave all other settings at their default values. + +![Configure Lambda function](/media/articles/integrations/aws-api-gateway/part-1/configure-function2.png) + +Click **Next** to review the information you provided. If all looks correct, click **Create function**. + +Click **Test**, leaving the *Input test event* at its default (which uses the Hello World template). When the test completes, you should see an empty output (`{}`) in the *Execution Result* section. The table is empty. + +![Execution Result](/media/articles/integrations/aws-api-gateway/part-1/execution-result.png) + +#### Create the Lambda Function for `UpdatePetInfo` + +Repeat the instructions used to create the `GetPetInfo` function, but use the following instead as the function code: + +```js +var AWS = require('aws-sdk'); +var DOC = require('dynamodb-doc'); +var dynamo = new DOC.DynamoDB(); +exports.handler = function(event, context) { + var item = { username:"default", + pets: event.pets || {} + }; + + var cb = function(err, data) { + if(err) { + console.log(err); + context.fail('unable to update pets at this time'); + } else { + console.log(data); + context.done(null, data); + } + }; + dynamo.putItem({TableName:"Pets", Item:item}, cb); +}; +``` + +Test the function by clicking the *Actions* drop-down and choosing **Configure sample event**. Enter the following for sample data and click **Submit**: + +```json +{ + "pets": [{ + "id": 1, + "type": "dog", + "price": 249.99 + }] +} +``` + +You should see an empty return result (`{}`). + +![Execution Result](/media/articles/integrations/aws-api-gateway/part-1/execution-result-update.png) + +Return to your `GetPetInfo` Lambda function and click **Test** again. You should now see a single pet. + +![Test result](/media/articles/integrations/aws-api-gateway/part-1/test-result-one-pet.png) + +#### Create the Third Lambda Function + +You will create one additional Lambda function. While this function will do nothing, it is required by the *OPTIONS* method for CORS as described in a later section. + +Using the steps described above, create a Lambda function named `NoOp`. The function's code will be as follows: + +```js +exports.handler = function(event, context) { + context.succeed(''); +} +``` + +::: note +Instead of creating this third Lambda function, you may choose to [create an OPTIONS method](#method-options) on the API Gateway. +::: + +### 3. Create the Amazon API Gateway API + +You will create an API with two methods: one will `GET` pet information, and one will `POST` pet information. + +#### Method: `GET` Pet Information + +Go to the [Amazon API Gateway Console](https://console.aws.amazon.com/apigateway), and click **Create API**. If this is the first time you are creating an API, you will see a screen prompting you to **Get Started** instead. + +![Get started with API Gateway](/media/articles/integrations/aws-api-gateway/part-1/get-started-with-api-gateway.png) + +If this is the first time you are creating an API, you will be prompted to create an *Example API*. Click **OK** to exit the pop-up notification, and choose the **New API** radio button instead of the **Example API** button. + +![Create API Sample](/media/articles/integrations/aws-api-gateway/part-1/create-example-api.png) + +Name the API `SecurePets` and click **Create API**. + +![Create New API](/media/articles/integrations/aws-api-gateway/part-1/create-new-api.png) + +Navigate to the *Resources* tab of the `SecurePets` API and click the **Create Resource** action. + +![Create Resource](/media/articles/integrations/aws-api-gateway/part-1/create-resource.png) + +Name the resource `Pets` and click **Create Resource** again. + +![Create Name Resource](/media/articles/integrations/aws-api-gateway/part-1/name-resource.png) + +In the left pane, select `/pets` and then click the **CreateMethod** button. + +![Create Pets Method](/media/articles/integrations/aws-api-gateway/part-1/create-pets-method.png) + +In the drop-down, select *GET* and click the checkmark button. Provide the following configuration values for the `GET` method: + +* **Integration type**: Lambda Function; +* **Lambda Region**: Region you are located in; +* **Lambda Function**: GetPetInfo. + +![Setup Get Pets Method](/media/articles/integrations/aws-api-gateway/part-1/pets-get-method-setup.png) + +Click **Save** and then **OK** when prompted in the popup to grant permissions to the Lambda function. + +![Set Lambda Permissions](/media/articles/integrations/aws-api-gateway/part-1/lambda-permissions.png) + +In the *Method Execution* window that appears next, click **Test**. + +![Method Execution](/media/articles/integrations/aws-api-gateway/part-1/method-execution.png) + +You should see the single pet returned in the response body. + +![Method Execution Results](/media/articles/integrations/aws-api-gateway/part-1/method-execution-results.png) + +#### Method: `POST` Pet Information + +Creating the API used to `POST` pet information is similar to creating the one used to `GET` pet information. + +In the left pane, select `/pets`, and click **CreateMethod**. + +In the drop-down, select *POST*, and click the checkmark button. + +Select *Lambda Function* for Integration Type, select the region you are located in, and select *UpdatePetInfo* for the Lambda function. + +Click **Save** and then **OK** when prompted in the popup to grant permissions to the Lambda function. + +**Test**, and paste the following for the request body: + +```js +{"pets": [ + {"id": 1, "type": "dog", "price": 249.99}, + {"id": 2, "type": "cat", "price": 124.99} + ] +} +``` + +![Post Method Request Test](/media/articles/integrations/aws-api-gateway/part-1/post-method-request-test.png) + +You should see an empty return result (`{}`). + +Return to the *GET* method, and click **Test** again to see that the response body indicates there are two pets listed in the table: + +```json +[ + { + "id": 1, + "price": 249.99, + "type": "dog" + }, + { + "id": 2, + "price": 124.99, + "type": "cat" + } +] +``` + +![Get Method Request Test](/media/articles/integrations/aws-api-gateway/part-1/get-method-request-test2.png) + +#### Method: `OPTIONS` + +Instead of creating a lambda function that performs no action, you can create an `OPTIONS` method on the API Gateway. + +In the left pane, select `/pets`, and click **CreateMethod**. In the drop down, select *OPTIONS*, and click the checkmark button. Select *Mock* for Integration Type. Click **Save**. + +![Configure Options Method](/media/articles/integrations/aws-api-gateway/part-1/options-method.png) + +Leaving the Response Body blank, click **Test**. You should receive a Response Body indicating `no data`. + +![Options Test](/media/articles/integrations/aws-api-gateway/part-1/options-test.png) + + +At this point, the AWS Lambda functions and the Amazon API Gateway methods are defined with no security. + +<%= include('./_stepnav', { + prev: ["0. Introduction", "/integrations/aws-api-gateway/delegation"], + next: ["2. Securing and Deploying", "/integrations/aws-api-gateway/delegation/part-2"] +}) %> diff --git a/articles/integrations/aws-api-gateway/delegation/part-2.md b/articles/integrations/aws-api-gateway/delegation/part-2.md new file mode 100644 index 0000000000..e96b9a1882 --- /dev/null +++ b/articles/integrations/aws-api-gateway/delegation/part-2.md @@ -0,0 +1,251 @@ +--- +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 + +<%= include('./_delegation-version-warning') %> + +## Step 2 - Secure and Deploy the Amazon API Gateway + +Now that you have your API running, you need to add security. In this step, you will: + +* 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. + +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) + +You will see two ways of implementing this flow: + +1. Using Auth0 Delegation with AWS IAM; +2. Adding an identity token to flow identity to the Lambda function. + +Delegation makes it easy for you to obtain tokens from AWS to access AWS services in your application. + +### Ways to Secure the Amazon API Gateway + +AWS API Gateway provides several different methods to secure your APIs: + +1. API keys; +2. IAM; +3. [Amazon Cognito](/integrations/aws-api-gateway/secure-api-with-cognito). + +Using API keys is typically appropriate for a service-to-service interaction, as illustrated below. However, there are several downsides to this approach: + +* Placing a secret with a long lifetime on the application is risky (applications are easier to compromise); +* Creating a framework to issue and manage API keys requires a secure implementation that can be challenging to develop. + +This section of the tutorial will utilize [IAM roles and policies](http://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html) to secure your API in API Gateway, but you can also choose to do so using [user pools in Amazon Cognito](http://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html). See detailed instructions on doing so [here](/integrations/aws-api-gateway/secure-api-with-cognito). + +### 1. Configure IAM and Auth0 for SAML Integration with the API Gateway + +You can specify an AWS IAM role for the SAML token you exchange for an AWS token. Depending on the permissions granted to that IAM role (which are set using your identity provider), the received token possesses those same permissions. By issuing different SAML tokens, each with its own AWS IAM role, you can control the levels of access for your users. + +For example, the IDP could specify the IAM role based on group membership (for example, an administrator in Active Directory) or authentication source (for example, a database connection or a social provider like Facebook). This approach lets you differentiate user access to your Amazon API Gateway methods when secured using AWS IAM. + +#### Configure Auth0 + +Log in to your Auth0 account. You will be brought to the Management Dashboard. Click on **+ New Application**, which is located in the top right corner of the page. + +![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**. + +![Create Application](/media/articles/integrations/aws-api-gateway/part-2/create-new-client.png) + +Navigate to the *Addons* tab for your newly-created Application. Using the appropriate slide, enable *Amazon Web Services*. This turns on AWS Delegation. + +![Enable AWS for Application](/media/articles/integrations/aws-api-gateway/part-2/enable-aws-addon.png) + +#### Configure AWS + +Follow the [How to Set Up AWS for Delegated Authentication](/aws-api-setup) tutorial to configure AWS for delegated access, which uses SAML. Some caveats: + +* Follow the [instructions below](#setting-the-permissions-policy-on-your-iws-iam-role) for attaching the permissions policy to your role instead of the one for the linked tutorial; +* Name the SAML provider you create `auth0`; +* Name the AWS IAM role `auth0-api-role`. + +##### Set the Permissions Policy on Your IWS IAM Role + +Once you have configured the AWS IAM role, you will add a policy to `auth0-api-role` that lets you execute your API Gateway methods. + +::: note +For more information on this process, please see [User Access Permissions for Amazon API Gateway](http://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html). +::: + +::: panel Getting the Gateway API ARN + +Before you begin, you will need the ARN for your Gateway API: + +1. Navigate to [Amazon API Gateway Console](https://console.aws.amazon.com/apigateway) and log in. +2. Select the appropriate API. +3. Click on any of the Methods associated with the API to bring up the *Method Execution* page. +4. On the *Method Execution* page, the *Method Request* box in the top left corner displays the **ARN** for the API, though it includes the Method name: + +`arn:aws:execute-api:us-east-2:484857107747:97i1dwv0j4/*/POST/` + +You'll strip the method name to get the base ARN for the API: + +`arn:aws:execute-api:us-east-2:484857107747:97i1dwv0j4/*` + +The wildcard (`*`) in the ARN above enables permissions to your API for all stages, but you can deploy different stages individually (for example, development, then test, then production). +::: + +Select the `auth0-api-role` role you just created to open its *Summary* page. + +![Select IAM Role](/media/articles/integrations/aws-api-gateway/part-2/select-iam-role.png) + +Expand **Inline Policies**, and click **click here**. + +![Attach Policy](/media/articles/integrations/aws-api-gateway/part-2/attach-policy.png) + +Select **Custom Policy** and click **Select**. + +![Custom Policy](/media/articles/integrations/aws-api-gateway/part-2/custom-policy.png) + +Edit your policy document. You can set the **Policy Name** to whatever you would like, but we suggest something like `api-gateway-policy`. To enable access to the API methods for this role, apply the following policy *after* updating the ARN with the one for your API. + +```js +{ + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Action": [ + "execute-api:*" + ], + "Resource": [ + "arn:[YOUR_ARN]" + ] + } + ] +} +``` + +![Edit custom policy](/media/articles/integrations/aws-api-gateway/part-2/edit-custom-policy.png) + +Click **Apply Policy**. + +Since the API Gateway will assume this role on behalf of the user, the trust policy needs to permit this action. To do so, edit the role's *Trust Relationships* by navigating to this tab on the role's *Summary* page. + +![Edit trust policy](/media/articles/integrations/aws-api-gateway/part-2/edit-trust-policy.png) + + +The final trust relationship should look similar to the following: + +```js +{ + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "auth0", + "Effect": "Allow", + "Principal": { + "Federated": "arn:aws:iam::012345670:saml-provider/auth0-api" + }, + "Action": "sts:AssumeRoleWithSAML", + "Condition": { + "StringEquals": { + "SAML:iss": "urn:${account.namespace}" + } + } + }, + { + "Sid": "gateway", + "Effect": "Allow", + "Principal": { + "Service": "apigateway.amazonaws.com" + }, + "Action": "sts:AssumeRole" + } + ] +} +``` + +![Trust policy](/media/articles/integrations/aws-api-gateway/part-2/trust-relationship.png) + +At this point, you will need to set the *Authorization Settings* on the [API Gateway](https://console.aws.amazon.com/apigateway). + +In the **Resources** view, select the *POST* method under `/pets`. + +![Post Method](/media/articles/integrations/aws-api-gateway/part-2/post-method-request.png) + +Click the **Method Request** link. + +![Set Authorization Settings for Method](/media/articles/integrations/aws-api-gateway/part-2/auth-settings.png) + +Click the edit icon beside the **Authorization Type**, and select *AWS_IAM*. Now click the **Check Button** beside the field to save the setting. + +### 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. + +Select `/pets` under Resources, and click **Create Method**. In the drop-down, select **OPTIONS**, and click the **checkmark** to save the setting. + +![Create Options Method](/media/articles/integrations/aws-api-gateway/part-2/create-options-method.png) + +The Options method is used by the browser to get the necessary HTTP headers, but the function needs further instructions on what to do. Under the `OPTIONS` Setup screen, set the following variables/parameters: + +* **Integration Type**: Lambda Function; +* **Use Lambda Proxy Integration**: *leave unchecked*; +* **Lambda Region**: *select your region*; +* **Lambda Function**: NoOp. + +![Configure Options Method](/media/articles/integrations/aws-api-gateway/part-2/config-options-method.png) + +Click **Save**. On the next pop-up screen, grant your Lambda function the permissions it needs. + +![Set Lambda Permissions](/media/articles/integrations/aws-api-gateway/part-2/permissions.png) + +You will then be auto-directed to the `OPTIONS` *Method Execution* page. Open the *Method Response* page. + +![Method Response](/media/articles/integrations/aws-api-gateway/part-2/method-response.png) + +Expand the **200** section located under the *HTTP Status* bar and add the following response headers: + +* *Access-Control-Allow-Headers*; +* *Access-Control-Allow-Methods*; +* *Access-Control-Allow-Origin*. + +![Add headers](/media/articles/integrations/aws-api-gateway/part-2/add-headers.png) + +Next, map the appropriate values to each of the response headers. After returning to the *Method Execution* page, click on **Integration Response**. After expanding the row associated with the **200** method response status, expand the **Header Mappings**, and apply the following mappings: + +* *Access-Control-Allow-Headers*: `'Content-Type,X-Amz-Date,Authorization,x-api-key,x-amz-security-token'`; +* *Access-Control-Allow-Origin*: `'*'` +* *Access-Control-Allow-Methods*: `'POST, GET, OPTIONS'` + +![Configure headers](/media/articles/integrations/aws-api-gateway/part-2/integration-response.png) + +Finally, repeat the above steps to enable CORS for the *POST* and *GET* methods. However, for these two methods, you will add one header, *Access-Control-Allow-Origin*, and its value should be set to `'*'`. + +### Deploy the API + +Return to the **Resources** view for your API. Click on **Actions**, and select **DEPLOY API**. + +![Deploy API](/media/articles/integrations/aws-api-gateway/part-2/deploy-api.png) + +Select **New Stage** for Deploy State, and name the stage `Test`. Click the **Deploy** button. + +![Choose Deployment Stage](/media/articles/integrations/aws-api-gateway/part-2/choose-deploy-stage.png) + +On the result page, navigate to **SDK Generation**. Select *JavaScript* as the **Platform**. Click the **Generate SDK** button. + +![Test Stage Editor](/media/articles/integrations/aws-api-gateway/part-2/test-stage-editor.png) + +Save the downloaded zip file for later use. + +<%= include('./_stepnav', { + prev: ["1. Setup", "/integrations/aws-api-gateway/delegation/part-1"], + next: ["3. Building the Application", "/integrations/aws-api-gateway/delegation/part-3"] +}) %> diff --git a/articles/integrations/aws-api-gateway/delegation/part-3.md b/articles/integrations/aws-api-gateway/delegation/part-3.md new file mode 100644 index 0000000000..f2049e1858 --- /dev/null +++ b/articles/integrations/aws-api-gateway/delegation/part-3.md @@ -0,0 +1,262 @@ +--- +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 + +<%= 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. + +### 1. Set Up Your Sample Application + +For a simple starter app, download this seed project. + +<%= include('../../../_includes/_package', { + org: 'auth0', + repo: 'auth0-aws', + path: 'examples/api-gateway/client' +}) %> + +Copy the contents of this seed project to a local folder called `pets`, which you will be using for the remainder of this tutorial. Within this folder, update `auth0-variables.js` with your Auth0 Application `AUTH0_CLIENT_ID` and `AUTH0_CLIENT_ID` (this information is available in the [Management Dashboard](${manage_url}/#/applications) for the application in question). + +::: panel AWS S3 bucket +Be sure that you have [created the AWS S3 bucket configured to act as a static website](http://docs.aws.amazon.com/gettingstarted/latest/swh/website-hosting-intro.html). During the setup process, copy the contents of the `pets` folder to your S3 bucket to provide content for the website. + +If you are using a pre-existing bucket, you can move the files with the [AWS CLI](https://aws.amazon.com/cli/) using the following command: +``` +aws s3 cp --recursive --acl "public-read" ./ s3://YOUR-BUCKET/ +``` +::: + +Prior to proceeding, please be sure that you have at least one user associated with your *Username-Password-Authentication* (or the Database Connection associated with the Application you are using) Connection. To fully utilize the functionality of your sample app and its integration with AWS, you will need that user to test authentication and gain access. + +Lastly, ensure that Auth0 allows authentication from your website by providing the URL in the **Allowed Origins** field in the *Settings* page of your Application. Your website's URL should look something like this: + +`http://your-bucket.s3-website-us-east-1.amazonaws.com` + +If you don't know what your URL is, you can find it listed under the **Properties** tab of your S3 bucket. + +Before going further, test logging into your application. Open `http://your-bucket-domain/index.html` in your browser. After logging in, you should see an alert box pop up that says "getPets not implemented": + +![Pop up with Get Method Error](/media/articles/integrations/aws-api-gateway/part-3/log-in-popup.png) + +You should also see the page for viewing pets. + +![Log in success screen](/media/articles/integrations/aws-api-gateway/part-3/log-in-success.png) + +### 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: + +![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. + +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. + + +```js +auth.signin(params, function(profile, token) { + //Set user as admin if they did not use a social login. + profile.isAdmin = !profile.identities[0].isSocial; + store.set('profile', profile); + store.set('token', token); + + // get delegation token from identity token. + var options = getOptionsForRole(profile.isAdmin, token); + + // TODO: Step 3: Enable this section once you setup AWS delegation. + /* + auth.getToken(options) + .then( + function(delegation) { + store.set('awstoken', delegation.Credentials); + $location.path("/"); + }, + function(err) { + console.log('failed to acquire delegation token', err); + }); + */ + // TODO: Step 3: Remove this redirect after you add the get token API. + $location.path("/"); + +}, function(error) { + console.log("There was an error logging in", error); +}); +``` + +#### Modify the `role` and `principal` Strings + +To modify the `role` and `principal` strings (which are the final two lines of the `if` statement contained in the provided function), specify the appropriate values via [Rules](${manage_url}/#/rules): + +```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); +} +``` + +:::panel Rules +[How to Work with Rules](/rules#video-using-rules) +::: + +Be sure to update the `role` and `[principal]` ARN values with the ones for your integration. + +Copy the updated files to your S3 bucket for your website. + +Optionally, you can set a breakpoint in the browser at `store.set('awstoken', delegation.Credentials);`. When you log out and and log back in, inspect `delegation.Credentials` when you arrive at the breakpoint. You will see a familiar values like *AccessKeyId* and *SecretAccessKey*: + +```js +{ + AccessKeyId: "ASIAJB...BNQ", + SecretAccessKey: "vS+b6...2Noav", + SessionToken: "AQoDYBqsivOV...DdQW0gsKr8rgU=", + Expiration: "2015-08-27T14:48:32.000Z" +} +``` + +If you don't see these values, be sure that you have the *Amazon Web Services addon* enabled in the *Addons* tab for your Auth0 Application. + +### Display Pets with the AWS API Service + +The first thing you will do is show the pets to the end users. + +#### Add the API Code to Call Your API + +To add the API code for adding a call to your service, copy the contents of *apiGateway-js-sdk.zip* you [previously downloaded](/integrations/aws-api-gateway/part-2/#deploy-the-api) to the `pets` directory. The contents should include: + +* `apiClient.js`; +* `lib` folder; +* `README.md`. + +There is already a `README.md` in the `pets` directory, so you will need to rename one of the files to keep both in the directory. The `README.md` for the API gateway explains how to use the API application from your Auth0 Application. + +Open the `index.html` file located in the root of your `pets` folder to add all of the scripts listed at the top of the API readme to `index.html`: + +```html + + + + + + + + + + + + + +``` + +If you open `apigClient.js`, you can see that the downloaded library has created wrappers like `petsPost` and `petsGet` for your API methods. You do *not* need to modify this generated code. + +#### Configure the `getPets` Method + +Open `home.js` in the `home` folder, and update the contents of `getPets` with a method for retrieving pets data (be sure to update the region if you are not running in `us-east-1`): + +```js +function getPets() { + // this is unauthenticated + var apigClient = apigClientFactory.newClient({ + region: 'us-east-1' // The region where the API is deployed + }); + + apigClient.petsGet({},{}) + .then(function(response) { + console.log(response); + $scope.pets = response.data; + $scope.$apply(); + }).catch(function (response) { + alert('pets get failed'); + showError(response); + }); +} +``` + +Copy the updated code to your S3 bucket. Refresh the page to see two animals listed (if you ran the previously described test on your APIs that created these pets). + +![API Get Method Success](/media/articles/integrations/aws-api-gateway/part-3/get-success.png) + +### Update Pets with the AWS API Service + +Now that you have a working Auth0 Application with the API Gateway, you will add a method for updating the `pets` table. + +Modify the `putPets` method logic to update pets using your API function. This function will be used for both adding and removing pets. + +```js +function putPets(updatedPets) { + var body = {pets: updatedPets}; + + var apigClient = apigClientFactory.newClient({ + region: 'us-east-1' // set this to the region you are running in. + }); + + apigClient.petsPost({},body) + .then(function(response) { + console.log(response); + }).catch(function (response) { + alert('pets update failed'); + showError(response); + }); +} +``` + +Copy the updated code to your S3 bucket. Test the method: + +1. Log out and log back in. +2. Enter in values for `Pet Type` and `Pet Price`. +3. Click **Save** to post your data. + +You should see a message that says, "We have a `` for sale for ``" with a red **REMOVE** button to its left. + +![Post Method Success Screen](/media/articles/integrations/aws-api-gateway/part-3/add-frog-success.png) + +To add security, add the `getSecureApiClient` function at the start of the `putPets` method: + +```js + +function putPets(updatedPets) { + var apigClient = getSecureApiClient(); +} +``` + +Copy the code to your S3 bucket. + +The `getSecureApiClient` function provided for you retrieves the AWS token from local storage acquired using delegation to the API, and uses the access key, secret, and session token: + +```js + function getSecureApiClient() { + var awstoken = store.get('awstoken'); + + return apigClientFactory.newClient({ + accessKey: awstoken.AccessKeyId, + secretKey: awstoken.SecretAccessKey, + sessionToken: awstoken.SessionToken, + region: 'us-east-1' // The region you are working out of. + }); + } +``` + +<%= include('./_stepnav', { + prev: ["2. Securing and Deploying", "/integrations/aws-api-gateway/delegation/part-2"], + next: ["4. Using Multiple Roles", "/integrations/aws-api-gateway/delegation/part-4"] +}) %> diff --git a/articles/integrations/aws-api-gateway/delegation/part-4.md b/articles/integrations/aws-api-gateway/delegation/part-4.md new file mode 100644 index 0000000000..8e2766db92 --- /dev/null +++ b/articles/integrations/aws-api-gateway/delegation/part-4.md @@ -0,0 +1,335 @@ +--- +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 + +<%= include('./_delegation-version-warning') %> + +## Step 4 - Use Multiple Roles with Amazon API Gateway + +In this step, you'll assign different AWS IAM roles to users based on authentication information: + +* Users authenticating with Social Connections will be treated as buyers; +* Users authenticating with Database Connections will be treated as admins. + +You will perform this role assignment logic in two different ways: + +* JavaScript; +* Auth0 rules. + +For many Auth0 Applications, you'll want different users to have different levels of access, and you'll want additional information about a given identity to use in your service logic. In cases where it's sufficient to lock down access at the API level, you can use different AWS IAM roles (for example, administrators can use the update function to *add* and *remove* pets, but social users can only *buy* pets). + +The following diagram illustrates AWS IAM role assignments for two different user classes: users authenticated via Social Connections and users authenticated via Database Connections. It also illustrates that AWS IAM roles can be assigned to other entities, like AWS Lamdba functions, to control the permissions these entities are assigned for an account. In short, an IAM role is a group of permissions to AWS capabilities that is defined by one or more policies and then assigned to an entity. + +![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/delegation/part-5). + +### 1. Create the PetPurchase API Resource + +Using the [Amazon API Gateway Console](https://console.aws.amazon.com/apigateway), select your *Pets* API. You will be taken to its *Resources* page. + +![Create New Resource](/media/articles/integrations/aws-api-gateway/part-4/create-resource.png) + +Click on **Actions** and **Create Resource**. Name the *New Child Resource* `Purchase`. Click **Create Resource**. + +![Create Child Resource](/media/articles/integrations/aws-api-gateway/part-4/new-child-resource.png) + +Add an *OPTIONS* method for the `purchase` resource as outlined previously for `pets` in the [Set Up Cors and Deploy the API section of Step 2 - Securing and Deploying the Amazon API Gateway](/integrations/aws-api-gateway/part-2#set-up-cors-and-deploy-the-api). + +[Create a new AWS Lambda function](/integrations/aws-api-gateway/part-1#2-create-the-aws-lambda-functions) for purchasing a pet called `PetPurchase`, which adds `isSold` and `soldTo` attributes to a pet as follows: + +```js +var AWS = require('aws-sdk'); +var DOC = require('dynamodb-doc'); +var dynamo = new DOC.DynamoDB(); + +exports.handler = function(event, context) { + var petId = event.petId; + var user = event.userName; + var pets = {}; + console.log('start PetsPurchase, petId', petId, ' userName', user); + + var writecb = function(err, data) { + if(!err) { + context.done(null, pets); + } else { + console.log('error on GetPetsInfo: ',err); + context.done('failed on update', null); + } + }; + + var readcb = function(err, data) { + if(err) { + console.log('error on GetPetsInfo: ',err); + context.done('failed to retrieve pet information', null); + } else { + // make sure we have pets + if(data.Item && data.Item.pets) { + pets = data.Item.pets; + var found = false; + + for(var i = 0; i < pets.length && !found; i++) { + if(pets[i].id === petId) { + if(!pets[i].isSold) { + pets[i].isSold = true; + pets[i].soldTo = user; + var item = { username:"default",pets: pets}; + dynamo.putItem({TableName:"Pets", Item:item}, writecb); + found = true; + } + } + } + if(!found) { + console.log('pet not found'); + context.done('That pet is not available.', null); + } + } else { + console.log('pet already sold'); + context.done('That pet is not available.', null); + } + } + }; + + dynamo.getItem({TableName:"Pets", Key:{username:"default"}}, readcb); +}; +``` + +Once you have defined the Lambda function, [add a *POST* method to the `purchase` resource](/integrations/aws-api-gateway/part-1#method-post-pet-information) that calls the `PetPurchase` Lambda. Be sure to also add the `Access-Control-Allow-Origin` header with a value of `*` to the *POST* method using the [method response/integration response configuration](/integrations/aws-api-gateway/part-2#set-up-cors-and-deploy-the-api). + +Test the API gateway method, providing the following as an input message: + +```js + { + "petId": 1, + "userName": "fred flintstone" + } +``` + +In the test response, you should see the pet with ID of 1 is now sold to Fred Flintstone: +```js +[ + { + "id": 1, + "price": 249.99, + "type": "dog", + "isSold": true, + "soldTo": "fred flintstone" + }, + + ... +``` + +### 2. Use IAM to Secure the PurchasePet API + +#### Update IAM + +To secure your API, follow the same process for adding a new role that you [performed in Part 2](/integrations/aws-api-gateway/part-2) of this tutorial. Call the new role `auth0-api-social-role`. + +The ARN for the method you will secure in the IAM policy should look something like: + +``` +arn:aws:execute-api:us-east-1:your-accountid:your-api-id/*/pets/purchase +``` + +Be sure to update the trust policy as well. + +Go to the [Amazon API Gateway Console](https://console.aws.amazon.com/apigateway), and select the *POST* method for the `/pets/purchase` resource. Select **Method Request** and change **Authorization Type** to *AWS_IAM*. Click the check to save the setting. + +At this point, you have defined two roles that you can use with the API gateway: + +* `auth0-api-role`: permits updating pets +* `auth0-api-social-role`: permits purchasing a pet + +#### Configure Login with Amazon and Update Auth0 + +You can create a social role using Login with Amazon (LWA). + +::: note +While this tutorial includes instructions for using Login with Amazon, please note that you can use other social providers as well. +::: + +Go to the [Auth0 Management Dashboard](${manage_url}). Select **Connections**, then **Social** in the drop-down menu. Enable the connection for Amazon by setting the slide to the right so that it turns green. + +![Enable AWS](/media/articles/integrations/aws-api-gateway/part-4/enable-amazon.png) + +You will now see a pop-up that walks you through the configuration process. + +![Configure AWS](/media/articles/integrations/aws-api-gateway/part-4/configure-amazon.png) + +Once you've selected the Applications that will be using this social connection, you will be prompted to enter values for the following fields: + +* *client id*; +* *client secret*. + +If you haven't used Login with Amazon before, there is also a link called **How to Obtain a Client ID**". Click on this link and follow the process to obtain the *client id* and *client secret* values. + +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. +::: + +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 + +Using the [Amazon API Gateway Console](https://console.aws.amazon.com/apigateway), you will again [deploy the API and generate a new JavaScript SDK](/integrations/aws-api-gateway/part-2#set-up-cors-and-deploy-the-api). + +At this point, you have made the necessary configuration changes to enable pet purchases. To make this live, copy your newly downloaded SDK over the previous one in your `pets` folder, as well as your Amazon S3 bucket. + +##### Update the Login Controller Logic to Choose Different Roles for Different Types of Users + +The login controller logic uses `getOptionsForRole` to select different roles for different users. When you obtain the delegation token, you can tell Auth0 which role to use (that is, the user is an admin or not). + +In the `pets/login/login.js` file, modify the `role` and `principal` values for the non-admin user for the social user IAM role you just created. + +At this point, you should be able to log in using Amazon credentials **or** the database user you previously created. Notice that the UI lets a social user buy pets, while an admin user can add and remove pets. + +To test this functionality, you can temporarily hide the remove button in the UI by removing `ng-show="isAdmin"` in `/pets/home/home.html`: + +``` + +``` + +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/articles/integrations/aws-api-gateway/delegation/part-5.md b/articles/integrations/aws-api-gateway/delegation/part-5.md new file mode 100644 index 0000000000..0b8697e298 --- /dev/null +++ b/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/articles/integrations/aws-api-gateway/delegation/secure-api-with-cognito.md b/articles/integrations/aws-api-gateway/delegation/secure-api-with-cognito.md new file mode 100644 index 0000000000..09bdb2005f --- /dev/null +++ b/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/articles/integrations/aws-api-gateway/index.md b/articles/integrations/aws-api-gateway/index.md deleted file mode 100644 index e73038357b..0000000000 --- a/articles/integrations/aws-api-gateway/index.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -url: /integrations/aws-api-gateway -title: Amazon API Gateway Tutorial Introduction -description: How to build a serverless application using Token-based Authentication with AWS API Gateway and Lambda. ---- - -# Amazon API Gateway Tutorial - -## Build a Serverless Application Using Token-Based Authentication with AWS API Gateway and Lambda - -With AWS, you can create powerful, serverless, highly scalable APIs and applications through AWS Lambda, Amazon API Gateway, and a JavaScript client. - -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. - -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). - -You will be taken through the following steps: - -* [Step 1 - Set up the AWS API Gateway](/integrations/aws-api-gateway/part-1) -* [Step 2 - Secure and Deploy the Amazon API Gateway](/integrations/aws-api-gateway/part-2) -* [Step 3 - Build the Client Application](/integrations/aws-api-gateway/part-3) -* [Step 4 - Use Multiple Roles with Amazon API Gateway](/integrations/aws-api-gateway/part-4) -* [Step 5 - Use Identity Tokens to Flow Identity](/integrations/aws-api-gateway/part-5) - -<%= include('./_stepnav', { - next: ["1. Setup", "/integrations/aws-api-gateway/part-1"] -}) %> diff --git a/articles/integrations/aws-api-gateway/index.yml b/articles/integrations/aws-api-gateway/index.yml new file mode 100644 index 0000000000..0ed4f10449 --- /dev/null +++ b/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/articles/integrations/aws-api-gateway/part-1.md b/articles/integrations/aws-api-gateway/part-1.md deleted file mode 100644 index 53f6f255fa..0000000000 --- a/articles/integrations/aws-api-gateway/part-1.md +++ /dev/null @@ -1,317 +0,0 @@ ---- -title: Amazon API Gateway Tutorial - Set Up the Amazon API Gateway -description: Step 1 of Amazon API Gateway Tutorial ---- -# Amazon API Gateway Tutorial -## Step 1 - Set up the Amazon API Gateway - -After completing this step, you will have: - -* Set up Amazon API Gateway using AWS Lambda functions to execute your service logic that stores and retrieves pets from an [Amazon DynamoDB](https://aws.amazon.com/dynamodb) table; -* Created two unauthenticated REST service methods for getting and updating a list of pets. - -> Prior to beginning, please have [Node.js](https://nodejs.org/) installed. - -### 1. Create the Amazon DynamoDB Table - -In the [Amazon DynamoDB Console](https://console.aws.amazon.com/dynamodb), click on **Create Table**. - -![Create DB Table](/media/articles/integrations/aws-api-gateway/part-1/dynamodb-create-table.png) - -Configure the variables associated with the table: - -* **Table name**: Pets -* **Primary key**: username -* **Primary key type**: String -* **Use default settings**: *unchecked* -* **Read capacity units**: 3 -* **Write capacity units**: 3 - -![Create Table Settings](/media/articles/integrations/aws-api-gateway/part-1/configure-newly-created-table.png) - -Click **Create** to create the table with your provided settings. - -While the table is being created, take note of the *Amazon Resource Name (ARN)* under the *Table details* section. You will need the table's ARN in the next step. - -![ARN value](/media/articles/integrations/aws-api-gateway/part-1/table-arn.png) - -### 2. Create the Policy that Grants AWS Lambda Functions Access to the DynamoDB Pets Table - -Navigate to the [AWS IAM Console](https://console.aws.amazon.com/iam). - -Click on **Roles** in the left menu, and then click the **Create New Role** button. - -![IAM Landing](/media/articles/integrations/aws-api-gateway/part-1/roles.png) - -Name the role `APIGatewayLambdaExecRole` and click **Next Step**. - -![Set Role Name](/media/articles/integrations/aws-api-gateway/part-1/set-role-name.png) - -Select the Role Type. Under *AWS Service Roles*, select *AWS Lambda*. - -![Select Role Type](/media/articles/integrations/aws-api-gateway/part-1/select-role-type.png) - -On the Attach Policy screen, skip this step by clicking **Next Step**. At this point, review the information you provided. If all looks correct, click **Create Role**. When finished, you should see your role listed on the IAM homepage. - -![Roles List](/media/articles/integrations/aws-api-gateway/part-1/iam-roles-list.png) - -Select the role you just created, **APIGatewayLambdaExecRole**. Click the down arrow for *Inline Policies* and click the **Click Here** link. - -![Create Policy](/media/articles/integrations/aws-api-gateway/part-1/create-inline-policies.png) - -Select *Custom Policy*, and then click **Select**. Name the policy `LogAndDynamoDBAccess` and add the following code as the policy document (be sure to first update the Amazon Resource Name (ARN) for your DynamoDB table). Click **Apply Policy**. - -```json -{ - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "AccessCloudwatchLogs", - "Action": ["logs:*"], - "Effect": "Allow", - "Resource": "arn:aws:logs:*:*:*" - }, - { - "Sid": "PetsDynamoDBReadWrite", - "Effect": "Allow", - "Action": [ - "dynamodb:DeleteItem", - "dynamodb:GetItem", - "dynamodb:PutItem", - "dynamodb:UpdateItem" - ], - "Resource": ["DYNAMODB_TABLE_ARN_VALUE_FROM_PREVIOUS_STEP"] - } - ] -} -``` - -![Create Custom Policy](/media/articles/integrations/aws-api-gateway/part-1/custom-policy.png) - -### 2. Create the AWS Lambda Functions - -The next three steps create the AWS Lambda functions for retrieving and updating pet information in the DynamoDB table. - -#### Create the Lambda Function for `GetPetInfo` - -In the [AWS Lambda Console](https://console.aws.amazon.com/lambda), select **Create a Lambda Function** (if you have not created an AWS Lambda function before, you will click **Get Started Now**). - -![Get Started with Lambda](/media/articles/integrations/aws-api-gateway/part-1/lambda-get-started-now.png) - -On the *Select blueprint* screen, click **Skip** (without selecing a particular blueprint). You will then be prompted to *Configure triggers*. Click **Next** to proceed. You do not have to do so at this point. - -Finally, you will be asked to *Configure function*. - -![Configure Lambda function](/media/articles/integrations/aws-api-gateway/part-1/configure-function.png) - -Populate the appropriate fields with the following information: - -* **Name**: `GetPetInfo` -* **Runtime**: Node.js - -Paste the following code to read pet information from the DynamoDB table into the **Lambda function code** area. - -```js -var AWS = require('aws-sdk'); -var DOC = require('dynamodb-doc'); -var dynamo = new DOC.DynamoDB(); - -exports.handler = function(event, context) { - var cb = function(err, data) { - if(err) { - console.log('error on GetPetsInfo: ',err); - context.done('Unable to retrieve pet information', null); - } else { - if(data.Item && data.Item.pets) { - context.done(null, data.Item.pets); - } else { - context.done(null, {}); - } - } - }; - - dynamo.getItem({TableName:"Pets", Key:{username:"default"}}, cb); -}; -``` - -For *Role*, select *APIGatewayLambdaExecRole*. Leave all other settings at their default values. - -![Lambda Handler](/media/articles/integrations/aws-api-gateway/part-1/lambda-handler-role.png) - -Click **Next** to review the information you provided. If all looks correct, click **Create function**. - -Click **Test**, leaving the *Input test event* at its default (which uses the Hello World template). When the test completes, you should see an empty output (`{}`) in the *Execution Result* section. The table is empty. - -![Execution Result](/media/articles/integrations/aws-api-gateway/part-1/execution-result.png) - -#### Create the Lambda Function for `UpdatePetInfo` - -Repeat the instructions used to create the `GetPetInfo` function, but use the following instead as the function code: - -```js -var AWS = require('aws-sdk'); -var DOC = require('dynamodb-doc'); -var dynamo = new DOC.DynamoDB(); -exports.handler = function(event, context) { - var item = { username:"default", - pets: event.pets || {} - }; - - var cb = function(err, data) { - if(err) { - console.log(err); - context.fail('unable to update pets at this time'); - } else { - console.log(data); - context.done(null, data); - } - }; - dynamo.putItem({TableName:"Pets", Item:item}, cb); -}; -``` - -Test the function by clicking the *Actions* drop-down and choosing **Configure sample event**. Enter the following for sample data and click **Submit**: - -```json -{ - "pets": [{ - "id": 1, - "type": "dog", - "price": 249.99 - }] -} -``` - -You should see an empty return result (`{}`). - -Return to your `GetPetInfo` Lambda function and click **Test** again. You should now see a single pet. - -![Test result](/media/articles/integrations/aws-api-gateway/part-1/test-result-one-pet.png) - -#### Create the Third Lambda Function - -You will create one additional Lambda function. While this function will do nothing, it is required by the *OPTIONS* method for CORS as described in a later section. - -Using the steps described above, create a Lambda function named `NoOp`. The function's code will be as follows: - -```js -exports.handler = function(event, context) { - context.succeed(''); -} -``` - -> Instead of creating this third Lambda function, you may choose to [create an OPTIONS method](#method-options) on the API Gateway. - -### 3. Create the Amazon API Gateway API - -You will create an API with two methods: one will `GET` pet information, and one will `POST` pet information. - -#### Method: `GET` Pet Information - -Go to the [Amazon API Gateway Console](https://console.aws.amazon.com/apigateway), and click **Create API**. If this is the first time you are creating an API, you will see a screen prompting you to **Get Started** instead. - -![Get started with API Gateway](/media/articles/integrations/aws-api-gateway/part-1/get-started-with-api-gateway.png) - -If this is the first time you are creating an API, you will be prompted to create an *Example API*. Click **OK** to exit the pop-up notification, and choose the **New API** radio button instead of the **Example API** button. - -![Create API Sample](/media/articles/integrations/aws-api-gateway/part-1/create-example-api.png) - -Name the API `SecurePets` and click **Create API**. - -![Create New API](/media/articles/integrations/aws-api-gateway/part-1/create-new-api.png) - -Navigate to the *Resources* tab of the `SecurePets` API and click the **Create Resource** action. - -![Create Resource](/media/articles/integrations/aws-api-gateway/part-1/create-resource.png) - -Name the resource `Pets` and click **Create Resource** again. - -![Create Name Resource](/media/articles/integrations/aws-api-gateway/part-1/name-resource.png) - -In the left pane, select `/pets` and then click the **CreateMethod** button. - -![Create Pets Method](/media/articles/integrations/aws-api-gateway/part-1/create-pets-method.png) - -In the drop-down, select *GET* and click the checkmark button. - -![Get Pets Method](/media/articles/integrations/aws-api-gateway/part-1/pets-method-get.png) - -Provide the following configuration values for the `GET` method: - -* **Integration type**: Lambda Function; -* **Lambda Region**: Region you are located in; -* **Lambda Function**: GetPetInfo. - -![Setup Get Pets Method](/media/articles/integrations/aws-api-gateway/part-1/pets-get-method-setup.png) - -Click **Save** and then **OK** when prompted in the popup to grant permissions to the Lambda function. - -![Set Lambda Permissions](/media/articles/integrations/aws-api-gateway/part-1/lambda-permissions.png) - -In the *Method Execution* window that appears next, click **Test**. - -![Method Execution](/media/articles/integrations/aws-api-gateway/part-1/method-execution.png) - -You should see the single pet returned in the response body. - -![Method Execution Results](/media/articles/integrations/aws-api-gateway/part-1/method-execution-results.png) - -#### Method: `POST` Pet Information - -Creating the API used to `POST` pet information is similar to creating the one used to `GET` pet information. - -In the left pane, select `/pets`, and click **CreateMethod**. - -In the drop-down, select *POST*, and click the checkmark button. - -Select *Lambda Function* for Integration Type, select the region you are located in, and select *UpdatePetInfo* for the Lambda function. - -Click **Save** and then **OK** when prompted in the popup to grant permissions to the Lambda function. - -**Test**, and paste the following for the request body: - -```js -{"pets": [ - {"id": 1, "type": "dog", "price": 249.99}, - {"id": 2, "type": "cat", "price": 124.99} - ] -} -``` - -![Post Method Request Test](/media/articles/integrations/aws-api-gateway/part-1/post-method-request-test.png) - -You should see an empty return result (`{}`). - -Return to the *GET* method, and click **Test** again to see that the response body indicates there are two pets listed in the table: - -```json -[ - { - "id": 1, - "price": 249.99, - "type": "dog" - }, - { - "id": 2, - "price": 124.99, - "type": "cat" - } -] -``` - -#### Method: `OPTIONS` - -Instead of creating a lambda function that performs no action, you can create an `OPTIONS` method on the API Gateway. - -In the left pane, select `/pets`, and click **CreateMethod**. In the drop down, select *OPTIONS*, and click the checkmark button. Select *Mock* for Integration Type. Click **Save**. - -![Configure Options Method](/media/articles/integrations/aws-api-gateway/part-1/options-method.png) - -Leaving the Response Body blank, click **Test**. You should receive a Response Body indicating `no data`. - -At this point, the AWS Lambda functions and the Amazon API Gateway methods are defined with no security. - -<%= include('./_stepnav', { - prev: ["0. Introduction", "/integrations/aws-api-gateway"], - next: ["2. Securing and Deploying", "/integrations/aws-api-gateway/part-2"] -}) %> diff --git a/articles/integrations/aws-api-gateway/part-2.md b/articles/integrations/aws-api-gateway/part-2.md deleted file mode 100644 index 498fe1836d..0000000000 --- a/articles/integrations/aws-api-gateway/part-2.md +++ /dev/null @@ -1,238 +0,0 @@ ---- -title: Amazon API Gateway Tutorial - Adding Security and Deploying -description: Step 2 of Amazon API Gateway Tutorial ---- - -# AWS API Gateway Tutorial -## Step 2 - Secure and Deploy the Amazon API Gateway - -Now that you have your API running, you need to add security. In this step, you will: - -* 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. - -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) - -You will see two ways of implementing this flow: - -1. Using Auth0 Delegation with AWS IAM; -2. Adding an identity token to flow identity to the Lambda function. - -Delegation makes it easy for you to obtain tokens from AWS to access AWS services in your application. - -### Ways to Secure the Amazon API Gateway - -AWS API Gateway provides several different methods to secure your APIs: - -1. API keys; -2. IAM; -3. [Amazon Cognito](/integrations/aws-api-gateway/secure-api-with-cognito). - -Using API keys is typically appropriate for a service-to-service interaction, as illustrated below. However, there are several downsides to this approach: - -* Placing a secret with a long lifetime on the client is risky (clients are easier to compromise); -* Creating a framework to issue and manage API keys requires a secure implementation that can be challenging to develop. - -This section of the tutorial will utilize [IAM roles and policies](http://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html) to secure your API in API Gateway, but you can also choose to do so using [user pools in Amazon Cognito](http://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html). See detailed instructions on doing so [here](/integrations/aws-api-gateway/secure-api-with-cognito). - -### 1. Configure IAM and Auth0 for SAML Integration with the API Gateway - -You can specify an AWS IAM role for the SAML token you exchange for an AWS token. Depending on the permissions granted to that IAM role (which are set using your identity provider), the received token possesses those same permissions. By issuing different SAML tokens, each with its own AWS IAM role, you can control the levels of access for your users. - -For example, the IDP could specify the IAM role based on group membership (for example, an administrator in Active Directory) or authentication source (for example, a database connection or a social provider like Facebook). This approach lets you differentiate user access to your Amazon API Gateway methods when secured using AWS IAM. - -#### Configure Auth0 - -Log in to your Auth0 account. You will be brought to the Management Dashboard. Click on **+ New Client**, which is located in the top right corner of the page. - -![Auth0 Management Dashboard](/media/articles/integrations/aws-api-gateway/part-2/mgmt-dashboard.png) - -Name your new client *AWS API Gateway*, and indicate that this Client is going to be a *Single Page Application*. Click **Create**. - -![Create Client](/media/articles/integrations/aws-api-gateway/part-2/create-new-client.png) - -Navigate to the *Addons* tab for your newly-created Client. Using the appropriate slide, enable *Amazon Web Services*. This turns on AWS Delegation. - -![Enable AWS for Client](/media/articles/integrations/aws-api-gateway/part-2/enable-aws-addon.png) - -#### Configure AWS - -Follow the [Set Up AWS for Delegated Authentication with APIs](/aws-api-setup) tutorial to configure AWS for delegated access, which uses SAML. Some caveats: - -* Follow the [instructions below](#setting-the-permissions-policy-on-your-iws-iam-role) for attaching the permissions policy to your role instead of the one for the linked tutorial; -* Name the SAML provider you create `auth0`; -* Name the AWS IAM role `auth0-api-role`. - -##### Set the Permissions Policy on Your IWS IAM Role - -Once you have configured the AWS IAM role, you will add a policy to `auth0-api-role` that lets you execute your API Gateway methods. - -> For more information on this process, please see [User Access Permissions for Amazon API Gateway](http://docs.aws.amazon.com/apigateway/latest/developerguide/permissions.html). - -::: panel-info Getting the Gateway API ARN - -Before you begin, you will need the ARN for your Gateway API: - -1. Navigate to [Amazon API Gateway Console](https://console.aws.amazon.com/apigateway) and log in. -2. Select the appropriate API. -3. Click on any of the Methods associated with the API to bring up the *Method Execution* page. -4. On the *Method Execution* page, the *Method Request* box in the top left corner displays the **ARN** for the API, though it includes the Method name: - -`arn:aws:execute-api:us-east-2:484857107747:97i1dwv0j4/*/POST/` - -You'll strip the method name to get the base ARN for the API: - -`arn:aws:execute-api:us-east-2:484857107747:97i1dwv0j4/*/` - -The wildcard (`*`) in the ARN above enables permissions to your API for all stages, but you can deploy different stages individually (for example, development, then test, then production). - -::: - -Select the `auth0-api-role` role you just created to open its *Summary* page. - -![Select IAM Role](/media/articles/integrations/aws-api-gateway/part-2/select-iam-role.png) - -Expand **Inline Policies**, and click **click here**. - -![Attach Policy](/media/articles/integrations/aws-api-gateway/part-2/attach-policy.png) - -Select **Custom Policy** and click **Select**. - -![Custom Policy](/media/articles/integrations/aws-api-gateway/part-2/custom-policy.png) - -Edit your policy document. You can set the **Policy Name** to whatever you would like, but we suggest something like `api-gateway-policy`. To enable access to the API methods for this role, apply the following policy *after* updating the ARN with the one for your API. - -```js -{ - "Version": "2012-10-17", - "Statement": [ - { - "Effect": "Allow", - "Action": [ - "execute-api:*" - ], - "Resource": [ - "arn:[YOUR_ARN]" - ] - } - ] -} -``` - -![Edit custom policy](/media/articles/integrations/aws-api-gateway/part-2/edit-custom-policy.png) - -Click **Apply Policy**. - -Since the API Gateway will assume this role on behalf of the user, the trust policy needs to permit this action. To do so, edit the role's *Trust Relationships* by navigating to this tab on the role's *Summary* page. - -The final trust relationship should look similar to the following: - -```js -{ - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "auth0", - "Effect": "Allow", - "Principal": { - "Federated": "arn:aws:iam::012345670:saml-provider/auth0-api" - }, - "Action": "sts:AssumeRoleWithSAML", - "Condition": { - "StringEquals": { - "SAML:iss": "urn:${account.namespace}" - } - } - }, - { - "Sid": "gateway", - "Effect": "Allow", - "Principal": { - "Service": "apigateway.amazonaws.com" - }, - "Action": "sts:AssumeRole" - } - ] -} -``` - -At this point, you will need to set the *Authorization Settings* on the [API Gateway](https://console.aws.amazon.com/apigateway). - -In the **Resources** view, select the *POST* method under `/pets`. - -![Post Method](/media/articles/integrations/aws-api-gateway/part-2/post-method-request.png) - -Click the **Method Request** link. - -![Set Authorization Settings for Method](/media/articles/integrations/aws-api-gateway/part-2/auth-settings.png) - -Click the edit icon beside the **Authorization Type**, and select *AWS_IAM*. Now click the **Check Button** beside the field to save the setting. - -### 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. - -> See [Enable CORS for a Method in API Gateway](http://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-cors.html) for details. - -Select `/pets` under Resources, and click **Create Method**. In the drop-down, select **OPTIONS**, and click the **checkmark** to save the setting. - -![Create Options Method](/media/articles/integrations/aws-api-gateway/part-2/create-options-method.png) - -The Options method is used by the browser to get the necessary HTTP headers, but the function needs further instructions on what to do. Under the `OPTIONS` Setup screen, set the following variables/parameters: - -* **Integration Type**: Lambda Function; -* **Use Lambda Proxy Integration**: *leave unchecked*; -* **Lambda Region**: *select your region*; -* **Lambda Function**: NoOp. - -![Configure Options Method](/media/articles/integrations/aws-api-gateway/part-2/config-options-method.png) - -Click **Save**. On the next pop-up screen, grant your Lambda function the permissions it needs. - -![Set Lambda Permissions](/media/articles/integrations/aws-api-gateway/part-2/permissions.png) - -You will then be auto-directed to the `OPTIONS` *Method Execution* page. Open the *Method Response* page. - -![Method Response](/media/articles/integrations/aws-api-gateway/part-2/method-response.png) - -Expand the **200** section located under the *HTTP Status* bar and add the following response headers: - -* *Access-Control-Allow-Headers*; -* *Access-Control-Allow-Methods*; -* *Access-Control-Allow-Origin*. - -![Add headers](/media/articles/integrations/aws-api-gateway/part-2/add-headers.png) - -Next, map the appropriate values to each of the response headers. After returning to the *Method Execution* page, click on **Integration Response**. After expanding the row associated with the **200** method response status, expand the **Header Mappings**, and apply the following mappings: - -* *Access-Control-Allow-Headers*: `'Content-Type,X-Amz-Date,Authorization,x-api-key,x-amz-security-token'`; -* *Access-Control-Allow-Origin*: `'*'` -* *Access-Control-Allow-Methods*: `'POST, GET, OPTIONS'` - -![Configure headers](/media/articles/integrations/aws-api-gateway/part-2/integration-response.png) - -Finally, repeat the above steps to enable CORS for the *POST* and *GET* methods. However, for these two methods, you will add one header, *Access-Control-Allow-Origin*, and its value should be set to `'*'`. - -### Deploy the API - -Return to the **Resources** view for your API. Click on **Actions**, and select **DEPLOY API**. - -![Choose Deployment Stage](/media/articles/integrations/aws-api-gateway/part-2/choose-deploy-stage.png) - -Select **New Stage** for Deploy State, and name the stage `Test`. Click the **Deploy** button. - -![Test Stage Editor](/media/articles/integrations/aws-api-gateway/part-2/test-stage-editor.png) - -On the result page, you will see a tab for **SDK Generation**. Click the tab and select *JavaScript* for the platform. Click the **Generate SDK** button. - -![Generate SDK](/media/articles/integrations/aws-api-gateway/part-2/sdk-generation.png) - -Save the downloaded zip file for later use. - -<%= include('./_stepnav', { - prev: ["1. Setup", "/integrations/aws-api-gateway/part-1"], - next: ["3. Building the Client Application", "/integrations/aws-api-gateway/part-3"] -}) %> diff --git a/articles/integrations/aws-api-gateway/part-3.md b/articles/integrations/aws-api-gateway/part-3.md deleted file mode 100644 index 7fa061aa03..0000000000 --- a/articles/integrations/aws-api-gateway/part-3.md +++ /dev/null @@ -1,243 +0,0 @@ ---- -title: Amazon API Gateway Tutorial - Building the Client App -description: Step 3 of Amazon API Gateway Tutorial ---- - -# AWS API Gateway Tutorial -## Step 3 - Build the Client Application - -In this step, you will build a single page, serverless client 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 - -For a simple starter app, download this seed project. - -<%= include('../../_includes/_package', { - org: 'auth0', - repo: 'auth0-aws', - path: 'examples/api-gateway/client' -}) %> - -Copy the contents of this seed project to a local folder called `pets`, which you will be using for the remainder of this tutorial. Within this folder, update `auth0-variables.js` with your Auth0 Client `AUTH0_CLIENT_ID` and `AUTH0_CLIENT_ID` (this information is available in the [Management Dashboard](${manage_url}/#/clients) for the client in question). - -> Be sure that you have [created the AWS S3 bucket configured to act as a static website](http://docs.aws.amazon.com/gettingstarted/latest/swh/website-hosting-intro.html). During the setup process, copy the contents of the `pets` folder to your S3 bucket to provide content for the website. -> -> If you are using a pre-existing bucket, you can move the files with the [AWS CLI](https://aws.amazon.com/cli/) using the following command: -> ``` -> aws s3 cp --recursive --acl "public-read" ./ s3://YOUR-BUCKET/ -> ``` - -Prior to proceeding, please be sure that you have at least one user associated with your *Username-Password-Authentication* (or the Database Connection associated with the Client you are using) Connection. To fully utilize the functionality of your sample app and its integration with AWS, you will need that user to test authentication and gain access. - -Lastly, ensure that Auth0 allows authentication from your website by providing the URL in the **Allowed Origins** field in the *Settings* page of your Client. Your website's URL should look something like this: - -`http://your-bucket.s3-website-us-east-1.amazonaws.com` - -If you don't know what your URL is, you can find it listed under the **Properties** tab of your S3 bucket. - -Before going further, test logging into your application. Open `http://your-bucket-domain/index.html` in your browser. After logging in, you should see an alert box pop up that says "getPets not implemented": - -![Pop up with Get Method Error](/media/articles/integrations/aws-api-gateway/part-3/log-in-popup.png) - -You should also see the page for viewing pets. - -![Log in success screen](/media/articles/integrations/aws-api-gateway/part-3/log-in-success.png) - -### 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: - -![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. - -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. - - -```js -auth.signin(params, function(profile, token) { - store.set('profile', profile); - store.set('token', token); - -// set admin and get delegation token from identity token. -profile.isAdmin = !profile.identities[0].isSocial; -var options = getOptionsForRole(profile.isAdmin, token); - -auth.getToken(options) - .then( - function(delegation) { - store.set('awstoken', delegation.Credentials); //add to local storage - $location.path("/"); - }, - function(err) { - console.log('failed to acquire delegation token', err); - }); -}, function(error) { - console.log("There was an error logging in", error); -}); -``` - -#### Modify the `role` and `principal` Strings - -To modify the `role` and `principal` strings (which are the final two lines of the `if` statement contained in the provided function), specify the appropriate values via [Rules](${manage_url}/#/rules): - -```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); -} -``` - -:::panel-info Rules -[How to Work with Rules](/docs/rules#video-using-rules) -::: - -Be sure to update the `role` and `[principal]` ARN values with the ones for your integration. - -Copy the updated files to your S3 bucket for your website. - -Optionally, you can set a breakpoint in the browser at `store.set('awstoken', delegation.Credentials);`. When you log out and and log back in, inspect `delegation.Credentials` when you arrive at the breakpoint. You will see a familiar values like *AccessKeyId* and *SecretAccessKey*: - -```js -{ - AccessKeyId: "ASIAJB...BNQ", - SecretAccessKey: "vS+b6...2Noav", - SessionToken: "AQoDYBqsivOV...DdQW0gsKr8rgU=", - Expiration: "2015-08-27T14:48:32.000Z" -} -``` - -If you don't see these values, be sure that you have the *Amazon Web Services addon* enabled in the *Addons* tab for your Auth0 Client. - -### Display Pets with the AWS API Service - -The first thing you will do is show the pets to the end users. - -#### Add the API Code to Call Your API - -To add the API code for adding a call to your service, copy the contents of *apiGateway-js-sdk.zip* you [previously downloaded](/integrations/aws-api-gateway/part-2/#deploy-the-api) to the `pets` directory. The contents should include: - -* `apiClient.js`; -* `lib` folder; -* `README.md`. - -There is already a `README.md` in the `pets` directory, so you will need to rename one of the files to keep both in the directory. The `README.md` for the API gateway explains how to use the API client from your Auth0 Client. - -Open the `index.html` file located in the root of your `pets` folder to add all of the scripts listed at the top of the API readme to `index.html`: - -```html - - - - - - - - - - - - -``` - -If you open `apigClient.js`, you can see that the downloaded library has created wrappers like `petsPost` and `petsGet` for your API methods. You do *not* need to modify this generated code. - -#### Configure the `getPets` Method - -Open `home.js` in the `home` folder, and update the contents of `getPets` with a method for retrieving pets data (be sure to update the region if you are not running in `us-east-1`): - -```js -function getPets() { - // this is unauthenticated - var apigClient = apigClientFactory.newClient({ - region: 'us-east-1' // The region where the API is deployed - }); - - apigClient.petsGet({},{}) - .then(function(response) { - console.log(response); - $scope.pets = response.data; - $scope.$apply(); - }).catch(function (response) { - alert('pets get failed'); - showError(response); - }); -} -``` - -Copy the updated code to your S3 bucket. Refresh the page to see two animals listed (if you ran the previously described test on your APIs that created these pets). - -![API Get Method Success](/media/articles/integrations/aws-api-gateway/part-3/get-success.png) - -### Update Pets with the AWS API Service - -Now that you have a working Auth0 Client with the API Gateway, you will add a method for updating the `pets` table. - -Modify the `putPets` method logic to update pets using your API function. This function will be used for both adding and removing pets. - -```js -function putPets(updatedPets) { - var body = {pets: updatedPets}; - - var apigClient = apigClientFactory.newClient({ - region: 'us-east-1' // set this to the region you are running in. - }); - - apigClient.petsPost({},body) - .then(function(response) { - console.log(response); - }).catch(function (response) { - alert('pets update failed'); - showError(response); - }); -} -``` - -Copy the updated code to your S3 bucket. Test the method: - -1. Log out and log back in. -2. Enter in values for `Pet Type` and `Pet Price`. -3. Click **Save** to post your data. - -You should see a message that says, "We have a `` for sale for ``" with a red **REMOVE** button to its left. - -![Post Method Success Screen](/media/articles/integrations/aws-api-gateway/part-3/add-frog-success.png) - -To add security, add the `getSecureApiClient` function at the start of the `putPets` method: - -```js - -function putPets(updatedPets) { - var apigClient = getSecureApiClient(); -} -``` - -Copy the code to your S3 bucket. - -The `getSecureApiClient` function provided for you retrieves the AWS token from local storage acquired using delegation to the API, and uses the access key, secret, and session token: - -```js - function getSecureApiClient() { - var awstoken = store.get('awstoken'); - - return apigClientFactory.newClient({ - accessKey: awstoken.AccessKeyId, - secretKey: awstoken.SecretAccessKey, - sessionToken: awstoken.SessionToken, - region: 'us-east-1' // The region you are working out of. - }); - } -``` - -<%= include('./_stepnav', { - prev: ["2. Securing and Deploying", "/integrations/aws-api-gateway/part-2"], - next: ["4. Using Multiple Roles", "/integrations/aws-api-gateway/part-4"] -}) %> diff --git a/articles/integrations/aws-api-gateway/part-4.md b/articles/integrations/aws-api-gateway/part-4.md deleted file mode 100644 index 07ddb6e068..0000000000 --- a/articles/integrations/aws-api-gateway/part-4.md +++ /dev/null @@ -1,322 +0,0 @@ ---- -title: Amazon API Gateway Tutorial - Using Multiple Roles -description: Step 4 of Amazon API Gateway Tutorial ---- - -# AWS API Gateway Tutorial -## Step 4 - Use Multiple Roles with Amazon API Gateway - -In this step, you'll assign different AWS IAM roles to users based on authentication information: - -* Users authenticating with Social Connections will be treated as buyers; -* Users authenticating with Database Connections will be treated as admins. - -You will perform this role assignment logic in two different ways: - -* JavaScript; -* Auth0 rules. - -For many Auth0 Clients, you'll want different users to have different levels of access, and you'll want additional information about a given identity to use in your service logic. In cases where it's sufficient to lock down access at the API level, you can use different AWS IAM roles (for example, administrators can use the update function to *add* and *remove* pets, but social users can only *buy* pets). - -The following diagram illustrates AWS IAM role assignments for two different user classes: users authenticated via Social Connections and users authenticated via Database Connections. It also illustrates that AWS IAM roles can be assigned to other entities, like AWS Lamdba functions, to control the permissions these entities are assigned for an account. In short, an IAM role is a group of permissions to AWS capabilities that is defined by one or more policies and then assigned to an entity. - -![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). - -### 1. Create the PetPurchase API Resource - -Using the [Amazon API Gateway Console](https://console.aws.amazon.com/apigateway), select your *Pets* API. You will be taken to its *Resources* page. - -![Create New Resource](/media/articles/integrations/aws-api-gateway/part-4/create-resource.png) - -Click on **Actions** and **Create Resource**. Name the *New Child Resource* `Purchase`. Click **Create Resource**. - -![Create Child Resource](/media/articles/integrations/aws-api-gateway/part-4/new-child-resource.png) - -Add an *OPTIONS* method for the `purchase` resource as outlined previously for `pets` in the [Set Up Cors and Deploy the API section of Step 2 - Securing and Deploying the Amazon API Gateway](/integrations/aws-api-gateway/part-2#set-up-cors-and-deploy-the-api). - -[Create a new AWS Lambda function](/integrations/aws-api-gateway/part-1#2-create-the-aws-lambda-functions) for purchasing a pet called `PetPurchase`, which adds `isSold` and `soldTo` attributes to a pet as follows: - -```js -var AWS = require('aws-sdk'); -var DOC = require('dynamodb-doc'); -var dynamo = new DOC.DynamoDB(); - -exports.handler = function(event, context) { - var petId = event.petId; - var user = event.userName; - var pets = {}; - console.log('start PetsPurchase, petId', petId, ' userName', user); - - var writecb = function(err, data) { - if(!err) { - context.done(null, pets); - } else { - console.log('error on GetPetsInfo: ',err); - context.done('failed on update', null); - } - }; - - var readcb = function(err, data) { - if(err) { - console.log('error on GetPetsInfo: ',err); - context.done('failed to retrieve pet information', null); - } else { - // make sure we have pets - if(data.Item && data.Item.pets) { - pets = data.Item.pets; - var found = false; - - for(var i = 0; i < pets.length && !found; i++) { - if(pets[i].id === petId) { - if(!pets[i].isSold) { - pets[i].isSold = true; - pets[i].soldTo = user; - var item = { username:"default",pets: pets}; - dynamo.putItem({TableName:"Pets", Item:item}, writecb); - found = true; - } - } - } - if(!found) { - console.log('pet not found'); - context.done('That pet is not available.', null); - } - } else { - console.log('pet already sold'); - context.done('That pet is not available.', null); - } - } - }; - - dynamo.getItem({TableName:"Pets", Key:{username:"default"}}, readcb); -}; -``` - -Once you have defined the Lambda function, [add a *POST* method to the `purchase` resource](/integrations/aws-api-gateway/part-1#method-post-pet-information) that calls the `PetPurchase` Lambda. Be sure to also add the `Access-Control-Allow-Origin` header with a value of `*` to the *POST* method using the [method response/integration response configuration](/integrations/aws-api-gateway/part-2#set-up-cors-and-deploy-the-api). - -Test the API gateway method, providing the following as an input message: - -```js - { - "petId": 1, - "userName": "fred flintstone" - } -``` - -In the test response, you should see the pet with ID of 1 is now sold to Fred Flintstone: -```js -[ - { - "id": 1, - "price": 249.99, - "type": "dog", - "isSold": true, - "soldTo": "fred flintstone" - }, - - ... -``` - -### 2. Use IAM to Secure the PurchasePet API - -#### Update IAM - -To secure your API, follow the same process for adding a new role that you [performed in Part 2](/integrations/aws-api-gateway/part-2) of this tutorial. Call the new role `auth0-api-social-role`. - -The ARN for the method you will secure in the IAM policy should look something like: - -``` -arn:aws:execute-api:us-east-1:your-accountid:your-api-id/*/pets/purchase -``` - -Be sure to update the trust policy as well. - -Go to the [Amazon API Gateway Console](https://console.aws.amazon.com/apigateway), and select the *POST* method for the `/pets/purchase` resource. Select **Method Request** and change **Authorization Type** to *AWS_IAM*. Click the check to save the setting. - -At this point, you have defined two roles that you can use with the API gateway: - -* `auth0-api-role`: permits updating pets -* `auth0-api-social-role`: permits purchasing a pet - -#### Configure Login with Amazon and Update Auth0 - -You can create a social role using Login with Amazon (LWA). - -> While this tutorial includes instructions for using Login with Amazon, please note that you can use other social providers as well. - -Go to the [Auth0 Management Dashboard](${manage_url}). Select **Connections**, then **Social** in the drop-down menu. Enable the connection for Amazon by setting the slide to the right so that it turns green. - -![Enable AWS](/media/articles/integrations/aws-api-gateway/part-4/enable-amazon.png) - -You will now see a pop-up that walks you through the configuration process. - -![Configure AWS](/media/articles/integrations/aws-api-gateway/part-4/configure-amazon.png) - -Once you've selected the Clients that will be using this social connection, you will be prompted to enter values for the following fields: - -* *client id*; -* *client secret*. - -If you haven't used Login with Amazon before, there is also a link called **How to Obtain a Client ID**". Click on this link and follow the process to obtain the *client id* and *client secret* values. - -Once you've entered the appropriate information, click **Try** to ensure that everything is set up correctly. - -> When you configure LWA using the Amazon console, be sure to enter into *Allowed Return URLs* the callback URL to your Auth0 Client, 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 **Clients**, select your Client, 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 - -Using the [Amazon API Gateway Console](https://console.aws.amazon.com/apigateway), you will again [deploy the API and generate a new JavaScript SDK](/integrations/aws-api-gateway/part-2#set-up-cors-and-deploy-the-api). - -At this point, you have made the necessary configuration changes to enable pet purchases. To make this live, copy your newly downloaded SDK over the previous one in your `pets` folder, as well as your Amazon S3 bucket. - -##### Update the Login Controller Logic to Choose Different Roles for Different Types of Users - -The login controller logic uses `getOptionsForRole` to select different roles for different users. When you obtain the delegation token, you can tell Auth0 which role to use (that is, the user is an admin or not). - -In the `pets/login/login.js` file, modify the `role` and `principal` values for the non-admin user for the social user IAM role you just created. - -At this point, you should be able to log in using Amazon credentials **or** the database user you previously created. Notice that the UI lets a social user buy pets, while an admin user can add and remove pets. - -To test this functionality, you can temporarily hide the remove button in the UI by removing `ng-show="isAdmin"` in `/pets/home/home.html`: - -``` - -``` - -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 Client (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 Client; -* 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 client (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 Client Application", "/integrations/aws-api-gateway/part-3"], - next: ["5. Using Identity Tokens", "/integrations/aws-api-gateway/part-5"] -}) %> diff --git a/articles/integrations/aws-api-gateway/part-5.md b/articles/integrations/aws-api-gateway/part-5.md deleted file mode 100644 index 45a99faa88..0000000000 --- a/articles/integrations/aws-api-gateway/part-5.md +++ /dev/null @@ -1,166 +0,0 @@ ---- -title: Amazon API Gateway Tutorial - Flowing Identity -description: Step 5 of Amazon API Gateway Tutorial ---- - -# AWS API Gateway Tutorial -## 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. - -> 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 Client 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/part-4"] -}) %> diff --git a/articles/integrations/aws-api-gateway/secure-api-with-cognito.md b/articles/integrations/aws-api-gateway/secure-api-with-cognito.md deleted file mode 100644 index e98bc169cb..0000000000 --- a/articles/integrations/aws-api-gateway/secure-api-with-cognito.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -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. ---- - -# 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. - -> 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 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/articles/integrations/aws.md b/articles/integrations/aws.md deleted file mode 100644 index b9ce35714a..0000000000 --- a/articles/integrations/aws.md +++ /dev/null @@ -1,306 +0,0 @@ ---- -description: How to setup AWS Integration in Auth0. How to setup SSO and obtain AWS tokens. ---- - -# AWS Integration in Auth0 - -Auth0 ships with AWS IAM integration that allows you to: - - * [Perform SSO with the AWS Dashboard](#sso-with-the-aws-dashboard) - * [Obtain AWS Tokens to securely call AWS APIs and resources](#obtain-aws-tokens-to-securely-call-aws-apis-and-resources) - -## SSO with the AWS Dashboard - -By integrating Auth0 and AWS you will be able to login to the AWS Dashboard with any of the supported [Auth0 Identity Providers](/identityproviders). To configure Auth0 for federation with AWS using SAML, follow the steps below: - -1. On the Auth0 [Dashboard](${manage_url}/#/applications), add a new app. In the **Addons** tab of the app settings page, enable the **SAML2 Web App** add-on. - - ![](/media/articles/integrations/aws/addons.png) - -2. Under the **Settings** tab of the **SAML2 Web App Addon** page, enter `https://signin.aws.amazon.com/saml` for the **Application Callback URL** and paste the following default SAML configuration code into the *Settings* box: - - ```js - { - "audience": "https://signin.aws.amazon.com/saml", - "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:2.0:nameid-format:persistent", - "nameIdentifierProbes": [ - "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", - ] - } - ``` - - Scroll to the bottom of the page and click **Save**: - - ![](/media/articles/integrations/aws/configure.png) - -3. Auth0 needs to be configured as the identity provider (IdP) for AWS. AWS requires an **IdP Metadata** file to import. - Select the **Usage** tab and click the **Identity Provider Metadata** download link to save the file: - - ![](/media/articles/integrations/aws/idp-download.png) - -4. Create a SAML provider. - - 4.1. From the [IAM console](https://console.aws.amazon.com/iam/home#home), select **Identity Providers** in the left menu and click **Create Provider**. - - 4.2. Select **SAML** in the **Provider Type** dropdown, enter a name for your provider and browse for the metadata document you downloaded in the **Step 3**. Click **Next Step**. - - ![](/media/articles/integrations/aws/aws-configure-provider.png) - - 4.3. Verify your settings and click **Create**. - -5. Now you must create a role in AWS in a specific way to allow its use to gain access to AWS. For more information on creating roles, see [Creating SAML Identity Providers](http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html). - - 5.1. From the [IAM console](https://console.aws.amazon.com/iam/home#home), select **Roles** in the left menu, then click **Create New Role**: - - ![](/media/articles/integrations/aws/iam-new-role.png) - - 5.2. Enter a name for the role and click **Next Step**. - - 5.3. Select **Role for Identity Provider Access**. Then select **Grant Web Single Sign-On (WebSSO) access to SAML providers**: - - ![](/media/articles/integrations/aws/iam-role-type.png) - - 5.4. On the next screen, accept the default `SAML:aud` value of `https://signin.aws.amazon.com/saml`, and click **Next Step**. - - 5.5. Accept the **Role Trust** proposed. (This policy tells IAM to trust the Auth0 SAML IDP.) Click **Next Step**. - - 5.6. Choose an appropriate access policy for this role. This defines the permissions that the user granted this role will have with AWS. For example, to only let users read information in the console, select the `ReadOnlyAccess` policy. Click **Next Step**. - - 5.7. Review the role information, then click **Create Role**: - - ![](/media/articles/integrations/aws/iam-review-role.png) - -6. Write a [Rule](/rules) to map the AWS role to a user. - - The **AWS roles** you send will be associated to an **AWS IAM Policy** that will enforce the type of access allowed for a resource, including the AWS dashboard. (For more information on roles and policies, see [Creating IAM Roles](http://docs.aws.amazon.com/IAM/latest/UserGuide/roles-creatingrole.html)) Notice the **AWS Role** has a structure of `{Fully qualified Role name},{Fully qualified identity provider}`. The IdP is identified as `arn:aws:iam::951887872838:saml-provider/MyAuth0` in the sample below: - - ```js - function (user, context, callback) { - - user.awsRole = 'arn:aws:iam::951887872838:role/TestSAML,arn:aws:iam::951887872838:saml-provider/MyAuth0'; - user.awsRoleSession = 'eugeniop'; - - context.samlConfiguration.mappings = { - 'https://aws.amazon.com/SAML/Attributes/Role': 'awsRole', - 'https://aws.amazon.com/SAML/Attributes/RoleSessionName': 'awsRoleSession' - }; - - callback(null, user, context); - - } - ``` - - Notice that you can obtain these 2 values in multiple ways. The above example hardcodes them. You could store these in the *User Profile*, or you could derive them from other attributes. For example, you might use Active Directory and have properties already associated with users (e.g. `groups`). You can then define a map between `groups` and `AWS roles`: - - ```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' - }; - - context.samlConfiguration.mappings = { - 'https://aws.amazon.com/SAML/Attributes/Role': awsRoles[user.group], - 'https://aws.amazon.com/SAML/Attributes/RoleSessionName': user.name, - }; - ``` - -You are now setup for single sign-on to AWS. You can find the `Identity Provider Login URL` on the Auth0 Dashboard. Go to the **SAML2 Addon** settings page of your app, and select the **Usage** tab. - -![](/media/articles/integrations/aws/idp-url.png) - -To use the single sign-on, navigate to that URL, and you will be brought to the Auth0 login. After signing in, you will be redirected to AWS. - -**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). - -## Obtain AWS Tokens to securely call AWS APIs and resources - -This delegation scenario is more versatile. Auth0 interacts with **AWS STS** directly to obtain an **AWS token** that can be used to call the AWS API of any Auth0-supported [Identity Provider](/identityproviders). - -![](/media/articles/integrations/aws/aws-sts.png) - -In **Step 1** of the example above, a web application authenticates users with social providers (e.g. GitHub, LinkedIn, Facebook, Twitter) or with corporate credentials (e.g. Active Directory, Office365 and Salesforce). - -In **Step 2**, the app calls the **Identity delegation** endpoint in Auth0 and requests an AWS Token. - -Auth0 obtains the token from AWS STS in **Step 3**. - -The app can then use the AWS Token to connect with S3 or EC2 or any AWS API. - -### Setup delegation - -On the Auth0 [Dashboard](${manage_url}/#/applications), select your app. In the **Addons** tab of the app settings page, enable the **Amazon Web Services** add-on. - -![](/media/articles/integrations/aws/aws-addon.png) - -**NOTE:** For more detailed instructions on delegation, see [How to Setup AWS to do Delegated Authentication with APIs](/aws-api-setup). - -### Username Length with AWS - -Auth0 DB and custom DB users should take note that AWS requires usernames to be between 2-64 characters long. If you intend to use use Auth0 DB alongside of AWS here, change your [username length settings](/connections/database/require-username#length) accordingly in your Auth0 dashboard. - -Custom DB users should implement a similar username length policy in their application to ensure that this integration works. See this [AWS Troubleshooting Page](http://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_saml.html#troubleshoot_saml_invalid-rolesessionname) for more information. - -### IAM policy - -Here is an example of an IAM policy: - - { - "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" - } - ] - } - -This is a *dynamic* policy that gives access to a folder in a bucket. The folder name will be set based on an attribute of the digitally signed SAML token that Auth0 exchanges with AWS on your behalf (**Step 3** in the graphic). - -The `<%= "${saml:sub}" %>` will be automatically mapped from the authenticated user (`sub` means `subject`, and is equal to the user identifier). This means that the *original* identity of the user can be used throughout the system (in your app, S3, etc.). - -### Get the AWS token for an authenticated user - -When a user authenticates with Auth0, an `id_token` (as a [JWT](/jwt)) is returned. 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: - -```sh -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": "aws", -} -``` - -Where: - -* **client_id** identifies the requesting app (e.g. your website) -* **id_token** identifies the user you are requesting this on behalf-of -* **target** identifies this API endpoint in Auth0 (often the same as client_id). -* **api_type** must be aws - -Additionally, AWS requires two additional parameters, **role** and **principal**. To modify the `role` and `principal` strings, specify the appropriate values via [Rules](${manage_url}/#/rules): - -```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); -} - -``` - -You can optionally set `context.addonConfiguration.aws.region` to specifically target an 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: - - 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' - } - -But [other mappings are available in AWS](http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml_assertions.html). For example, if you wanted to use the `eduPersonAffiliation` AWS Context Key then you could set these mapping in a rule: - -```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. - -**NOTE:** Copy the Provider ARN, and use this as the Principal ARN when obtaining the delegation token. - -The result of calling the delegation endpoint will contain the AWS token in the `Credentials` field. i.e.: - -```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-info Auth0 Libraries -The [Auth0 client 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`. -::: - -Here is an example of client-side code used to obtain the token: - -```html - - -``` - -> Checkout a complete sample for S3 on GitHub: [https://github.com/auth0/auth0-s3-sample](https://github.com/auth0/auth0-s3-sample). diff --git a/articles/integrations/aws/aws-api-setup.md b/articles/integrations/aws/aws-api-setup.md new file mode 100644 index 0000000000..4612c92ce4 --- /dev/null +++ b/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/articles/integrations/aws/index.md b/articles/integrations/aws/index.md new file mode 100644 index 0000000000..e61b193cd1 --- /dev/null +++ b/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/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 new file mode 100644 index 0000000000..cd4f6d2506 --- /dev/null +++ b/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/articles/integrations/aws/tokens.md b/articles/integrations/aws/tokens.md new file mode 100644 index 0000000000..cd984901df --- /dev/null +++ b/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/articles/integrations/azure-api-management/_stepnav.html b/articles/integrations/azure-api-management/_stepnav.html new file mode 100644 index 0000000000..f679e60997 --- /dev/null +++ b/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/articles/integrations/azure-api-management/configure-auth0.md b/articles/integrations/azure-api-management/configure-auth0.md new file mode 100644 index 0000000000..d8eb7151d5 --- /dev/null +++ b/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/articles/integrations/azure-api-management/configure-azure.md b/articles/integrations/azure-api-management/configure-azure.md new file mode 100644 index 0000000000..fd8219189b --- /dev/null +++ b/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/articles/integrations/azure-api-management/index.md b/articles/integrations/azure-api-management/index.md new file mode 100644 index 0000000000..f3419f00af --- /dev/null +++ b/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/articles/integrations/azure-tutorial.md b/articles/integrations/azure-tutorial.md new file mode 100644 index 0000000000..e3f8078c28 --- /dev/null +++ b/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/articles/integrations/box.md b/articles/integrations/box.md deleted file mode 100644 index 4e91f70e1b..0000000000 --- a/articles/integrations/box.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Box -description: How to add Single Sign On (SSO) integration with Box. ---- -<%= include('./_template', { - image1: "tutorial-box.png" -}) %> diff --git a/articles/integrations/cloudbees.md b/articles/integrations/cloudbees.md deleted file mode 100644 index 9c9202e7fe..0000000000 --- a/articles/integrations/cloudbees.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: CloudBees -description: How to add Single Sign On (SSO) integration with Cloudbees. ---- -<%= include('./_template', { - image1: "tutorial-cloudbees.png" -}) %> diff --git a/articles/integrations/concur.md b/articles/integrations/concur.md deleted file mode 100644 index 37df727ca9..0000000000 --- a/articles/integrations/concur.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Concur -description: How to add Single Sign On (SSO) integration with Concur. ---- -<%= include('./_template', { - image1: "tutorial-concur.png" -}) %> diff --git a/articles/integrations/configure-wsfed-application.md b/articles/integrations/configure-wsfed-application.md new file mode 100644 index 0000000000..d6629e86c7 --- /dev/null +++ b/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/articles/integrations/dropbox.md b/articles/integrations/dropbox.md deleted file mode 100644 index 267103c684..0000000000 --- a/articles/integrations/dropbox.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Dropbox -description: How to add Single Sign On (SSO) integration with Dropbox. ---- -<%= include('./_template', { - image1: "tutorial-dropbox.png" -}) %> diff --git a/articles/integrations/dynamic-crm.md b/articles/integrations/dynamic-crm.md deleted file mode 100644 index 3f6dce05aa..0000000000 --- a/articles/integrations/dynamic-crm.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Dynamic CRM -description: How to add Single Sign On (SSO) integration with Dynamic CRM. ---- -<%= include('./_template', { - image1: "tutorial-dynamiccrm.png" -}) %> diff --git a/articles/integrations/echosign.md b/articles/integrations/echosign.md deleted file mode 100644 index 44e678557b..0000000000 --- a/articles/integrations/echosign.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: EchoSign -description: How to add Single Sign On (SSO) integration with EchoSign. ---- -<%= include('./_template', { - image1: "tutorial-echosign.png" -}) %> diff --git a/articles/integrations/egnyte.md b/articles/integrations/egnyte.md deleted file mode 100644 index e175f78b08..0000000000 --- a/articles/integrations/egnyte.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Egnyte -description: How to add Single Sign On (SSO) integration with Egnyte. ---- -<%= include('./_template', { - image1: "tutorial-egnyte.png" -}) %> diff --git a/articles/integrations/google-cloud-platform.md b/articles/integrations/google-cloud-platform.md new file mode 100644 index 0000000000..5b8581ee99 --- /dev/null +++ b/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/articles/integrations/index.md b/articles/integrations/index.md new file mode 100644 index 0000000000..c73d303ef5 --- /dev/null +++ b/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/articles/integrations/integrating-auth0-amazon-cognito-mobile-apps.md b/articles/integrations/integrating-auth0-amazon-cognito-mobile-apps.md new file mode 100644 index 0000000000..77803499d1 --- /dev/null +++ b/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/articles/integrations/marketing/adobe-campaign/index.md b/articles/integrations/marketing/adobe-campaign/index.md new file mode 100644 index 0000000000..9e1dcd8e58 --- /dev/null +++ b/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/articles/integrations/marketing/alterian/index.md b/articles/integrations/marketing/alterian/index.md new file mode 100644 index 0000000000..5f39fbdff9 --- /dev/null +++ b/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/articles/integrations/marketing/constant-contact/index.md b/articles/integrations/marketing/constant-contact/index.md new file mode 100644 index 0000000000..55048e1ca4 --- /dev/null +++ b/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/articles/integrations/marketing/eloqua/index.md b/articles/integrations/marketing/eloqua/index.md new file mode 100644 index 0000000000..7b3e3bad71 --- /dev/null +++ b/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/articles/integrations/marketing/index.md b/articles/integrations/marketing/index.md new file mode 100644 index 0000000000..b562fe8e1b --- /dev/null +++ b/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/articles/integrations/marketing/mailchimp/index.md b/articles/integrations/marketing/mailchimp/index.md new file mode 100644 index 0000000000..6b9c68dafc --- /dev/null +++ b/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/articles/integrations/marketing/marketo/index.md b/articles/integrations/marketing/marketo/index.md new file mode 100644 index 0000000000..4df61e62c9 --- /dev/null +++ b/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/articles/integrations/marketing/sailthru/index.md b/articles/integrations/marketing/sailthru/index.md new file mode 100644 index 0000000000..c4eaeb32a1 --- /dev/null +++ b/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/articles/integrations/marketing/salesforce-marketing-cloud/index.md b/articles/integrations/marketing/salesforce-marketing-cloud/index.md new file mode 100644 index 0000000000..95a203e3a0 --- /dev/null +++ b/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/articles/integrations/marketing/salesforce/index.md b/articles/integrations/marketing/salesforce/index.md new file mode 100644 index 0000000000..586964c0f1 --- /dev/null +++ b/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/articles/integrations/marketing/watson-campaign-automation/index.md b/articles/integrations/marketing/watson-campaign-automation/index.md new file mode 100644 index 0000000000..5f65f357ce --- /dev/null +++ b/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/articles/integrations/new-relic.md b/articles/integrations/new-relic.md deleted file mode 100644 index 696f6839cd..0000000000 --- a/articles/integrations/new-relic.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: New Relic -description: How to add Single Sign On (SSO) integration with New Relic. ---- -<%= include('./_template', { - image1: "tutorial-newrelic.png" -}) %> diff --git a/articles/integrations/office-365-custom-provisioning.md b/articles/integrations/office-365-custom-provisioning.md index ced6bce509..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 @@ -16,19 +24,22 @@ The [Office 365 tutorial](/integrations/office-365) explains how to register a c 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. -Go to [the Azure Management Portal](https://manage.windowsazure.com/@auth0testenv.onmicrosoft.com#Workspaces/ActiveDirectoryExtension) and create a new application in your Azure AD Directory: - -![Create Azure AD Application](/media/articles/integrations/office-365/office-365-create-app.png) - -Choose **Add an application my organization is developing**, give it a name (eg: **Auth0 Provisioning**). For the Sign-On Url and App ID Url any value will do (eg: **http://mycompany.com/auth0-provision**). - -On the **Configure** tab of the application you will be able to generate a new key. The Client ID and the key on this page will give you access to the Graph API: - -![Azure AD Client ID and Key](/media/articles/integrations/office-365/office-365-app-key.png) - -> Note: They key generated here is valid for 1 or 2 years. Make sure you generate a new key before it expires and you update it in Auth0 accordingly. - -The final step in the Azure AD configuration is to give the required permissions to the application. Under **Application Permissions** (at the bottom of the page) you will need to choose **Read and write directory data**. This will allow your application to create new users in Azure AD. +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 @@ -36,228 +47,222 @@ 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. Continue with the login transaction. + 5. Assign a license to the user. + 6. Continue with the login transaction. -The username is generated with the `AAD_USERNAME_GENERATOR` 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. +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'; - var AUTH0_OFFICE365_CLIENTID = 'CLIENT_ID_OF_MY_THIRD_PARTY_APP_IN_AUTH0'; - - var AAD_CUSTOM_DOMAIN = 'fabrikamcorp.be'; - var AAD_TENANT_NAME = 'fabrikamcorp365.onmicrosoft.com'; - var AAD_CLIENT_ID = 'AZURE_AD_CLIENT_ID'; - var AAD_CLIENT_SECRET = 'AZURE_AD_CLIENT_SECRET'; - // https://go.microsoft.com/fwLink/?LinkID=335775&clcid=0x409 + // 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'; - var AAD_USER_CREATE_WAIT = 15000; - var AAD_USERNAME_GENERATOR = function() { - - // Will generate something like: - // auth0-c3fb6eec-3afd-4d52-8e0a-d9f357dd19ab@fabrikamcorp.be - var uuid = require('node-uuid').v4(); - return 'auth0-' + uuid + '@' + AAD_CUSTOM_DOMAIN; - }; + // 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 (context.clientID === AUTH0_OFFICE365_CLIENTID) { - // Check if the user was already provisioned. - user.app_metadata = user.app_metadata || {}; - if (user.app_metadata.office365_provisioned) return continue_with_azuread_user(); - - // Generate a new uuid. - var uuid = require('node-uuid').v4(); - var immutable_id = guid_to_base64(uuid); - - // Log context. - console.log('Preparing user provisioning:'); - console.log(' > uuid:', uuid); - console.log(' > immutable_id:', immutable_id); + // 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(); + } - // Get the token. - get_azuread_token(function(err, token) { - if (err) return callback(err); + // 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' + }, + }; - var context = { - displayName: user.nickname, - mailNickname: user.email.split('@')[0], - userPrincipalName: 'auth0-' + uuid + '@' + AAD_CUSTOM_DOMAIN, - uuid: uuid, - immutableId: immutable_id - }; - - // Create the user. - provision_azuread_user(token, context, function(err) { - if (err) return callback(err); - - console.log('Done! Storing info in user profile.'); - - // Update the user. - user.app_metadata.office365_provisioned = true; - user.app_metadata.office365_upn = context.userPrincipalName; - user.app_metadata.office365_immutable_id = context.immutableId; - auth0.users.updateAppMetadata(user.user_id, user.app_metadata) - .then(function() { - // Wait a little bit, it takes some time before the user is created. - setTimeout(function() { - return continue_with_azuread_user(); - }, AAD_USER_CREATE_WAIT); - }) - .catch(function(err) { - console.log('Error updating user profile:', err); - return callback(err); - }); - }); - }); - } - else { - return callback(null, user, context); + return rp(options); } - /* - * Continue the login... - */ - function continue_with_azuread_user() { - user.app_metadata = user.app_metadata || {}; - user.upn = user.app_metadata.office365_upn; - user.inmutableid = user.app_metadata.office365_immutable_id; - console.log('Logging in user:', { - upn: user.upn, - immutable_id: user.inmutableid - }); - return callback(null, user, context); - } + // 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; - /* - * Create the user in Azure AD. - */ - function provision_azuread_user(token, context, cb) { var options = { - url: 'https://graph.windows.net/' + AAD_TENANT_NAME + - '/users?api-version=1.5', + url: 'https://graph.windows.net/' + AAD_DOMAIN + '/users?api-version=1.6', headers: { 'Content-type': 'application/json', 'Authorization': 'Bearer ' + token }, json: true, body: { - /* - * Additional properties are documented here (like license assignment) - * https://msdn.microsoft.com/Library/Azure/Ad/Graph/api/entity-and-complex-type-reference#EntityreferenceUserEntity - */ accountEnabled: true, - displayName: context.displayName, - mailNickname: context.mailNickname, - userPrincipalName: context.userPrincipalName, + displayName: user.nickname, + mailNickname: mailNickname, + userPrincipalName: userPrincipalName, passwordProfile: { - password: context.uuid, + password: immutableId, forceChangePasswordNextLogin: false }, - immutableId: context.immutableId, + immutableId: immutableId, usageLocation: AAD_USAGE_LOCATION }, }; - console.log('Creating user in Azure AD:', options.body); - request.post(options, function(err, res, body) { - if(err) { - console.log('Error creating user in Azure AD.', err); - return cb(err); - } + return rp(options); + } - if (body.error) { - console.log('Error creating user in Azure AD.', body.error_description); - return cb(new Error(body.error_description)); + // 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 } - - console.log('User created!'); - return cb(null); - }); + }; + return rp(options); } - /* - * Get the token for Azure AD. - */ - function get_azuread_token(cb) { + // 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://login.windows.net/' + AAD_TENANT_NAME + - '/oauth2/token?api-version=1.5', + url: ' https://graph.windows.net/' + AAD_DOMAIN + '/users/' + userId + '/assignLicense?api-version=1.6', headers: { 'Content-type': 'application/json', + 'Authorization': 'Bearer ' + token }, json: true, - form: { - client_id: AAD_CLIENT_ID, - client_secret: AAD_CLIENT_SECRET, - grant_type: 'client_credentials', - resource: 'https://graph.windows.net' - }, + body: { + 'addLicenses': [ + { + 'disabledPlans': [], + 'skuId': office365License + } + ], + 'removeLicenses': [] + } }; + return rp(options); + } - console.log('Getting token for Azure AD...'); - request.post(options, function(err, res, body) { - if(err) { - console.log('Error getting token for Azure AD.', err); - return cb(err); - } + // 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 || {}; - if (body.error) { - console.log('Error getting token for Azure AD.', body.error_description); - return cb(new Error(body.error_description)); - } + user.app_metadata.office365Provisioned = true; + user.app_metadata.office365UPN = userPrincipalName; + user.app_metadata.office365ImmutableId = immutableId; - console.log('Token received:', body.access_token); - return cb(null, body.access_token); - }); + return auth0.users.updateAppMetadata(user.user_id, user.app_metadata); } - /* - * Create the actual immutable id. - */ - function guid_to_base64(g) { - var le = true; - var hexlist = '0123456789abcdef'; - var b64list = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/'; - var s = g.replace(/[^0-9a-f]/ig, '').toLowerCase(); - if (s.length !== 32) return ''; - - if (le) s = s.slice(6, 8) + s.slice(4, 6) + s.slice(2, 4) + s.slice(0, 2) + - s.slice(10, 12) + s.slice(8, 10) + - s.slice(14, 16) + s.slice(12, 14) + - s.slice(16); - s += '0'; - - var a, p, q; - var r = ''; - var i = 0; - - while (i < 33) { - a = (hexlist.indexOf(s.charAt(i++)) << 8) | - (hexlist.indexOf(s.charAt(i++)) << 4) | - (hexlist.indexOf(s.charAt(i++))); - p = a >> 6; - q = a & 63; - - r += b64list.charAt(p) + b64list.charAt(q); - } - r += '=='; + // 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); + }); + } - return r; + // 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 synchronise metadata of existing users. +::: 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 @@ -266,10 +271,12 @@ The easiest way for your external users to authenticate is by using IdP initiate 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=CLIENT_ID_OF_THIRD_PARTY_APP&protocol=wsfed&state=&redirect_uri=& +https://${account.namespace}/login?client=AUTH0_OFFICE365_CLIENT_ID&protocol=wsfed&state=&redirect_uri=& ``` -> Note: the `CLIENT_ID_OF_THIRD_PARTY_APP` 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 an URL in the form of `https://${account.namespace}/#/externalapps/${account.clientId}/settings`. The `${account.clientId}` is the value you need here. +::: 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. diff --git a/articles/integrations/office-365.md b/articles/integrations/office-365.md index 67ab0fe85a..03c17657ba 100644 --- a/articles/integrations/office-365.md +++ b/articles/integrations/office-365.md @@ -1,11 +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 @@ -13,11 +18,11 @@ Your users will be able to log in using their existing Active Directory credenti 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, SharePoint Server, ... +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 (Lync Online, Exchange Online, ...). +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) @@ -25,15 +30,17 @@ 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, ...). +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, traditional AD, ...) you can [write a rule with custom provisioning logic](/integrations/office-365-custom-provisioning) +::: 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 @@ -75,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" @@ -98,7 +105,7 @@ To skip the Auth0 page with the **windows authentication** button you can append ### 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, ...) the users will see the username/password login page instead. +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) @@ -130,3 +137,68 @@ Fabrikam can now host a simple website, like `http://office.fabrikamcorp.com` wh 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/articles/integrations/office365-connection-deprecation-guide.md b/articles/integrations/office365-connection-deprecation-guide.md new file mode 100644 index 0000000000..28a608c5ca --- /dev/null +++ b/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/articles/integrations/salesforce.md b/articles/integrations/salesforce.md deleted file mode 100644 index d5ae19b71e..0000000000 --- a/articles/integrations/salesforce.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Salesforce -description: How to add Single Sign On (SSO) integration with Salesforce. ---- -<%= include('./_template', { - image1: "tutorial-salesforce.png" -}) %> diff --git a/articles/integrations/sharepoint-apps.md b/articles/integrations/sharepoint-apps.md index 37442817b4..54666c43c3 100644 --- a/articles/integrations/sharepoint-apps.md +++ b/articles/integrations/sharepoint-apps.md @@ -1,50 +1,54 @@ --- 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. -## 1. Register your app in Auth0 - -Just register a new app 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. +## 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 app +## 2. Create a package for your application -You need to obtain a __Client ID__ and a __Client Secret__ for your app. There are many ways of registering your app depending on the expected usage. +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. -> [This article](http://msdn.microsoft.com/en-us/library/office/jj687469(v=office.15).aspx) explains all different ways of registering your app in SharePoint. This step in the tutorial will use the simplest form: using self-registration in a specific tenant (yours). +::: 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 +### 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__: +### Generate a __Client_Id__ and __ClientSecret__: ![](/media/articles/integrations/sharepoint-apps/90SvG.png) -#### Complete the information in the form: +### 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**: - +**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 (e.g. "sharepoint"). +* `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: +### Package the app and upload to SharePoint: Complete the information in your app manifest in Visual Studio: @@ -58,7 +62,6 @@ Create a __Publishing Profile__ (you will have to enter the same __Client Id__ & Click on __Package__ and upload the resulting file to SharePoint. ---- ## 3. Create the Connection in Auth0 @@ -70,16 +73,19 @@ 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. (e.g. 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. +* `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: +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) +![](/media/articles/integrations/sharepoint-apps/8Xp6x.png) -> Notice that the following properties will be included: `cacheKey`, `refresh_token`, `host` and `site`. These will allow you to call back SharePoint APIs (e.g. lists, etc.). +::: 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/articles/integrations/sharepoint.md b/articles/integrations/sharepoint.md index ed78e35681..4870a916cb 100644 --- a/articles/integrations/sharepoint.md +++ b/articles/integrations/sharepoint.md @@ -1,24 +1,31 @@ --- -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 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, etc.), [Enterprise Providers](/identityproviders) (LDAP, Active Directory, ADFS, etc.) or with 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 ### 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. +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 -> If your SharePoint server does not have Internet access, you will need to download the installation files to a SharePoint server manually. [Learn more](https://github.com/auth0/auth0-sharepoint/tree/master/auth0-authentication-provider#offline-installation) +::: 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). +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) @@ -26,11 +33,11 @@ The Live Documentation will first start with the installation of the Auth0 CmdLe ![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'll first enable authentication with Auth0: +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 as a last step you'll also install the Claims Provider, to make sure the People Picker, permissions, ... work correctly: +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) @@ -40,29 +47,29 @@ Once these scripts have been executed you'll complete the configuration in Centr Note that the call to `Enable-Auth0` can be adapted to: - - Change the unique identifier for users (eg: email or user_id) - - Allow addition claims to be passed through to SharePoint + - 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" +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 + "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've nailed it. +### 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. +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) @@ -70,6 +77,64 @@ Depending on which claims have been mapped when installing the claims provider t ![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: @@ -104,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) { @@ -119,9 +184,9 @@ function (user, context, callback) { '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. @@ -129,13 +194,13 @@ This will add an additional outgoing claim `http://schemas.microsoft.com/ws/2008 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" +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", - ...) + "Email|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", + "Role|http://schemas.microsoft.com/ws/2008/06/identity/claims/role", + ...) ... -Verbose ``` @@ -206,11 +271,11 @@ Alternatively this logic could also be implemented as an HttpModule which runs e ```cs public class PersistUserClaimsHttpModule : IHttpModule { - private SPFederationAuthenticationModule FederationModule + private SPFederationAuthenticationModule FederationModule { get { return HttpContext.Current.ApplicationInstance.Modules["FederatedAuthentication"] as SPFederationAuthenticationModule; } } - + public void Init(HttpApplication context) { FederationModule.SecurityTokenValidated += OnFederationSecurityTokenValidated; diff --git a/articles/integrations/slack.md b/articles/integrations/slack.md deleted file mode 100644 index 8bd6a86092..0000000000 --- a/articles/integrations/slack.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Slack -description: How to add Single Sign On (SSO) integration with Slack. ---- -<%= include('./_template', { - image1: "tutorial-slack.png" -}) %> diff --git a/articles/integrations/springcm.md b/articles/integrations/springcm.md deleted file mode 100644 index a2dd972b41..0000000000 --- a/articles/integrations/springcm.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Spring CM -description: How to add Single Sign On (SSO) integration with Spring CM. ---- -<%= include('./_template', { - image1: "tutorial-springcm.png" -}) %> diff --git a/articles/integrations/sso/_template.md b/articles/integrations/sso/_template.md new file mode 100644 index 0000000000..3cf0d599a6 --- /dev/null +++ b/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/articles/integrations/sso/ad-rms.md b/articles/integrations/sso/ad-rms.md new file mode 100644 index 0000000000..c54065deb4 --- /dev/null +++ b/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/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 new file mode 100644 index 0000000000..808a65ec41 --- /dev/null +++ b/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/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 new file mode 100644 index 0000000000..912c641323 --- /dev/null +++ b/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/articles/integrations/sso/concur.md b/articles/integrations/sso/concur.md new file mode 100644 index 0000000000..96a7527cca --- /dev/null +++ b/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/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 new file mode 100644 index 0000000000..def0e7328a --- /dev/null +++ b/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/articles/integrations/sso/dropbox.md b/articles/integrations/sso/dropbox.md new file mode 100644 index 0000000000..8e4f2b3105 --- /dev/null +++ b/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/articles/integrations/sso/dynamics-crm.md b/articles/integrations/sso/dynamics-crm.md new file mode 100644 index 0000000000..70382fd3bc --- /dev/null +++ b/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/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 new file mode 100644 index 0000000000..fd5395bcac --- /dev/null +++ b/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/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 new file mode 100644 index 0000000000..afe2efda39 --- /dev/null +++ b/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/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 new file mode 100644 index 0000000000..68fbf8906b --- /dev/null +++ b/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/articles/integrations/sso/office-365.md b/articles/integrations/sso/office-365.md new file mode 100644 index 0000000000..155d016fdd --- /dev/null +++ b/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/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 new file mode 100644 index 0000000000..2946044f0f --- /dev/null +++ b/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/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 new file mode 100644 index 0000000000..8fde6b36df --- /dev/null +++ b/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/articles/integrations/sso/slack.md b/articles/integrations/sso/slack.md new file mode 100644 index 0000000000..7fff98bb76 --- /dev/null +++ b/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/articles/integrations/sso/springcm.md b/articles/integrations/sso/springcm.md new file mode 100644 index 0000000000..ca7ea7e521 --- /dev/null +++ b/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/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 new file mode 100644 index 0000000000..f4409ec17d --- /dev/null +++ b/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/articles/integrations/sso/zoom.md b/articles/integrations/sso/zoom.md new file mode 100644 index 0000000000..c987b3d838 --- /dev/null +++ b/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/articles/integrations/using-auth0-to-secure-a-cli.md b/articles/integrations/using-auth0-to-secure-a-cli.md new file mode 100644 index 0000000000..deacfe2ad6 --- /dev/null +++ b/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/articles/integrations/zendesk.md b/articles/integrations/zendesk.md deleted file mode 100644 index 208a046694..0000000000 --- a/articles/integrations/zendesk.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Zendesk -description: How to add Single Sign On (SSO) integration with Zendesk. ---- -<%= include('./_template', { - image1: "tutorial-zendesk.png" -}) %> diff --git a/articles/integrations/zoom.md b/articles/integrations/zoom.md deleted file mode 100644 index a2ab15c6df..0000000000 --- a/articles/integrations/zoom.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Zoom -description: How to add Single Sign On (SSO) integration with Zoom. ---- -<%= include('./_template', { - image1: "tutorial-zoom.png" -}) %> diff --git a/articles/libraries/_includes/_change_get_profile.md b/articles/libraries/_includes/_change_get_profile.md new file mode 100644 index 0000000000..96838117ae --- /dev/null +++ b/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/articles/libraries/_includes/_configure_custom_domain.md b/articles/libraries/_includes/_configure_custom_domain.md new file mode 100644 index 0000000000..5a98890df2 --- /dev/null +++ b/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/articles/libraries/_includes/_configure_embedded_login.md b/articles/libraries/_includes/_configure_embedded_login.md new file mode 100644 index 0000000000..3585ca28f0 --- /dev/null +++ b/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/articles/libraries/_includes/_default_values.md b/articles/libraries/_includes/_default_values.md new file mode 100644 index 0000000000..48b1b9eff4 --- /dev/null +++ b/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/articles/libraries/_includes/_default_values_lock.md b/articles/libraries/_includes/_default_values_lock.md new file mode 100644 index 0000000000..b66229d099 --- /dev/null +++ b/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/articles/libraries/_includes/_embedded_sso.md b/articles/libraries/_includes/_embedded_sso.md new file mode 100644 index 0000000000..bd379358ae --- /dev/null +++ b/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/articles/libraries/_includes/_get_auth0_js_latest_version.md b/articles/libraries/_includes/_get_auth0_js_latest_version.md new file mode 100644 index 0000000000..c372c1c25b --- /dev/null +++ b/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/articles/libraries/_includes/_get_lock_latest_version.md b/articles/libraries/_includes/_get_lock_latest_version.md new file mode 100644 index 0000000000..8f775a2240 --- /dev/null +++ b/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/articles/libraries/_includes/_ip_ranges.md b/articles/libraries/_includes/_ip_ranges.md new file mode 100644 index 0000000000..b3813c37ce --- /dev/null +++ b/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/articles/libraries/_includes/_last_logged_in_window.md b/articles/libraries/_includes/_last_logged_in_window.md new file mode 100644 index 0000000000..696166ebfb --- /dev/null +++ b/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/articles/libraries/_includes/_legacy_flows.md b/articles/libraries/_includes/_legacy_flows.md new file mode 100644 index 0000000000..b6793b4966 --- /dev/null +++ b/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/articles/libraries/_includes/_migrate_universal.md b/articles/libraries/_includes/_migrate_universal.md new file mode 100644 index 0000000000..c43bcae9f8 --- /dev/null +++ b/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/articles/libraries/_includes/_oidc_conformant.md b/articles/libraries/_includes/_oidc_conformant.md new file mode 100644 index 0000000000..ec12a82cf5 --- /dev/null +++ b/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/articles/libraries/_includes/_popup_mode.md b/articles/libraries/_includes/_popup_mode.md new file mode 100644 index 0000000000..6de2c95a77 --- /dev/null +++ b/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/articles/libraries/_includes/_review_get_ssodata.md b/articles/libraries/_includes/_review_get_ssodata.md new file mode 100644 index 0000000000..509974a67a --- /dev/null +++ b/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/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 new file mode 100644 index 0000000000..a4edd88b3c --- /dev/null +++ b/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/articles/libraries/auth0-android/configuration.md b/articles/libraries/auth0-android/configuration.md new file mode 100644 index 0000000000..08e87aef3f --- /dev/null +++ b/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/articles/libraries/auth0-android/database-authentication.md b/articles/libraries/auth0-android/database-authentication.md new file mode 100644 index 0000000000..430ed70c91 --- /dev/null +++ b/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/articles/libraries/auth0-android/index.md b/articles/libraries/auth0-android/index.md index 5c1962d42a..adfdcc3f4d 100644 --- a/articles/libraries/auth0-android/index.md +++ b/articles/libraries/auth0-android/index.md @@ -3,11 +3,21 @@ 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 for [Auth0](http://auth0.com). Using it with your Android native app development should simplify your interactions with Auth0. +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 @@ -15,15 +25,9 @@ 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: +<%= include('../../quickstart/native/android/_includes/_gradle.md') %> -```gradle -dependencies { - compile "com.auth0.android:auth0:1.1.0" -} -``` - -## Permissions +## Permissions Open your app's `AndroidManifest.xml` file and add the following permission. @@ -31,22 +35,10 @@ Open your app's `AndroidManifest.xml` file and add the following permission. ``` -## Initializing Auth0 - -You can set up your Auth0 credentials and initiate Auth0 in one of two ways: +## Initialize Auth0 -### 1) Client Information In-Line +Save your application information in the `strings.xml` file using the following names: -Method one is to simply create an instance of `Auth0` with your client information. - -```java -Auth0 account = new Auth0("${account.clientId}", "${account.namespace}"); -``` - -### 2) Client Information Read from XML - -Method two is to save your client information in the `strings.xml` file using the following names: - ```xml ${account.clientId} @@ -61,323 +53,167 @@ And then create your new Auth0 instance by passing an Android Context: Auth0 account = new Auth0(context); ``` -## Using the Authentication API - -The Authentication Client provides methods to authenticate the user against Auth0 server. Create a new instance by passing in the Auth0 object created in the previous step. - -```java -AuthenticationAPIClient authentication = new AuthenticationAPIClient(account); -``` - -### Login with database connection - -Logging in with a database connection merely requires calling `login` with the user's email, password, and the name of the connection you wish to authenticate with. The response will be a Credentials object. - -```java -authentication - .login("info@auth0.com", "a secret password", "my-database-connection") - .start(new BaseCallback() { - @Override - public void onSuccess(Credentials payload) { - //Logged in! - } - - @Override - public void onFailure(AuthenticationException error) { - //Error! - } - }); -``` - -::: panel-info Scope -Note that the default scope used is `openid` -::: - -### Passwordless Login - -Logging in with a Passwordless is slightly different. 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. - -**Step 1:** 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'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. - -```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! - } - }); -``` - -::: panel-info Scope -Note that the default scope used is `openid` -::: - -**Step 2:** Input the code +## OIDC Conformant Mode -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! - } - }); -``` - -### Signing up with database connection - -Signing up with a database connection is similarly easy. Call the `signUp` method passing the user's given email, chosen password, and the connection name to initiate the signup process. - -```java -authentication - .signUp("info@auth0.com", "a secret password", "my-database-connection") - .start(new BaseCallback() { - @Override - public void onSuccess(Credentials payload) { - //Signed Up & Logged in! - } - - @Override - public void onFailure(AuthenticationException error) { - //Error! - } - }); -``` - -### Getting user information - -In order to retrieve a user's profile, you call the `tokenInfo` method and pass it the user's token. - -```java -authentication - .tokenInfo("user token") - .start(new BaseCallback() { - @Override - public void onSuccess(UserProfile payload) { - //Got the profile! - } - - @Override - public void onFailure(AuthenticationException error) { - //Error! - } - }); -``` - - -## Using the Management API - -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, 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. +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}"); -UsersAPIClient users = new UsersAPIClient(account, "token"); +//Configure the account in OIDC conformant mode +account.setOIDCConformant(true); +//Use the account in the API applications ``` - -### 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. +## Authentication via Universal Login -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. +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: -```java -users - .link("primary user id", "secondary user token") - .start(new BaseCallback>() { - @Override - public void onSuccess(List payload) { - //Got the updated identities! Accounts linked. - } - - @Override - public void onFailure(Auth0Exception error) { - //Error! - } - }); ``` - -### Unlinking users - -Unlinking users is a similar provess 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>() { - @Override - public void onSuccess(List payload) { - //Got the updated identities! Accounts linked. - } - - @Override - public void onFailure(Auth0Exception error) { - //Error! - } - }); +https://${account.namespace}/android/{YOUR_APP_PACKAGE_NAME}/callback ``` -::: panel-info Unlinking - Metadata -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 +Replace `{YOUR_APP_PACKAGE_NAME}` with your actual application's package name, available in your `app/build.gradle` file as the `applicationId` value. ::: -### Updating user metadata +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. -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. +```groovy +apply plugin: 'com.android.application' -```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! - } - }); -``` +android { + compileSdkVersion 25 + defaultConfig { + applicationId "com.auth0.samples" + minSdkVersion 15 + targetSdkVersion 25 + //... -## Implementing web-based auth - -First go to [Auth0 Dashboard](${manage_url}/#/clients) and go to your client'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 + //---> Add the next line + manifestPlaceholders = [auth0Domain: "@string/com_auth0_domain", auth0Scheme: "https"] + //<--- + } + //... +} ``` -Open your app's `AndroidManifest.xml` file and add the following permission. - -```xml - -``` +::: 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. +::: -Also register the intent filters inside your activity's tag, so you can receive the call in your activity. **Note that you will have to specify the callback url inside the `data` tag**. +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 + - + - android:launchMode="singleTask"> - + android:name="com.auth0.android.provider.RedirectActivity" + tools:node="replace"> - - /callback" android:scheme="https" /> - - + + ``` -Make sure the Activity's `launchMode` is declared as `singleTask` or the result won't come back after the authentication. - -When you launch the WebAuthProvider you'll expect a result back. To capture the response override the `onNewIntent` method and call `WebAuthProvider.resume()` with the received parameters: - -```java -public class MyActivity extends Activity { - - @Override - protected void onNewIntent(Intent intent) { - if (WebAuthProvider.resume(intent)) { - return; - } - super.onNewIntent(intent); - } -} +Finally, don't forget to add the internet permission: +```xml + ``` -### Authenticate with a specific Auth0 connection +::: 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. +::: -The `withConnection` option allows you to specify a connection that you wish to authenticate with. If no connection is specified here, the browser will show the Hosted Login page, with all of the connections which are enabled for this client. +Now, let's authenticate a user by presenting the universal [login page](/universal-login): ```java -WebAuthProvider.init(account) - .withConnection("twitter") - .start(MainActivity.this, authCallback); +WebAuthProvider.login(account) + .withAudience("https://${account.namespace}/userinfo") + .start(this, authCallback); ``` -### Authenticate using a code grant with PKCE +The authentication result will be delivered to the callback. -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. +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). -Before you can use `Code Grant` in Android, make sure to go to your [client's section](${manage_url}/#/applications) in dashboard and check in the Settings that `Client Type` is `Native`. If you have not used code grants before, you might want to take a look at our [tutorial on executing an authorization code grant flow with PKCE](/api-auth/tutorials/authorization-code-grant-pkce) before proceeding. +## 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 -WebAuthProvider.init(account) - .useCodeGrant(true) - .start(MainActivity.this, authCallback); +AuthenticationAPIClient authentication = new AuthenticationAPIClient(account); ``` -### Authenticate using a specific scope +### Get user information -Using scopes can allow you to return specific claims for specfic fields in your request. Adding parameters to `withScope` 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. +To get the information associated with a given user's Access Token, you can call the `userInfo` endpoint, passing the token. ```java -WebAuthProvider.init(account) - .withScope("user openid") - .start(MainActivity.this, authCallback); -``` +authentication + .userInfo("Access Token") + .start(new BaseCallback() { + @Override + public void onSuccess(UserProfile information) { + //user information received + } -::: panel-info Scope -Note that the default scope used is `openid` -::: + @Override + public void onFailure(AuthenticationException error) { + //user information request failed + } + }); +``` -### Authenticate using specific connection scopes +### Password Resets -There may be times when you need to authenticate with particular connection scopes, or permissions, from the IDP in question. Auth0 has [documentation on setting up connection scopes for external IDPs](/tutorials/adding-scopes-for-an-external-idp), but 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, or from the IDP's documentation. +To initiate a password reset for a user, call `resetPassword` with the user's email address and the database connection name as parameters. ```java -WebAuthProvider.init(account) - .withConnectionScope("email", "profile", "calendar:read") - .start(MainActivity.this, authCallback); +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 + } + }); ``` -### Authenticate with Auth0 hosted login page +::: 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). +::: -If no connection name is specified, using the Auth0 [Hosted Login Page](hosted-pages/login) is the default behavior. +## Next Steps -```java -WebAuthProvider.init(account) - .start(MainActivity.this, authCallback); -``` +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/articles/libraries/auth0-android/passwordless.md b/articles/libraries/auth0-android/passwordless.md new file mode 100644 index 0000000000..166610f555 --- /dev/null +++ b/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/articles/libraries/auth0-android/save-and-refresh-tokens.md b/articles/libraries/auth0-android/save-and-refresh-tokens.md new file mode 100644 index 0000000000..c70ab2403e --- /dev/null +++ b/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/articles/libraries/auth0-android/user-management.md b/articles/libraries/auth0-android/user-management.md new file mode 100644 index 0000000000..51c085825e --- /dev/null +++ b/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/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 new file mode 100644 index 0000000000..039f9467b1 --- /dev/null +++ b/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/articles/libraries/auth0-swift/index.md b/articles/libraries/auth0-swift/index.md index 4065b95b7e..bc88fd539e 100644 --- a/articles/libraries/auth0-swift/index.md +++ b/articles/libraries/auth0-swift/index.md @@ -3,42 +3,78 @@ 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](http://auth0.com). +Auth0.swift is a client-side library for Auth0. -## Requirements - -iOS 9+ and Xcode 8 (Swift 3.0) - -::: panel-info Swift 2.3 -For Swift 2.3 you need to use [v1@swift-2.3](https://github.com/auth0/Auth0.swift/tree/v1@swift-2.3) branch. +::: note +Check out the [Auth0.swift repository](https://github.com/auth0/Auth0.swift) on GitHub. ::: -If using CocoaPods, we recommend version 1.1.0 or later. +## Requirements + +- iOS 9+ / macOS 10.11+ / tvOS 9.0+ / watchOS 2.0+ +- Xcode 11.4+ / 12.x +- Swift 4.x / 5.x ## Installation -### Using CocoaPods +### Cocoapods -Auth0.swift is available through [CocoaPods](http://cocoapods.org). -To install it, simply add the following line to your Podfile: +If you are using [Cocoapods](https://cocoapods.org), add this line to your `Podfile`: ```ruby pod 'Auth0', '~> 1.0' ``` -### Using Carthage +Then run `pod install`. -In your Cartfile add this line +::: 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 ``` -## Credentials +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: @@ -55,251 +91,101 @@ You will need to add an `Auth0.plist` file, containing your Auth0 client id and ``` -## Using the Authentication API +### Web-based Auth (iOS / macOS 10.15+) -The Authentication API provides methods to authenticate the user against Auth0 server. +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: -### Login with 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: "a secret password", - connection: "Username-Password-Authentication" - ) - .start { result in - switch result { - case .success(let credentials): - print("access_token: \(credentials.accessToken)") - case .failure(let error): - print(error) - } - } -``` - -### Passwordless Login - -Logging in with Passwordless is slightly different. 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. - -#### How Passwordless Works - -Passwordless requires two steps. Requesting the code, and inputting the code. When using links, this is slightly different, because the user does not have to input a code themselves - but the code is just 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", connection: "email") - .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( - usernameOrEmail: "support@auth0.com", - password: "123456", - connection: "email" - ) - .start { result in - switch result { - case .success(let credentials): - print("access_token: \(credentials.accessToken)") - case .failure(let error): - print(error) - } - } -``` - -#### Passwordless Parameters - -As you can see, Passwordless authentication can be started with a variety of different parameters. - -``` -.startPasswordless(email: String, type: String, connection: String) +```text +{YOUR_BUNDLE_IDENTIFIER}://${account.namespace}/ios/{YOUR_BUNDLE_IDENTIFIER}/callback ``` -or +In your application's `Info.plist` file register your iOS Bundle Identifier as a custom scheme like this: -``` -.startPasswordless(phoneNumber: String, type: String, connection: String) +```xml +CFBundleURLTypes + + + CFBundleTypeRole + None + CFBundleURLName + auth0 + CFBundleURLSchemes + + {YOUR_BUNDLE_IDENTIFIER} + + + ``` -- **Parameter One** - Either the parameter `email` or `phoneNumber`, depending on which you intend to use. The value of either should be a string. -- **Parameter Two** - The parameter `type`, its value should be either `.Code` or `.iOSLink`. The default is `.Code` (a code is sent to the user, then they input it in a secondary screen), but if you have [iOS Universal Links](https://developer.apple.com/library/content/documentation/General/Conceptual/AppSearch/UniversalLinks.html) configured, you can use `.iOSLink`. -- **Parameter Three** - The parameter `connection`, its value should be the name of the connection, defaults to `sms`. - -### Signing Up with database connection - -Signing up requires calling the `signUp` method, passing the user's given email, chosen password, and the connection name to initiate the signup process. +::: 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**. +::: -```swift -Auth0 - .authentication() - .signUp( - email: "support@auth0.com", - password: "password123", - connection: "Username-Password-Authentication" - ) - .start { result in - switch result { - case .success(let credentials): - print("access_token: \(credentials.accessToken)") - case .failure(let error): - print(error) - } - } -``` +::: 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` +::: -### Getting user information +Allow Auth0 to handle authentication callbacks. In your `AppDelegate.swift`, add the following: -In order to retrieve a user's profile, you call the `tokenInfo` method and pass it the user's token. +##### iOS ```swift -Auth0 - .authentication() - .tokenInfo(token: "user token") - .start { result in - switch result { - case .success(let profile): - print("profile email: \(profile.email)") - case .failure(let error): - print(error) - } - } +func application(_ app: UIApplication, open url: URL, options: [UIApplicationOpenURLOptionsKey: Any]) -> Bool { + return Auth0.resumeAuth(url) +} ``` -### Using the Management API - -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. - -#### 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 `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. +##### macOS ```swift -Auth0 - .users(token: "user 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) - } - } +func application(_ application: NSApplication, open urls: [URL]) { + Auth0.resumeAuth(urls) +} ``` -#### Unlinking users +#### Authenticate with Universal Login -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. -The parameters read, essentially: "Unlink this **secondary user** (with this **provider**) from this **primary user**". +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. -```swift -Auth0 - .users(token: "user 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) - } - } -``` - -::: panel-info Unlinking - Metadata -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 +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) ::: -#### 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 token") - .patch("user identifier", userMetadata: ["first_name": "John", "last_name": "Doe"]) + .webAuth() + .audience("https://${account.namespace}/userinfo") .start { result in - switch result { - case .success(let userInfo): - print("user: \(userInfo)") + switch result { // Auth0.Result + case .success(let credentials): + print("Credentials: \(credentials)") case .failure(let error): print(error) } } ``` -### Web-based Auth (iOS Only) - -First go to [Auth0 Dashboard](${manage_url}/#/clients) and go to client's settings. Make sure you have in *Allowed Callback URLs* a URL with the following format: - -``` -{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} - - - -``` - -> **Auth0.swift** will only handle URLs with your Auth0 domain as host, e.g. `com.auth0.MyApp://samples.auth0.com/ios/com.auth0.MyApp/callback` - -And add the following method in your application's `AppDelegate`: +::: 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. +::: -```swift -func application(_ app: UIApplication, open url: URL, options: [UIApplicationOpenURLOptionsKey : Any] = [:]) -> Bool { - return Auth0.resumeAuth(url, options:options) -} -``` +::: 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 Hosted Login page, with all of the connections which are enabled for this client. +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)") + print("Credentials: \(credentials)") case .failure(let error): print(error) } @@ -308,36 +194,50 @@ 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 .webAuth() .scope("openid email") .connection("google-oauth2") + .audience("https://${account.namespace}/userinfo") .start { result in switch result { case .success(let credentials): - print("credentials: \(credentials)") + print("Credentials: \(credentials)") case .failure(let error): print(error) } } ``` -#### Authenticate with Auth0 hosted login page +### Getting user information -If no connection name is specified, using the Auth0 [Hosted Login Page](/hosted-pages/login) is the default behavior. +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 - .webAuth() - .start { result in - switch result { - case .success(let credentials): - print("credentials: \(credentials)") - case .failure(let error): - print(error) - } - } + .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/articles/libraries/auth0-swift/passwordless.md b/articles/libraries/auth0-swift/passwordless.md new file mode 100644 index 0000000000..664f8e8d7f --- /dev/null +++ b/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/articles/libraries/auth0-swift/save-and-refresh-jwt-tokens.md b/articles/libraries/auth0-swift/save-and-refresh-jwt-tokens.md new file mode 100644 index 0000000000..c633a9c650 --- /dev/null +++ b/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/articles/libraries/auth0-swift/touchid-authentication.md b/articles/libraries/auth0-swift/touchid-authentication.md new file mode 100644 index 0000000000..e86bcad058 --- /dev/null +++ b/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/articles/libraries/auth0-swift/user-management.md b/articles/libraries/auth0-swift/user-management.md new file mode 100644 index 0000000000..c2ad08deab --- /dev/null +++ b/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/articles/libraries/auth0js/index.md b/articles/libraries/auth0js/index.md deleted file mode 100644 index 68c0af437e..0000000000 --- a/articles/libraries/auth0js/index.md +++ /dev/null @@ -1,370 +0,0 @@ ---- -section: libraries -toc: true -description: How to install, initialize and use auth0.js v8 -url: /libraries/auth0js ---- - -# Auth0.js v8 Reference - -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. - -
        - This document covers the most up-to-date version of auth0.js - version 8. If you are already using version 7, you can take a look at the v7 reference guide, or take a look at the v8 migration guide -
        - -## 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! - -### 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 that 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 client as follows: - -```html - - -``` - -#### Available Parameters - -##### Required - -* **domain** {string}: Your Auth0 account domain (ex. myaccount.auth0.com) -* **client\_id** {string}: Your Auth0 client\_id - -##### Optional - -* **redirectUri** {string}: The default redirectUri used. Defaults to an empty string (none). -* **scope** {string}: The default scope 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 about them. -* **audience** {string}: The default audience used for requesting API Access. -* **responseType** {string}: The default responseType used, 'token' or 'code'. Defaults to 'token', unless a `redirectUri` is provided, then defaults to 'code'. -* **responseMode** {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. -* **_disableDeprecationWarnings** {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 the [Hosted Login Page](/libraries/auth0js#hosted-login-page), 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 for social login with popup using `authorize`: - -```js -webAuth.popup.authorize({ - connection: 'twitter' -}); -``` - -### 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' -}); -``` - -### 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' -}); -``` - -### 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 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). - -#### Start Passwordless - -The `passwordlessStart` method requires several options: - -* `connection`: a string that specifies how to send the code/link to the user. Value must be either `email` or `sms`. -* `send`: a string, value must be either 'code' or 'link'. If null, a link will be sent. - -In addition, _one_ of the two following options must be sent: - -* `phoneNumber`: a string containing the user's phone number for delivery of a code or link via SMS. -* `email`: a string containing the user's email for delivery of a code or link via email. - -```js -webAuth.passwordlessStart({ - connection: 'email', - send: 'code', - email: 'foo@bar.com' - }, function (err,res) { - // handle errors or continue - } -); -``` - -#### Verify Passwordless - -The `passwordlessVerify` method requires several options: - -* `connection`: a string that specifies how to send the code/link to the user. Value must be either `email` or `sms` and the same with the one used at `passwordlessStart`. -* `verificationCode`: a string, the code sent to the user as a code or within a link. - -In addition, _one_ of the two following options must be sent: - -* `phoneNumber`: a string containing the user's phone number, to which the code or link was delivered via SMS -* `email`: a string containing the user's email, to which the code or link was delivered via email - - -```js -webAuth.passwordlessVerify({ - connection: 'email', - email: 'foo@bar.com', - verificationCode: '389945' - }, function (err,res) { - // handle errors or continue - } -); -``` - -## Log out - -To log out a user, use the `logout` method. This accepts an options object, which can include a `client_id`, and a `returnTo` URL. If you want to navigate the user to a specific URL after the logout, set that URL at the `returnTo` parameter. - -::: panel-info returnTo parameter -Note that if the `client_id` parameter _is_ included, the `returnTo` URL that is provided must be listed in the Client's **Allowed Logout URLs** in the [Auth0 dashboard](${manage_url}). -However, if the `client_id` 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', - client_id: 'some client ID here' -}); -``` - -## Sign up - -The `signup` method accepts an `options` object that contains parameters for your signup. Note that 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 renewAuth to Acquire New Tokens - -The `renewAuth` method allows you to acquire a new token from Auth0 for a user who is already authenticated against the [hosted login page](/hosted-pages/login) for your domain. - - -```js -webAuth.renewAuth({ - audience: 'https://example.com/api/v2', - scope: 'read:something write:otherthing', - redirectUri: 'https://example.com/auth/silent-callback', - usePostMessage: true -}, function (err, authResult) { - ... -}); -``` - -::: panel-info postMessage -This will use postMessage to comunicate between the silent callback and the SPA. When false, the SDK will attempt to parse the URL hash, should ignore the URL hash, and no extra behaviour is needed. -::: - -The actual redirect to `/authorize` happens inside an iframe, so it will not reload your application or redirect away from it. However, it is strongly recommended to have a dedicated callback page for silent authentication in order to avoid the delay of loading your entire application again inside an iframe. - -This callback page should only parse the URL hash and post it to the parent document, so that your application can take action depending on the outcome of the silent authentication attempt. The callback page should be something like the following one. It will parse the URL hash and post it to the parent document: - -```html - - - - - - - - -``` - -Remember to add the URL of the silent authentication callback page that you create to the **Allowed Callback URLs** list of your Auth0 client in the [Auth0 Dashboard](${manage_url}) under your client's *Settings*. - -## 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 (Read more about [Linking Accounts](/link-accounts) with Auth0). It also allows you to update user metadata. - -To get started, create a new `auth0.Management` instance by passing it the account's Auth0 domain, 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. - -```js -var auth0Manage = new auth0.Management({ - domain: '${account.namespace}', - token: "YOUR_PRIMARY_IDENTITY_TOKEN" -}); -``` - -### Get 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. - -```js -auth0Manage.getUser(userId, cb); -``` - -### Update 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); -``` - -### 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. - -The `linkUser` 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. Visit the [Linking Accounts](/link-accounts) documentation for more details on linking accounts. - -```js -auth0Manage.linkUser(userId, secondaryUserToken, cb); -``` - -::: panel-info Linking - Metadata -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/index.yml b/articles/libraries/auth0js/index.yml new file mode 100644 index 0000000000..44a74ecb88 --- /dev/null +++ b/articles/libraries/auth0js/index.yml @@ -0,0 +1,7 @@ +versioning: + baseUrl: libraries/auth0js + current: v9 + versions: + - v9 + defaultArticles: + v9: index diff --git a/articles/libraries/auth0js/migration-guide.md b/articles/libraries/auth0js/migration-guide.md deleted file mode 100644 index 85f03d0b04..0000000000 --- a/articles/libraries/auth0js/migration-guide.md +++ /dev/null @@ -1,174 +0,0 @@ ---- -section: libraries -description: How to migrate from auth0.js v7 to auth0.js v8 -url: /libraries/auth0js/migration-guide ---- - -# 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. Note that we especially recommend migrating to auth0.js v8 if you have [enabled the new API Authorization flows](/api-auth/tutorials/configuring-tenant-for-api-auth). - -Take a look below for more information about changes and additions to auth0.js in version 8! - -## Initialization of auth0.js - -Initialization of auth0.js in your application will now use `auth0.WebAuth` instead of `Auth0` -```html - - -``` - -## The parseHash Method - -The `parseHash` method now validates the id_token. In order for this to work properly, the token should be signed using RS256, and will fail if the token is signed using HS256. - -This can be avoided by either switching how your id_tokens are signed, or by manually parsing hashes, rather than using the `parseHash` method. - -### Switching from HS256 to RS256 - -::: panel-warning Before Changing the Signing Algorithm -Please note that altering the signing algorithm for your client will immediately change the way your user's tokens are signed. This means that if you have already implemented JWT verification for your client 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 client, follow these instructions: -1. Go to [Dashboard > Clients](https://manage.auth0.com/#/clients) -1. Select your client -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. - -### Manually Parsing Hashes - -If you would rather manually parse hashes, to avoid the `parseHash` method since it only works with RS256, feel free to take a look at [this example](https://github.com/auth0/auth0.js/blob/master/src/web-auth/index.js#L97) or [this one](https://github.com/auth0/auth0.js/blob/master/src/helper/qs.js#L10) to help you get started. - -## 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 the [Hosted Login Page](/libraries/auth0js#hosted-login-page), 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 `passwordlessVerify`. 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.passwordlessVerify({ - connection: 'Username-Password-Authentication', - email: 'foo@bar.com', - verificationCode: '389945' - }, function (err,res) { - // handle errors or continue - } -); -``` - -## Refreshing Tokens - -In [auth0.js v7](/libraries/auth0js/v7#refresh-token), the `renewIdToken` and `refreshToken` methods were used to renew tokens. In [auth0.js v8](/libraries/auth0js#using-renewauth-to-acquire-new-tokens), -refreshing tokens is now done via the `renewAuth` method. If a user is already authenticated, `renewAuth` can acquire a new token for that user. - -## User Management - -Linking accounts and gathering info has also changed. You can now instantiate a Management client 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/v7/index.md b/articles/libraries/auth0js/v7/index.md deleted file mode 100644 index 4a8cc2e073..0000000000 --- a/articles/libraries/auth0js/v7/index.md +++ /dev/null @@ -1,770 +0,0 @@ ---- -section: libraries -toc: true -description: How to install, initialize and use auth0.js v7 -url: /libraries/auth0js/v7 ---- - -# Auth0.js v7 Reference - -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`. - -
        - This document covers an out-of-date version of auth0.js - version 7. If you are already using version 8, you can take a look at the v8 reference, or if you are using v7 but interested in upgrading, take a look at the v8 migration guide. -
        - -## 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 client 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 client 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 client 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. - -> Note: Server-side processing of the `code` looks something like this: Using whichever [Auth0 server-side SDK](https://auth0.com/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. - -> **WARNING**: 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 (i.e. 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 client 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/v9/index.md b/articles/libraries/auth0js/v9/index.md new file mode 100644 index 0000000000..4366c9d400 --- /dev/null +++ b/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/articles/libraries/auth0js/v9/migration-angular.md b/articles/libraries/auth0js/v9/migration-angular.md new file mode 100644 index 0000000000..ee64ca6012 --- /dev/null +++ b/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/articles/libraries/auth0js/v9/migration-angularjs-v6.md b/articles/libraries/auth0js/v9/migration-angularjs-v6.md new file mode 100644 index 0000000000..b87b3568e6 --- /dev/null +++ b/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/articles/libraries/auth0js/v9/migration-angularjs-v7.md b/articles/libraries/auth0js/v9/migration-angularjs-v7.md new file mode 100644 index 0000000000..6020f63d6c --- /dev/null +++ b/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/articles/libraries/auth0js/v9/migration-angularjs-v8.md b/articles/libraries/auth0js/v9/migration-angularjs-v8.md new file mode 100644 index 0000000000..edea9b70ee --- /dev/null +++ b/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/articles/libraries/auth0js/v9/migration-guide.md b/articles/libraries/auth0js/v9/migration-guide.md new file mode 100644 index 0000000000..51c3f7a950 --- /dev/null +++ b/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/articles/libraries/auth0js/v9/migration-react.md b/articles/libraries/auth0js/v9/migration-react.md new file mode 100644 index 0000000000..633c543fbb --- /dev/null +++ b/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/articles/libraries/auth0js/v9/migration-v6-v9.md b/articles/libraries/auth0js/v9/migration-v6-v9.md new file mode 100644 index 0000000000..99375af3f5 --- /dev/null +++ b/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/articles/libraries/auth0js/v9/migration-v7-v9.md b/articles/libraries/auth0js/v9/migration-v7-v9.md new file mode 100644 index 0000000000..7a1c5bb666 --- /dev/null +++ b/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/articles/libraries/auth0js/v9/migration-v8-v9.md b/articles/libraries/auth0js/v9/migration-v8-v9.md new file mode 100644 index 0000000000..2a40de08b2 --- /dev/null +++ b/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/articles/libraries/custom-signup.md b/articles/libraries/custom-signup.md index 87ff5b6139..fe0c3841bf 100644 --- a/articles/libraries/custom-signup.md +++ b/articles/libraries/custom-signup.md @@ -1,33 +1,47 @@ --- 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 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 10 supports [custom fields signup](/libraries/lock/v10/customization#additionalsignupfields-array-). +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 Rules +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. -One way to use social IDP signups with Lock and collect custom fields is to use [redirect rules](/rules/redirect) to redirect the user to another page (Ideally, a [webtask](https://webtask.io/docs) or a custom page hosted by you) where you ask for extra information, and then redirect back to finish the authentication transaction. +### Redirect to another page -### Progressive Profiling +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. -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. +### Progressive profiling -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
        @@ -51,15 +65,22 @@ For further reference, here is our [documentation on progressive profiling](/use
        ``` -**NOTE**: `name` and `color` are custom fields. +The `name` is a user profile attribute and `color` is a custom field. -::: panel-info Custom field validation -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 logic in your application. +::: 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 { @@ -71,25 +92,28 @@ 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\"}}" } } ``` -## Custom Fields Limitations +## 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. +* `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. +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). +::: 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({ @@ -102,24 +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. -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. +Capture the `username` field in your custom form, and add the `username` to your request body. -Similarly, the Lock widget in sign up mode will prompt for a username, email and password. - -Then users can log in with Username and Password. +```html +
        +
        + Sign up +

        + +

        +

        + +

        +

        + +

        + +
        +
        +``` -## Optional: Verifying password strength +```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() + } +} -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). +$.ajax(settings).done(function (response) { + console.log(response); +}); +``` -The configured password policies, along with other connection information, can be retrieved publicly by accessing a JSONP file at the following URL: +## Optional: Verify password strength -`https://cdn.auth0.com/client/${account.clientId}.js` +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). -This file can then be parsed client-side to find the current password policy configured in the dashboard. For an example, see: [Custom signup with password policy](https://github.com/auth0/auth0-password-policy-sample). +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 4ef47310fc..a6c1e29606 100644 --- a/articles/libraries/error-messages.md +++ b/articles/libraries/error-messages.md @@ -1,16 +1,49 @@ --- -description: API authentication-related errors using Auth0 libraries +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 -# API Authentication-Related Errors Using Auth0 Libraries +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. -If you are using any of the Auth0-provided libraries, your users may trigger one or more of the following API authentication-related error messages when they either sign up or log in. While this is not an exhaustive list of all possible errors, these are the ones that may be easily handled by the end users themselves. +## Sign up -* **mfa_required**: the user must provide the multifactor authentication (MFA) code to authenticate; -* **mfa_registration_required**: the administrator has required multifactor authentication (MFA), but the user has not enrolled; -* **mfa_invalid_code**: the multifactor authentication (MFA) code provided by the user is invalid/expired; -* **PasswordStrengthError**: the password provided for sign up does not match the connection's strength requirements; -* **PasswordHistoryError**: the password provided for sign up/update has already been used (reported when password history feature is enabled); -* **unauthorized**: the user's action violates an Auth0 rule; the message provided by the rule may be located in the 'description' field; -* **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. +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/articles/libraries/index.md b/articles/libraries/index.md new file mode 100644 index 0000000000..cb41e46b6c --- /dev/null +++ b/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/articles/libraries/lock-android/_includes/_lock-version.md b/articles/libraries/lock-android/_includes/_lock-version.md new file mode 100644 index 0000000000..4c92f0862e --- /dev/null +++ b/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/articles/libraries/lock-android/_includes/_next-steps.md b/articles/libraries/lock-android/_includes/_next-steps.md new file mode 100644 index 0000000000..98cf862b59 --- /dev/null +++ b/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/articles/libraries/lock-android/configuration.md b/articles/libraries/lock-android/configuration.md deleted file mode 100644 index eb73d041a6..0000000000 --- a/articles/libraries/lock-android/configuration.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -section: libraries -toc_title: Lock for Android Configuration Options -description: Altering the appearance and behavior of Lock for Android ---- - -# Lock Configuration Options - -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. - -## 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. -- **useImplicitGrant {boolean}**: Whether to use the Implicit Grant or Code Grant flow when authenticating. By default it will try to use Code Grant. If the device has an old API level and can't generate the hash because it lacks the required algorithms, it will use the Implicit Grant. - -## 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'll 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. -- **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. -- **setPrivacyURL {String}**: Allows to customize the Privacy Policy URL. Will default to "https://auth0.com/privacy". -- **setTermsURL {String}**: Allows to customize the Terms of Service URL. Will default to "https://auth0.com/terms". -- **setMustAcceptTerms {boolean}**: Forces the user to accept the Terms&Policy before signing up. Defaults to false. - -## 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/custom-oauth-connections) 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. The scopes are not validated in any way and need to be recognized by the given authentication provider. - -## 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. \ No newline at end of file diff --git a/articles/libraries/lock-android/custom-authentication-providers.md b/articles/libraries/lock-android/custom-authentication-providers.md deleted file mode 100644 index 6251ddbf34..0000000000 --- a/articles/libraries/lock-android/custom-authentication-providers.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -section: libraries -toc_title: Custom Authentication Providers -description: Implementing custom authentication providers ---- - -# 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. Currently available are [Google](/libraries/lock-android/native-provider-google) and [Facebook](/libraries/lock-android/native-provider-facebook). - -## 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. - -> In this example we used `MyLinkedInProvider`, `TwitterDevProvider` and `TwitterProvider` classes _not included_ in **Lock**. - -Our [Google](https://github.com/auth0/Lock-Google.Android) and [Facebook](https://github.com/auth0/Lock-Facebook.Android) Native Providers implementations will provide `AuthHandler`s for you to use directly with **Lock**. diff --git a/articles/libraries/lock-android/custom-fields.md b/articles/libraries/lock-android/custom-fields.md deleted file mode 100644 index 6b44934fa0..0000000000 --- a/articles/libraries/lock-android/custom-fields.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -section: libraries -toc_title: Custom Fields at Signup -description: Adding additional fields to signups with Lock for Android ---- - -# Lock for 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). -2. Type: The `FieldType` to use in this field. The type defines the keyboard layout and sometimes the input validation. -3. 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. -4. Hint: The `@StringRes` of the text to show as hint in the field. - -```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); -``` - -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. - -> 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. - -## Field Types -Each custom field can only have one `FieldType` associated. - -* TYPE_NAME -* TYPE_NUMBER -* TYPE_PHONE_NUMBER -* TYPE_EMAIL diff --git a/articles/libraries/lock-android/custom-oauth-connections.md b/articles/libraries/lock-android/custom-oauth-connections.md deleted file mode 100644 index caa038c759..0000000000 --- a/articles/libraries/lock-android/custom-oauth-connections.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -section: libraries -description: Lock for Android - Custom Oauth Connections ---- - -# Custom OAuth Connections - -## Create the OAuth Connection in the Dashboard - -First the user needs to create a new connection by using the `Custom Social Connections` [extension](https://manage.auth0.com/#/extensions), filling every required field before saving the changes. - -## Customize the Style in Lock - -To customize OAuth connections 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 is found it will default to the Lock social defaults. This means that for "facebook" it will use facebook background color, facebook logo and "FACEBOOK" as name. - -As the builder method receives the `connectionName` you can now customize `oauth2` strategy type connections. The default values for this strategy are the same as in v1: Auth0 logo, Auth0 background color, and "OAUTH2" as name. diff --git a/articles/libraries/lock-android/custom-theming.md b/articles/libraries/lock-android/custom-theming.md deleted file mode 100644 index 1af373d3d5..0000000000 --- a/articles/libraries/lock-android/custom-theming.md +++ /dev/null @@ -1,63 +0,0 @@ ---- -section: libraries -toc_title: Custom Theming -description: Customizing the Lock for Android UI ---- - -# Lock for Android Custom Theming - -The **Lock.Android** UI is very customizable. - -## 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. | - -## 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 - - - -``` - -> 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 `MyLockTheme` 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. diff --git a/articles/libraries/lock-android/delegation-api.md b/articles/libraries/lock-android/delegation-api.md deleted file mode 100644 index c2e69c1cc5..0000000000 --- a/articles/libraries/lock-android/delegation-api.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -section: libraries -description: Integrate with third-party apps with the delegation API. ---- - -::: panel-warning Version Warning -This document is not yet updated to use [Lock for Android](https://github.com/auth0/Lock.Android) 2.0. It will be soon! -::: - -# Lock Android: Delegation API - -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 -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 - } - }); -``` - -> 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/articles/libraries/lock-android/error-messages.md b/articles/libraries/lock-android/error-messages.md deleted file mode 100644 index efd4fc7929..0000000000 --- a/articles/libraries/lock-android/error-messages.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -section: libraries -description: Types of error messages with Lock for Android ---- - -# Android Lock: Error Messages - -You may encounter one or more of the following messages when signing up using Lock for Android: - -* 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; -* user is blocked: the user you are attempting to sign up with is blocked; -* too_many_attempts: too many attempts to sign in have been made and the account was blocked -* unauthorized: you may not sign up for this application; diff --git a/articles/libraries/lock-android/index.md b/articles/libraries/lock-android/index.md deleted file mode 100644 index 0bab1ac017..0000000000 --- a/articles/libraries/lock-android/index.md +++ /dev/null @@ -1,252 +0,0 @@ ---- -section: libraries -toc: true -toc_title: Getting Started with Lock for Android -title: Lock for Android -url: /libraries/lock-android -description: A widget that provides a frictionless login and signup experience for your native Android apps. ---- - -# Lock for Android - -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. You can also use Lock for Android to provide Passwordless authentication using email or SMS. - -Get started using Lock for Android below, or if you're looking for a specific document, try the listing of [additional documents](#additional-documents) related to Lock for Android!! - -## Requirements - -You need Android API level 15+ to use Lock's UI. -If you intend to create your own UI and call the Auth0 API via the [Auth0.Android library](https://github.com/auth0/Auth0.Android), the minimum required API level is also 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.0.0' -``` - -_You can check for the latest version on the repository [Releases](https://github.com/auth0/Lock.Android/releases) tab, 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/lock-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](https://manage.auth0.com) before you get started. - -### Callback URL - -Head over to your Auth0 Dashboard and go to the client's settings. Add the following URL to the client's "Allowed Callback URLs" - -```text -https://{YOUR_AUTH0_DOMAIN}/android/{YOUR_APP_PACKAGE_NAME}/callback -``` - -Be sure to change the URL to add your Auth0 domain and your app package name of course! - -### Keystores - -You will need a keystore 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 "debug keystore" to sign your application, and that requires specific values. - -The following examples will explain how to generate a keystore using debug values. For a release keystore, replace the name, password, alias, and key password with your own values. - -**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 -``` - -Once you have your keystore file output, copy the resulting SHA256 value and go to your client's settings in the Auth0 Dashboard. 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 value you copied from your keystore. Don't forget to save the changes. - -::: panel-warning Required Actions -If you don't add the callback URL to the client settings nor the key hash to the client's mobile settings, the Auth0 server won't return the call result to your application. -::: - -## 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/passwordless) page. - -### Configuring AndroidManifest.xml - -Add the `android.permission.INTERNET` permission to the Manifest to allow Lock to make requests to the Auth0 API. - -```java - -``` - -Add `LockActivity` to your Manifest, replacing the `host` attribute with your `${account.namespace}` domain and the `{YOUR_APP_PACKAGE_NAME}` in the `pathPrefix` attribute with your application's package name. This filter allows Android OS to notify your application when an URL with that format is hit. For Lock, this means receiving the authentication result. - -```xml - - - - - - - - - - -``` - -#### Some Restrictions - -* Make sure the Activity's 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}'); -``` - -### 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 the [Tokens documentation](/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`. - -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) { - Auth0 auth0 = new Auth0('${account.clientId}','${account.namespace}'); - lock = Lock.newBuilder(auth0, callback) - // ... Options - .build(this); - } - - @Override - public void onDestroy() { - lock.onDestroy(this); - lock = null; - super.onDestroy(); - } - - 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 the `LockActivity` when your `Activity` calls the `OnDestroy` method, as it helps to keep the Lock state. - -Then, start `LockActivity` from inside your `Activity` - -```java -startActivity(lock.newIntent(this)); -``` - -That's it! Lock will handle the rest for you. - -## 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/passwordless). - -## Proguard - -In the [proguard directory](https://github.com/auth0/Lock.Android/tree/master/proguard) you can find the *Proguard* configuration for Lock for Android and its dependencies. You can use this in your release builds to avoid issues when compiling. - -By default you should at least use the following files: -* `proguard-okio.pro` -* `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 the [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/configuration). Also, for users of v1 migrating to v2, read the [Migration Guide](/libraries/lock-android/migration-guide) to see what options have changed. - -## Additional Documents - -
          -<% cache.find('articles/libraries/lock-android', {sort: 'toc_title'}).forEach(article => { %> - <% if (article.toc_title) { %> -
        • - <%- article.toc_title %> - <% if (article.description) { %> - - <%- article.description %> - <% } %> - -
          • - <% } %> -<% }); %> -
        diff --git a/articles/libraries/lock-android/index.yml b/articles/libraries/lock-android/index.yml new file mode 100644 index 0000000000..f8c9d39302 --- /dev/null +++ b/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/articles/libraries/lock-android/internationalization.md b/articles/libraries/lock-android/internationalization.md deleted file mode 100644 index e25b146c17..0000000000 --- a/articles/libraries/lock-android/internationalization.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -section: libraries -toc_title: Internationalization -title: Internationalization -description: Internationalization support in Lock for 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/articles/libraries/lock-android/migration-guide.md b/articles/libraries/lock-android/migration-guide.md deleted file mode 100644 index 03d07caf70..0000000000 --- a/articles/libraries/lock-android/migration-guide.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -section: libraries -toc_title: Migration Notes v1 to v2 -description: A reference for changed option names and behaviors in Lock for Android v2 ---- - -# Lock for Android v1 to v2 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. If you want to get the UserProfile you'll need to make a request to Auth0 using the `id_token`. - -1. Reuse the previous instance of the `Auth0` object or create a new one with your account details. -2. Save the `id_token` value received in the authentication. If the value is not present in the `Credentials` object that you received, check that you're requesting the authentication with the scope `openid`. This is the default requested scope. -3. Create a new `AuthenticationAPIClient` instance by passing the auth0 object. -4. Call the `tokenInfo` method on the api client passing the saved token. - -```java -Auth0 auth0 = new Auth0( '${account.clientId}','${account.namespace}'); -String idToken = credentials.getIdToken(); -AuthenticationAPIClient apiClient = new AuthenticationAPIClient(auth0); - -apiClient.tokenInfo(idToken) - .start(new BaseCallback() { - @Override - public void onSuccess(final UserProfile profile) { - //profile received - } - - @Override - public void onFailure(AuthenticationException error) { - //profile 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 [options documentation](/libraries/lock-android#lock-configuration-options) for a complete list of them. \ No newline at end of file diff --git a/articles/libraries/lock-android/native-provider-facebook.md b/articles/libraries/lock-android/native-provider-facebook.md deleted file mode 100644 index eaecf0d7e5..0000000000 --- a/articles/libraries/lock-android/native-provider-facebook.md +++ /dev/null @@ -1,214 +0,0 @@ ---- -section: libraries -description: Lock for Android - Google as a Provider ---- - -# 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. - -## 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.0.1' -``` - -## Requirements - -Android 4.0 or later & Facebook Android SDK 4.+ - -## Github Repository - -[https://github.com/auth0/Lock-Facebook.Android](https://github.com/auth0/Lock-Facebook.Android) - -## 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](https://manage.auth0.com/#/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. -3. Complete the "App Secret" field with the `APP SECRET` value obtained in the step 5 of the **Facebook Developers Console** section above. -6. Click the Save button. -7. Go to the Auth0 Dashboard and click [Clients](https://manage.auth0.com/#/clients). If you haven't created yet one, do that first and get into your client configuration page. -8. At the bottom of the page, click the "Show Advanced Settings" link and go to the "Mobile 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 `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) { - Auth0 auth0 = new Auth0(getString(R.string.com_auth0_client_id), getString(R.string.com_auth0_domain)); - final AuthenticationAPIClient client = new AuthenticationAPIClient(auth0); - provider = new FacebookAuthProvider(client); - } - - // ... -} -``` - -> If you need further help with the 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 and redirect the call to the provider instance. Finally, call start to begin the authentication process. - -```java -@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 with 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); -``` - -### Requesting custom Facebook Permissions -By default, the permission `public_profile` is requested. You can customize them by calling `setPermissions` with the list of Permissions. - -```java -provider.setPermissions(Arrays.asList("public_profile", "user_photos")); -``` - -### Requesting custom Android Runtime Permissions -This provider doesn't require any special Android Manifest Permission 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"}); -``` - -### 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 App in the Facebook Developers Console, you will need to provide the SHA-1 of the certificate you're using to sign your application in Base64 encoding. To obtain it follow this steps: - -Locate the certificate you're using to sign your application. If you don't have one you can generate it or use the default `android.keystore` certificate, that was generated automatically for you when you installed the SDK. In this example we're going to use the default one. - -* On Windows: - -```sh -keytool -exportcert -alias androiddebugkey -keystore %USERPROFILE%\.android\debug.keystore -storepass android | openssl sha1 -binary | openssl base64 -``` - -* On Linux / macOS: - -```sh -keytool -exportcert -alias androiddebugkey -keystore ~/.android/debug.keystore -storepass android | openssl sha1 -binary | openssl base64 -``` - -Sample output: - -``` -no71633JAC3qgzQYCbskprUr55k= -``` - -In your Auth0 Dashboard Client's settings, you will need to provide the SHA-256 of the certificate you're using to sign your application. To obtain it follow this steps: - -* On Windows: - -```sh -keytool -list -v -keystore "%USERPROFILE%\.android\debug.keystore" -alias androiddebugkey -storepass android -keypass android -``` - -* On Linux / macOS - -```sh -keytool -list -v -keystore ~/.android/debug.keystore -alias androiddebugkey -storepass android -keypass android -``` - -Sample output: - -``` -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 -``` - -The value you need for the Auth0 Dashboard is in the **SHA-256** line. diff --git a/articles/libraries/lock-android/native-provider-google.md b/articles/libraries/lock-android/native-provider-google.md deleted file mode 100644 index 1f66f26c97..0000000000 --- a/articles/libraries/lock-android/native-provider-google.md +++ /dev/null @@ -1,188 +0,0 @@ ---- -section: libraries -description: Lock for Android - Google as a Provider ---- - -# 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. - -## Latest version - -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.0.0' -``` - -## Requirements - -Android 4.0 or later & Google Play Services 9.+ - -## Github Repository - -[https://github.com/auth0/Lock-Google.Android](https://github.com/auth0/Lock-Google.Android) - -## 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://{YOUR_DOMAIN}.auth0.com/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](https://manage.auth0.com/#/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 [Clients](https://manage.auth0.com/#/clients). If you haven't created yet one, do that first and get into your client configuration page. -8. At the bottom of the page, click the "Show Advanced Settings" link and go to the "Mobile 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 value 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)); - final AuthenticationAPIClient client = new AuthenticationAPIClient(auth0); - provider = new GoogleAuthProvider(getString(R.string.google_server_client_id), client); - } - - // ... -} -``` - -> If you need further help with the 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 instance. - -```java -FacebookAuthHandler 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 -@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 with 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); -``` - -### 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 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 Permission 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 `ActivityCompat.OnRequestPermissionsResultCallback` and override the `onRequestPermissionsResult` method, calling `provider.onRequestPermissionsResult` with the activity context and the received parameters. - -### 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 Client's Configuration in the Auth0 Dashboard you will also need to provide the SHA-256 value. To obtain them follow this steps: - -Locate the certificate you're using to sign your application. If you don't have one you can generate it or use the default `android.keystore` certificate, that was generated automatically for you when you installed the SDK. In this example we're going to use the default one. - -* On Windows: - -```sh -keytool -list -v -keystore "%USERPROFILE%\.android\debug.keystore" -alias androiddebugkey -storepass android -keypass android -``` - -* On Linux / macOS - -```sh -keytool -list -v -keystore ~/.android/debug.keystore -alias androiddebugkey -storepass android -keypass android -``` - -Sample output: - -``` -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 -``` - -The values you need are located in the **SHA-1** and the **SHA-256** lines. diff --git a/articles/libraries/lock-android/passwordless-magic-link.md b/articles/libraries/lock-android/passwordless-magic-link.md deleted file mode 100644 index f8ea2cd846..0000000000 --- a/articles/libraries/lock-android/passwordless-magic-link.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -section: libraries -description: Passwordless with Magic Link with Lock Android ---- - -::: panel-warning Version Warning -This document is not yet updated to use [Lock for Android](https://github.com/auth0/Lock.Android) 2.0. It will be soon! -::: - -# 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 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). - -> 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. - -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. - -### Client configuration - -We'll have to configure/add some field to our Auth0 client. 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. - -#### 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 client 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": ["", ""] - } - } -} -``` - -> Don't forget to change the body to use your package name and keystore fingerprint! - -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 %} -``` - -> 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 client 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 appropiate mode. - -If we would like to send app links by **Email**, just start `LockPasswordlessActivity` especifying 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/articles/libraries/lock-android/passwordless.md b/articles/libraries/lock-android/passwordless.md deleted file mode 100644 index 7d4568189f..0000000000 --- a/articles/libraries/lock-android/passwordless.md +++ /dev/null @@ -1,88 +0,0 @@ ---- -section: libraries -toc_title: Passwordless Authentication with Lock for Android -description: Guide on implementing Passwordless authentication with Lock for Android ---- - -# Implementing Lock Passwordless - -`PasswordlessLockActivity` 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 email/SMS connection enabled and configured in your [Auth0 dashboard](https://manage.auth0.com/#/connections/passwordless). - -You'll need to add the `PasswordlessLockActivity` to your Manifest, inside the `application` tag: - -```xml - - - - - - - - - - -``` - -Make sure the Activity's `launchMode` is declared as `"singleTask"` or the result won't come back after the authentication. - -Also, you'll need to add *Internet* permission to your application: -```xml - -``` - -Then in any of your Activities, you need to initialize **PasswordlessLock** - -```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}'); - lock = PasswordlessLock.newBuilder(auth0, callback) - //Customize Lock - .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 - } - }; -} -``` - -Then, just start `PasswordlessLockActivity` from inside your `Activity` - -```java -startActivity(lock.newIntent(this)); -``` \ No newline at end of file diff --git a/articles/libraries/lock-android/refresh-jwt-tokens.md b/articles/libraries/lock-android/refresh-jwt-tokens.md deleted file mode 100644 index fc58a5b045..0000000000 --- a/articles/libraries/lock-android/refresh-jwt-tokens.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -section: libraries -description: Keeping your user logged in ---- - -::: panel-warning Version Warning -This document is not yet updated to use [Lock for Android](https://github.com/auth0/Lock.Android) 2.0. It will be soon! -::: - -# Lock Android: Refreshing JWT 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 JWT token and avoid asking the user their credentials again. - -> 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. - -```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 a 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. - -## Using a non-expired id_token - -```java -String idToken = // Retrieve id_token from the 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 the 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/articles/libraries/lock-android/sending-authentication-parameters.md b/articles/libraries/lock-android/sending-authentication-parameters.md deleted file mode 100644 index 8a289fb7b8..0000000000 --- a/articles/libraries/lock-android/sending-authentication-parameters.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -section: libraries -description: Sending Authentication parameters with Lock Android ---- - -::: panel-warning Version Warning -This document is not yet updated to use [Lock for Android](https://github.com/auth0/Lock.Android) 2.0. It will be soon! -::: - -# Lock Android: Sending Authentication Parameters - -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 `ParemterBuilder.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 (e.g. 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 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/articles/libraries/lock-android/v1/configuration.md b/articles/libraries/lock-android/v1/configuration.md new file mode 100644 index 0000000000..918f0e31ed --- /dev/null +++ b/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/articles/libraries/lock-android/v1/delegation-api.md b/articles/libraries/lock-android/v1/delegation-api.md new file mode 100644 index 0000000000..f868a9de45 --- /dev/null +++ b/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/articles/libraries/lock-android/v1/index.md b/articles/libraries/lock-android/v1/index.md new file mode 100644 index 0000000000..9c2bdbf318 --- /dev/null +++ b/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/articles/libraries/lock-android/v1/internationalization.md b/articles/libraries/lock-android/v1/internationalization.md new file mode 100644 index 0000000000..141c75ae56 --- /dev/null +++ b/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/articles/libraries/lock-android/v1/native-social-authentication.md b/articles/libraries/lock-android/v1/native-social-authentication.md new file mode 100644 index 0000000000..295964224c --- /dev/null +++ b/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/articles/libraries/lock-android/v1/passwordless-magic-link.md b/articles/libraries/lock-android/v1/passwordless-magic-link.md new file mode 100644 index 0000000000..a318f4fb5f --- /dev/null +++ b/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/articles/libraries/lock-android/v1/passwordless.md b/articles/libraries/lock-android/v1/passwordless.md new file mode 100644 index 0000000000..473c2ee94a --- /dev/null +++ b/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/articles/libraries/lock-android/v1/refresh-jwt-tokens.md b/articles/libraries/lock-android/v1/refresh-jwt-tokens.md new file mode 100644 index 0000000000..6460b9756c --- /dev/null +++ b/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/articles/libraries/lock-android/v1/sending-authentication-parameters.md b/articles/libraries/lock-android/v1/sending-authentication-parameters.md new file mode 100644 index 0000000000..9ebaa1ad4e --- /dev/null +++ b/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/articles/libraries/lock-android/v1/use-your-own-ui.md b/articles/libraries/lock-android/v1/use-your-own-ui.md new file mode 100644 index 0000000000..5ab6f8899c --- /dev/null +++ b/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/articles/libraries/lock-android/v2/configuration.md b/articles/libraries/lock-android/v2/configuration.md new file mode 100644 index 0000000000..0a6bc8c3f2 --- /dev/null +++ b/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/articles/libraries/lock-android/v2/custom-authentication-providers.md b/articles/libraries/lock-android/v2/custom-authentication-providers.md new file mode 100644 index 0000000000..44e93d8d40 --- /dev/null +++ b/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/articles/libraries/lock-android/v2/custom-fields.md b/articles/libraries/lock-android/v2/custom-fields.md new file mode 100644 index 0000000000..f68d7cf54b --- /dev/null +++ b/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/articles/libraries/lock-android/v2/custom-theming.md b/articles/libraries/lock-android/v2/custom-theming.md new file mode 100644 index 0000000000..9ed6a02d3f --- /dev/null +++ b/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/articles/libraries/lock-android/v2/delegation-api.md b/articles/libraries/lock-android/v2/delegation-api.md new file mode 100644 index 0000000000..98291b7eb8 --- /dev/null +++ b/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/articles/libraries/lock-android/v2/index.md b/articles/libraries/lock-android/v2/index.md new file mode 100644 index 0000000000..1eb9d180a9 --- /dev/null +++ b/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/articles/libraries/lock-android/v2/internationalization.md b/articles/libraries/lock-android/v2/internationalization.md new file mode 100644 index 0000000000..f2dc13d979 --- /dev/null +++ b/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/articles/libraries/lock-android/v2/keystore.md b/articles/libraries/lock-android/v2/keystore.md new file mode 100644 index 0000000000..7b31c26d29 --- /dev/null +++ b/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/articles/libraries/lock-android/v2/migration-guide.md b/articles/libraries/lock-android/v2/migration-guide.md new file mode 100644 index 0000000000..7fcc499bb9 --- /dev/null +++ b/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/articles/libraries/lock-android/v2/native-social-authentication.md b/articles/libraries/lock-android/v2/native-social-authentication.md new file mode 100644 index 0000000000..94576b4705 --- /dev/null +++ b/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/articles/libraries/lock-android/v2/passwordless-magic-link.md b/articles/libraries/lock-android/v2/passwordless-magic-link.md new file mode 100644 index 0000000000..b2479a7542 --- /dev/null +++ b/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/articles/libraries/lock-android/v2/passwordless.md b/articles/libraries/lock-android/v2/passwordless.md new file mode 100644 index 0000000000..c5bbd7d967 --- /dev/null +++ b/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/articles/libraries/lock-android/v2/refresh-jwt-tokens.md b/articles/libraries/lock-android/v2/refresh-jwt-tokens.md new file mode 100644 index 0000000000..3f039ce2c3 --- /dev/null +++ b/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/articles/libraries/lock-ios/_includes/_dependencies.md b/articles/libraries/lock-ios/_includes/_dependencies.md new file mode 100644 index 0000000000..f0b8babdc6 --- /dev/null +++ b/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/articles/libraries/lock-ios/_includes/_lock-version-1.md b/articles/libraries/lock-ios/_includes/_lock-version-1.md new file mode 100644 index 0000000000..fb21b112e4 --- /dev/null +++ b/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/articles/libraries/lock-ios/_includes/_lock-version.md b/articles/libraries/lock-ios/_includes/_lock-version.md new file mode 100644 index 0000000000..2596ef64e6 --- /dev/null +++ b/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/client-platforms/emberjs/dependencies.md b/articles/libraries/lock-ios/_includes/_roadmap.md similarity index 100% rename from snippets/client-platforms/emberjs/dependencies.md rename to articles/libraries/lock-ios/_includes/_roadmap.md diff --git a/articles/libraries/lock-ios/customization.md b/articles/libraries/lock-ios/customization.md deleted file mode 100644 index 28c4e86513..0000000000 --- a/articles/libraries/lock-ios/customization.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -section: libraries -toc_title: Customization -description: Learn how to customize the look and feel of Lock ---- - -# Lock iOS: Customization - -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().registerTheme(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/articles/libraries/lock-ios/delegation-api.md b/articles/libraries/lock-ios/delegation-api.md deleted file mode 100644 index 1d22ca8944..0000000000 --- a/articles/libraries/lock-ios/delegation-api.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -section: libraries -toc_title: Delegation API -description: Integrate with third-party apps with the delegation API. ---- - -# Lock iOS: Delegation API - -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.sharedLock().apiClient() -let token = ...; // Auth0's id_token obtained on login -let parameters = A0AuthParameters.newWithDictionary([ - "id_token": token, - A0ParameterAPIType: "firebase" - ]) -client.fetchDelegationTokenWithParameters(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/articles/libraries/lock-ios/index.md b/articles/libraries/lock-ios/index.md deleted file mode 100644 index 1b0455fe6c..0000000000 --- a/articles/libraries/lock-ios/index.md +++ /dev/null @@ -1,420 +0,0 @@ ---- -section: libraries -toc: true -url: /libraries/lock-ios -title: Lock 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. ---- - -# Lock for iOS and macOS - -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 Lock makes it easy to integrate SSO into your app. Lock's many benefits include: - -* Providing a professional looking login dialog that displays well on any device. -* Finding the right icons for popular social providers. -* Solving the home realm discovery challenge with enterprise users (i.e.: asking the enterprise user the email, and redirecting to the right enterprise identity provider). -* Implementing a standard sign-in protocol (OpenID Connect / OAuth2 Login) - -## 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, etc.), **Enterprise Providers** (AD, LDAP, etc.) and **Username & Password** authentication. -* Provides the ability to do **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 **TouchID** and **SMS**. - -## 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 [Client 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: - -#### Objective C - -```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 - -```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 -self.lock.applicationLaunchedWithOptions(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: - -#### Objective C - -```objc -- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation { - return [self.lock handleURL:url sourceApplication:sourceApplication]; -} -``` - -#### Swift - -```swift -func application(application: UIApplication, openURL url: NSURL, sourceApplication: String?, annotation: AnyObject?) -> Bool { - return self.lock.handleURL(url, sourceApplication: sourceApplication) -} -``` - -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 client 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. e.g.: 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 = lock.newLockViewController() -controller.onAuthenticationBlock = {(profile: A0UserProfile!, token: A0Token!) -> () in - // Do something with token & profile. e.g.: save them. - // Lock will not save the Token and the profile for you. - // And dismiss the UIViewController. - self.dismissViewControllerAnimated(true, completion: nil) -} -self.presentViewController(controller, animated: true, completion: nil) -``` - -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. e.g.: save them. - // And dismiss the ViewController -}; - -controller.onUserDismissBlock = ^(){ - NSLog(@"User closed Lock UI"); -}; - -[self presentViewController:controller animated:YES completion:nil]; -``` - -#### Swift - -```swift -let controller = A0Lock.sharedLock().newLockViewController() -controller.closable = true - -controller.onAuthenticationBlock = { (profile, token) in - // Do something with token & profile. e.g.: save them. - // And dismiss the ViewController -} - -controller.onUserDismissBlock = { () in - print("User closed Lock UI") -} - -self.presentViewController(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. e.g.: save them. - // And dismiss the ViewController -}; - -[self presentViewController:controller animated:YES completion:nil]; -``` - -#### Swift - -```swift -let controller = A0Lock.sharedLock().newSignUpViewController() -controller.onAuthenticationBlock = { (profile, token) in - // Do something with token & profile. e.g.: save them. - // And dismiss the ViewController -} - -self.presentViewController(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 implementating 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 = A0Lock.sharedLock().newLockViewController() - -controller.onAuthenticationBlock = { (profile, token) in - self.dismissViewControllerAnimated(true, completion: nil) -} - -//Create custom SignUp view controller -controller.customSignUp = { (lock:A0Lock, delegate:A0LockEventDelegate) 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.presentViewController(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. - -#### Important notes: - -* 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.sharedLock().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. e.g.: save them. - // And dismiss the ViewController -}; -controller.onUserDismissBlock = ^(){ -[self presentViewController:controller animated:YES completion:nil]; -``` - -#### Swift - -```swift -let controller = A0Lock.sharedLock().newLockViewController() -controller.useWebView = false -controller.onAuthenticationBlock = { (profile, token) in - // Do something with token & profile. e.g.: save them. - // And dismiss the ViewController -} -self.presentViewController(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). - -### Related Documentation - -
          -<% cache.find('articles/libraries/lock-ios', {sort: 'toc_title'}).forEach(article => { %> - <% if (article.toc_title) { %> -
        • - <%- article.toc_title %> - <% if (article.description) { %> - - <%- article.description %> - <% } %> - -
          • - <% } %> -<% }); %> -
        diff --git a/articles/libraries/lock-ios/index.yml b/articles/libraries/lock-ios/index.yml new file mode 100644 index 0000000000..4e65cc67bb --- /dev/null +++ b/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/articles/libraries/lock-ios/lock-ios-api.md b/articles/libraries/lock-ios/lock-ios-api.md deleted file mode 100644 index c7e344debb..0000000000 --- a/articles/libraries/lock-ios/lock-ios-api.md +++ /dev/null @@ -1,177 +0,0 @@ ---- -section: libraries -toc_title: Lock Objective-C API -description: Description of the Lock Objective-C API ---- - -## API - -### 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 client 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. e.g.: 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/articles/libraries/lock-ios/logging.md b/articles/libraries/lock-ios/logging.md deleted file mode 100644 index 1e4d15188f..0000000000 --- a/articles/libraries/lock-ios/logging.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -section: libraries -toc_title: Logging -description: Learn how to debug Lock by enabling logging. ---- - -# Lock iOS: Logging - -__Lock__ logs serveral useful debugging information using [CocoaLumberjack](https://github.com/CocoaLumberjack/CocoaLumberjack). - -> 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() -``` -> 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/articles/libraries/lock-ios/native-social-authentication.md b/articles/libraries/lock-ios/native-social-authentication.md deleted file mode 100644 index e1ca84ee2d..0000000000 --- a/articles/libraries/lock-ios/native-social-authentication.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -section: libraries -toc_title: Native Social Authentication -description: How to enable native login for some the supported social social connections. ---- - -# Lock iOS: Native Social Authentication - -**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' -``` -> We recommend to at least fix the major version instead of always obtaining the latest version, e.g `pod 'Lock-Facebook', '~> 2.0` - -## Configuration - -> 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 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. - -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` -> 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/articles/libraries/lock-ios/password-reset-ios.md b/articles/libraries/lock-ios/password-reset-ios.md deleted file mode 100644 index 0032e4a12f..0000000000 --- a/articles/libraries/lock-ios/password-reset-ios.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -section: libraries -toc_title: Password Reset -description: All you need to know about password reset with Lock for iOS. ---- - -# Lock iOS: Password Reset - -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. - -### Examples - -**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); - }]; -``` - -**Swift** - -```swift -let client = A0Lock.sharedLock().apiClient() -let params = A0AuthParameters.newDefaultParams(); -params[A0ParameterConnection] = "Username-Password-Authentication"; - // Or your configured DB connection -client.requestChangePasswordForUsername(, - parameters: params, success: { () in - print("Please check your email!") - }, failure: { (error: NSError) in - print("Oops something went wrong: \(error)") -}) -``` diff --git a/articles/libraries/lock-ios/save-and-refresh-jwt-tokens.md b/articles/libraries/lock-ios/save-and-refresh-jwt-tokens.md deleted file mode 100644 index 5da6e450ef..0000000000 --- a/articles/libraries/lock-ios/save-and-refresh-jwt-tokens.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -section: libraries -toc_title: Saving and Refreshing JWT Tokens -description: Keeping your user logged in ---- - -# Lock iOS: Saving and Refreshing JWT 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 JWT token and avoid asking the user his/her -credentials again. - -> 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 = ... -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.archivedDataWithRootObject(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/articles/libraries/lock-ios/sending-authentication-parameters.md b/articles/libraries/lock-ios/sending-authentication-parameters.md deleted file mode 100644 index 65dee93f75..0000000000 --- a/articles/libraries/lock-ios/sending-authentication-parameters.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -section: libraries -toc_title: Sending Authentication Parameters -description: How to send authentication parameters, and what parameters are supported when using Lock iOS. ---- - -# Lock iOS: Sending Authentication Parameters - -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 (e.g. 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 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 -}; -``` - -> 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/articles/libraries/lock-ios/sms-lock-ios.md b/articles/libraries/lock-ios/sms-lock-ios.md deleted file mode 100644 index e32f2c1f81..0000000000 --- a/articles/libraries/lock-ios/sms-lock-ios.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -section: libraries -toc_title: SMS in Lock iOS -description: How to use SMS in Lock iOS ---- - -## 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. e.g.: 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 = lock.newSMSViewController() -controller.auth0APIToken = {() -> String in return "Copy API v2 token here"} -controller.onAuthenticationBlock = {(profile: A0UserProfile!, token: A0Token!) -> () in - // Do something with token & profile. e.g.: save them. - // Lock will not save the Token and the profile for you. - // And dismiss the UIViewController. - self.dismissViewControllerAnimated(true, completion: nil) -} -lock.presentSMSController(controller, fromController: self) -``` -And you'll see SMS login screen - -![Lock SMS Screenshot](/media/articles/libraries/lock-ios/Lock-SMS-Screenshot.png) diff --git a/articles/libraries/lock-ios/sso-on-mobile-apps.md b/articles/libraries/lock-ios/sso-on-mobile-apps.md deleted file mode 100644 index e32f9bc2e5..0000000000 --- a/articles/libraries/lock-ios/sso-on-mobile-apps.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -section: libraries -toc_title: SSO on Mobile Apps -description: How to implement SSO on mobile apps with Lock iOS. ---- - - -# Lock iOS: SSO on Mobile Apps - -Lock allows you to easily implement single sign-on (SSO). Single sign-on is a mechanism that allows a user to use the same credentials between multiple applications. If you have two different applications and you have a user that is already authenticated app A, single sign-on allows that user to automatically be authenticated in app B as well. The experience is similar to what happens with Facebook and it's companion Messenger app, as well as Foursquare and Swarm. - -In order to do SSO on Mobile Apps, we need to use a shared keychain. We'll learn how to do this throughout this post. - -To enable keychain sharing you'll have to define a keychain access group with the following format: -`.` - -e.g.: ABC1234DEF.mysharedgroup - -The Bundle Seed Id is a unique (within the App Store) ten character string that is generated by Apple after you create your appId (using Apple's dev site). Each application identifier has the following format: - -`.` - -So each app that has the same Bundle Seed can access to values stored in groups with the same prefix so the apps: -* **ABC1234DEF.com.auth0.awesomeapp1** -* **ABC1234DEF.com.auth0.awesomeapp2** - -Can read/write values stored in the group **ABC1234DEF.mysharedgroup** - -In your project you'll need to add an entitlements file for each app declaring the access group. You can do it in capabilities tab of the project's target (under the label Keychain Sharing), just turn it on and add only the group name (without the Bundle Seed Id). - -To obtain a value form the Keychain: -```objc -A0SimpleKeychain *keychain = [A0SimpleKeychain keychainWithService:@"Auth0" accessGroup:@"ABC1234DEF.mysharedgroup"]; -NSString *refreshToken = [keychain stringForKey:@"refresh_token"]; -``` -```swift -let keychain = A0SimpleKeychain.keychainWithService("Auth0", accessGroup:"ABC1234DEF.mysharedgroup") -let refreshToken = keychain.stringForKey("refresh_token") -``` - -To store a value in the Keychain: -```objc -A0SimpleKeychain *keychain = [A0SimpleKeychain keychainWithService:@"Auth0" accessGroup:@"ABC1234DEF.mysharedgroup"]; -[keychain setString:auth0User.refreshToken forKey:@"refresh_token"]; -``` -```swift -let keychain = A0SimpleKeychain.keychainWithService("Auth0", accessGroup:"ABC1234DEF.mysharedgroup") -keychain.setString(auth0User.refreshToken, forKey:"refresh_token") -``` - -> This examples our a Keychain wrapper `SimpleKeychain`. For more information on how to use it please go to it's [Github repo](https://github.com/auth0/SimpleKeychain) - -You can now learn how to use the stored `refresh_token` with your app to be able to call an API securely in [this other guide](https://github.com/auth0/Auth0.iOS/wiki/How-to-save-and-refresh-JWT-token) diff --git a/articles/libraries/lock-ios/swift.md b/articles/libraries/lock-ios/swift.md deleted file mode 100644 index 4494d752dd..0000000000 --- a/articles/libraries/lock-ios/swift.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -section: libraries -toc_title: Using Lock with Swift -description: How to use Swift with Lock iOS. ---- - - -# Lock iOS: Using Swift - -**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`. - -> 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 = A0Lock.sharedLock().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.archivedDataWithRootObject(profile), forKey: "profile") - - // Other stuff - - self.dismissViewControllerAnimated(true, completion: nil) -} -self.presentViewController(authController, animated: true, completion: nil) -``` diff --git a/articles/libraries/lock-ios/touchid-authentication.md b/articles/libraries/lock-ios/touchid-authentication.md deleted file mode 100644 index 76aa62764e..0000000000 --- a/articles/libraries/lock-ios/touchid-authentication.md +++ /dev/null @@ -1,57 +0,0 @@ ---- -section: libraries -toc_title: TouchID Authentication -description: How to implement TouchID authentication with Lock iOS. ---- - -# Lock iOS: TouchID Authentication - -Lock provides passwordless authentication with TouchID for your Auth0 DB connection. To start authenticating your users with TouchID 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 - ``` - > 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 controller = A0TouchIDLockViewController() - controller.onAuthenticationBlock = { (profile, token) -> () in - //Store token & profile. For example in the keychain using SimpleKeychain. - self.dismissViewControllerAnimated(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.currentDevice().userInterfaceIdiom == .Pad { - navController.modalPresentationStyle = .FormSheet - } - self.presentViewController(navController, animated: true, completion:nil) - ``` - > 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/articles/libraries/lock-ios/use-your-own-ui.md b/articles/libraries/lock-ios/use-your-own-ui.md deleted file mode 100644 index 424523e243..0000000000 --- a/articles/libraries/lock-ios/use-your-own-ui.md +++ /dev/null @@ -1,146 +0,0 @@ ---- -section: libraries -toc_title: Build your own UI -description: Customize the UI of Lock in your App ---- - -# Lock iOS: Build your own UI - -<%= 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.loginWithUsername(email, password: password, parameters: parameters, success: { profile, token in - println("We did it!. Logged in with Auth0.") - }, failure: { error in - println("Oops something went wrong: \(error)") - }) - ``` -> 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.applicationLaunchedWithOptions(launchOptions) - ``` - -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]; - } - ``` - ```swift - func application(application: UIApplication, openURL url: NSURL, sourceApplication: String?, annotation: AnyObject?) -> Bool { - let lock = ... // Get your Lock instance - return lock.handleURL(url, sourceApplication: sourceApplication) - } - ``` - -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/articles/libraries/lock-ios/v1/customization.md b/articles/libraries/lock-ios/v1/customization.md new file mode 100644 index 0000000000..ed76e46250 --- /dev/null +++ b/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/articles/libraries/lock-ios/v1/delegation-api.md b/articles/libraries/lock-ios/v1/delegation-api.md new file mode 100644 index 0000000000..81be9f0cf1 --- /dev/null +++ b/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/articles/libraries/lock-ios/v1/index.md b/articles/libraries/lock-ios/v1/index.md new file mode 100644 index 0000000000..57b47e6a6c --- /dev/null +++ b/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/articles/libraries/lock-ios/v1/lock-ios-api.md b/articles/libraries/lock-ios/v1/lock-ios-api.md new file mode 100644 index 0000000000..660eb5dbe3 --- /dev/null +++ b/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/articles/libraries/lock-ios/v1/logging.md b/articles/libraries/lock-ios/v1/logging.md new file mode 100644 index 0000000000..f33ff75ea7 --- /dev/null +++ b/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/articles/libraries/lock-ios/v1/native-social-authentication.md b/articles/libraries/lock-ios/v1/native-social-authentication.md new file mode 100644 index 0000000000..56a08f5617 --- /dev/null +++ b/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/articles/libraries/lock-ios/v1/password-reset-ios.md b/articles/libraries/lock-ios/v1/password-reset-ios.md new file mode 100644 index 0000000000..9d7462f62f --- /dev/null +++ b/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/articles/libraries/lock-ios/v1/passwordless.md b/articles/libraries/lock-ios/v1/passwordless.md new file mode 100644 index 0000000000..6296f23b3c --- /dev/null +++ b/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/articles/libraries/lock-ios/v1/save-and-refresh-jwt-tokens.md b/articles/libraries/lock-ios/v1/save-and-refresh-jwt-tokens.md new file mode 100644 index 0000000000..69be180f58 --- /dev/null +++ b/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/articles/libraries/lock-ios/v1/sending-authentication-parameters.md b/articles/libraries/lock-ios/v1/sending-authentication-parameters.md new file mode 100644 index 0000000000..325e52750d --- /dev/null +++ b/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/articles/libraries/lock-ios/v1/swift.md b/articles/libraries/lock-ios/v1/swift.md new file mode 100644 index 0000000000..de468cce8c --- /dev/null +++ b/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/articles/libraries/lock-ios/v1/use-your-own-ui.md b/articles/libraries/lock-ios/v1/use-your-own-ui.md new file mode 100644 index 0000000000..e7cd769663 --- /dev/null +++ b/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/articles/libraries/lock-ios/v2/configuration.md b/articles/libraries/lock-ios/v2/configuration.md new file mode 100644 index 0000000000..20831500fb --- /dev/null +++ b/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/articles/libraries/lock-ios/v2/custom-fields.md b/articles/libraries/lock-ios/v2/custom-fields.md new file mode 100644 index 0000000000..3ce74320cf --- /dev/null +++ b/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/articles/libraries/lock-ios/v2/customization.md b/articles/libraries/lock-ios/v2/customization.md new file mode 100644 index 0000000000..438a224801 --- /dev/null +++ b/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/articles/libraries/lock-ios/v2/index.md b/articles/libraries/lock-ios/v2/index.md new file mode 100644 index 0000000000..ccde6a136d --- /dev/null +++ b/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/articles/libraries/lock-ios/v2/internationalization.md b/articles/libraries/lock-ios/v2/internationalization.md new file mode 100644 index 0000000000..cda2d77a2b --- /dev/null +++ b/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/articles/libraries/lock-ios/v2/logging.md b/articles/libraries/lock-ios/v2/logging.md new file mode 100644 index 0000000000..821a5dae26 --- /dev/null +++ b/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/articles/libraries/lock-ios/v2/migration.md b/articles/libraries/lock-ios/v2/migration.md new file mode 100644 index 0000000000..274c9bd896 --- /dev/null +++ b/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/articles/libraries/lock-ios/v2/passwordless.md b/articles/libraries/lock-ios/v2/passwordless.md new file mode 100644 index 0000000000..5f9478eca3 --- /dev/null +++ b/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/articles/libraries/lock/_includes/_lock-toc.md b/articles/libraries/lock/_includes/_lock-toc.md deleted file mode 100644 index bd34808f01..0000000000 --- a/articles/libraries/lock/_includes/_lock-toc.md +++ /dev/null @@ -1,11 +0,0 @@ -## Lock: Table of Contents - -* [Getting Started With Lock](/libraries/lock#lock-10-installation) - Methods of installation and an example app setup -* [Lock Configuration Options](/libraries/lock/v10/customization) - Altering Lock's behavior for your project's needs -* [Lock UI Customization](/libraries/lock/v10/ui-customization) - Customizing Lock's look and feel -* [Lock API Reference](/libraries/lock/v10/api) - The Lock API reference -* [Lock With auth0.js](/libraries/lock/v10/auth0js) - How to use Lock alongside `auth0.js` -* [Lock 9 to 10 Migration Guide](/libraries/lock/v10/migration-guide) - What existing customers need to know to migrate from Lock v9 to v10 -* [Language Support and Custom Text](/libraries/lock/v10/i18n) - Languages supported and customization of text fields -* [Customizing Error Messages](/libraries/lock/v10/customizing-error-messages) - Customizing error messages that are shown in Lock -* [Advanced Use Case: Popup Mode](/libraries/lock/v10/popup-mode) - An alternate Lock mode, not recommended in most use cases diff --git a/articles/libraries/lock/_includes/_lock-version-9.md b/articles/libraries/lock/_includes/_lock-version-9.md deleted file mode 100644 index b5814fbcc1..0000000000 --- a/articles/libraries/lock/_includes/_lock-version-9.md +++ /dev/null @@ -1,3 +0,0 @@ -
        - Heads up! This document uses an outdated version of Lock (version 9). Learn how to migrate to version 10, or, if you're new to Lock, start out with the Lock 10 Documentation. -
        diff --git a/articles/libraries/lock/_includes/_lock-version.md b/articles/libraries/lock/_includes/_lock-version.md deleted file mode 100644 index 345c00b49f..0000000000 --- a/articles/libraries/lock/_includes/_lock-version.md +++ /dev/null @@ -1,3 +0,0 @@ -
        - Heads up! This document uses the latest version of Lock (version 10). If you are still using version 9, check out the Lock 9 to Lock 10 migration guide, or the Lock 9 Documentation. -
        diff --git a/articles/libraries/lock/index.md b/articles/libraries/lock/index.md deleted file mode 100644 index 411f42f1b4..0000000000 --- a/articles/libraries/lock/index.md +++ /dev/null @@ -1,146 +0,0 @@ ---- -section: libraries -toc: true -url: /libraries/lock -title: Lock for Web -description: A widget that provides a frictionless login and signup experience for your web apps. ---- - -# Lock for Web - -You're looking at the documentation for the _easiest_ way of securing your website and mobile apps! - -Lock is an embeddable login form, which is [configurable to your needs][lock-customization] and ready for use on mobile devices. It's easier than ever to add social identity providers to Lock, as well, allowing your users to login seamlessly using whichever providers make sense for your application. Check out one of the pages listed below to delve into details about Lock usage, if you know what you are looking for, or continue down this page for a basic installation and usage guide! - -<%= include('_includes/_lock-version') %> - -<%= include('_includes/_lock-toc') %> - -## 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: - -```html - - - - - -``` - -**NOTE**: Replace `.x` and `.y` with the latest minor and patch release numbers from the [Lock Github repository](https://github.com/auth0/lock) for production environments. - -### 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 - -### Implementing Lock - -```js -// Initiating our Auth0Lock -var lock = new Auth0Lock( - '${account.clientId}', - '${account.namespace}' -); - -// 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; - } - - localStorage.setItem('accessToken', authResult.accessToken); - localStorage.setItem('profile', JSON.stringify(profile)); - }); -}); -``` - -### Showing Lock - -```js -document.getElementById('btn-login').addEventListener('click', function() { - lock.show(); -}); -``` - -### Displaying the User's Profile - -```js -// Verify that there's a token in localStorage -var token = localStorage.getItem('accessToken'); -if (token) { - showLoggedIn(); -} - -// Display the user's profile -function showLoggedIn() { - var profile = JSON.parse(localStorage.getItem('profile')); - document.getElementById('nick').textContent = profile.nickname; -} -``` - -```html -

        Welcome

        -``` - -**NOTE**: This example demonstrates using Lock 10 with a Single Page Application (SPA). To learn how Lock can be modified to provide frictionless authentication for any app, see the [API Reference][lock-api] and the [Configuration Options Reference][lock-customization]. For details specifically about customizing the look and feel of Lock in your app, please take a look at the [UI Customization][ui-customization] page. - -## Start Using Lock - -<%= include('../../_includes/_lock-sdk') %> - -## 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. - - - -[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-customization]: /libraries/lock/v10/customization -[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/index.yml b/articles/libraries/lock/index.yml new file mode 100644 index 0000000000..a120986e44 --- /dev/null +++ b/articles/libraries/lock/index.yml @@ -0,0 +1,7 @@ +versioning: + baseUrl: libraries/lock + current: v11 + versions: + - v11 + defaultArticles: + v11: index diff --git a/articles/libraries/lock/v10/api.md b/articles/libraries/lock/v10/api.md deleted file mode 100644 index 2ae0c58cfb..0000000000 --- a/articles/libraries/lock/v10/api.md +++ /dev/null @@ -1,214 +0,0 @@ ---- -section: libraries -toc: true -description: Details on the Lock V10 API. ---- - -<%= include('../_includes/_lock-version') %> - -# API - -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 - -## Auth0Lock - -```js -new Auth0Lock(clientID, domain, options) -``` - -Initializes a new instance of `Auth0Lock` configured with your client'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-info 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([callback]) -``` - -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. - -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); - }); -}); -``` - -- `authorization_error`: emitted when authorization fails. Has the error as its only argument. -- `hash_parsed`: _Note that this is a low level event for advanced use cases, and `authenticated` and `authorization_error` should be preferred when possible._ 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. 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/popup-mode), because in popup mode, there is no need to parse the URL's hash part. - -<%= include('../_includes/_lock-toc') %> diff --git a/articles/libraries/lock/v10/auth0js.md b/articles/libraries/lock/v10/auth0js.md deleted file mode 100644 index 76442da7ad..0000000000 --- a/articles/libraries/lock/v10/auth0js.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -section: libraries -description: How to use Lock V10 with auth0.js ---- - -<%= include('../_includes/_lock-version') %> - -# Using Lock With auth0.js - -If you try to use auth0.js along with Lock 10, you will not be able to call `getClient()`. Instead, you should include its dependency and instantiate the object. - -In the past, a version of auth0.js was included automatically with Lock; at this point, you must include auth0.js yourself, allowing you to choose the supported version of auth0.js that best suits the needs of your application - version 7, or version 8. Note that the two versions have different CDN paths, as well as slightly different instantiations. - -## Using auth0.js v8 - -### Including auth0.js - -If you included the Lock script from the Auth0 CDN, you will need to also include the auth0.js script before Lock: - -```html - - -``` - -If you installed Lock from npm, you must include `auth0-js` in your project dependencies and import it. Before instantiating the `Auth0` object, you will need to require `auth0-js`: - -```js -var Auth0 = require('auth0-js'); -``` - -### Initiating auth0.js - -Then, to use `auth0.js`, simply instantiate a new `Auth0` object: - -```js -var auth0 = new auth0.WebAuth({ - domain: "${account.namespace}", - clientID: "${account.clientId}" -}); -``` - -If you need further detail about usage, check out the [Auth0.js v8 Reference](/libraries/auth0js). - -## Using auth0.js v7 - -### Including auth0.js - -If you included the Lock script from the Auth0 CDN, you will need to also include the auth0.js script before Lock: - -```html - - -``` - -If you installed Lock from npm, you must include `auth0-js` in your project dependencies and import it. Before instantiating the `Auth0` object, you will need to require `auth0-js`: - -```js -var Auth0 = require('auth0-js'); -``` - -### Initiating auth0.js - -Then, to use `auth0.js`, simply instantiate a new `Auth0` object: - -```js -var client = new Auth0({ - domain: '${account.namespace}', - clientID: '${account.clientId}', - callbackURL: '{YOUR APP URL}', - responseType: 'token' -}); -``` - -If you need further detail about usage, check out the [Auth0.js v7 Reference](/libraries/auth0js/v7). - -<%= include('../_includes/_lock-toc') %> diff --git a/articles/libraries/lock/v10/customization.md b/articles/libraries/lock/v10/customization.md deleted file mode 100644 index dd6ba376cf..0000000000 --- a/articles/libraries/lock/v10/customization.md +++ /dev/null @@ -1,826 +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! ---- - -<%= include('../_includes/_lock-version') %> - -# Lock: Configurable 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); -``` - -## Index of Configurable Options - -### Display Options - -| Option | Description | -| --- | --- | -| [allowedConnections](#allowedconnections-array-) | limit the client connections shown in Lock to a particular set | -| [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 Options - -| 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 Options - -| Option | Description | -| --- | --- | -| [socialButtonStyle](#socialbuttonstyle-string-) | Force small or large social connection buttons | - -### Authentication Setup - -| Option | Description | -| --- | --- | -| [auth](#auth-object-) | The auth object contains the below auth options | -| [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 attempt to fetch SSO data and set cookie | - -### Database Options - -| 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 Options - -| Option | Description | -| --- | --- | -| [defaultEnterpriseConnection](#defaultenterpriseconnection-string-) | Specifies a connection if more than one present | - -### Other Options - -| Option | Description | -| --- | --- | -| [clientBaseUrl](#clientbaseurl-string-) | Override your client's base URL | -| [languageBaseUrl](#languagebaseurl-string-) | Override your language file base URL | - ---- - -## Display Options - -### 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) - -### autoclose {Boolean} - -Determines whether or not the Lock will be closed automatically after a successful sign in. Defaults to false. - -::: panel-info Side effects -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. - -::: panel-info Side effects -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 an 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 client 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 - } -}; -``` - -#### 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' - }, - } -}; -``` - -::: panel-info Supported parameters -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. - -::: panel-warning Popup mode -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. See more info [here](https://ask.auth0.com/t/popup-login-window-is-not-closed-after-authentication/2843). -::: - -```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' - } -}; -``` - -::: panel-info Side effects -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} - - When Lock is initialized it will make a request to obtain SSO data. If the `sso` option is set to `true`, the data is fetched and a cookie is set after a successful login. - -::: panel-warning Multifactor authentication -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-info 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 - -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 - -```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); - } - }] -} -``` - -::: panel-info Using additionalSignupFields for email -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. - -::: panel-info Side effects -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-info 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 an 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 - -### clientBaseUrl {String} - -This option can provide a URL to override the client 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 client 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" -}; -``` - -<%= include('../_includes/_lock-toc') %> - - - -[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 c996babd69..0000000000 --- a/articles/libraries/lock/v10/customizing-error-messages.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -section: libraries -description: Customizing error messages with Lock 10 ---- - -<%= include('../_includes/_lock-version') %> - -# Lock: Customizing Error Messages - -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. - -<%= include('../_includes/_lock-toc') %> \ No newline at end of file diff --git a/articles/libraries/lock/v10/i18n.md b/articles/libraries/lock/v10/i18n.md deleted file mode 100644 index 5816ce5128..0000000000 --- a/articles/libraries/lock/v10/i18n.md +++ /dev/null @@ -1,64 +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. ---- - -<%= include('../_includes/_lock-version') %> - -# 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. - -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. - -> **Note:** 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 clients. - -::: panel-info Further Information -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. -::: - -<%= include('../_includes/_lock-toc') %> \ No newline at end of file diff --git a/articles/libraries/lock/v10/migration-guide.md b/articles/libraries/lock/v10/migration-guide.md deleted file mode 100644 index 6dce0da1c0..0000000000 --- a/articles/libraries/lock/v10/migration-guide.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -section: libraries -toc: true -description: Lock 9 to Lock 10 Migration Guide ---- - -<%= include('../_includes/_lock-version') %> - -# 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 customization 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/customization#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. - -### Customizing Options -- The `show` method no longer takes any arguments. You pass the options to the constructor and you listen for an `authenticated` event instead of providing a callback. You can listen for this event with the [on](/libraries/lock/v10/api#on-event-callback-) method. - -### 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). -- 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 passed to the `show` method's callback. -- See information on all of the new events in Lock 10 on the [Lock 10 API page](/libraries/lock/v10/api). - -### 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/customization#initialscreen-string-), [allowLogin](/libraries/lock/v10/customization#allowlogin-boolean-), [allowSignUp](/libraries/lock/v10/customization#allowsignup-boolean-) and [allowForgotPassword](/libraries/lock/v10/customization#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 Customization Options -Some existing options suffered changes, in addition to the beforementioned removals and additions. Please see below for brief descriptions, or consult the [customization reference](/libraries/lock/v10/customization) for more information. - -### Display Options - - The `connections` option was renamed to [allowedConnections](/libraries/lock/v10/customization#allowedconnections-array-). - - The `focusInput` option was renamed to [autofocus](/libraries/lock/v10/customization#autofocus-boolean-). - - The `gravatar` option was renamed to [avatar](/libraries/lock/v10/customization#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/customization#language-string-) and [languageDictionary](/libraries/lock/v10/customization#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/customization#logo-string-) and namespaced under `theme`. Now you use it like this `theme: {logo: "https://example.com/icon.png"}`. - - The [primaryColor](/libraries/lock/v10/customization#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/customization#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/customization#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/customization#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/customization#redirecturl-string-) and namespaced under `auth`. Now you use it like this `auth: {redirectUrl: "https://example.com/callback"}`. - - The [responseType](/libraries/lock/v10/customization#responsetype-string-) option was namespaced under `auth`. Now you use it like this `auth: {responseType: "code"}`. - - The [sso](/libraries/lock/v10/customization#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/customization#allowforgotpassword-boolean-). - - The `disableSignUpAction` option was renamed to [allowSignUp](/libraries/lock/v10/customization#allowsignup-boolean-). - - The `defaultUserPasswordConnection` option has been replaced by the [defaultDatabaseConnection](/libraries/lock/v10/customization#defaultdatabaseconnection-string-) and the [defaultEnterpriseConnection](/libraries/lock/v10/customization#defaultenterpriseconnection-string-) options. - - The `resetLink` option was renamed to [forgotPasswordLink](/libraries/lock/v10/customization#forgotpasswordlink-string-). - -### 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 [customization page](/libraries/lock/v10/customization) for more details on all of the customization options that are available. - - Take a look at the [api page](/libraries/lock/v10/api) for more details on Lock 10's API. - -## Upgrading From Preview Releases - -**This section is only pertinent if you are currently using a pre-release version of Lock 10, and wish to update to the release version.** It is a summary of what you absolutely need to know before upgrading between preview releases. For the full list of changes, please see the project's [CHANGELOG](https://github.com/auth0/lock/blob/master/CHANGELOG.md). - -### Upgrading from v10.0.0-beta.1 to v10.0.0-beta.2 - -- Renamed `close` method to `hide`. -- Renamed `connections` option to `allowedConnections`. -- Renamed `signUp.footerText` dict key to `signUp.terms`. -- Requiring the npm package has been fixed, you need to `require('auth0-lock')` instead of `require('auth0-lock/lib/classic')`. - -### Upgrading from v10.0.0-beta.2 to v10.0.0-beta.3 - -- The profile is no longer fetched automatically after a successful login. To obtain it you need to call `lock.getProfile` (see the examples above for the details). - -### Upgrading from v10.0.0-beta.3 to v10.0.0-beta.4 - -- The `jsonp` option was removed. - -### Upgrading from v10.0.0-beta.4 to v10.0.0-beta.5 - -- The constructor no longer takes a callback. See the examples above to learn how to use events instead. -- The `language` option has been added, and the structure of the `languageDictionary` option has been updated. - -### Upgrading from v10.0.0-beta.5 to v10.0.0-rc.1 - -- No API changes were made in this release. - -<%= include('../_includes/_lock-toc') %> diff --git a/articles/libraries/lock/v10/new-features.md b/articles/libraries/lock/v10/new-features.md deleted file mode 100644 index 60e487f9f4..0000000000 --- a/articles/libraries/lock/v10/new-features.md +++ /dev/null @@ -1,216 +0,0 @@ ---- -section: libraries -description: Describes the new features with Lock V10. ---- - -<%= include('../_includes/_lock-version') %> - -# New Features in Lock 10 - -## 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 Agreement - -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 - } -); -``` - -<%= include('../_includes/_lock-toc') %> diff --git a/articles/libraries/lock/v10/popup-mode.md b/articles/libraries/lock/v10/popup-mode.md deleted file mode 100644 index 0a9c9e324b..0000000000 --- a/articles/libraries/lock/v10/popup-mode.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -section: libraries -description: Details about Popup Mode with Lock V10. ---- - -<%= include('../_includes/_lock-version') %> - -# Popup Mode - -## The Default: Redirect Mode - -If after you click on the IdP button (Facebook for example), the web app you built gets redirected to Facebook, it means you're using Redirect Mode. Redirect Mode is the default with Lock 10, and is the recommended mode for almost all use cases. Once you successfully login to Facebook, Facebook will redirect you back to your app (through Auth0). - -## Using 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**. - -::: panel-warning Popup Mode -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. See more info [here](https://ask.auth0.com/t/popup-login-window-is-not-closed-after-authentication/2843). -::: - -![Widget Popup](/media/articles/libraries/lock/v10/widget-popup.gif) - -Implementing Lock with Popup Mode is again a simple change of an option from its default. - -```js -var lock = new Auth0Lock( - '${account.clientId}', - '${account.namespace}', - { - auth: { - redirect: false - } - } -); - -lock.on("authenticated", function(authResult) { - lock.getProfile(authResult.idToken, function(error, profile) { - if (error) { - // Handle error - return; - } - - localStorage.setItem('token', authResult.idToken); - localStorage.setItem('profile', JSON.stringify(profile)); - }); -}); -``` - -## 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](/api/authentication/reference#resource-owner) 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 - } -} -``` - -**Redirect mode is recommended whenever possible to avoid potential browser compatibility issues.** - -<%= include('../_includes/_lock-toc') %> 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 5f3eeeacc5..0000000000 --- a/articles/libraries/lock/v10/selecting-the-connection-for-multiple-logins.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -section: libraries -description: How to select different connection types for multiple login options with Lock V10. ---- - -# Selecting the connection in Auth0 for multiple login options - -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) - -> 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: - - auth0.show({connections: ['YOUR_CONNECTION']}); - - -Notice that this is equivalent of just navigating to: - - 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) - -> 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 (e.g. through a primary verification, out of band channel for example). - -## Option 2: using email domains with Lock - -The [Lock](/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. 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 c5378fe2f2..0000000000 --- a/articles/libraries/lock/v10/sending-authentication-parameters.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -section: libraries -description: Lock V10 documentation on setting authentication parameters. ---- - -<%= include('../_includes/_lock-version') %> - -# 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: `access_token`, `scope`, `protocol`, `device`, `request_id`, `nonce` and `state`. - -::: panel-info 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'`: (not recommended): will return all the user attributes in the token. This can cause problems when sending or receiving tokens in URLs (e.g. 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'`). 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' - } - } -}); -``` - -::: panel-info Connection Scopes -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 [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. - -[Click here to learn more about how to send/receive the state parameter.](/protocols/oauth-state) - -<%= include('../_includes/_lock-toc') %> diff --git a/articles/libraries/lock/v10/ui-customization.md b/articles/libraries/lock/v10/ui-customization.md deleted file mode 100644 index 2ed98ebcbd..0000000000 --- a/articles/libraries/lock/v10/ui-customization.md +++ /dev/null @@ -1,81 +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. ---- - -<%= include('../_includes/_lock-version') %> - -# Customizing the Look and Feel of Lock 10 - -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} -The value for `logo` is an 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/assets/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/assets/logo.png', - primaryColor: 'green' - } -}; -``` - -### Customizing Text -The `languageDictionary` option allows customization of every piece of text displayed in the Lock. Defaults to {}. See below Language Dictionary Specification for the details. - -```js -var options = { - languageDictionary: { - emailInputPlaceholder: "something@youremail.com", - title: "Log me in" - }, -}; -``` -### 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 my 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. - -<%= include('../_includes/_lock-toc') %> - - diff --git a/articles/libraries/lock/v11/api.md b/articles/libraries/lock/v11/api.md new file mode 100644 index 0000000000..58949c9ed4 --- /dev/null +++ b/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/articles/libraries/lock/v11/authentication-modes.md b/articles/libraries/lock/v11/authentication-modes.md new file mode 100644 index 0000000000..b11a8d6310 --- /dev/null +++ b/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/articles/libraries/lock/v11/configuration.md b/articles/libraries/lock/v11/configuration.md new file mode 100644 index 0000000000..d5c1e9492c --- /dev/null +++ b/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/articles/libraries/lock/v11/customizing-error-messages.md b/articles/libraries/lock/v11/customizing-error-messages.md new file mode 100644 index 0000000000..1d06250ce5 --- /dev/null +++ b/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/articles/libraries/lock/v11/i18n.md b/articles/libraries/lock/v11/i18n.md new file mode 100644 index 0000000000..cdd35c7c3e --- /dev/null +++ b/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/articles/libraries/lock/v11/index.md b/articles/libraries/lock/v11/index.md new file mode 100644 index 0000000000..babcef08a8 --- /dev/null +++ b/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/articles/libraries/lock/v11/migration-angular.md b/articles/libraries/lock/v11/migration-angular.md new file mode 100644 index 0000000000..1eb1e5647d --- /dev/null +++ b/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/articles/libraries/lock/v11/migration-angularjs-v10.md b/articles/libraries/lock/v11/migration-angularjs-v10.md new file mode 100644 index 0000000000..621be6bea3 --- /dev/null +++ b/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/articles/libraries/lock/v11/migration-angularjs-v8.md b/articles/libraries/lock/v11/migration-angularjs-v8.md new file mode 100644 index 0000000000..8152ec0ef0 --- /dev/null +++ b/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/articles/libraries/lock/v11/migration-angularjs-v9.md b/articles/libraries/lock/v11/migration-angularjs-v9.md new file mode 100644 index 0000000000..6217541cf6 --- /dev/null +++ b/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/articles/libraries/lock/v11/migration-cordova.md b/articles/libraries/lock/v11/migration-cordova.md new file mode 100644 index 0000000000..ce7a0e9ef2 --- /dev/null +++ b/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/articles/libraries/lock/v11/migration-guide.md b/articles/libraries/lock/v11/migration-guide.md new file mode 100644 index 0000000000..a815c11a66 --- /dev/null +++ b/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/articles/libraries/lock/v11/migration-lock-passwordless.md b/articles/libraries/lock/v11/migration-lock-passwordless.md new file mode 100644 index 0000000000..3108edcae5 --- /dev/null +++ b/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/articles/libraries/lock/v11/migration-react.md b/articles/libraries/lock/v11/migration-react.md new file mode 100644 index 0000000000..fbac6ae04c --- /dev/null +++ b/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/articles/libraries/lock/v11/migration-v10-v11.md b/articles/libraries/lock/v11/migration-v10-v11.md new file mode 100644 index 0000000000..16e9b75071 --- /dev/null +++ b/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/articles/libraries/lock/v11/migration-v8-v11.md b/articles/libraries/lock/v11/migration-v8-v11.md new file mode 100644 index 0000000000..2f2e3e53c6 --- /dev/null +++ b/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/articles/libraries/lock/v11/migration-v9-v11.md b/articles/libraries/lock/v11/migration-v9-v11.md new file mode 100644 index 0000000000..cb56f72034 --- /dev/null +++ b/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/articles/libraries/lock/v11/selecting-the-connection-for-multiple-logins.md b/articles/libraries/lock/v11/selecting-the-connection-for-multiple-logins.md new file mode 100644 index 0000000000..928c694dac --- /dev/null +++ b/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/articles/libraries/lock/v11/sending-authentication-parameters.md b/articles/libraries/lock/v11/sending-authentication-parameters.md new file mode 100644 index 0000000000..fa5e7055ff --- /dev/null +++ b/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/articles/libraries/lock/v11/ui-customization.md b/articles/libraries/lock/v11/ui-customization.md new file mode 100644 index 0000000000..6bbb747ae9 --- /dev/null +++ b/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/articles/libraries/lock/v9/authentication-modes.md b/articles/libraries/lock/v9/authentication-modes.md deleted file mode 100644 index ce1ca1a117..0000000000 --- a/articles/libraries/lock/v9/authentication-modes.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -section: libraries -description: Lock V9 doc on the different types of authentication modes. ---- - -<%= include('../_includes/_lock-version-9') %> - -# Lock: Authentication Modes - -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 openned, 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. - -![Widget redirect](/media/articles/libraries/lock/v9/WidgetRedirect.gif) - -You can [click here](/libraries/lock/v9/types-of-applications#redirect-mode) to learn how to implement Redirect mode with Single Page Apps, or you can [click here](/libraries/lock/v9/types-of-applications#redirect-mode-1) to learn how to implement it with Regular WebApps. - -## 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 either only using redirect mode or detecting these special cases and selectively enabling redirect mode. See more info [here](https://ask.auth0.com/t/popup-login-window-is-not-closed-after-authentication/2843). - -![Widget Popup](/media/articles/libraries/lock/v10/widget-popup.gif) - -You can [click here](/libraries/lock/v9/types-of-applications#popup-mode) to learn how to implement Popup mode with Single Page Apps. - -### Database connections and popup mode - -Some Auth0 features such as [MFA](/multifactor-authentication) and [SSO](/sso) between multiple applications depend on users being redirected to Auth0 to set a cookie on `https://YOUR_DOMAIN.auth0.com`. -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](/api/authentication/reference#resource-owner) 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) { ... }); -``` - -Redirect mode is recommended whenever possible to avoid potential browser compatibility issues. diff --git a/articles/libraries/lock/v9/customization.md b/articles/libraries/lock/v9/customization.md deleted file mode 100644 index daa7833cf3..0000000000 --- a/articles/libraries/lock/v9/customization.md +++ /dev/null @@ -1,483 +0,0 @@ ---- -section: libraries -description: How to configure user options with Lock V9 ---- - -<%= include('../_includes/_lock-version-9') %> - -## Lock: User configurable options -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 `id` of the html element where the widget will be shown. This makes the widget appear inline instead of in 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`. - -``` -// 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. -> 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 multifactor 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 2cb6e5859b..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 ---- - -<%= include('../_includes/_lock-version-9') %> - -# Lock: Customizing Error Messages - -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/display-modes.md b/articles/libraries/lock/v9/display-modes.md deleted file mode 100644 index bc1e4315db..0000000000 --- a/articles/libraries/lock/v9/display-modes.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -section: libraries -description: Lock V9 document on the display modes, overlay and embedded mode ---- - -<%= include('../_includes/_lock-version-9') %> - -# Lock: Display Modes - -You can display Lock embedded or as a modal dialog with an overlay - -## Overlay Mode - -Shows the widget on top of your web page. This is the default mode. - -![](/media/articles/libraries/lock/v9/mode-1.png) - -Here is the code you would add to your web application. - -```html - -``` - -## Embedded Mode - -The embedded mode will render the widget inside a `
        ` that you specify. - -![](/media/articles/libraries/lock/v9/mode-2.png) - -```html -
        - -Here is the code you would add to your web application. - - -``` - -Notice that when you use the embedded mode the widget can't be "closed" unless you change the `closable` [property](/libraries/lock/v9/customization#closable-boolean). diff --git a/articles/libraries/lock/v9/events.md b/articles/libraries/lock/v9/events.md deleted file mode 100644 index 34f12f444d..0000000000 --- a/articles/libraries/lock/v9/events.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -section: libraries -description: Lock V9 API syntax ---- - -<%= include('../_includes/_lock-version-9') %> - -## Lock: API syntax - -```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. - - diff --git a/articles/libraries/lock/v9/i18n.md b/articles/libraries/lock/v9/i18n.md deleted file mode 100644 index a2f422970b..0000000000 --- a/articles/libraries/lock/v9/i18n.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -section: libraries -description: Lock V9 internationalization ---- - -<%= include('../_includes/_lock-version-9') %> - -# Lock: Internationalization - -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) - -> 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 fb72cd2d3e..0000000000 --- a/articles/libraries/lock/v9/index.md +++ /dev/null @@ -1,318 +0,0 @@ ---- -section: libraries -description: Lock V9 documentation -url: /libraries/lock/v9 ---- - -<%= include('../_includes/_lock-version-9') %> - -![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 (i.e.: 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) - -> 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" - } -} -``` - - -## 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. - - -## API - -### 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) {}); - -``` - -> 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) {}); -``` -> 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) {}); -``` -> 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) {}); -``` -> 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 }); -``` - -## 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-customization] -* [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-customization]: /libraries/lock/v9/customization -[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/initialization.md b/articles/libraries/lock/v9/initialization.md deleted file mode 100644 index 0e52fa748a..0000000000 --- a/articles/libraries/lock/v9/initialization.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -section: libraries -description: Lock V9 guide to initialization. ---- - -<%= include('../_includes/_lock-version-9') %> - -# Lock: Initialization - -```javascript -// Initialize with clientID and domain -var lock = new Auth0Lock(clientID, domain); - -// Initialize with options -var lock = new Auth0Lock(clientID, domain, options); -``` - -- **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. diff --git a/articles/libraries/lock/v9/migration-guide.md b/articles/libraries/lock/v9/migration-guide.md deleted file mode 100644 index ebbebf681a..0000000000 --- a/articles/libraries/lock/v9/migration-guide.md +++ /dev/null @@ -1,134 +0,0 @@ ---- -section: libraries -description: Guide to migrate from Auth0 Widget to Auth0 Lock. ---- - -<%= include('../_includes/_lock-version-9') %> - -# Lock: Migration Guide - -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'); -``` -> 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' - ] -}); -``` -> 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. - -> 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 `_` for ` ` (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 ccd9891c08..0000000000 --- a/articles/libraries/lock/v9/selecting-the-connection-for-multiple-logins.md +++ /dev/null @@ -1,128 +0,0 @@ ---- -section: libraries -description: Describes different options for selecting the connection in Auth0 when there are multiple login options for Lock v9. ---- - -<%= include('../_includes/_lock-version-9') %> - -# Selecting the connection in Auth0 for multiple login options - -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) - -> 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: - - auth0.show({connections: ['YOUR_CONNECTION']}); - - -Notice that this is equivalent of just navigating to: - - 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) - -> 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 (e.g. through a primary verification, out of band channel for example). - -## Option 2: using email domains with Lock - -The [Lock](/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](/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: - -``` -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: - -``` -.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 16d7a609dc..0000000000 --- a/articles/libraries/lock/v9/sending-authentication-parameters.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -section: libraries -description: Supported parameters that can be used with Lock V9. ---- - -<%= include('../_includes/_lock-version-9') %> - -# 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 -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 (e.g. 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 - } - } -} -``` - -> 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 [XSRF 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) - -#### Getting the `state` value in a rule - -If you need to access the `state` parameter 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, so you should do: - -```js -var state = context.request.query.state || context.request.body.state;. -``` diff --git a/articles/libraries/lock/v9/types-of-applications.md b/articles/libraries/lock/v9/types-of-applications.md deleted file mode 100644 index 81b6206fa3..0000000000 --- a/articles/libraries/lock/v9/types-of-applications.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -section: libraries -description: Explains the types of applications that can be used with Lock. ---- - -<%= include('../_includes/_lock-version-9') %> - -# Lock: Types of applications - -You can use Auth0 Lock with both Single Page Apps and with Regular WebApps. In this section we'll learn how to use it with each of them. - -## Single Page App - -When you're using a Single Page App, you need that after a successful login through Auth0, you get the `id_token` ([JWT](/jwt)) with which you can then call your API. When you want to use [this workflow](/sequence-diagrams), the `responseType` is then a `token`. - -Lock can work in [2 Authentication modes: Redirect and Popup](/libraries/lock/v9/authentication-modes). - -### Popup Mode - -````js -var lock = new Auth0Lock('dsa7d77dsa7d7', 'mine.auth0.com'); - -lock.show(function(err, profile, id_token) { - if (err) { - console.log("There was an error :/", err); - return; - } - - console.log("Hey dude", profile); -}) -```` -### Redirect mode - -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 current URL. - -Optionally, [you can set the callbackURL to whatever you need](/libraries/lock/v9/customization#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('dsa7d77dsa7d7', 'mine.auth0.com'); - -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(); -```` - -To learn more about `parseHash` please [read this](https://github.com/auth0/auth0.js#redirect-mode). - -## Regular Webapp - -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](/libraries/lock/v9/authentication-modes#redirect-mode) makes sense. - -### Redirect mode - -```js -var lock = new Auth0Lock('dsa7d77dsa7d7', 'mine.auth0.com'); - -lock.show({ - callbackURL: 'http://myUrl.com/auth/callback' -}); -``` diff --git a/articles/libraries/lock/v9/ui-customization.md b/articles/libraries/lock/v9/ui-customization.md deleted file mode 100644 index 9177688374..0000000000 --- a/articles/libraries/lock/v9/ui-customization.md +++ /dev/null @@ -1,109 +0,0 @@ ---- -section: libraries -description: Customizing how Lock with CSS and Javascript ---- - -<%= include('../_includes/_lock-version-9') %> - -# Lock: Customize the look and feel - -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**: https://github.com/auth0/lock-theme-reflex -- **demo**: https://cdn.auth0.com/widget-theme-reflex/index.html - -### Gradient theme - -![](/media/articles/libraries/lock/ui-customization/gradient-theme.png) - -- **repo**: https://github.com/auth0/lock-theme-gradient -- **demo**: https://cdn.auth0.com/widget-theme-gradient/index.html - -## Send us an screenshot! - -We would love to see what you can do. 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 7f83d05793..0000000000 --- a/articles/libraries/lock/v9/using-a-refresh-token.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -section: libraries -description: Getting and using a refresh token with Lock. ---- - -<%= include('../_includes/_lock-version-9') %> - -# Lock: Refresh tokens - -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/login-widget.md b/articles/libraries/login-widget.md deleted file mode 100644 index dd5f454340..0000000000 --- a/articles/libraries/login-widget.md +++ /dev/null @@ -1,196 +0,0 @@ ---- -description: Info page on the Auth0 Login widget which has been deprecated. ---- - -::: warning-banner -__WARNING:__ This version of the login widget has been deprecated.
        Please use the [new version](/lock) instead. -::: - -# Auth0 Login Widget - -The __Auth0 Login Widget__ 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 (i.e.: asking the enterprise user the email, and redirecting to the right enterprise identity provider). -* Implementing a standard sign in protocol (OpenID Connect / OAuth2 Login) - -## Anatomy of the Auth0 Login Widget - -![](/media/articles/login-widget/widget-numbered.png) - -1. The __title__ of the widget. You can optionally show a 24x24 icon. -2. The __social buttons__ will be shown if you have at least one social connection enabled. -3. The __Email__ field will be shown if you have at least one enterprise connection enabled. The __Password__ field will be shown if you have a Database connection. -4. The __Sign Up__ and __Forgot Password__ links will be shown if you have a Database connection. - -> **How does enterprise SSO work?** Consider a user that enters john@**fabrikam.com**. If there's an enterprise connection with an associated domain "**fabrikam.com**", then the password field will be hidden. When the user clicks on __Sign In__, he/she will be redirected to the corresponding identity provider (Google Apps, AD, Windows Azure AD, etc.) where that domain is registered. If the user is already logged in with the Identity Provider, then Single Sign On will happen. - -## Including the Login Widget on your page - - - -Add the script tag to your page to get started with __Auth0 Login Widget__. This script will add an `Auth0` component to the `window` object. - -## Invoking the Widget - -To invoke the widget, use the `signIn` method - - window.Auth0.signIn({onestep: true}); - -## Customizing the Widget - -The Widget can be customized through the parameters sent to the `signIn` method. - -This example shows how to display the labels in Spanish: - - window.Auth0.signIn({ - onestep: true, - title: "Contoso", - signInButtonText: "Ingresar", - emailPlaceholder: "Correo", - passwordPlaceholder: "Contraseña", - separatorText: "o", - showIcon: true, - icon: "https://myapp.com/logo.png", - showSignup: true, - signupText: "Registrarme!", - signupLink: "https://myapp.com/signup", - showForgot: true, - forgotText: "Olvidé mi contraseña", - forgotLink: "https://myapp.com/forgot" - }); - - -Resulting in: - -![](/media/articles/login-widget/widget-customized.png) - -## Customizing the Login Widget for Database Connections - -When using a database connections, the **Login Widget** has support for account creation (sign-up) and password changes: - -### Customizing **sign-up** messages - - window.Auth0.signIn({ - onestep: true, - separatorText: "o", - showIcon: true, - icon: "https://myapp.com/logo.png", - // ... other properties ... - signupTitle: "Registrarse", - signupHeaderText: "Por favor, ingrese su correo y contraseña", - signupFooterText: "Al hacer clic en \"Crear Usuario\", usted está aceptando nuestros términos y condiciones.", - signupButtonText: "Crear Usuario", - signupEmailPlaceholder: "Correo", - signupPasswordPlaceholder: "Contraseña", - signupCancelButtonText: "Cancelar" - }); - -Will display the following: - -![](/media/articles/login-widget/widget-customized-signup.png) - -### Customizing **change-password** messages - - window.Auth0.signIn({ - onestep: true, - separatorText: "o", - showIcon: true, - icon: "https://myapp.com/logo.png", - // ... other properties ... - resetTitle: "Cambiar Contraseña", - resetHeaderText: "Por favor, ingrese su correo y una nueva contraseña. Se le enviará un correo para confirmar el cambio de la misma.", - resetButtonText: "Enviar", - resetEmailPlaceholder: "Correo", - resetPasswordPlaceholder: "Nueva Contraseña", - resetRepeatPasswordPlaceholder: "Confirmar Nueva Contraseña", - resetCancelButtonText: "Cancelar", - resetSuccessText: "Se ha enviado un correo electrónico para confirmar el cambio de contraseña.", - resetEnterSamePasswordText: "Por favor, ingrese la misma contraseña" - }); - -Will display the following: - -![](/media/articles/login-widget/widget-customized-reset.png) - -## Customizing error messages - -You can also customize the error messages that will be displayed on certain situations: - - window.Auth0.signIn({ - onestep: true, - title: "Contoso", - // ... other properties ... - // wrongEmailPasswordErrorText, serverErrorText, signupEnterpriseEmailWarningText, signupServerErrorText and resetServerErrorText are used only if you have a Database connection - wrongEmailPasswordErrorText: 'Custom error message for invalid user/pass.', - serverErrorText: 'There was an error processing the sign in.', - signupEnterpriseEmailWarningText: 'This domain {domain} has been configured for Single Sign On and you can\'t create an account. Try signing in instead.', - signupServerErrorText: 'There was an unhandled error processing the sign up.', - resetServerErrorText: 'There was an unhandled error processing the change password.', - // strategyDomainInvalid is shown if the email does not have a matching enterprise connection - strategyDomainInvalid: 'The domain {domain} has not been setup.', - // strategyEmailInvalid is shown if the email is not valid - strategyEmailInvalid: 'The email is invalid.' - }); - -These errors will be shown on the widget header: - -![](/media/articles/login-widget/widget-error.png) - -## Sending extra query string parameters - -You can send extra parameters when starting a login by adding query strings in the `script` tag. The example below adds a `state` parameter with a value equal to `foo`. - - - -Common parameters are: - -* `response_type`: this could be `code` or `token`. Usually `code` is used in web apps (server-side) and `token` on mobile, native or single page apps. See [server side protocol](/oauth-web-protocol) and [mobile, single page apps and native apps](/oauth-implicit-protocol) sections for more information about one or the other. -* `state`: arbitrary state value that will be mantained across redirects (useful for XSRF) -* `scope`: there are various possible values for scope: - * `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. - * `scope=openid {attr1} {attr2}`: if you want specific user profile properties returned.(For example: `__scope: "openid name email picture"`). You can get more information about this in the [Scopes documentation](/scopes). -* `redirect_uri`: by setting this value you can choose what callback url to use if you have multiple registered. Useful when you have multiple environments (e.g. Dev & Test), and a single application in Auth0. -* `authorize_url`: if specified, it will start the login transaction at that url. This is useful if you want to do something on the server, before redirecting to Auth0. For instance, this is used when integrating with ASP.NET MVC4 which uses DotNetOpenAuth and generates a proprietary "state" parameter that can only be generated on the server side. -* `protocol`: this could be `oauth2` (default), `samlp` or `wsfed`. -* `any other thing`: will be passed through. - -## Using the API instead of the widget - -If you don't want to use the widget, you can still make use of the API with a simple JavaScript call and render anything you want. - -Here is an example: - - var client = window.Auth0.getClient(); - for (var i in client.strategies) { - for (var j in client.strategies[i].connections) { - var connection = client.strategies[i].connections[j]; - - var link = $('') - .text(connection.name) - .attr('href', connection.url); - - $('ul.login-list').append($('
      • ').append(link)); - } - } - -## FAQs - -* Can I customize the colors and structure of the widget? - - Yes. You can customize it by passing a `css` parameter to the script pointing to a URL with your CSS (hosted on HTTPS). Or you can use the JavaScript API and use your own UI. - Here are a couple of fiddles to play around: css customization and JavaScript API - -* Can I remove the "Powered by Auth0"? - - It can be removed if you are subscribed to one of the paid plans. - -* Is it possible to embed the widget in an HTML element instead of using a modal dialog? - - Yes. You can embed it on a `div` by adding a query string to the script URL specifying the div `id`. e.g.: <script id="auth0" src="https://sdk.auth0.com/auth0.js#client=...&**container=root**"></script> - -* What happens if the user enters an email corresponding to a domain that has not been provisioned before? - - That behavior will depend on another parameter called `provisioningOnUnknownDomain`. If this flag is true, we will show the [provisioning widget](#) pre-populated with that domain. If that flag is false, an error message will be displayed (The domain has not been setup yet). diff --git a/articles/libraries/login-widget2.md b/articles/libraries/login-widget2.md deleted file mode 100644 index 23e00c8e5f..0000000000 --- a/articles/libraries/login-widget2.md +++ /dev/null @@ -1,196 +0,0 @@ ---- -description: Info page on the Auth0 Login widget which has been deprecated. ---- - -::: warning-banner -__WARNING:__ This version of the login widget has been deprecated.
        Please use the [new version](/lock) instead. -::: - -# Auth0 Login Widget - -The __Auth0 Login Widget__ makes it easy to integrate SSO in your app. You won't have to worry about: - -* Having a professionally 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 (i.e.: asking the enterprise user the email, and redirecting to the right enterprise identity provider). -* Implementing a standard sign in protocol (OpenID Connect / OAuth2 Login) - -## Including the Login Widget on your page -Add the script tag to your page to get started with __Auth0 Login Widget__. - - - -## Single Page Applications - -You can handle the authorization process client-side as follows: - - - -> When `callbackOnLocationHash: true` is specified, Auth0 will send the response back as a redirect to your site passing the tokens after the hash sign: `${account.callback}#access_token=...&id_token=...`. - -## Customizing the Widget - -The Widget can be customized through the `options` parameter sent to the `signin` method. - -### Options - -* __connections__: Array of enabled connections that will be used for the widget. Default: all enabled connections. -* __container__: The id of the DIV where the widget will be contained. -* __icon__: Icon url. Recommended: 32x32. -* __showIcon__: Show/Hide widget icon. Default: false. -* __showForgot__: Show/Hide the "Forgot your password?" link. Default: true. -* __showSignup__: Show/Hide the "Sign Up" link. Default: true. -* __enableReturnUserExperience__: Show the account used last time the user signed in. Default: `true`. -* __userPwdConnectionName__: Specify which Database/AD-LDAP connection should be used with the Email/Password fields. Default: the first Database connection found (if it exists) or the first AD-LDAP connection found. -* __username_style__: Specify the format of the username. Options: `email` or `username`. - -> Is there an option that you think would be useful? Just open an issue on GitHub and we'll look into adding it. - -This example shows how to work with only specified connections and display the labels in Spanish: - - var widget = new Auth0Widget({ - domain: '${account.namespace}', - clientID: '${account.clientId}', - callbackURL: '${account.callback}', - dict: 'es' - }); - - widget.signin({ - connections: ['facebook', 'google-oauth2', 'twitter', 'Username-Password-Authentication'], - icon: 'https://contoso.com/logo-32.png', - showIcon: true - }, - function () { - // The Auth0 Widget is now loaded. - }); - -> `dict` constructor parameter is a string matching the language (`'en'`, `'es'`, `'it'`, etc.) or object containing all your customized text labels. - -Resulting in: - -![](/media/articles/login-widget2/W9rpHdyIwf.png) - -## Sending extra login parameters - -You can send extra 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`. - - widget.signin({ - // ... other options ... - state: 'foo' - }); - -The following parameters are supported: `access_token`, `protocol`, `request_id`, `scope`, `state` and `connection_scopes`. - -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: - - widget.signin({ - // ... other options ... - extraParameters: { - access_type: 'offline' - } - }); - -> Note: this would be analogous to trigger the login with `https://${account.namespace}/authorize?state=foo&access_type=offline&...`. - -### Scope - -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 {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'`). - -You can get more information about this in the [Scopes documentation](/scopes). - -### Connection Scopes - -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: - - widget.signin({ - 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 - } - } - -> The values for each scope are not transformed in any way. They must match exactly the values recognized by each identity provider. - -## Signup and Reset - -It is also possible to start the widget in the **Sign Up** mode or **Reset Password** mode as follows: - - widget.signup(/* [same as the .signin method] */); - // or - widget.reset(/* [same as the .signin method] */); - -## Anatomy of the Auth0 Login Widget - -![](/media/articles/login-widget2/y2iG3mE8Ll.png) - -1. The __title__ of the widget. You can optionally show a 32x32 icon. -2. The __social buttons__ will be shown if you have at least one social connection enabled. -3. The __Email__ field will be shown if you have at least one enterprise connection enabled. The __Password__ field will be shown if you have a Database connection. -4. The __Sign Up__ and __Forgot Password__ links will be shown if you have a Database connection. - -> **How does enterprise SSO work?** Consider a user that enters john@**fabrikam.com**. If there's an enterprise connection whose primary or additional domains match "**fabrikam.com**", then the password field will be hidden. When the user clicks on __Sign In__, he/she will be redirected to the corresponding identity provider (Google Apps, AD, Windows Azure AD, etc.) where that domain is registered. If the user is already logged in with the Identity Provider, then Single Sign On will happen. - -## Customize the look and feel - -You can apply your own style to the elements. All classes and ids are prefixed with `a0-` to avoid conflicts with your own stylesheets. - -## Customizing error messages - -You can also customize the error messages that will be displayed on certain situations: - - var widget = new Auth0Widget({ - // ... other parameters ... - 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 - } - }); - -These errors will be shown on the widget header: - -![](/media/articles/login-widget2/9AfFb-pbwm.png) diff --git a/articles/libraries/overview.md b/articles/libraries/overview.md deleted file mode 100644 index 13d8e55cce..0000000000 --- a/articles/libraries/overview.md +++ /dev/null @@ -1,43 +0,0 @@ ---- -section: libraries -classes: topic-page -title: Auth0 Libraries -description: Auth0 Libraries - helping you implement Auth0 with simple efficiency -url: /libraries ---- - -
        -
        -

        Auth0 Libraries

        -

        - There are several libraries and widgets 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! -

        -
        - -## How Should You Implement Auth0? - -- [Lock](#lock-login-signup-widgets) is a drop-in authentication widget that provides a standard set of behaviors and a customizable user interface. -- [Auth0 Libraries](#auth0-client-side-libraries) are client-side libraries that *do not* come with a user interface - you use your own. These allow for expanded customization of the behavior and appearance of the login process. -- The [Authentication API](/api-auth) provides integration without requiring the use of Auth0 libraries. - -The best option to choose will depend on the needs of your app. Check out the [When to Use Lock](/libraries/when-to-use-lock) page for more information to help you decide. - -## Lock - Login/Signup Widgets - -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 provides a customizable UI for your users to use to authenticate with your app. - -<%= include('../_includes/_topic-links', { links: [ - 'libraries/lock', - 'libraries/lock-ios', - 'libraries/lock-android' -] }) %> - -## Auth0 Client-side Libraries - -These client-side libraries for Auth0 allow you to trigger the authentication process, parse JWTs, and authenticate requests to your APIs. There is no UI or widget provided, so these libraries are for use when you need to implement a custom UI, or already have one that you'd like to integrate Auth0 into. - -<%= include('../_includes/_topic-links', { links: [ - 'libraries/auth0js', - 'libraries/auth0-swift', - 'libraries/auth0-android' -] }) %> \ No newline at end of file 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 3dd241b2b7..fba0c02d30 100644 --- a/articles/libraries/when-to-use-lock.md +++ b/articles/libraries/when-to-use-lock.md @@ -1,108 +1,117 @@ --- 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 --- +# Universal Login Page Customization -# Lock vs. a Custom UI - -When adding Auth0 to your web apps, you have the option to implement either: - -* 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). - -**Lock** is a drop-in authentication widget that provides a standard set of behaviors and a customizable user interface. The Auth0 Libraries 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. The **Authentication API** provides integration without requiring the use of Auth0 libraries. The best option to choose will depend on the needs of your app. - -## When to Implement Lock vs. a Custom UI - -Below is a quick overview of reasons you might want to use Lock, versus using an Auth0 library or the authentication API. There are details about each option (Lock, Auth0 Libraries, Authentication API) below the table, to assist you in finding the right way to implement Auth0 in your application! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +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
        + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
        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
        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
        Adapts to a simpler process for username/password and social provider authenticationNoYes
        Handles multiple databases or Active Directory connectionsNoYes
        + + ## 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) @@ -116,15 +125,15 @@ 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) -### When to Use Lock +### When to use Lock 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 @@ -132,29 +141,27 @@ 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 an 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) 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 +### 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 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 -* [What is SSO](/sso) -* [Single Sign On with username/password logins](/sso/sso-username-password) +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/auth-api.md b/articles/link-accounts/auth-api.md deleted file mode 100644 index 3c4d624805..0000000000 --- a/articles/link-accounts/auth-api.md +++ /dev/null @@ -1,109 +0,0 @@ ---- -description: How to link accounts using the Authentication API (Deprecated) ---- - -# Link Accounts using Authentication API (Deprecated) - -**NOTE:** This method of linking accounts using the linking endpoint of the [Authentication API](/api/authentication/reference#link), either through **Lock** or by manually calling the API, is **deprecated** and should no longer be used. - -## 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: '${account.clientSecret}', - 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) -} -``` diff --git a/articles/link-accounts/index.md b/articles/link-accounts/index.md deleted file mode 100644 index 2dc85ea896..0000000000 --- a/articles/link-accounts/index.md +++ /dev/null @@ -1,234 +0,0 @@ ---- -url: /link-accounts -title: Linking User Accounts -description: Auth0 supports the linking of user accounts from various identity providers, allowing a user to authenticate from any of their accounts and still be recognized by your app and associated with the same user profile. ---- - -# Linking Accounts - -Auth0 supports the linking of user accounts from various identity providers, allowing a user to authenticate from any of their accounts and still be recognized by your app and associated with the same user profile. - -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 2nd 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. - -* Allows your app to interact with several identity provider APIs with the user's identity (for example: to share their status over Twitter or Facebook. Learn more at: [Calling an external IdP API](/what-to-do-once-the-user-is-logged-in/calling-an-external-idp-api).) - -* Allows your app to gather a user's contacts from their social networks for expanded engagement opportunities. - -## The linking process - -The process of linking accounts merges two existing user profiles into a single account. When linking accounts, a **primary account** and a **secondary account** must be specified. - -For example, if the profile of the **primary account** is: - -```json -{ - "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" - ] - }, - ... -} -``` - -and the profile of the **secondary account** is: - -```json -{ - "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" - ] - }, - ... -} -``` - -after linking, the resulting profile will be: - -```json -{ - "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 as a result of linking these accounts: - -* 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 is unchanged. -* The `user_metadata` and `app_metadata` of the secondary account is discarded. -* There is no automatic merging of user profiles with associated identities. -* The secondary account is removed from the users list. - -#### Merging Metadata - -As stated above, [user_metadata and app_metadata](/api/v2/changes#app-_metadata-and-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. 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). - -## The Management API - -The Auth0 Management API V2 provides a [Link a user account endpoint](/api/v2#!/Users/post_identities), which can be invoked in two ways: - - 1. With the JWT from both the primary and secondary accounts: - - ```text - POST https://${account.namespace}/api/v2/users/PRIMARY_ACCOUNT_USER_ID/identities - Authorization: 'Bearer PRIMARY_ACCOUNT_JWT' - { - link_with: 'SECONDARY_ACCOUNT_JWT' - } - ``` - - This method requires a token with `update:current_user_identities` scope (which the authenticated user's JWT already has) and is suitable for scenarios where the user initiates the linking process. By requiring both JWTs, you can determine that the user was able to authenticate into both accounts and has the right to merge them. - - 2. With the user id from both the primary and secondary accounts: - - ```text - POST https://${account.namespace}/api/v2/users/PRIMARY_ACCOUNT_USER_ID/identities - Authorization: 'Bearer YOUR_API_V2_TOKEN' - { - provider: 'SECONDARY_ACCOUNT_PROVIDER', - user_id: 'SECONDARY_ACCOUNT_USER_ID' - } - ``` - - This method requires an [API V2 token](/api/v2/tokens) with `update:users` scope and is intended for use in server-side code where you can make sure that both accounts correspond to the same person. - -## Scenarios - -Below are implementation details for calling the Linking Account API in these scenarios: - -* [Automatic account linking](#automatic-account-linking) -* [User-initiated account linking](#user-initiated-account-linking) -* [Suggested account linking](#suggested-account-linking) - -### Automatic account linking - -**Auth0 does not support automatic linking**, per se. However, you can implement automatic linking by setting up a [Rule](/rules) that will link accounts with the same e-mail address. For security purposes, it is best to link accounts **only if both e-mails are verified**. - -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 v2 token](/api/v2/tokens) with `update:users` scope. - -**NOTE:** For starting point, see [Link Accounts with Same Email Address](https://github.com/auth0/rules/blob/master/rules/link-users-by-email.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. - -![](/media/articles/link-accounts/spa-user-settings.png) - -**NOTE:** You can follow the [User-initiated Account Linking](/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. - -![](/media/articles/link-accounts/regular-web-app-suggest-linking.png) - -**NOTE:** You can follow the [Account Linking from 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 calling the endpoint from client-side code where you have the primary user's JWT (which comes with this scope). -* `update:users`: when calling the endpoint from server-side code where you need to generate an [Management API v2 TOKEN](/api/v2/tokens) having this scope. - -```text -DELETE https://${account.namespace}/api/v2/users/PRIMARY_ACCOUNT_USER_ID/identities/SECONDARY_ACCOUNT_PROVIDER/SECONDARY_ACCOUNT_USER_ID -Authorization: 'Bearer [PRIMARY_ACCOUNT_JWT OR API_V2_TOKEN]' -``` - -As a result of unlinking the accounts, the secondary account is removed from the identities array of the primary account, and a new secondary user account is created. This means that if, for example, a user was `john@example.com` using Facebook to login, and used the same email address to login via Linkedin, and then unlinked those accounts, then you will end up with two separate accounts; both using `john@example.com`, one for each identity provider in question. - -::: panel-warning Unlinking - Metadata -Note that any metadata stored in the primary user account will not be in the secondary account when unlinked. When accounts are linked, the secondary account's metadata is not linked; thus, when unlinked and the secondary account becomes separated again, it will have no metadata. -::: - -If your goal is to delete the secondary identity entirely, you'll want to first unlink the accounts, and then delete the newly (re)created secondary account. diff --git a/articles/link-accounts/suggested-linking.md b/articles/link-accounts/suggested-linking.md deleted file mode 100644 index e4e654fda0..0000000000 --- a/articles/link-accounts/suggested-linking.md +++ /dev/null @@ -1,273 +0,0 @@ ---- -description: How to link user accounts with server-side code. ---- - -# Account Linking from Server Side Code - -In this scenario, you will search for users with same verified email address, (as with an automatic linking rule). However, instead of completing the link automatically on authentication, your app will first prompt the user to link their identities. - -**NOTE:** You can find sample code for this at the [Auth0 Node.js Regular Web App Account Linking](https://github.com/auth0/auth0-link-accounts-sample/tree/master/RegularWebApp) sample on Github. - -The following steps implement suggested account linking for a Regular Web App: - -## 1. Initial Login - -First, the user will authenticate to the website using either [Lock](https://github.com/auth0/lock), [Lock Passwordless](https://github.com/auth0/lock-passwordless), or [Auth0.js](/libraries/auth0js) and a custom UI. - -![](/media/articles/link-accounts/regular-web-app-initial-login.png) - -The following is a sample login using Lock: - -```html - - - -``` - -In the typical SPA login, the callback is handled client-side by the same page and a JWT is received after successful authentication. You can refer to the [Single Page Apps Quickstarts](/quickstart/spa) for more details. You can also see the [Passwordless for Single Page Apps](/connections/passwordless/spa) tutorials for examples of passwordless login. - -## 2. User initiates account linking - -Your SPA must provide a UI for the user to initiate a link to their other accounts (social, passwordless, etc.). For example, in the user's settings 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 JWT to link the accounts. - - * Handling the second authentication with Lock: - - ```html - - - - ``` - - * Handling the second authentication with Lock Passwordless: - - ```html - - - -
        • - -

        -
        - -
      - - - */ - } -} -``` - -**NOTE:** The redirect to Auth0 contains two querystring parameters: `id_token` and `state`. `id_token` is a convenient and secure way of transferring information back to Auth0. `state` is mandatory to protect against CSRF attacks. - -**NOTE:** No keys are hard-coded into the Webtask code. They are referred to by the variables `context.data.yubico_clientid` and `context.data.yubico_secret`. These parameters are securely embedded in the Webtask token when the Webtask is created. - -### 1. Initialize Webtask CLI - -*Rules* code is automatically packaged as Webtasks by Auth0. Since this is a custom Webtask, it must be created with the Webtask CLI. - -Follow the instructions for installing Webtask CLI under [Account Settings > Webtasks](${manage_url}/#/account/webtasks) on the Auth0 dashboard. - -Once the Webtask CLI is installed, run: - -```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:** Replace `WEBTASK PROFILE` in the code above with the value of the -p parameter shown at the end of the code in Step 2 of the [Account Settings > Webtasks](${manage_url}/#/account/webtasks) page. - -The `create` command will generate a URL that will look like: - -```txt -https://sandbox.it.auth0.com/api/run/${account.tenant}/yubikey-mfa?webtask_no_cache=1 -``` - -Keep a copy of this URL. - -## Configure the Rule - -This sample uses a single rule that handles both the initial redirect to the Webtask, and the returned result. - - * The `context.redirect` statement instructs Auth0 to redirect the user to the Webtask URL instead of calling back to the app. - - * Returning is indicated by the `protocol` property of the `context` object. - -```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: config.WEBTASK_URL + "?user=" + user.name - } - - callback(null,user,context); -} -``` - -**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. - -Every time the user logs in they will be redirected to the Webtask and will see something like: - -![](/media/articles/mfa/yubico-mfa.png) - - -### Rule customizations -You can add logic to the rule to decide under which conditions the challenge will be triggered based on: - -* The IP address or location of the user -* The application the user is logging into -* The type of authentication used (e.g. AD, LDAP, social, etc.) - -## Additional Information: - -* [Rules](/rules) -* [Multi-factor in Auth0](/multifactor-authentication) -* [Auth0 Webtask](https://webtask.io/) diff --git a/articles/native-platforms/_includes/_authorization-create-rule.md b/articles/native-platforms/_includes/_authorization-create-rule.md deleted file mode 100644 index 3227e20199..0000000000 --- a/articles/native-platforms/_includes/_authorization-create-rule.md +++ /dev/null @@ -1,11 +0,0 @@ -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/articles/native-platforms/_includes/_authorization-introduction.md b/articles/native-platforms/_includes/_authorization-introduction.md deleted file mode 100644 index 554ec03b5a..0000000000 --- a/articles/native-platforms/_includes/_authorization-introduction.md +++ /dev/null @@ -1,3 +0,0 @@ -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/articles/native-platforms/_includes/_mfa-enable.md b/articles/native-platforms/_includes/_mfa-enable.md deleted file mode 100644 index 88a3098cee..0000000000 --- a/articles/native-platforms/_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/native-platforms/_includes/_mfa-introduction.md b/articles/native-platforms/_includes/_mfa-introduction.md deleted file mode 100644 index 5b6a2e680e..0000000000 --- a/articles/native-platforms/_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/native-platforms/_includes/_mfa-login.md b/articles/native-platforms/_includes/_mfa-login.md deleted file mode 100644 index ac9d206bca..0000000000 --- a/articles/native-platforms/_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/native-platforms/_includes/_new_app_no_sample.html b/articles/native-platforms/_includes/_new_app_no_sample.html deleted file mode 100644 index 7f5693f447..0000000000 --- a/articles/native-platforms/_includes/_new_app_no_sample.html +++ /dev/null @@ -1,5 +0,0 @@ -<% if (account.userName) { %> -

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

      Create an Auth0 account (or login) and add an authentication client instance from the dashboard. Once you create your client, 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 Client Type. -<% } %> diff --git a/articles/native-platforms/_includes/_profile-metadata-explanation.md b/articles/native-platforms/_includes/_profile-metadata-explanation.md deleted file mode 100644 index 0f6ac7889e..0000000000 --- a/articles/native-platforms/_includes/_profile-metadata-explanation.md +++ /dev/null @@ -1 +0,0 @@ -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 diff --git a/articles/native-platforms/android/00-introduction.md b/articles/native-platforms/android/00-introduction.md deleted file mode 100644 index d5eb2ac698..0000000000 --- a/articles/native-platforms/android/00-introduction.md +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Introduction -description: Short Introduction to the Auth0 Android Quickstarts. -budicon: 715 ---- - -This multistep quickstart guide will walk you through managing authentication in your android apps with Auth0. - -## 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 either [Lock](https://github.com/auth0/Lock.Android) or the [Auth0.Android](https://github.com/auth0/Auth0.Android) library. - -- [Lock](https://github.com/auth0/Lock.Android) is an `Activity` that is easy to present in your app. It contains default templates (that can be customized) for login with email/password, sign up, social providers integration, and also password recovery. -- [Auth0.Android](https://github.com/auth0/Auth0.Android) is a toolkit that lets you communicate with many of the basic [Auth0 API](https://auth0.com/docs/api) functions in a neat way. - -The `Lock` dependency is already integrated in each sample project through [Gradle](https://gradle.org/). -`Lock` packs most of the `Auth0.Android` functionality inside. - -## Create a Client - -If you haven't already done so, create a new client application in your [Auth0 dashboard](${manage_url}/#/applications/${account.clientId}/settings) and choose **Native**. - -![App Dashboard](/media/articles/angularjs/app_dashboard.png) - -<%= include('_includes/_callback_urls') %> - -<%= include('_includes/_credentials') %> diff --git a/articles/native-platforms/android/01-login.md b/articles/native-platforms/android/01-login.md deleted file mode 100644 index dc096354f2..0000000000 --- a/articles/native-platforms/android/01-login.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Login -description: This tutorial will show you how to integrate Lock v2 in your Android project in order to present a login screen. -budicon: 448 ---- - -This tutorial will show you how to integrate Lock v2 in your Android project in order to present a login screen. - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-android-sample', - path: '01-Login', - requirements: [ - 'Android Studio 2.2', - 'Android SDK 24', - 'Emulator - Nexus 5X - Android 6.0' - ] -}) %> - -<%= include('_includes/_lock') %> - -<%= include('_includes/_manifest') %> - -<%= include('_includes/_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/native-platforms/android/02-custom-login.md b/articles/native-platforms/android/02-custom-login.md deleted file mode 100644 index 2980f8a838..0000000000 --- a/articles/native-platforms/android/02-custom-login.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: Custom Login -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: 448 ---- - -This quickstart will show you how to add Auth0 login capabilities while using a customized login screen. - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-android-sample', - path: '02-Custom-Login', - requirements: [ - 'Android Studio 2.2', - 'Android SDK 24', - 'Emulator - Nexus 5X - Android 6.0' - ] -}) %> - -## Before Starting - -Go to the [Client Settings](${manage_url}/#/applications/${account.clientId}/settings) section in the Auth0 dashboard and make sure that **Allowed Callback URLs** contains the value: - -``` -https://${account.namespace}/android/YOUR_APP_PACKAGE_NAME/callback -``` - -## Add The Auth0 Android Dependency - -Your first step is to add [Auth0 Android](https://github.com/auth0/Auth0.Android) into your project, which is basically the library that will manage the login process, via [Auth0](https://auth0.com/) Authentication Client. - -#### i. Gradle - -Add to your app's module Gradle file: - -```gradle -compile 'com.auth0.android:auth0:1.0.0' -``` - -Then, run "Sync project with Gradle files" inside Android Studio or `./gradlew clean assembleDebug` 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). - -### 2. Configure Your Manifest File - -You need to add the following permissions inside the `AndroidManifest.xml`: - -```xml - -``` - -## Implement The Login - -At this point, you're all set to implement the login in any activity you want. - -First, in your customized login method, instantiate the Authentication API: - -```java -private void login(String email, String password) { - Auth0 auth0 = new Auth0("${account.clientId}", "${account.namespace}"); - AuthenticationAPIClient client = new AuthenticationAPIClient(auth0); - - // proper login -} -``` - -Then, login using the newly created client: - -```java -client.login(email, password, "YOUR_DATABASE_CONNECTION_NAME") - .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 - } - }); -``` - -> 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. diff --git a/articles/native-platforms/android/03-session-handling.md b/articles/native-platforms/android/03-session-handling.md deleted file mode 100644 index 7aedd3b1f7..0000000000 --- a/articles/native-platforms/android/03-session-handling.md +++ /dev/null @@ -1,165 +0,0 @@ ---- -title: Session Handling -description: This tutorial will show you how to use Lock v2 to maintain a session’s connectivity. -budicon: 280 ---- - -This tutorial will show you how to use Lock to maintain an active session with Auth0. - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-android-sample', - path: '03-Session-Handling', - requirements: [ - 'Android Studio 2.2', - 'Android SDK 24', - 'Emulator - Nexus 5X - Android 6.0' - ] -}) %> - - -For this, you will need to handle the user's `credentials`. Let's take a look at this class, which is composed of three objects: - -* ``idToken``: Identity Token that proves the identity of the user. -* ``accessToken``: Access Token used by the Auth0 API. -* ``refreshToken``: Refresh Token that can be used to request new tokens without signing in again. - -Those objects are the keys needed to keep the user connected, as they will be used in all the API calls`. - -## Before Starting - -Be sure that you have completed the [Login](01-login.md) quickstart. - -## Save The User's Credentials - -Your first step is to save--through a secure method--the user's credentials obtained in the login success response. - -```java -private LockCallback callback = new AuthenticationCallback() { - @Override - public void onAuthentication(Credentials credentials) { - // Login Success response - saveCredentials(credentials); - } - ... -}; -``` - -> In the seed project, the `SharedPreference` object in private mode is used to store different `Credentials` values. There are other means of storage, but we won't cover them in this tutorial. - -## At Startup: Check `idToken` Existence - -The main purpose of storing this token is to save users from having to re-enter their login credentials when relaunching the app. Once the app has launched, we need to check for the existence of an `idToken` to see if we can automatically log the user in and redirect the user straight into the app’s main flow, skipping the login screen. - -To do so, we check whether this value exists at startup to either prompt for login information or to try to perform an automated login. - -```java -if(CredentialsManager.getCredentials(this).getIdToken() == null) { - // Prompt Login screen. -} -else { - // Try to make an automatic login -} -``` - -## Validate an Existing `idToken` - -If the idToken exists, we need to check whether it’s still valid. To do so, we will fetch the user profile with the `AuthenticationAPI`. - -```java -AuthenticationAPIClient aClient = new AuthenticationAPIClient(auth0); -aClient.tokenInfo(CredentialsManager.getCredentials(this).getIdToken()) - .start(new BaseCallback() { - @Override - public void onSuccess(UserProfile payload) { - // Valid ID > Navigate to the app's MainActivity - startActivity(new Intent(LoginActivity.this, MainActivity.class)); - } - - @Override - public void onFailure(AuthenticationException error) { - // Invalid ID Scenario - } -}); -``` - -How you deal with a non-valid idToken is up to you. You will normally choose between two scenarios. You can either ask users to re-enter their credentials or use the `refreshToken` to get a new valid `idToken`. - ->If you want users to re-enter their credentials, you should clear the stored data and prompt the login screen. - - -## Check for an Valid `idToken` at Startup - -First, for both cases, you need to instantiate an `AuthenticationAPIClient`: - -```java -AuthenticationAPIClient client = new AuthenticationAPIClient( - new Auth0(${account.clientId}, ${account.namespace})); -``` - -### i. Using a non-expired idToken - -If your current idToken hasn't expired, you can use it to get a new one. - -```java -String idToken = ... // TODO: GET STORED TOKEN ID - -client.delegationWithIdToken(idToken) - .start(new BaseCallback() { - - @Override - public void onSuccess(Delegation payload) { - String idToken = payload.getIdToken(); // New ID Token - long expiresIn = payload.getExpiresIn(); // New ID Token Expire Date - } - - @Override - public void onFailure(AuthenticationException error) { - //Show error to the user - } -}); -``` - -### ii. Using refreshToken - -If the `idToken` already expired, you can always use the `refreshToken` to get a new one, without having to login again. For this reason, the token must be securely saved. - -```java -String refreshToken = ... // TODO: GET STORED REFRESH ID - -client.delegationWithRefreshToken(refreshToken) - .start(new BaseCallback() { - - @Override - public void onSuccess(Delegation payload) { - String idToken = payload.getIdToken(); // New ID Token - long expiresIn = payload.getExpiresIn(); // New ID Token Expire Date - } - - @Override - public void onFailure(AuthenticationException error) { - - } -}); -``` - -> It is recommended that you read and understand the [refresh token documentation](/refresh-token) before proceeding. For example, you should remember that even though the refresh token cannot expire, it can be revoked. - -## Log Out - -To log the user out, you just need to remove the user's credentials and navigate them to the login screen. - -An example would be: - -```java -private void logout() { - setUserCredentials(null); - startActivity(new Intent(this, LoginActivity.class)); -} -``` - -> **Note:** Deleting the user credentials depends on how you store them. - -### Optional: Encapsulated session handling - -As you have probably realized by now, session handling is not a straightforward process. All the token-related information and processes can be encapsulated into a class that separates its logic from the activity. We recommend that you download the sample project from this tutorial and take a look at its implementation, focusing on the CredentialManager class, which is in charge of dealing with this process as well as saving and obtaining the credentials object from the SharedPreferences. diff --git a/articles/native-platforms/android/04-user-profile.md b/articles/native-platforms/android/04-user-profile.md deleted file mode 100644 index cf8f61832b..0000000000 --- a/articles/native-platforms/android/04-user-profile.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: User Profile -description: This tutorial will show you how to use Lock to get the user's profile data. -budicon: 292 ---- - -This tutorial will show you how to use Lock to get the user's profile data in your Android apps with Auth0. - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-android-sample', - path: '04-User-Profile', - requirements: [ - 'Android Studio 2.2', - 'Android SDK 24', - 'Emulator - Nexus 5X - Android 6.0' - ] -}) %> - -## Before Starting - -Be sure that you have completed the [Basic Login](01-login) and the [Session Handling](03-session-handling) Quickstarts. - -## Request User Data - -The first step is to instantiate the authentication API client. This will be used to request the user's profile data. - -```java -AuthenticationAPIClient client = new AuthenticationAPIClient( -new Auth0("${account.clientId}", "${account.namespace}")); -``` - -> It's suggested that you add both the `Auth0DomainID` and `Auth0ClientID` to the `strings.xml` file rather than hardcode them in the manifest. - - -Then, use your previously stored credentials (in this example, stored in the Application Singleton) to request the data. - -```java -client.tokenInfo(App.getInstance().getUserCredentials().getIdToken()) - .start(new BaseCallback() { - @Override - public void onSuccess(UserProfile payload){ - } - - @Override - public void onFailure(AuthenticationException error){ - } -}); -``` - -## Access The Data Inside The UserProfile - -##### I. DEFAULT INFO - -At this point, you already have access to the `UserProfile`. -You can use this data wherever you need it. - -Some examples are: - -```java -payload.getName(); -payload.getEmail(); -payload.getPictureURL(); -``` - -> Remember that you can't modify the UI inside the onSuccess() method, as it works in a second thread. To solve this, you can persist the data, create a task in the UI thread or create a handler to receive that information. - -#### I. ADDITIONAL INFO - -Besides the defaults, you can handle more information that is contained within any of the following `map`: - -##### A. USER METADATA - -The userMetadata `map` contains fields related to the user profile that can be added from the client-side (e.g. when editing the profile). We're going to edit this one in this tutorial. You can access its fields as follows: - -```java -String country = payload.getUserMetadata().get("country").toString(); -boolean active = payload.getUserMetadata().get("active"); -``` - -> The strings you use for subscripting the userMetadata dictionary, and the variable types you handle, are up to you. - -##### B. APP METADATA - -The appMetadata `map` contains fields that are usually added via a rule, which is read-only for the native platform. - -##### C. EXTRA INFO - -The extraInfo `map` contains any other extra information stored in Auth0. That information is read-only for the native platform. - -> For further information on metadata, see the full documentation. - -## Update the User Profile - -You can only update the user metadata. In order to do so you must: -Create a `Map` and add the new metadata: - -```java -Map userMetadata = new HashMap<>(); -userMetadata.put("country", "USA"); -``` -And then with the `UserApiClient`, perform the update: - -```java -UsersAPIClient usersClient = new UsersAPIClient(mAuth0, App.getInstance().getUserCredentials().getIdToken()); -usersClient.updateMetadata(mUserProfile.getId(), userMetadata).start(new BaseCallback() { - @Override - public void onSuccess(final UserProfile payload) { - // As receive the updated profile here - // You can react to this, and show the information to the user. - } - - @Override - public void onFailure(ManagementException error) { - - } -}); -``` diff --git a/articles/native-platforms/android/05-linking-accounts.md b/articles/native-platforms/android/05-linking-accounts.md deleted file mode 100644 index 4c175f955d..0000000000 --- a/articles/native-platforms/android/05-linking-accounts.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: Linking Accounts -description: This tutorial will show you how to use Lock within your Android project to link two different accounts for the same user. -budicon: 345 ---- - -This tutorial will show you how to use Lock within your Android project to link two different accounts for the same user. - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-android-sample', - path: '05-Linking-Accounts', - requirements: [ - 'Android Studio 2.2', - 'Android SDK 24', - 'Emulator - Nexus 5X - Android 6.0' - ] -}) %> - -## Before Starting - -You should be familiar with previous tutorials. This tutorial assumes that: - -* You've integrated [Lock for Android](https://github.com/auth0/Lock.Android) as a dependency in your project and you're familiar with presenting the Lock login dialog. For further information, see the [login tutorial](01-login) and the [session handling](03-session-handling) tutorial first. -* You're familiar with the concepts of `userId` and `idToken`. You can find info about them in the session handling and user profile tutorials. - -> It is highly recommended that you take a look at the [linking accounts](/link-accounts) documentation to understand the process of linking accounts. - -## Enter Account Credentials - -Here's the scenario: Your logged-in user wants to link one (or multiple) accounts to the account they are logged in with. - -To do this, we will use Lock for logging in as we did in the [Login tutorial](01-login). In this case, we will send as an `Extra`, a boolean value to indicate that this is a secondary login. - -```java -Intent intent = new Intent(this, LoginActivity.class); intent.putExtra(Constants.LINK_ACCOUNTS, true); -intent.putExtra(Constants.PRIMARY_USER_ID, mUserProfile.getId()); -startActivity(intent); -``` - -In the `LoginActivity.java` we obtain that value: - -```java -mLinkSessions = getIntent().getExtras().getBoolean(Constants.LINK_ACCOUNTS, false); -``` - -Then, in the login response, we decide if we advance to the `MainActivity.java` as usual, or return to the already instantiated one: - -```java -@Override -public void onAuthentication(Credentials secondaryCredentials) { - if(mLinkSessions){ - // Link the accounts - } - else { - App.getInstance().setUserCredentials(credentials); - startActivity(new Intent(LoginActivity.this, MainActivity.class)); - } -} -``` - -> Remember to instantiate the `auth0` object with `auth0 = new Auth0(${account.clientId}, ${account.namespace});` -> Also, bear in mind that the `App.getInstance().getUserCredentials().getIdToken()` method depends on how you stored your user's `Credentials`. - -## Link an Account - -Now we can link the accounts. You have a main user along with another account you want to link to that user. All we need is the `id` of the logged-in user and the `id_token`s for the two accounts: the one we had previously saved and the one that we just received in the login response. - -```java -UsersAPIClient client = new UsersAPIClient(auth0, credentials.getIdToken()); - String primaryUserId = mUserProfile.getId(); - client.link(primaryUserId, secondaryCredentials.getIdToken()); -``` - -## Retrieve Linked Accounts - -The linked accounts are stored within the `UserProfile` as a list of `UserIdentity`, something we've previously learned when fetching the user profile (a process that we already know from the [user profile tutorial](04-user-profile)): - -```java -@Override -public void onSuccess(final UserProfile payload) { - mUserProfile.getIdentities(); //Get all the profile accounts -} -``` - -> For more information, check the [UserIdentity.java](https://github.com/auth0/Auth0.Android/blob/master/auth0/src/main/java/com/auth0/android/result/UserIdentity.java) documentation. - -### 4. Unlink An Account - -The unlink process is similar to the linking one, the only difference being that you need to specify the `identityId` and `provider` to unlink the connections. Additionally, as the first parameter, you need to use the main connection's `idToken`. - -```java -UsersAPIClient client = new UsersAPIClient(mAuth0, App.getInstance().getUserCredentials().getIdToken()); -client.unlink(primaryUserId, secondaryUserId, secondaryProvider); -``` - -> You can access the userId directly from the list, `userProfile.getIdentities().get(0).getId()`, if you know the connection's position in the array. diff --git a/articles/native-platforms/android/06-rules.md b/articles/native-platforms/android/06-rules.md deleted file mode 100644 index 4ef2dc37ee..0000000000 --- a/articles/native-platforms/android/06-rules.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: Rules -description: This tutorial will show you how to add customized Auth0 rules to your app. -seo_alias: android -budicon: 173 ---- - -Rules are functions written in JavaScript that are executed in Auth0 as part of the transaction every time a user authenticates to your application. For more information about Auth0 rules, please refer to [the full documentation](/rules). - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-android-sample', - path: '06-Rules', - requirements: [ - 'Android Studio 2.2', - 'Android SDK 24', - 'Emulator - Nexus 5X - Android 6.0' - ] -}) %> - -## Before Starting - -Make sure you have completed either the [Login](01-login) or the [Custom Login](02-custom-login) examples. - -## Create a Rule - -To create a rule, you need to go to the [new rule page](${manage_url}/#/rules/new). From there, you can either use a predefined template or create one from scratch. - -In this example we will use "*Add country to the user profile*" template, under the *Enrich Profile* section: - -![Add country template](/media/articles/rules/rule-choose-add-country-template.png) - -This rule gets the `country_name` from the context and adds it as a new `country` attribute to the user profile. - -![Country rule sample](/media/articles/angularjs2/rule-country-show.png) - -This is just a basic template. You can edit it to meet your business needs. Once you are done, save the rule and that's it. Whenever your users log in, the rule will be executed and their country will be added. - -## Test the Rule - -To see the newly created rule working, just implement a login and check the user profile information (you can find out how to do this in the [user profile tutorial](04-user-profile)). - -You can access the `country` added by the rule within the `extraInfo` hashmap from the `userProfile` object you receive in the callback (named payload by default): - -```java -client.tokenInfo(${account.clientId}) - .start(new BaseCallback() { - - @Override - public void onSuccess(final UserProfile userProfile) { - runOnUiThread(new Runnable() { - public void run() { - // Get the country from the user profile - if (payload.getExtraInfo().containsKey("country")){ - String country = (String) payload.getExtraInfo().get("country"); - //Show the country - } - } - }); - } - - @Override - public void onFailure(AuthenticationException error) { - - } -}); -``` diff --git a/articles/native-platforms/android/07-authorization.md b/articles/native-platforms/android/07-authorization.md deleted file mode 100644 index 05f03d81f3..0000000000 --- a/articles/native-platforms/android/07-authorization.md +++ /dev/null @@ -1,68 +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 step demonstrates how to use Auth0 to create access roles for your users. With access roles, you can authorize or deny 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.2', - 'Android SDK 24', - 'Emulator - Nexus 5X - Android 6.0' - ] -}) %> - -## Before Starting - -Be sure that you have completed the [user profile](04-user-profile) quickstart. - -## Create A Rule To Assign Roles - -First, you need to create a rule that assigns your users either an `admin` role, or a single `user` role. To do so, go to the [new rule page](${manage_url}/#/rules/new) and select the "*Set Roles To A User*" template, under *Access Control*. Then, replace this line from the default script: - -```java -if (user.email.indexOf('@example.com') > -1) -``` -to match the condition that fits your needs. - -By default, it says that if the user email contains `@example.com` then they will be given an `admin` role, otherwise a regular `user` role. - -> You can define more roles other than `admin` and `user`, depending on your product requirements. - -> In the demo app, we use `@admin.com` to validate, like the next rule: - -``` - var addRolesToUser = function(user, cb) { - if (user.email.indexOf('@admin.com') > -1) { - cb(null, ['admin']); - } else { - cb(null, ['user']); - } - }; -``` - -## Test the Rule in Your Project - -Once you have the user profile (as explained in the [user profile](04-user-profile) tutorial), you can save it and access it at any point. - -Inside it, you will have the role, and you will be ready to perform the access control. - -```java -List roles = (List) mUserProfile.getAppMetadata().get("roles"); - -if (roles.contains("admin")) { - // perform any action -}; -``` - -> Notice that you'll find the `roles` information within the `appMetadata` HashMap and not in the `userMetadata`. Application metadata cannot be modified by users, whereas User metadata can be. - -## Restrict Content Based On Access Level - -At this point, you are able to distinguish the users roles in your app and authorize or deny (depending on the user) access to a certain feature. diff --git a/articles/native-platforms/android/08-calling-apis.md b/articles/native-platforms/android/08-calling-apis.md deleted file mode 100644 index f0101eb65f..0000000000 --- a/articles/native-platforms/android/08-calling-apis.md +++ /dev/null @@ -1,110 +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 ---- - -This tutorial demonstrates how to use a previously saved token to authenticate your API calls. - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-android-sample', - path: '08-Calling-APIs', - requirements: [ - 'Android Studio 2.2', - 'Android SDK 24', - 'Emulator - Nexus 5X - Android 6.0' - ] -}) %> - -## Before Starting - -You should already know how to manage the `Credentials` object, as explained in the [Session Management](03-session-handling) tutorial. - -## Get a Token - -Your first step is to get the `Credentials` object. - -```java -private LockCallback callback = new AuthenticationCallback() { - @Override - public void onAuthentication(Credentials credentials) { - // Save your newly obtained credentials - } - - ... - -}; -``` -You can use any of the token strings contained in the `Credentials` object. - -## Attach the Token - -First, prepare the request. - -```java -RequestQueue queue = Volley.newRequestQueue(this); -String url = "YOUR API URL"; -``` - -Next you need to add the token to the request header so that authenticated requests can be made. In this example we use Android's `Volley` and a custom `JsonObjectRequest`. - -```java -// Retrieve the credentials from where you saved them -String tokenID = getCredentials.getTokenID(); - -AuthorizationRequestObject authorizationRequest = new AuthorizationRequestObject(Request.Method.GET,url, - tokenID, null, new Response.Listener(){ - - @Override - public void onResponse(JSONObject response) { - // Parse Response - } -}, new Response.ErrorListener() { - - @Override - public void onErrorResponse(VolleyError error) { - - } -}); -``` - -The customized `AuthorizationRequestObject` looks like: - -```java -public class AuthorizationRequestObject extends JsonObjectRequest { - private String headerTokenID = null; - - public AuthorizationRequestObject(int method, String url, String tokenID, JSONObject jsonRequest, - Response.Listener listener, Response.ErrorListener errorListener) { - super(method, url, jsonRequest, listener, errorListener); - headerTokenID = tokenID; - } - - @Override - public Map getHeaders() throws AuthFailureError { - Map headers = new HashMap(); - headers.put("Authorization", "Bearer " + headerTokenID); - return headers; - } - -} -``` - -> This customized request is meant to manipulate the header of the `JsonObjectRequest`. - -Notice that how you configure your authorization header should match the standards that you're using in your API, this is just an example of what it could look like. - -## Send the Request - -At this point, you only need to schedule the request. - -```java -// Add the request to the RequestQueue. -queue.add(authorizationRequest); -``` - -From here, check that the request was made and that the response came back as expected. You will need to configure your server-side to protect your API endpoints with the secret key for our Auth0 application. - -> For further information on authentication API on the server-side, check [the official documentation](https://auth0.com/docs/api/authentication). diff --git a/articles/native-platforms/android/09-mfa.md b/articles/native-platforms/android/09-mfa.md deleted file mode 100644 index 5976a988fc..0000000000 --- a/articles/native-platforms/android/09-mfa.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: Multifactor Authentication -description: This tutorial will show you how to configure Multifactor Authentication (MFA) via Google Authenticator in your app. -budicon: 243 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-android-sample', - path: '09-MFA', - requirements: [ - 'Android Studio 2.2', - 'Android SDK 24', - 'Emulator - Nexus 5X - Android 6.0' - ] -}) %> - -## Enable Multifactor Authentication In Your Account - -Multifactor authentication can be enabled with the flip of a switch with Auth0. Go to the [MFA section](${manage_url}/#/multifactor) of your dashboard and flip the switch on for **Google Authenticator** under the *Choose a Provider* section. - -You must specify which clients you want to enable MFA for. This can be done by editing the snippet that appears below, replacing the placeholder with your actual client IDs. - -![MFA Rule Screenshot](/media/articles/mfa/mfa-native/mfa-native-02.png) - -If you want to use MFA in **all** of your clients, the easiest you can do is disabling this conditional in the script: - -```javascript -if (CLIENTS_WITH_MFA.indexOf(context.clientID) !== -1) -``` - -> For more information on how to configure Lock-Android in your app, take a look at the [login tutorial](01-login). diff --git a/articles/native-platforms/android/10-api-authorization.md b/articles/native-platforms/android/10-api-authorization.md deleted file mode 100644 index eba1a5d214..0000000000 --- a/articles/native-platforms/android/10-api-authorization.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: OAuth 2.0 API Authorization -description: This tutorial demonstrates how to use Auth0 to make authorized API calls from your web app. -budicon: 500 ---- - -At some point, your APIs may need to allow limited access to users, servers, or servers on behalf of users. This tutorial demonstrates how to use the [Authorization Code Flow with PKCE](https://auth0.com/docs/api-auth/tutorials/authorization-code-grant-pkce) to give your applications (or third-party applications) limited access to your APIs on behalf of users. For more information, check out [our documentation](https://auth0.com/docs/api-auth). - -<%= include('../../_includes/_compat_warning') %> - -### Before Starting - -## Enable OAuth 2.0 API Authorization - -<%= include('../../_includes/_configure_oauth2aas') %> - -## Create an Application - -<%= include('../_includes/_new_app_no_sample') %> - -![App Dashboard](/media/articles/native-platforms/native-app-client.png) - -Be sure to register the URL of your app in the Allowed Callback URLs in your Client Settings. - -## Create a Resource Server (API) - -<%= include('../../_includes/_new_api') %> - -![Create API](/media/articles/api-auth/api-5.png) -![Update Scopes](/media/articles/api-auth/api-6.png) - -Take note of the API Identifier and Scopes you defined in the Dashboard, as they will be used later. - -<%= include('./_includes/_api_authz') %> diff --git a/articles/native-platforms/android/_includes/_api_authz.md b/articles/native-platforms/android/_includes/_api_authz.md deleted file mode 100644 index 9e04f9dce2..0000000000 --- a/articles/native-platforms/android/_includes/_api_authz.md +++ /dev/null @@ -1,127 +0,0 @@ -## Configuring Your Application - -## Dependences - -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.1.0" -} -``` - -Next, Syncronize bundle.gradle in Android Studio or run `./gradlew clean assembleDebug` 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). - - -## Configuration - -First, you need to update `AndroidManifest.xml` with the following: - -```xml -... - - - -... - - - - - - - -... - - - - -... -``` - -Also include following permission: - -```xml - -``` - -Finally, open the Dashboard and make sure the Allowed Callback URLs for your client contains a URL with the following format: - -`https://{YOUR_AUTH0_DOMAIN}/android/{YOUR PACKAGE NAME}/callback` - -## Initiate Authentication and Authorization - -First create an instance of Auth0 with your client information: - -```java -Auth0 account = new Auth0("{YOUR_CLIENT_ID}", "{YOUR_DOMAIN}"); -``` - -Next, you need to use the WebAuthProvider to initate the authentication and authorization. You also need to define a constant like `WEB_REQ_CODE` that holds the request code (an `int`), that will be sent back with the intent once the auth is finished in the webview: - -```java -public static final int WEB_REQ_CODE=1234; - -public void startAuth() { - - Map params = new HashMap(); - params.put("audience", "{YOUR API IDENTIFIER}"); - - WebAuthProvider.init(account) - .withConnection("Username-Password-Authentication") - .withScope("openid profile {API SCOPES}") - .withParameters(params) - .start(MainActivity.this, authCallback , WEB_REQ_CODE); -} - -private AuthCallback authCallback = new AuthCallback() { - @Override - public void onSuccess(Credentials payload) { - // here you have access to the tokens - // payload.getAccessToken() - // payload.getIdToken() - // payload.getRefreshToken() - } - - @Override - public void onFailure(Dialog d) { - // Called when the failure reason is displayed in a android.app.Dialog - } - - @Override - public void onFailure(AuthenticationException e) { - //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 WebView: - -```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). \ No newline at end of file diff --git a/articles/native-platforms/android/_includes/_callback_urls.md b/articles/native-platforms/android/_includes/_callback_urls.md deleted file mode 100644 index 1279c29dcb..0000000000 --- a/articles/native-platforms/android/_includes/_callback_urls.md +++ /dev/null @@ -1,7 +0,0 @@ -## Configure Callback URLs - -<%= include('../../../client-platforms/_includes/_callback-url-introduction') %> - -> If you wish to only use DB connections, skip this point. - -The callback URLs are meant to be used to receive the OAuth response when logging in with social connections or enterprise connections. To set a callback URL, navigate to the [settings](${manage_url}/#/applications/${account.clientId}/settings) for your client application and include the URL in the "Callback URLs" text box. diff --git a/articles/native-platforms/android/_includes/_credentials.md b/articles/native-platforms/android/_includes/_credentials.md deleted file mode 100644 index b4e23050f6..0000000000 --- a/articles/native-platforms/android/_includes/_credentials.md +++ /dev/null @@ -1,17 +0,0 @@ -## Set Credentials - -You will require the **Client ID** and **Domain** for your client application. These values can be found in your Auth0 dashboard. The suggested approach is to add these credentials to your `strings.xml` file so they are accessible to your application. - -```xml -${account.clientId} -${account.namespace} -``` - -The data path for Lock (located in `AndroidManifest.xml`) also needs to be set. - -```xml - -``` diff --git a/articles/native-platforms/android/_includes/_lock.md b/articles/native-platforms/android/_includes/_lock.md deleted file mode 100644 index 81e1b4026f..0000000000 --- a/articles/native-platforms/android/_includes/_lock.md +++ /dev/null @@ -1,21 +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 `build.gradle` dependencies section: - -```xml -apply plugin: 'com.android.application' -android { - //.. -} -dependencies { - compile 'com.auth0.android:lock:2.0.0' -} -``` - -Then, run **Sync Project with Gradle Files** inside Android Studio or `./gradlew clean assembleDebug` from the command line. - -> For more information about Gradle usage, check [their official documentation](https://gradle.org/getting-started-android-build/). \ No newline at end of file diff --git a/articles/native-platforms/android/_includes/_login.md b/articles/native-platforms/android/_includes/_login.md deleted file mode 100644 index 9596dd7ddc..0000000000 --- a/articles/native-platforms/android/_includes/_login.md +++ /dev/null @@ -1,54 +0,0 @@ -## Implement the Login - -At this point, you're all set to implement the login in any activity you want. Inside the activity, add the `onCreate`, `onDestroy`, and `callback` methods. - -```java -@Override -protected void onCreate(Bundle savedInstanceState) { - Auth0 auth0 = new Auth0("${account.clientId}", "${account.namespace}"); - lock = Lock.newBuilder(auth0, callback) - // 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
      - -> If you require in-depth configuration, see [Lock Builder](/libraries/lock-android#lock-builder) for more information - -> 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](02-custom-login). diff --git a/articles/native-platforms/android/_includes/_manifest.md b/articles/native-platforms/android/_includes/_manifest.md deleted file mode 100644 index a816398e59..0000000000 --- a/articles/native-platforms/android/_includes/_manifest.md +++ /dev/null @@ -1,35 +0,0 @@ -## Configure the Manifest File - -Add the following code to your project's `AndroidManifest.xml`. - -```xml - - - - - - - - - - - - -``` - -Add the following permissions: - -```xml - - -``` - -> Do not add `` to the `LockActivity` as this will alter the correct functionality of **Lock**. \ No newline at end of file diff --git a/articles/native-platforms/android/dashboard-default.md b/articles/native-platforms/android/dashboard-default.md deleted file mode 100644 index 37d96a0cb1..0000000000 --- a/articles/native-platforms/android/dashboard-default.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Login -default: true -description: This tutorial will show you how to integrate Lock v2 in your Android project in order to present a login screen. ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-android-sample', - path: '01-Login', - requirements: [ - 'Android Studio 2.2', - 'Android SDK 24', - 'Emulator - Nexus 5X - Android 6.0' - ] -}) %> - -<%= include('_includes/_callback_urls') %> - -<%= include('_includes/_credentials') %> - -<%= include('_includes/_lock') %> - -<%= include('_includes/_manifest') %> - -<%= include('_includes/_login') %> - diff --git a/articles/native-platforms/android/index.yml b/articles/native-platforms/android/index.yml deleted file mode 100644 index 123d996699..0000000000 --- a/articles/native-platforms/android/index.yml +++ /dev/null @@ -1,27 +0,0 @@ -title: Android -alias: - - Android -language: - - Java - - C -hybrid: false -image: /media/platforms/android.png -tags: - - quickstart -snippets: - dependencies: native-platforms/android/dependencies - setup: native-platforms/android/setup - use: native-platforms/android/use -seo_alias: android -default_article: dashboard-default -articles: - - 00-introduction - - 01-login - - 02-custom-login - - 03-session-handling - - 04-user-profile - - 05-linking-accounts - - 06-rules - - 07-authorization - - 08-calling-apis - - 09-mfa diff --git a/articles/native-platforms/chrome/01-login.md b/articles/native-platforms/chrome/01-login.md deleted file mode 100644 index eafb3e4055..0000000000 --- a/articles/native-platforms/chrome/01-login.md +++ /dev/null @@ -1,270 +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/native-platforms/chrome/index.yml b/articles/native-platforms/chrome/index.yml deleted file mode 100644 index 8c5b6000d9..0000000000 --- a/articles/native-platforms/chrome/index.yml +++ /dev/null @@ -1,18 +0,0 @@ -title: Chrome Extension -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/native-platforms/cordova/01-login.md b/articles/native-platforms/cordova/01-login.md deleted file mode 100644 index 142ad072a7..0000000000 --- a/articles/native-platforms/cordova/01-login.md +++ /dev/null @@ -1,113 +0,0 @@ ---- -title: Login -description: This tutorial will show you how to use the Auth0 Cordova SDK to add authentication and authorization to your mobile app. -budicon: 448 ---- - -You can get started by either downloading the seed project or if you would like to add Auth0 to an existing application you can follow the tutorial steps. - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-cordova-samples', - path: '00-Starter-Seed/basic-sample', - requirements: [ - 'NodeJS 5', - 'Cordova 5.4 or later' - ] -}) %> - -## 1. Setting Up the Callback URL - -
      -

      Go to the Client 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 from Cordova to be able to show the Login popup. For that, just run the following command: - -${snippet(meta.snippets.dependencies)} - -and then add the following configuration to the `config.xml` file: - -```xml - - - - -``` - -## 3. Follow the Front End Quickstarts - -Follow the [quickstart guide](/quickstart/spa) for the specific technology you are using in your Cordova app. - -> **Note**: Cordova doesn't support getting dependencies from a CDN, so it is necessary to download the JavaScript and CSS dependencies locally and then point to the downloaded files. - -> **Note**: You must use `popup` mode when configuring an application with Cordova. This can be done by setting `redirect: false` in the options object for Lock. See the [Lock customization](/libraries/lock/v9/customization) documentation for more. - -### Troubleshooting - -#### Command failed with exit code 65 when running cordova build - -This means that the `InAppBrowser` plugin wasn't installed successfully by Cordova. Try any of the following: - -* Reinstall the `InAppBrowser` plugin - -```bash -cordova plugin remove cordova-plugin-inappbrowser -cordova plugin add cordova-plugin-inappbrowser -``` -* Remove the platform and re add it - -iOS: - -```bash -cordova platform remove ios -cordova platform add ios -``` -Android: - -```bash -cordova platform remove android -cordova 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/ -``` - -#### Blank page with an OK after signin - -This may be caused by the default setting like below - -```js -lock.show(function(err, profile, token) { - -}); -``` - -You must configure Lock as shown below, to avoid the blank screen popup with the OK button. - -```js -lock.show({sso: false},function(err, profile, token) { - -}); -``` - -#### Lock is displaying errors when using cordova serve command - -Debug your app inside the simulator for your platform or an actual device. Running Lock from inside a browser using `cordova serve` is not supported at this time. diff --git a/articles/native-platforms/cordova/index.yml b/articles/native-platforms/cordova/index.yml deleted file mode 100644 index 7f8125216b..0000000000 --- a/articles/native-platforms/cordova/index.yml +++ /dev/null @@ -1,21 +0,0 @@ -title: Cordova -community: true -language: - - Javascript -framework: - - Cordova -hybrid: true -image: /media/platforms/phonegap.png -tags: - - quickstart -snippets: - dependencies: native-platforms/cordova/dependencies - setup: native-platforms/jquery/setup - use: native-platforms/jquery/use -alias: - - cordova - - apache-cordova -seo_alias: cordova -default_article: 01-login -articles: - - 01-login diff --git a/articles/native-platforms/electron/01-login.md b/articles/native-platforms/electron/01-login.md deleted file mode 100644 index ca6975f90a..0000000000 --- a/articles/native-platforms/electron/01-login.md +++ /dev/null @@ -1,46 +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:

      - -``` -https://${account.namespace}/mobile, file:/// -``` - -
      - -## Add the Lock Widget - -Add **Auth0Lock** to your `index.html` file and set the viewport. - -${snippet(meta.snippets.dependencies)} - -> **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/native-platforms/electron/index.yml b/articles/native-platforms/electron/index.yml deleted file mode 100644 index c6cf7d5972..0000000000 --- a/articles/native-platforms/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/native-platforms/ionic/00-intro.md b/articles/native-platforms/ionic/00-intro.md deleted file mode 100644 index 061fce61eb..0000000000 --- a/articles/native-platforms/ionic/00-intro.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: Introduction -description: This quickstart guide demonstrates how to add authentication to an Ionic application using Auth0 -budicon: 715 ---- - -This multistep quickstart guide will walk you through setting up and managing authentication in your Ionic apps using Auth0. - -Auth0 provides wrappers for using the [Lock widget](https://auth0.com/lock) and the [auth0.js](https://github.com/auth0/auth0.js) library in Angular apps, and these wrappers will be used throughout these quickstart guides. - -## Samples Projects - -If you want to follow along with these quickstart guides, download the [seed project](https://github.com/auth0-samples/auth0-ionic-samples/tree/master/00-Starter-Seed) as a starting point. The seed project is just a basic, blank Ionic application with all the Bower dependencies included and the required references added to the `index.html` file. You can also download the source code for each quickstart step from these docs. - -<%= include('../../_includes/_new_app') %> - -<%= include('_includes/_setup') %> diff --git a/articles/native-platforms/ionic/01-login.md b/articles/native-platforms/ionic/01-login.md deleted file mode 100644 index b398d3fa94..0000000000 --- a/articles/native-platforms/ionic/01-login.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Login -description: This tutorial demonstrates how to use the Auth0 Ionic SDK to add authentication and authorization to your mobile app -budicon: 448 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-ionic-samples', - path: '01-Login', - requirements: [ - 'Ionic 1.3.1' - ] -}) %> - -<%= include('_includes/_login') %> \ No newline at end of file diff --git a/articles/native-platforms/ionic/02-custom-login.md b/articles/native-platforms/ionic/02-custom-login.md deleted file mode 100644 index a9308be0f4..0000000000 --- a/articles/native-platforms/ionic/02-custom-login.md +++ /dev/null @@ -1,259 +0,0 @@ ---- -title: Custom Login -description: This tutorial demonstrates how to use Auth0 to add authentication and authorization to your Ionic app -budicon: 448 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-ionic-samples', - path: '02-Custom-Login', - requirements: [ - 'Ionic 1.3.1' - ] -}) %> - -The previous step explained how you can log users into your application using the Lock Widget. You do not necessarily need to use Lock, instead, you can create a custom login page and UI if you wish. - -If you are using social logins, you can also launch the login screen for a particular social login provider directly from your Ionic application. - -## Add auth0.js - -To implement a custom login screen, the **auth0.js** library and **angular-auth0** wrapper are required. Install these packages, along with angular-jwt, and add them to your project. - -```bash -bower install auth0.js#7.6.1 angular-auth0#1.0.6 angular-jwt -``` - -```html - - - - - - -``` - -## Implement the Login - -For the login view, you must display fields for **Username** and **Password**, along with a **Login** to allow users to log in with their email address. For social login, a single button can be supplied. - -```html - - - - -
      - - -
      - - - -       -       -``` - -This view is calling a `login` and `loginWithGoogle` which should be defined in the controller. - -```js -// www/components/login/login.controller.js - -(function () { - 'use strict'; - - angular - .module('app') - .controller('LoginController', LoginController) - - LoginController.$inject = ['authService']; - - function LoginController(authService) { - var vm = this; - - vm.login = login; - vm.signup = signup; - vm.loginWithGoogle = authService.loginWithGoogle; - - // Log in with username and password - function login() { - authService.login(vm.username, vm.password); - } - - function signup() { - authService.signup(vm.username, vm.password); - } - - } - -})(); -``` - -The `AuthService` needs to be adjusted to accept the supplied `username` and `password` values, or alternatively launch the Google login dialog when the user taps on the **Login with Google** button. - -```js -// www/components/auth/auth.service.js - -(function () { - - 'use strict'; - - angular - .module('app') - .service('authService', authService); - - authService.$inject = ['$rootScope', 'angularAuth0', 'authManager', 'jwtHelper', '$location', '$ionicPopup']; - - function authService($rootScope, angularAuth0, authManager, jwtHelper, $location, $ionicPopup) { - - var userProfile = JSON.parse(localStorage.getItem('profile')) || {}; - - function login(username, password) { - angularAuth0.login({ - connection: 'Username-Password-Authentication', - responseType: 'token', - ppopup: true, - email: username, - password: password - }, onAuthenticated, null); - } - - function signup(username, password, callback) { - angularAuth0.signup({ - connection: 'Username-Password-Authentication', - responseType: 'token', - popup: true, - email: username, - password: password - }, onAuthenticated, null); - } - - function loginWithGoogle() { - angularAuth0.login({ - connection: 'google-oauth2', - responseType: 'token', - popup: true - }, onAuthenticated, null); - } - - - // Logging out just requires removing the user's - // id_token and profile - function logout() { - localStorage.removeItem('id_token'); - localStorage.removeItem('profile'); - authManager.unauthenticate(); - userProfile = {}; - } - - function authenticateAndGetProfile() { - var result = angularAuth0.parseHash(window.location.hash); - - if (result && result.idToken) { - onAuthenticated(null, result); - } else if (result && result.error) { - onAuthenticated(result.error); - } - } - - function onAuthenticated(error, authResult) { - if (error) { - return $ionicPopup.alert({ - title: 'Login failed!', - template: error - }); - } - - localStorage.setItem('id_token', authResult.idToken); - authManager.authenticate(); - - angularAuth0.getProfile(authResult.idToken, function (error, profileData) { - if (error) { - return console.log(error); - } - - localStorage.setItem('profile', JSON.stringify(profileData)); - userProfile = profileData; - - $location.path('/'); - }); - } - - function checkAuthOnRefresh() { - var token = localStorage.getItem('id_token'); - if (token) { - if (!jwtHelper.isTokenExpired(token)) { - if (!$rootScope.isAuthenticated) { - authManager.authenticate(); - } - } - } - } - - return { - login: login, - logout: logout, - signup: signup, - loginWithGoogle: loginWithGoogle, - checkAuthOnRefresh: checkAuthOnRefresh, - authenticateAndGetProfile: authenticateAndGetProfile - } - } -})(); - -``` - -Notice that in the `onAuthenticated` method, which is called when a user successfully authenticates, the `profile` and `token` values are saved to the local storage. These values can be retrieved from local storage at a later stage, such as when you want to display the user's profile information. - -The `authenticateAndGetProfile` method should be called in the application's `run` block so that it is triggered when the user logs in or signs up. - -```js -// www/app.run.js - -(function () { - - 'use strict'; - - angular - .module('app') - .run(run); - - run.$inject = ['$ionicPlatform', 'authService']; - - function run($ionicPlatform, authService) { - - $ionicPlatform.ready(function () { - if (window.t && window.cordova && window.cordova.plugins.Keyboard) { - // Hide the accessory bar by default (remove this to show the accessory bar above the keyboard - // for form inputs) - cordova.plugins.Keyboard.hideKeyboardAccessoryBar(true); - - // Don't remove this line unless you know what you are doing. It stops the viewport - // from snapping when text inputs are focused. Ionic handles this internally for - // a much nicer keyboard experience. - cordova.plugins.Keyboard.disableScroll(true); - } - if (window.StatusBar) { - StatusBar.styleDefault(); - } - - // Use the authManager from angular-jwt to check for - // the user's authentication state when the page is - // refreshed and maintain authentication - authService.checkAuthOnRefresh(); - - // Process the auth token if it exists and fetch the profile - authService.authenticateAndGetProfile(); - - }); - - } - -})(); -``` diff --git a/articles/native-platforms/ionic/03-user-profile.md b/articles/native-platforms/ionic/03-user-profile.md deleted file mode 100644 index 8f8636be2e..0000000000 --- a/articles/native-platforms/ionic/03-user-profile.md +++ /dev/null @@ -1,201 +0,0 @@ ---- -title: User Profile -description: This example demonstrates how to display the user's profile -budicon: 292 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-ionic-samples', - path: '03-User-Profile', - requirements: [ - 'Ionic 1.3.1' - ] -}) %> - - -You can obtain a user's profile from the `getProfile()` method. - -## Accessing the User's Profile - -At any given time, you can call `getProfile` on `lock` passing in a token and callback function. - -```js -// www/components/auth/auth.service.js - -(function() { - ... - function authService($rootScope, lock, authManager, jwtHelper) { - ... - // Set up the logic for when a user authenticates - // This method is called from app.run.js - function registerAuthenticationListener() { - lock.on('authenticated', function(authResult) { - ... - lock.getProfile(authResult.idToken, function(error, profile) { - if (error) { - console.log(error); - } - - localStorage.setItem('profile', JSON.stringify(profile)); - - }); - ... - }); - } - ... - } -})(); - -``` - -The user's profile is being saved in local storage in the success callback and just needs to be retrieved for use from any place in the application. An example can be found in the `HomeController`. - -```js -// www/components/home/home.controller.js - -(function () { - - 'use strict'; - - angular - .module('app') - .controller('HomeController', HomeController); - - HomeController.$inject = ['$state', 'authService', '$scope']; - - function HomeController($state, authService, $scope) { - var vm = this; - - vm.login = login; - vm.logout = logout; - - $scope.$on("$ionicView.beforeEnter", function() { - - authService.getProfileDeferred().then(function(profile) { - vm.profile = profile; - }); - - }); - - function login() { - $state.go("login"); - } - - function logout() { - authService.logout(); - - // Clear VM value - vm.profile = null; - } - - } - -}()); -``` - -The user's profile is retrieved using the `getProfileDeferred()` method which is implemented in the `authService`. - -```js -// www/components/auth/auth.service.js - -(function() { - ... - function authService($rootScope, lock, authManager, jwtHelper, $q) { - - var userProfile = JSON.parse(localStorage.getItem('profile')) || null; - var deferredProfile = $q.defer(); - - if (userProfile) { - deferredProfile.resolve(userProfile); - } - - function login() { - lock.show(); - } - - // Logging out just requires removing the user's - // id_token and profile - function logout() { - deferredProfile = $q.defer(); - localStorage.removeItem('id_token'); - localStorage.removeItem('profile'); - authManager.unauthenticate(); - userProfile = {}; - } - - // Set up the logic for when a user authenticates - // This method is called from app.run.js - function registerAuthenticationListener() { - lock.on('authenticated', function(authResult) { - localStorage.setItem('id_token', authResult.idToken); - authManager.authenticate(); - lock.hide(); - - lock.getProfile(authResult.idToken, function(error, profile) { - if (error) { - console.log(error); - } - - localStorage.setItem('profile', JSON.stringify(profile)); - - // Redirect to default page - location.hash = '#/'; - - deferredProfile.resolve(profile); - }); - }); - } - - function getProfileDeferred() { - return deferredProfile.promise; - } - ... - return { - userProfile: userProfile, - login: login, - logout: logout, - registerAuthenticationListener: registerAuthenticationListener, - checkAuthOnRefresh: checkAuthOnRefresh, - getProfileDeferred: getProfileDeferred - } - } -})(); - -``` - -> **Note:** You must retrieve the profile in the Ionic `beforeEnter` event to ensure it is read everytime the home view is activated. You can read more about view lifecycle and events in the [Ionic documentation](http://ionicframework.com/docs/api/directive/ionView/). - -Once the profile is retrieved it can be bound to the view. - -```html - - - - -
      -

      Welcome to the Auth0 Ionic Sample! Please log in:

      - -
      -
      - -
      - -
      - -

      {{ vm.profile.name }}

      -
      - - - Log Out - - -
      - - -
      -       -       -``` diff --git a/articles/native-platforms/ionic/04-linking-accounts.md b/articles/native-platforms/ionic/04-linking-accounts.md deleted file mode 100644 index d82cd10f92..0000000000 --- a/articles/native-platforms/ionic/04-linking-accounts.md +++ /dev/null @@ -1,231 +0,0 @@ ---- -title: Linking Accounts -description: This tutorial demonstrates how to integrate Auth0 with Ionic to link accounts -budicon: 345 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-ionic-samples', - path: '04-Linking-Accounts', - requirements: [ - 'Ionic 1.3.1' - ] -}) %> - - - -<%= include('../../_includes/_linking_accounts') %> - -```js -// www/components/auth/auth.service.js - -(function () { - ... - function authService($rootScope, lock, authManager, jwtHelper, $http, $q) { - ... - function linkAccount() { - try { - var profile = JSON.parse(localStorage.getItem('profile')); - var token = localStorage.getItem('id_token'); - } catch (e) { - return false; - } - - var options = { - rememberLastLogin: false, - auth: { - redirect: false, - params: { - scope: 'openid', - device: 'Mobile device' - } - } - }; - - var lockLink = new Auth0Lock(AUTH0_CLIENT_ID, AUTH0_DOMAIN, options); - var deferred = $q.defer(); - - lockLink.on('authenticated', function (authResult) { - - // do linking accounts - - }); - - lockLink.show(); - - return deferred.promise; - - } - - return { - ... - linkAccount: linkAccount, - ... - } - } -})(); -``` - -Now that the second login is handled, you will need to actually do the linking. - -```js -// www/components/auth/auth.service.js - - -lockLink.on('authenticated', function (authResult) { - - $http({ - method: 'POST', - url: 'https://' + AUTH0_DOMAIN + '/api/v2/users/' + profile.user_id + '/identities', - headers: { - Authorization: 'Bearer ' + token - }, - data: { - link_with: authResult.idToken - } - }) - .then(function () { - lockLink.hide(); - - lock.getProfile(token, function (error, profile) { - if (!error) { - deferred.resolve(profile); - } else { - deferred.reject(error); - } - }); - - }); - -}); -``` - -This function posts to the API, passing the `link_with` parameter with the JWT value in the body. It then fetches the profile on success to check that the accounts are linked. - -Now to begin the link process, call the `linkAccount` method and update the user's local profile when it resolves. - -```js -// www/components/home/home.controller.js - -(function () { - ... - function HomeController($state, authService, $scope) { - ... - function linkAccount() { - authService.linkAccount() - .then(function (profile) { - vm.profile = profile; - localStorage.setItem('profile', JSON.stringify(profile)); - refreshIdentities(); - }); - } - ... - } - -}()); - -``` - -## User Profile Linked Accounts Information - -The user profile contains an array of identities which includes the profile information from linked providers. - -To view a user's identities, access the [Users](${manage_url}/#/users) page on the Auth0 dashboard, select a user, and scroll down to `identities`. - -This example shows a user with a linked Google account: - -![User identities](/media/articles/users/user-identities-linked.png) - -If you fetch the profile after linking accounts, this same information will be available. - -You can display this information and provide an **Unlink** button: - -```html - - -
      -
      - ... -
      - -

      {{ identity.profileData.name || identity.profileData.email }}

      - -
      - ... -
      -
      -``` - -The user's primary identity can be filtered by putting in a function to refresh the identities. - -```js -// www/components/home/home.controller.js - -(function () { - ... - function HomeController($state, authService, $scope) { - ... - function refreshIdentities() { - vm.profile.identities.shift(); - vm.identities = vm.profile.identities; - } - ... - } - -}()); -``` - -## Unlinking Accounts - -You can dissociate a linked account by calling the [unlink a user account](/api/management/v2#!/Users/delete_provider_by_user_id) endpoint using the primary `user_id`, and the `provider` and `user_id` of the identity to unlink. - -```js -// www/components/auth/auth.service.js - -(function () { - ... - function authService($rootScope, lock, authManager, jwtHelper, $http, $q) { - ... - function unLinkAccount(identity) { - try { - var profile = JSON.parse(localStorage.getItem('profile')); - var token = localStorage.getItem('id_token'); - } catch (e) { - return false; - } - - var deferred = $q.defer(); - - $http({ - method: 'DELETE', - url: 'https://' + AUTH0_DOMAIN + '/api/v2/users/' + profile.user_id + '/identities/' + identity .provider + '/' + identity .user_id, - headers: { - Authorization: 'Bearer ' + token - } - }) - .then(function () { - - lock.getProfile(token, function (error, profile) { - if (!error) { - deferred.resolve(profile); - } else { - deferred.reject(error); - } - }); - - }); - - return deferred.promise; - - } - - return { - ... - unLinkAccount: unLinkAccount - } - } -})(); -``` diff --git a/articles/native-platforms/ionic/05-rules.md b/articles/native-platforms/ionic/05-rules.md deleted file mode 100644 index b3006a0c00..0000000000 --- a/articles/native-platforms/ionic/05-rules.md +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: Rules -description: This tutorial demonstrates how to use rules to extend what Auth0 has to offer -budicon: 173 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-ionic-samples', - path: '05-Rules', - requirements: [ - 'Ionic 1.3.1' - ] -}) %> - - -<%= include('../_includes/_rules-introduction') %> - -## Create a Rule - -<%= include('../_includes/_rules-create-section') %> - -## Test the Rule - -<%= include('../_includes/_rules-test-result-intro', { profilelink: '/quickstart/native/ionic/03-user-profile' }) %> - -```html - - - - -
      -

      Welcome to the Auth0 Ionic Sample! Please log in:

      - -
      -
      -
      -
      - -

      {{ vm.profile.name }}

      - Country (added by rule): {{ vm.profile.country }} -
      - - Log Out - -
      -
      -       -       -``` - -
      - Mobile example screenshot -
      diff --git a/articles/native-platforms/ionic/06-authorization.md b/articles/native-platforms/ionic/06-authorization.md deleted file mode 100644 index 29bbaff030..0000000000 --- a/articles/native-platforms/ionic/06-authorization.md +++ /dev/null @@ -1,182 +0,0 @@ ---- -title: Authorization -description: This tutorial demonstrates how to assign roles to your users and use those claims to authorize or deny a user to access secure content in the app -budicon: 500 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-ionic-samples', - path: '06-Authorization', - requirements: [ - 'Ionic 1.3.1' - ] -}) %> - -<%= include('../_includes/_authorization-introduction', { ruleslink: '/quickstart/native/ionic/05-rules' }) %> - -## Create a Rule to Assign Roles - -<%= include('../_includes/_authorization-create-rule') %> - -## Restrict Access to Secure Content - -To restrict secure content to users with a role of `admin`, start by providing a function in any controller which checks the role. The `auth.isAdmin` function in this example will be defined later. - -```js -// www/components/home/home.controller.js - -// Restrict access to secure content -function showAdminContent() { - - if (auth.isAdmin()) { - - // Secure content - - } else { - - // Non-secure content - - } - - // common content - -} -``` - -Add the `showAdminContent` method to `HomeController`. - -```js -// www/components/home/home.controller.js - -(function () { - - 'use strict'; - - angular - .module('app') - .controller('HomeController', HomeController); - - HomeController.$inject = ['$state', 'authService', '$scope', '$ionicPopup']; - - function HomeController($state, authService, $scope, $ionicPopup) { - var vm = this; - - vm.login = login; - vm.logout = logout; - vm.showAdminContent = showAdminContent; - - $scope.$on("$ionicView.beforeEnter", function() { - - authService.getProfileDeferred().then(function(profile) { - vm.profile = profile; - }); - - }); - - function login() { - $state.go("login"); - } - - function logout() { - authService.logout(); - - // Clear VM value - vm.profile = null; - } - - // Restrict access to secure content - function showAdminContent() { - - var popup = {}; - - if (authService.isAdmin()) { - - // Secure content - - popup = { - title: 'Congratulations!', - template: 'You are viewing this because you are logged in and you have \'admin\' role' - }; - - } else { - - // Non-secure content - - popup = { - title: 'Unauthorized', - template: 'You are not allowed to see this content' - }; - - } - - // common content - - $ionicPopup.alert(popup); - } - - } - -}()); -``` - -Create a new `Show Admin Content` item in the `home` template: - -```html - - - -
      -

      Welcome to the Auth0 Ionic Sample! Please log in:

      - -
      -
      -
      -
      - -

      {{ vm.profile.name }}

      - Country (added by rule): {{ vm.profile.country }} -
      - - - Show Admin Content - - - Log Out - -
      -
      -       -       -``` - -The `showAdminContent` method checks if the user is an admin using a new `isAdmin` function added to the `authService`. This method checks if the `roles` attribute of `app_metadata` added by the rule contains `admin`. - - -```js -// www/components/auth/auth.service.js -(function() { - ... - function authService($rootScope, lock, authManager, jwtHelper, $q) { - ... - function isAdmin() { - return userProfile && userProfile.app_metadata - && userProfile.app_metadata.roles - && userProfile.app_metadata.roles.indexOf('admin') > -1; - } - - return { - ... - isAdmin: isAdmin - } - } -})(); -``` - -Now if an user logs in with an email that contains `@example`, they will be see a popup informing them that they are authorized. - -
      - Mobile example screenshot -
      diff --git a/articles/native-platforms/ionic/07-calling-api.md b/articles/native-platforms/ionic/07-calling-api.md deleted file mode 100644 index 492aa57422..0000000000 --- a/articles/native-platforms/ionic/07-calling-api.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -title: Calling APIs -description: This tutorial demonstrates how to make secure calls to an API -budicon: 546 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-ionic-samples', - path: '07-Calling-Api', - requirements: [ - 'Ionic 1.3.1' - ] -}) %> - - -<%= include('../../_includes/_calling_apis') %> - -## JWT Interceptor - -To attach the user's JWT as an `Authorization` header, we could write a service that returns a token and attaches it to all HTTP requests. However, the **angular-jwt** library already provides this functionality. Ensure that **angular-jwt** is added to your app as a dependency and configure it with `jwtOptionsProvider` in the `config` block. A `tokenGetter` function needs to be provided to inform **angular-jwt** how it should be retrieving the user's JWT. - -```js -// www/app.js - -(function () { - ... - function config($stateProvider, $urlRouterProvider, lockProvider, jwtOptionsProvider, $httpProvider) { - ... - // Configuration for angular-jwt - jwtOptionsProvider.config({ - tokenGetter: function() { - return localStorage.getItem('id_token'); - }, - whiteListedDomains: ['localhost'], - unauthenticatedRedirectPath: '/login' - }); - - //Push interceptor function to $httpProvider's interceptors - $httpProvider.interceptors.push('jwtInterceptor'); - - } - -})(); -``` - -## Not Sending the JWT for Specific Requests - -This basic example will attach the JWT as an `Authorization` header to all requests. This may not be desired as some requests don't require authentication. You can choose not to send the JWT by specifying `skipAuthorization: true`. - -```js -// www/components/home/home.service.js - -(function () { - ... - function HomeController($state, authService, $scope, $http, $ionicPopup) { - var vm = this; - ... - vm.ping = ping; - ... - function ping() { - // This request will NOT send the token as it has skipAuthorization - $http.get(SERVER_PATH + '/ping', { skipAuthorization: true }) - .success(onPingSuccess) - .error(onPingFail); - } - ... -}()); -``` - -## Avoiding Template Requests - -Remember that template requests via `ui-router` or `ng-route` are HTTP requests. This means that `Authorization` headers will be attached as well and that might not be needed. You may provide some configuration to avoid sending the JWT for template requests. - -```js -// www/app.js - -(function () { - ... - function config($stateProvider, $urlRouterProvider, lockProvider, jwtOptionsProvider, $httpProvider) { - ... - // Configuration for angular-jwt - jwtOptionsProvider.config({ - tokenGetter: function(options) { - // Skip authentication for any requests ending in .html - if (options.url.substr(options.url.length - 5) == '.html') { - return null; - } - - return localStorage.getItem('id_token'); - }, - whiteListedDomains: ['localhost'], - unauthenticatedRedirectPath: '/login' - }); - - //Push interceptor function to $httpProvider's interceptors - $httpProvider.interceptors.push('jwtInterceptor'); - - } - -})(); -``` - -## Different Tokens Based on URLs - -If for any reason you would want to send different tokens based on different URLs, you can configure the `tokenGetter` to do so. - -```js -// www/app.js - -(function () { - ... - function config($stateProvider, $urlRouterProvider, lockProvider, jwtOptionsProvider, $httpProvider) { - ... - // Configuration for angular-jwt - jwtOptionsProvider.config({ - tokenGetter: function(options) { - if (options.url.indexOf('http://auth0.com') === 0) { - return localStorage.getItem('auth0.id_token'); - } else { - return localStorage.getItem('id_token'); - } - - return localStorage.getItem('id_token'); - }, - whiteListedDomains: ['localhost'], - unauthenticatedRedirectPath: '/login' - }); - - //Push interceptor function to $httpProvider's interceptors - $httpProvider.interceptors.push('jwtInterceptor'); - - } - -})(); -``` diff --git a/articles/native-platforms/ionic/08-mfa.md b/articles/native-platforms/ionic/08-mfa.md deleted file mode 100644 index de196b9434..0000000000 --- a/articles/native-platforms/ionic/08-mfa.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: Multifactor Authentication -description: This tutorial demonstrates how to add Multifactor Authentication to your Ionic app -budicon: 546 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-ionic-samples', - path: '08-MFA', - requirements: [ - 'Ionic 1.3.1' - ] -}) %> - -<%= include('../_includes/_mfa-introduction') %> - -In this tutorial, you will learn how to enable MFA in the Ionic application you created in the previous steps. - -## Enable Multifactor Authentication in Your Account - -<%= include('../_includes/_mfa-enable') %> - -## Login - -<%= include('../_includes/_mfa-login', { loginlink: '/quickstart/native/ionic/01-login' }) %> diff --git a/articles/native-platforms/ionic/09-customizing-lock.md b/articles/native-platforms/ionic/09-customizing-lock.md deleted file mode 100644 index 5ba4274aec..0000000000 --- a/articles/native-platforms/ionic/09-customizing-lock.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: Customizing Lock -description: This tutorial demonstrates how to customize the Lock widget -budicon: 243 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-ionic-samples', - path: '09-Customizing-Lock', - requirements: [ - 'Ionic 1.3.1' - ] -}) %> - -Using Lock is easy, but you may want to customize your login UI. There are several options available for this. - -## Lock Options - -Some UI customization can be done via the `options` parameter when initializing a `lockProvider`. - -## Theme Options - -You can set custom theme properties, such as a different logo or primary color, by adding a `theme` property with custom values: - -```js -// www/app.js - -(function () { - ... - function config($stateProvider, $urlRouterProvider, lockProvider, jwtOptionsProvider) { - ... - lockProvider.init({ - clientID: AUTH0_CLIENT_ID, - domain: AUTH0_DOMAIN, - options: { - auth: { - redirect: false, - params: { - scope: 'openid', - device: 'Mobile device' - } - }, - theme: { - logo: 'https://auth0.com/lib/homepage/img/logo-tmz.svg', - primaryColor: "#b81b1c" - } - } - }); - }); - ... -})(); -``` - -**NOTE**: For more information, see the [theming options](https://github.com/auth0/lock#theming-options). - -## Language Dictionary Specification - -You can also customize the text that `Lock` will display with the `languageDictionary` option parameter: - -```js -// www/app.js - -(function () { - ... - function config($stateProvider, $urlRouterProvider, lockProvider, jwtOptionsProvider) { - ... - lockProvider.init({ - clientID: AUTH0_CLIENT_ID, - domain: AUTH0_DOMAIN, - options: { - auth: { - redirect: false, - params: { - scope: 'openid', - device: 'Mobile device' - } - }, - languageDictionary: { - title: "Log me in" - } - } - }); - }); - ... -})(); -``` - -> **NOTE**: For more information, see the [Language Dictionary Specification](https://github.com/auth0/lock#language-dictionary-specification). - -This is how Lock will appear using a custom logo, color, and title: - -
      - Mobile example screenshot -
      diff --git a/articles/native-platforms/ionic/_includes/_login.md b/articles/native-platforms/ionic/_includes/_login.md deleted file mode 100644 index 413387a2c5..0000000000 --- a/articles/native-platforms/ionic/_includes/_login.md +++ /dev/null @@ -1,366 +0,0 @@ -## Create an Auth Service - -The best way to have authentication utilities available across the application is to use an **Injectable** service. - -You will need an `Auth0Lock` instance to receive your Auth0 credentials and an options object. For a full list of Lock's options, see the [customization docs](/libraries/lock/customization). - -Your app will need to listen for Lock's `authenticated` event and have a callback registered to handle authentication. The callback has a single parameter that will have the user's authentication information and it will be invoked once the user is redirected after authenticating. - -There is a property on the object that gets returned by Auth0 called `idToken` which is a [JSON Web Token](https://jwt.io/introduction) identifying the user. It is this token that can be used to give an indication in your Angular 2 application that the user is authenticated, and it is also used to access resources from an API. - -For now, store the `idToken` attribute into `localStorage`. - -In the `login` method, call `lock.show()` to display the login widget. - -```js -// www/components/auth/auth.service.js - -(function() { - - 'use strict'; - - angular - .module('app') - .service('authService', authService); - - authService.$inject = ['$rootScope', 'lock', 'authManager', 'jwtHelper']; - - function authService($rootScope, lock, authManager, jwtHelper) { - - var userProfile = JSON.parse(localStorage.getItem('profile')) || {}; - - function login() { - lock.show(); - } - - // Logging out just requires removing the user's - // id_token and profile - function logout() { - localStorage.removeItem('id_token'); - localStorage.removeItem('profile'); - authManager.unauthenticate(); - userProfile = {}; - } - - // Set up the logic for when a user authenticates - // This method is called from app.run.js - function registerAuthenticationListener() { - lock.on('authenticated', function(authResult) { - console.log('authenticated'); - localStorage.setItem('id_token', authResult.idToken); - authManager.authenticate(); - lock.hide(); - - // Redirect to default page - location.hash = '#/'; - - lock.getProfile(authResult.idToken, function(error, profile) { - if (error) { - console.log(error); - } - - localStorage.setItem('profile', JSON.stringify(profile)); - - }); - }); - } - - function checkAuthOnRefresh() { - var token = localStorage.getItem('id_token'); - if (token) { - if (!jwtHelper.isTokenExpired(token)) { - if (!$rootScope.isAuthenticated) { - authManager.authenticate(); - } - } - } - } - - return { - userProfile: userProfile, - login: login, - logout: logout, - registerAuthenticationListener: registerAuthenticationListener, - checkAuthOnRefresh: checkAuthOnRefresh - } - } -})(); - -``` - -## Add the Lock Widget and angular-jwt - -Add the Lock widget and the **angular-jwt** helper library by referencing `auth0.lock` and `angular-jwt` in your application's module definition. To configure the Lock widget, include your application's Client ID and Domain in the `init` method of the `lockProvider`. - -```js -// www/app.js - -(function () { - - 'use strict'; - - angular - .module('app', ['ionic', 'auth0.lock', 'angular-jwt']) - .config(config); - - config.$inject = ['$stateProvider', '$urlRouterProvider', 'lockProvider', 'jwtOptionsProvider']; - - function config($stateProvider, $urlRouterProvider, lockProvider, jwtOptionsProvider) { - $stateProvider - - // setup an abstract state for the tabs directive - .state('home', { - url: '/', - templateUrl: 'components/home/home.html' - }) - - // if none of the above states are matched, use this as the fallback - $urlRouterProvider.otherwise('/'); - - lockProvider.init({ - clientID: '${account.clientId}', - domain: '${account.namespace}', - options: { - auth: { - redirect: false, - params: { - scope: 'openid', - device: 'Mobile device' - } - } - } - }); - - // Configuration for angular-jwt - jwtOptionsProvider.config({ - tokenGetter: function() { - return localStorage.getItem('id_token'); - }, - whiteListedDomains: ['localhost'], - unauthenticatedRedirectPath: '/login' - }); - - } - -})(); -``` - -Add a call to `authService.registerAuthenticationListener()` in the `$ionicPlatform.ready` callback function and add `authService.checkAuthOnRefresh()` method as a trigger on `$locationChangeStart` event. -You will also need to call `authService.checkAuthOnRefresh()` before Ionic is ready to check the user's authentication status at startup. - -```js -// www/app.run.js - -(function () { - - 'use strict'; - - angular - .module('app') - .run(run); - - run.$inject = ['$ionicPlatform', '$rootScope', 'authService']; - - function run($ionicPlatform, $rootScope, authService) { - $ionicPlatform.ready(function () { - // Hide the accessory bar by default (remove this to show the accessory bar above the keyboard - // for form inputs) - if (window.cordova && window.cordova.plugins && window.cordova.plugins.Keyboard) { - cordova.plugins.Keyboard.hideKeyboardAccessoryBar(true); - cordova.plugins.Keyboard.disableScroll(true); - } - - if (window.StatusBar) { - // org.apache.cordova.statusbar required - StatusBar.styleDefault(); - } - - // Register the authentication listener that is - // set up in auth.service.js - authService.registerAuthenticationListener(); - - //This event gets triggered on URL change - $rootScope.$on('$locationChangeStart', authService.checkAuthOnRefresh); - - }); - - // Check is the user authenticated before Ionic platform is ready - authService.checkAuthOnRefresh(); - } - -})(); - -``` - -## Implement Login - -To implement login, add a `LoginController`. Be sure to inject the `authService` service into the controller, and then call the `login` method to display the Login / Signup screen: - -```js -// www/components/login/login.controller.js - -(function () { - 'use strict'; - - angular - .module('app') - .controller('LoginController', LoginController); - - LoginController.$inject = ['$state', 'authService']; - - function LoginController($state, authService) { - var vm = this; - - function doLogin() { - authService.login(); - } - - doLogin(); - } - -})(); -``` - -The code sample above defines a `LoginController` controller which has a `doLogin()` function that gets called when the controller is instantiated. This `doLogin()` function initializes Lock by calling the `login()` method. - -Next, provide a view for the `LoginController`. - -```html - - - - -
      -
      -
      - - - -``` - -This view simply contains an `ion-view` component and inside that we have a `div` tag. - -Lastly, configure `stateProvider` in `app.js` with the state responsible for login. - -```js -// www/app.js - -(function () { - - ... - - function config($stateProvider, $urlRouterProvider, lockProvider, jwtOptionsProvider) { - $stateProvider - - // setup an abstract state for the tabs directive - .state('home', { - url: '/', - templateUrl: 'components/home/home.html' - }) - - .state('login', { - url: '/login', - templateUrl: 'components/login/login.html' - }); - - // if none of the above states are matched, use this as the fallback - $urlRouterProvider.otherwise('/'); - - ... - } - -})(); - -``` - -### 3. Implement a Logout Button - -To log the user out, you simply need to call the `unauthenticate` method of `authManager` and clear the user's information from the local storage. This can be done in a `logout` method in the `authService`. - -```js -// www/components/auth/auth.service.js - -(function() { - - ... - - function authService($rootScope, lock, authManager, jwtHelper) { - - var userProfile = JSON.parse(localStorage.getItem('profile')) || {}; - - ... - - // Logging out just requires removing the user's - // id_token and profile - function logout() { - localStorage.removeItem('id_token'); - localStorage.removeItem('profile'); - authManager.unauthenticate(); - userProfile = {}; - } - - ... - - return { - ... - - logout: logout, - - ... - } - } -})(); - -``` - -Remember to also add a Logout button which calls this function. In our example we call this function from `HomeController`, so in our `home.html` file we add a logout button. - -A logout button needs to be added to call the `logout` method, and this can be done in the `home` view. - -```html - - - -``` - -## Keep the User Logged In - -When the user exits the app, the mobile OS (iOS or Android) may unload it to recover some RAM. - -The user's JWT and profile have already been saved in `localStorage`. To determine whether the user is authenticated on app startup, a check should be made for the JWT and profile when it loads. - -```js -// www/components/auth/auth.service.js - -(function() { - - ... - - function authService($rootScope, lock, authManager, jwtHelper) { - - ... - - function checkAuthOnRefresh() { - var token = localStorage.getItem('id_token'); - if (token) { - if (!jwtHelper.isTokenExpired(token)) { - if (!$rootScope.isAuthenticated) { - authManager.authenticate(); - } - } - } - } - - return { - ... - - checkAuthOnRefresh: checkAuthOnRefresh - } - } -})(); - -``` - -This method has already been called in the `run` block above. diff --git a/articles/native-platforms/ionic/_includes/_setup.md b/articles/native-platforms/ionic/_includes/_setup.md deleted file mode 100644 index 6eeea0cdfa..0000000000 --- a/articles/native-platforms/ionic/_includes/_setup.md +++ /dev/null @@ -1,53 +0,0 @@ -## Configure Callback URLs - -A callback URL is a URL in your application where Auth0 redirects to after the user has authenticated. You can set the Callback URL by going to the [Client Settings](${manage_url}/#/applications/${account.clientId}/settings) section of your Auth0 dashboard and make sure that **Allowed Callback URLs** contains the following value: - -
      https://${account.namespace}/mobile
      - -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)**: - -```bash -file://\* -``` - -## Install the Dependencies - -As stated before, the seed project contains all the required Bower dependencies and has the references added to the `index.html` file. If you would rather integrate Auth0 into an existing Ionic application instead of using our seed project, you will need to add the following Bower dependencies to your application: - -```bash -bower install --save auth0-lock angular-lock angular-jwt -``` - -You will also need to add the references to the libraries to your application's `index.html`: - -```html - - - - - - -``` - -The purpose of each of these references are as follows: - - - **auth0-lock** is the default authentication widget provided by Auth0 - - **angular-lock**: Auth0's wrapper for using Lock with Angular - - **angular-jwt**: Library that contains several useful services which make using JSON Web Tokens in Angular apps easy - -## Add the `InAppBrowser` Plugin - -You must install the `InAppBrowser` plugin from Cordova to be able to show the Login popup. The seed project already has this plugin added, but if you are adding Auth0 to your own application you need to run the following command: - -```bash -ionic plugin add cordova-plugin-inappbrowser -``` - -and then add the following configuration to the `config.xml` file: - -```xml - - - - -``` diff --git a/articles/native-platforms/ionic/dashboard-default.md b/articles/native-platforms/ionic/dashboard-default.md deleted file mode 100644 index 6238fd5b8e..0000000000 --- a/articles/native-platforms/ionic/dashboard-default.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: Login -default: true -description: This tutorial demonstrates how to use the Auth0 Ionic SDK to add authentication and authorization to your mobile app ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-ionic-samples', - path: '01-Login', - requirements: [ - 'Ionic 1.3.1' - ] -}) %> - -<%= include('_includes/_setup') %> - -<%= include('_includes/_login') %> \ No newline at end of file diff --git a/articles/native-platforms/ionic/index.yml b/articles/native-platforms/ionic/index.yml deleted file mode 100644 index 70994ddc39..0000000000 --- a/articles/native-platforms/ionic/index.yml +++ /dev/null @@ -1,39 +0,0 @@ -title: Ionic -alias: - - ionic -language: - - Javascript -framework: - - AngularJS - - Cordova -hybrid: true -image: /media/platforms/ionic.jpeg -tags: - - quickstart -snippets: - bower: native-platforms/ionic/bower - references: native-platforms/ionic/references - dependencies: native-platforms/ionic/dependencies - appsetup: native-platforms/ionic/appsetup - login: native-platforms/ionic/login - loginview: native-platforms/ionic/loginview - loginroute: native-platforms/ionic/loginroute - logout: native-platforms/ionic/logout - autologin: native-platforms/ionic/autologin - referencescustom: native-platforms/ionic/references-custom - logincustom: native-platforms/ionic/login-custom - loginviewcustom: native-platforms/ionic/loginview-custom - use: native-platforms/ionic/use -seo_alias: ionic -default_article: dashboard-default -articles: - - 00-intro - - 01-login - - 02-custom-login - - 03-user-profile - - 04-linking-accounts - - 05-rules - - 06-authorization - - 07-calling-api - - 08-mfa - - 09-customizing-lock diff --git a/articles/native-platforms/ionic2/01-login.md b/articles/native-platforms/ionic2/01-login.md deleted file mode 100644 index cb27f4d5ea..0000000000 --- a/articles/native-platforms/ionic2/01-login.md +++ /dev/null @@ -1,115 +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' -}) %> - -::: panel-info System Requirements -This tutorial and seed project have been tested with the following: -* NodeJS 6.3.0 -* Ionic 2.0.0-rc.0 -* Angular 2.0.0 -::: - -## Set Up the Callback URL - -
      -

      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://\*
      - -
      - -## Install angular2-jwt - -You can use **[angular2-jwt](https://github.com/auth0/angular2-jwt)** to make authenticated HTTP requests. - -${snippet(meta.snippets.dependencies)} - -After **angular2-jwt** is installed, it needs to be configured and included in the `providers` array in your application's `@NgModule`. - -${snippet(meta.snippets.configure)} - -## Add the Lock Widget - -Add Auth0's Lock widget and auth0.js library to your `index.html`. - -${snippet(meta.snippets.setup)} - -## Add the `InAppBrowser` Plugin - -You must install the `InAppBrowser` plugin from Cordova to be able to show the Login popup. The seed project already has this plugin added, but if you are adding Auth0 to your own application you need to run the following command: - -```bash -ionic plugin add cordova-plugin-inappbrowser -``` - -and then add the following configuration to the `config.xml` file: - -```xml - - - - -``` - -## Create an Authentication Service and Configure Lock - -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. - -This is also where `Auth0Lock` can be configured with your Auth0 credentials. Be sure to configure Auth0Lock in Popup mode by setting `redirect` to `false`. - -${snippet(meta.snippets.use)} - -The service can now be injected wherever it is needed. - -## Create a Profile Page - -You 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 in and out. - -For the `profile` page component, simply inject the `AuthService`. - -${snippet(meta.snippets.profile)} - -The `AuthService` is now accessible in the view and can be used to conditionally hide and show elements depending on whether the user has a valid JWT in local storage. - -${snippet(meta.snippets.profiletemplate)} - -![auth0 lock](/media/articles/native-platforms/ionic2/ionic2-auth-5.png) - -## Optional: Implement Refresh Tokens - -[Refresh tokens](/refresh-token) are special tokens that are used to retrieve a new JWT for the user so that they can remain authenticated. - -In Angular 1.x, obtaining a new JWT with a refresh token can be accomplished using HTTP interceptors. However, Angular 2 doesn't have the concept of HTTP interceptors, so another approach is needed. There are several different ways to implement token refreshing in Angular 2, and one of them is to use observables. - -${snippet(meta.snippets.refresh)} - -When the user logs in, a refresh gets scheduled with an interval equal to the amount of time the JWT is valid for. If the user closes the application, their state will be lost and the scheduled refresh will no longer exist the next time they open it. We need a slightly different approach for setting up a refresh when the application is first opened again because the amount of time that the JWT is valid for (if there is still an unexpired JWT in local storage) will be less than that of a "fresh" token. We need to first check for an unexpired JWT, and if there is one, schedule a one-time refresh to take place when the JWT expires. - -To run the token refresh when the application is started, call the `startupTokenRefresh` method when the app is ready. - -${snippet(meta.snippets.configurerefresh)} - -## Make Authenticated HTTP Requests - -To make HTTP requests to a secure endpoint, simply use `AuthHttp` which will automatically attach the JWT as an `Authorization` header. - -${snippet(meta.snippets.http)} - -### Troubleshooting - -#### Completly 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/native-platforms/ionic2/index.yml b/articles/native-platforms/ionic2/index.yml deleted file mode 100644 index 7e18afe610..0000000000 --- a/articles/native-platforms/ionic2/index.yml +++ /dev/null @@ -1,28 +0,0 @@ -title: Ionic 2 -logo_name: ionic -alias: - - ionic2 -language: - - Typescript -framework: - - Ionic2 - - Angular2 - - Cordova -hybrid: true -image: /media/platforms/ionic.jpeg -tags: - - quickstart -snippets: - configure: native-platforms/ionic2/configure - configurerefresh: native-platforms/ionic2/configurerefresh - dependencies: native-platforms/ionic2/dependencies - http: native-platforms/ionic2/http - profile: native-platforms/ionic2/profile - profiletemplate: native-platforms/ionic2/profiletemplate - refresh: native-platforms/ionic2/refresh - setup: native-platforms/ionic2/setup - use: native-platforms/ionic2/use -seo_alias: ionic2 -default_article: 01-login -articles: - - 01-login diff --git a/articles/native-platforms/ios-objc/01-login.md b/articles/native-platforms/ios-objc/01-login.md deleted file mode 100644 index de32ae5928..0000000000 --- a/articles/native-platforms/ios-objc/01-login.md +++ /dev/null @@ -1,193 +0,0 @@ ---- -title: iOS Objective-C -default: true -description: This tutorial demonstrates how to use the Auth0 iOS Objective-C SDK to add authentication and authorization to your mobile app -budicon: 448 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-ios-objc-sample', - path: '01-Login', - requirements: [ - 'CocoaPods 0.39.0', - 'XCode 7.2.1', - 'Simulator - iOS 9.2 - iPhone 6' - ] -}) %> - -## Initial Setup - -Go to the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) section of your app in the Auth0 dashboard and make sure that **Allowed Callback URLs** contains the following value: - -`a0${account.clientId}://\*.auth0.com/authorize` - -## Add the Auth0 Dependencies - -Add the following to the `Podfile` and run `pod install`: - -${snippet(meta.snippets.dependencies)} - -**NOTE:** If you need help installing CocoaPods, see: [What is CocoaPods](http://guides.cocoapods.org/using/getting-started.html). - -## Configure Auth0 Lock for iOS - -1. Add the following entries to your app's `Info.plist`: - -| Key | Value | -| --- | --- | -| Auth0ClientId | `${account.clientId}` | -| Auth0Domain | `${account.namespace}` | - - -2. Register a new _URL Type_ in your app's **Targets** info section with the following scheme: -`a0${account.clientId}` - - ![Lock.png](/media/articles/native-platforms/ios-objc/url-type-register.png) - -3. Create and configure an instance of `A0Lock` with your Auth0 credentials from `Info.plist`. This sample uses a custom object called `MyApplication`: - -${snippet(meta.snippets.setup)} - -**NOTE:** You can create `A0Lock` in any other class, even in your `AppDelegate`, the only requirement is that you keep it in a **strong** reference. - -## Register Native Authentication Handlers - -1. In your `AppDelegate` method `application:didFinishLaunchingWithOptions:`, add the following lines: - -```objc -A0Lock *lock = [[MyApplication sharedInstance] lock]; -[lock applicationLaunchedWithOptions:launchOptions]; -``` - -2. Add the following import: - -```objc -#import -#import “MyApplication.h" -``` - -3. To allow native logins using other iOS apps (e.g: Twitter, Facebook, Safari etc.), add the following method: - -```objc -- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation { - A0Lock *lock = [[MyApplication sharedInstance] lock]; - return [lock handleURL:url sourceApplication:sourceApplication]; -} -``` - -**NOTE:** If you need Facebook or Twitter native authentication, continue reading to learn how to configure these. Otherwise, skip to [Implement the login](#implement-the-login). - -::: panel-info Configuration -Before continuing to configure either Facebook or Twitter integration, check that you have enabled and correctly configured the social connection with your credentials in the [Dashboard](${manage_url}/#/connections/social). -::: - - -### Facebook - -Lock uses the native Facebook SDK to obtain the user's access token. Use the information from your app that is configured for Facebook connections in the Auth0 dashboard: - -1. Add the following entries to the `Info.plist`: - - | Key | Value | -| --- | --- | -| FacebookAppID | `YOUR_FACEBOOK_APP_ID` | -| FacebookDisplayName | `YOUR_FACEBOOK_DISPLAY_NAME` | - - -2. Register a custom URL Type with the format `fb`. - -**NOTE:** For more information on how to configure your app for Facebook, see: [Facebook Getting Started Guide](https://developers.facebook.com/docs/ios/getting-started) and [Connect your app to Facebook](/connections/social/facebook). - -Here is an example of how the entries should look: - -![FB plist](/media/articles/native-platforms/ios-objc/fb-plist.png) - -3. Add the following key to the `Info.plist` inside the main `` key. To open this file in Source Code mode within Xcode, **Control-Click** (or right click) on it, and select **Open As > Source Code**. - -```xml -LSApplicationQueriesSchemes - - fbapi - fb-messenger-api - fbauth2 - fbshareextension - -``` -**NOTE:** These entries enable compatibility with iOS 9. You can get more information about this on Facebook's developer portal at: [Preparing your apps for iOS 9](https://developers.facebook.com/docs/ios/ios9). - -4. Add Lock Facebook's Pod: - -`pod 'Lock-Facebook', '~> 2.0'` - -5. Add to the import: - -`#import ` - -6. Register it after initializing `A0Lock`: - -```objc -A0FacebookAuthenticator *facebook = [A0FacebookAuthenticator newAuthenticatorWithDefaultPermissions]; -[lock registerAuthenticators:@[facebook]]; -``` - -### Twitter - -1. Add Lock Twitter's Pod - -`pod 'Lock-Twitter', '~> 2.0'` - -2. Import the Lock-Twitter Class - -`#import ` - -3. Configure Auth0 Twitter Authenticator - -```objc -NSString *twitterApiKey = ... -A0TwitterAuthenticator *twitter = [A0TwitterAuthenticator newAuthenticationWithConsumerKey:twitterApiKey]; -``` - -Register the `A0TwitterAuthenticator` instance with your `A0Lock` instance if native integration is available. Lock-Twitter does not default to an OAuth flow, so a check should be made to determine if native authentication is available. If it is, the integration can be registered. - -```objc -A0Lock *lock = ... // Get your instance of A0Lock -if ([A0TwitterAuthenticator canUseNativeTwitterAuthentication]) { - [lock registerAuthenticators:@[twitter]]; -} -``` - -**NOTE:** For more information on configuring your app for Twitter, see: [Connect your app to Twitter](/connections/social/twitter). - -## Implement the Login - -Now you are ready to implement the Login using Lock. You only need to instantiate and present it from any of your `UIViewControllers`, like this: - -${snippet(meta.snippets.use)} - -![Lock.png](/media/articles/native-platforms/ios-objc/Lock-Widget-Screenshot.png) - -::: panel-info Login UI Options -There are multiple ways of implementing the login box. What you see above is the Login Widget. You can also [Build your own UI](/libraries/lock-ios/use-your-own-ui), or implement one of the passwordless Login Widgets: [SMS](/libraries/lock-ios#sms) or [TouchID](/libraries/lock-ios#touchid). -::: - -On successful authentication, `onAuthenticationBlock` will yield the user's profile and tokens. - -**NOTE:** To learn how to save and manage the tokens and profile, see: [Lock iOS: Saving and Refreshing JWT Tokens](/libraries/lock-ios/save-and-refresh-jwt-tokens). - -## 5. Showing user information - -After the user has logged in, you can use the `profile` object which contains all the user information: - -```objc - self.usernameLabel.text = profile.name; - self.emailLabel.text = profile.email; -``` - -## Additional Information - -See [User Profile](/user-profile) to find out all of the available properties of the user profile. - -Also see: [A0UserProfile](https://github.com/auth0/Lock.iOS-OSX/blob/master/Lock/Core/A0UserProfile.h). - -You can also download a [sample project](/package/native-mobile-samples/master?path=iOS/profile-sample-swift&file_path=iOS/profile-sample-swift/ProfileSample/Info.plist&type=replace&client_id=${account.clientId}) that shows how to store/update your user profile with Auth0. diff --git a/articles/native-platforms/ios-objc/02-custom-login.md b/articles/native-platforms/ios-objc/02-custom-login.md deleted file mode 100644 index e12ef21e20..0000000000 --- a/articles/native-platforms/ios-objc/02-custom-login.md +++ /dev/null @@ -1,182 +0,0 @@ ---- -title: Custom Login -description: This tutorial will teach you how to perform Login and Sign Up by using your own View Controllers, without using the Lock widget interface. -budicon: 448 ---- - -<%= include('../../_includes/_package', { - org: 'auth0', - repo: 'native-mobile-samples', - path: 'iOS/basic-sample-objc', - requirements: [ - 'CocoaPods 1.0.0 ', - 'Xcode 7.3 (7D175)', - 'Simulator - iPhone 6 - iOS 9.3 (13E230)' - ] -}) %> - -### Setting up Auth0 - -
      -

      Go to the Application Settings part of the dashboard and check that this scheme is set on the *Allowed Callback URLs*:

      -
      - -``` -a0${account.clientId}://\*.auth0.com/authorize* -``` - -### 1. Import the Auth0 Toolkit to the project - -Your first step is to add [Auth0 Swift Toolkit](https://github.com/auth0/Auth0.swift) into your project, which is a library that contains helper functions that will allow you to perform basic authentication operations (such as login, sign up, or retrieve and update profiles) against the Auth0 API in a very easy manner. -This toolkit is writen in Swift, but you can incorporate it on your Objective-C project just fine. Xcode will automatically generate a header file you can include in your source and will enable you to use it's classes and methods as if they were native Objective-C code. - -#### i. Carthage - -If you are using Carthage, add the following line to the `Cartfile`: - -```ruby -github "auth0/Auth0.swift" "1.0.0-beta.3" -``` - -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). - -#### ii. Cocoapods - -If you are using [Cocoapods](https://cocoapods.org/), add these lines to your `Podfile`: - -```ruby -use_frameworks! -pod 'Auth0', '1.0.0-beta.3' -``` - -Remember to add the `use_frameworks!` line, since it's necessary for Swift pods to be included on Xcode even if it's an Objective-C project. -Then, run `pod install`. - -> For further reference on Cocoapods, check [their official documentation](http://guides.cocoapods.org/using/getting-started.html). - -### 2. Set up your Credentials - -Create a property list file named `Auth0.plist` in your project, and add the following entries into it: - -| Key | Value | -|-----------|----------------------| -| ClientId | ${account.clientId} | -| Domain | ${account.namespace} | - -Then you'll need to create a `Auth0InfoHelper` class to handle this properties. With the following methods: - -```objc -+ (NSDictionary*) readAuth0Plist { - NSDictionary *dict = [[NSDictionary alloc] initWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@"Auth0" ofType:@"plist"]]; - - return dict; -} -``` - -This will open the `Auth0.plist` file and load it in a dictionary. Then you'll need to create a method to read each value: - -```objc -+ (NSString*) Auth0ClientID { - return [[Auth0InfoHelper readAuth0Plist] objectForKey:@"ClientId"]; -} - -+ (NSURL*) Auth0Domain { - return [NSURL a0_URLWithDomain: [[Auth0InfoHelper readAuth0Plist] objectForKey:@"Domain"]]; -} -``` - -In the Domain case, we call an extension of `NSURL` included in the [Auth0 Swift Toolkit](https://github.com/auth0/Auth0.swift). It makes sure the URL we are instanciating has a `https` scheme included. - -### 3. Implement the Login - -Now, to the actual Login. - -Import both the helper class and the [Auth0 Swift Toolkit](https://github.com/auth0/Auth0.swift) header file: - -```objc -#import "Auth0-Swift.h" -#import "Auth0InfoHelper.h" -``` - -And, in order to perform the actual login: - -```objc - - A0AuthenticationAPI *authApi = [[A0AuthenticationAPI alloc] initWithClientId:[Auth0InfoHelper Auth0ClientID] url:[Auth0InfoHelper Auth0Domain]]; - - [authApi loginWithUsername:@"email@foo.com" password:@"1234" connection:@"Username-Password-Authentication" scope:@"openid" parameters:@{} callback:^(NSError * _Nullable error, A0Credentials * _Nullable credentials) { - if(error){ - // Something went wrong, let the user know - } else{ - // Logged in successfully, you may continue - // Use the A0Credentials instance to access the user profile - // information - } - }]; -``` - -Basically, `credentials` contains token-related information; you will normally store this object for later use. On the other hand, `error` contains the authentication error information that you might want to keep track of. - -> For further reference on the `credentials` and `error` objects, check the [Credentials](https://github.com/auth0/Auth0.objc/blob/master/Auth0/Authentication/Credentials.Objc) and [Authentication](https://github.com/auth0/Auth0.Objc/blob/master/Auth0/Authentication/Authentication.objc) files documentation. - -### Done! - -It is that simple. - -### Optional I: Retrieve the User Profile - -You can retrieve your user profile information using the `Credentials` object you just obtained. For that you can keep your `A0AuthenticationAPI` object or instanciate a new one, and then call: - -```objc - [authApi userInfoWithToken:credentials.accessToken callback:callback:^(NSError * _Nullable error, A0UserProfile * _Nullable profile) { - if(error) { - // Something went wrong, let the user know - } else { - // You have your user profile object - } - }]; -``` - -You can use the `profile.name` to show the user's name or show the users profile picture in a `UIImageView` - -```objc - [[[NSURLSession sharedSession] dataTaskWithURL:profile.pictureURL completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) { - dispatch_async(dispatch_get_main_queue(), ^{ - self.avatarImageView.image = [UIImage imageWithData:data]; - }); - - }] resume]; -``` - - -> For further reference on the `profile` and `error` objects, check the [UserProfile](https://github.com/auth0/Auth0.swift/blob/master/Auth0/Authentication/UserProfile.swift) and [Authentication](https://github.com/auth0/Auth0.swift/blob/master/Auth0/Authentication/Authentication.swift) files documentation. - -### Optional II: Implement a Sign Up - -If you are going to let the user sign in, you'll probably need to let the user to register first. And creating a user is as easy as sign in: - -```objc - A0AuthenticationAPI *authApi = [[A0AuthenticationAPI alloc] initWithClientId:[Auth0InfoHelper Auth0ClientID] url:[Auth0InfoHelper Auth0Domain]]; - - [authApi signUpWithEmail:@"email@foo.com" - username:nil // by default the username is the users email - password:@"1234" - connection:@"Username-Password-Authentication" - userMetadata:@{ @"Country": @"Australia", - @"Telephone": @"99 99 9999 9999"} - // Here you can include any extra information - // you need about the user - scope:@"openid" - parameters:nil - callback:^(NSError * _Nullable error, A0Credentials * _Nullable credentials) { - if(error) { - // Something went wrong, let the user know - } else { - // You signed up correctly, and you have the Credentials, - // so no need to make the user login. They are already in. - } - }); -}]; -``` diff --git a/articles/native-platforms/ios-objc/03-session-handling.md b/articles/native-platforms/ios-objc/03-session-handling.md deleted file mode 100644 index efcfe23d97..0000000000 --- a/articles/native-platforms/ios-objc/03-session-handling.md +++ /dev/null @@ -1,126 +0,0 @@ ---- -title: Session Handling -description: This tutorial will show you how to handle sessions in your app, with the aim of preventing the user from being asked for credentials each time the app is launched. -budicon: 280 ---- - -<%= include('../../_includes/_package', { - org: 'auth0', - repo: 'native-mobile-samples', - path: 'iOS/basic-sample-objc', - requirements: [ - 'CocoaPods 1.0.0 ', - 'Xcode 7.3 (7D175)', - 'Simulator - iPhone 6 - iOS 9.3 (13E230)' - ] -}) %> - -### In the Beginning - -#### i. Be familiar with Auth0 - -This tutorial assumes you are already familiar with Auth0 and how to Sign up and Sign in using Lock or Auth0 Toolkit. **If you're not sure, check out [this tutorial](01-login) first.** - -#### ii. Add the SimpleKeychain dependency - - -We're going to use the [SimpleKeychain](https://github.com/auth0/SimpleKeychain) library to help us manage user credentials. Make sure you integrate it before proceeding. - -##### a. Carthage - -If you are using Carthage, add the following line to the `Cartfile`: - -```ruby -github "auth0/SimpleKeychain" -``` - -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). - -##### b. Cocoapods - -If you are using [Cocoapods](https://cocoapods.org/), add these lines to your `Podfile`: - -```ruby -pod 'SimpleKeychain', '~> 0.7' -``` - -Then, run `pod install`. - -> For further reference on Cocoapods, check [their official documentation](http://guides.cocoapods.org/using/getting-started.html). - - -### 1. Save the token for later - -First of all, you need to import the headers for Lock and SimpleKeychain - -```objc -#import -#import "SimpleKeychain.h" -``` - -Once your user successfully signs in, you'll have a reference to a 'A0Token' object with the user's credentials. SimpleKeychain is a simple 'key-value' storage that we can use keep safe the the user's 'id_token'. - -> The `idToken` is a string representing, basically, the user's [JWT token](https://en.wikipedia.org/wiki/JSON_Web_Token). - -```objc -- (void) saveCredentials:(A0Token* ) token -{ - A0SimpleKeychain* keychain = [[A0SimpleKeychain alloc] initWithService:@"Auth0"]; - [keychain setString:token.idToken forKey:@"id_token"]; - [keychain setString:token.refreshToken forKey:@"refresh_token"]; -} -``` - -We'll be storing the 'refresh_token' too, which we'll use to get a new token, once the current one has expired. - - -### 2. Don't I know you from somewhere? - -Once you have stored the user's token, next time the app launches, you can use it to restore the user's profile and avoid making the user have to sign in again. First, you need to check if SimpleKeychain has a token stored: - -```objc - A0SimpleKeychain* keychain = [[A0SimpleKeychain alloc] initWithService:@"Auth0"]; - - if([keychain stringForKey:@"id_token"]){ - // There is a token stored - - [[A0Lock sharedLock].apiClient fetchUserProfileWithIdToken:[keychain stringForKey:@"id_token"] - success:^(A0UserProfile * _Nonnull profile) { - // You have successfully retreived the user's profile, you don't need to sign in again. - // Let your user continue to the next step - } failure:^(NSError * _Nonnull error) { - // Something went wrong, let the user know - } - } -``` - -If the `fetchUserProfileWithIdToken:` call is successful, you can continue as if the user had signed in. But, if it failed, there could be a number of reasons for it. One option is that it has expired, in which case you still have the option to refresh it, and keep the session valid: - -```objc - [lock.apiClient fetchNewIdTokenWithRefreshToken:[keychain stringForKey:@"refresh_token"] parameters:nil success:^(A0Token * _Nonnull token) { - [self saveCredentials:token]; - // Save the new credentials and use them instead. - } failure:^(NSError * _Nonnull error) { - [keychain clearAll]; // The saved token is invalid, delete them all from the keychain - // Something went wrong, let the user know - }]; -``` - -If the `fetchNewIdTokenWithRefreshToken` call fails, it means your token has been revoked or for what ever reason it's become invalid. In this case, the user will have to sign in again. - ->It's recommendable that you read and understand the [refresh token documentation](/refresh-token) before proceeding. **You got to keep on mind, for example, that, even though the refresh token cannot expire, it can be revoked.** - -### 3. Sign out - -Last, when you have to sign out, you only need to clear the keychain. - -```objc - A0SimpleKeychain* keychain = [[A0SimpleKeychain alloc] initWithService:@"Auth0"]; - [keychain clearAll]; -``` - -### 3. And we are done - -Now you can let your user's persist their sign in session. diff --git a/articles/native-platforms/ios-objc/index.yml b/articles/native-platforms/ios-objc/index.yml deleted file mode 100644 index 7081970feb..0000000000 --- a/articles/native-platforms/ios-objc/index.yml +++ /dev/null @@ -1,20 +0,0 @@ -title: iOS - Objective C -hybrid: false -language: - - Objective C -image: /media/platforms/ios.png -tags: - - quickstart -snippets: - dependencies: native-platforms/ios-objc/dependencies - setup: native-platforms/ios-objc/setup - use: native-platforms/ios-objc/use -alias: - - ios - - objective-c - - iphone - - ipad -seo_alias: ios-objc -default_article: 01-login -articles: - - 01-login diff --git a/articles/native-platforms/ios-swift/00-introduction.md b/articles/native-platforms/ios-swift/00-introduction.md deleted file mode 100644 index d9316d777d..0000000000 --- a/articles/native-platforms/ios-swift/00-introduction.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Introduction -description: Brief introduction to the iOS Swift tutorials. First steps required to follow any of the tutorials. -budicon: 715 ---- - -This multi-step quickstart guide will walk you through managing authentication in your iOS apps with Auth0. - -## Sample Projects - -Each tutorial in the series includes a link to its corresponding sample project, which demonstrates how to achieve the tutorial's goal. You can find all the samples [here](https://github.com/auth0-samples/auth0-ios-swift-sample/). - -## Dependencies - -Each tutorial will require you to use either [Lock](https://github.com/auth0/Lock.iOS-OSX) or the [Auth0.swift](https://github.com/auth0/Auth0.swift) toolkit, or both. - -A brief description: - -- [**Lock**](https://github.com/auth0/Lock.iOS-OSX) is a widget that is easy to present in your app. It contains default templates (that can be customized) for login with email/password, signup, social providers integration, and password recovery. -- [**Auth0.swift**](https://github.com/auth0/Auth0.swift) is a toolkit that lets you communicate efficiently with many of the basic [Auth0 API](/api/info) functions. - -#### Carthage - -If you are using Carthage, add the following lines to your `Cartfile`: - -```ruby -github "auth0/Lock.iOS-OSX" ~> 1.26 -github "auth0/Auth0.swift" ~> 1.1 -``` - -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 - -If you are using [Cocoapods](https://cocoapods.org/), add these lines to your `Podfile`: - -```ruby -use_frameworks! -pod 'Lock', '~> 1.28' -pod 'Auth0', '~> 1.1' -``` - -Then, run `pod install`. - -> For further reference on Cocoapods, check [their official documentation](http://guides.cocoapods.org/using/getting-started.html). - -<%= include('../../_includes/_new_app') %> - -<%= include('_includes/_config') %> diff --git a/articles/native-platforms/ios-swift/01-login.md b/articles/native-platforms/ios-swift/01-login.md deleted file mode 100644 index f25a8c944c..0000000000 --- a/articles/native-platforms/ios-swift/01-login.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: Login -description: This tutorial demonstrates how to integrate Lock in your iOS Swift project in order to present a login screen. -budicon: 448 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-ios-swift-sample', - path: '01-Login', - requirements: [ - 'CocoaPods 1.0.0', - 'XCode 7.3 (7D175)', - 'iPhone 6 - iOS 9.3 (13E230)' - ] -}) %> - -<%= include('_includes/_login') %> diff --git a/articles/native-platforms/ios-swift/02-custom-login.md b/articles/native-platforms/ios-swift/02-custom-login.md deleted file mode 100644 index bb8193bc47..0000000000 --- a/articles/native-platforms/ios-swift/02-custom-login.md +++ /dev/null @@ -1,175 +0,0 @@ ---- -title: Custom Login -description: This tutorial demonstrates how to perform Login and Sign Up by using your own View Controllers, without using the Lock widget interface. -budicon: 448 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-ios-swift-sample', - path: '02-Custom-Login', - requirements: [ - 'CocoaPods 1.0.0', - 'XCode 7.3 (7D175)', - 'iPhone 6 - iOS 9.3 (13E230)' - ] -}) %> - -## 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( - emailOrUsername: "email@foo.com", - password: "123456", - connection: "Username-Password-Authentication" - ) - .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. - -> For further reference on the `credentials` and `error` objects, check the [Credentials](https://github.com/auth0/Auth0.swift/blob/master/Auth0/Authentication/Credentials.swift) and [Authentication](https://github.com/auth0/Auth0.swift/blob/master/Auth0/Authentication/Authentication.swift) files 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 idToken = credentials.idToken else { return } -Auth0 - .authentication() - .tokenInfo(token: idToken) - .start { result in - switch result { - case .success(let profile): - // You've got a UserProfile object - case .failure(let error): - // You've got an error - } -} -``` - -A trivial example of how to use some profile info: - -```swift -welcomeLabel.text = "Welcome, \(profile.name)!" -memberLabel.text = "You are member since \(profile.createdAt)" -``` - -> For further reference on the `profile` and `error` objects, check the [UserProfile](https://github.com/auth0/Auth0.swift/blob/master/Auth0/Authentication/UserProfile.swift) and [Authentication](https://github.com/auth0/Auth0.swift/blob/master/Auth0/Authentication/Authentication.swift) files documentation. - -## Implement a Sign Up - -Including a register process in your app is also a piece of cake. - -First, don't forget to import the toolkit module in your register form view controller: - -```swift -import Auth0 -``` - -Then, all you have to do is: - -```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 [Client 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.domain}/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. - -> 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) -} -``` - -Finally, perform webauth social authentication by specifying a social connection, for instance, Facebook: - -```swift -Auth0 - .webAuth() - .connection("facebook") - .scope("openid") - .start { result in - switch result { - case .success(let credentials): - // You've got your credentials - case .failure(let error): - // Handle the error - } - } -``` - -Once you get the `credentials` object, upon a successful authentication, you deal with them as usual. For more information on that topic, check out the [login](01-login) and [session handling](session-handling) tutorials. diff --git a/articles/native-platforms/ios-swift/03-session-handling.md b/articles/native-platforms/ios-swift/03-session-handling.md deleted file mode 100644 index 6c2c1c787c..0000000000 --- a/articles/native-platforms/ios-swift/03-session-handling.md +++ /dev/null @@ -1,195 +0,0 @@ ---- -title: Session Handling -description: This tutorial will show you how to handle sessions in your app, with the aim of preventing the user from being asked for credentials each time the app is launched. -budicon: 280 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-ios-swift-sample', - path: '03-Session-Handling', - requirements: [ - 'CocoaPods 1.0.0', - 'XCode 7.3 (7D175)', - 'iPhone 6 - iOS 9.3 (13E230)' - ] -}) %> - - -## Before Starting - -This tutorial assumes you're using the Lock library for handling login. Make sure you've integrated this library into your project and you're familiar with it. **If you're not sure, review the [login tutorial](/quickstart/native/ios-swift/01-login) first.** - -### Add the SimpleKeychain Dependency - -We're going to use the [SimpleKeychain](https://github.com/auth0/SimpleKeychain) library to help us manage user credentials. Make sure you integrate it before proceeding. - -##### a. Carthage - -If you are using Carthage, add the following line to the `Cartfile`: - -```ruby -github "auth0/SimpleKeychain" -``` - -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). - -##### b. Cocoapods - -If you are using [Cocoapods](https://cocoapods.org/), add these lines to your `Podfile`: - -```ruby -use_frameworks! -pod 'SimpleKeychain', '~> 0.7' -``` - -Then, run `pod install`. - -> For further reference on Cocoapods, check [their official documentation](http://guides.cocoapods.org/using/getting-started.html). - -## On Login: Store the user's idToken - -> The `idToken` is a string representing, basically, the user's [JWT token](https://en.wikipedia.org/wiki/JSON_Web_Token). - -We will store this `idToken` **upon a successful login**, in order to prevent the user from being asked for login credentials again every time the app is re-launched. - -Once the user has logged in, you get both an `A0Profile` and an `A0Token` object, as follows: - -```swift -let controller = A0Lock.shared().newLockViewController() -controller?.onAuthenticationBlock = { profile, token in - // do something with profile and token -} -``` - -> Even though `profile` and `token` come as optional values, the [A0LockViewController](https://github.com/auth0/Lock.iOS-OSX/blob/master/Lock/UI/A0LockViewController.h) documentation guarantees that both of them will only be `nil` if login is disabled after sign up. We assume that's not the case here; therefore, we will perform force-unwrap to get their values. - -We need to store the `id_token` string value, which is inside the `A0Token` instance that comes in `maybeToken`. To do so, we'll use an `A0SimpleKeychain` instance: - -```swift -guard let token = token else { return } -let keychain = A0SimpleKeychain(service: "Auth0") -keychain.setString(token.idToken, forKey: "id_token") -``` - -As you can see, `A0SimpleKeychain` can be seen simply as a key-value storage. - -> You can also verify whether a JWT token is valid or not by decoding it locally, to check its expiration. For further reference, you can check out this [JWT decoder for Swift](https://github.com/auth0/JWTDecode.swift). - -## On Startup: Check idToken existence - -The main purpose of storing this token is to save the user from having to re-enter login credentials upon relaunch of the app. So, **once the app has launched**, we need to check for the existence of an `idToken` to see if we can automatically log the user in and redirect the user straight into the app's main flow, skipping any login screen. - -To do so, first, we retrieve its value from the `id_token` key we used above, from the keychain: - -```swift -let keychain = A0SimpleKeychain(service: "Auth0") -guard let idToken = keychain.string(forKey: "id_token") else { - // idToken doesn't exist, user has to enter their credentials to log in - // Present A0Lock Login - return -} -// idToken exists -// We still need to validate it (see step 3) -``` - -## Validate an existent idToken - -Then, if such a token exists, we need to check whether it's still valid, has expired, or is no longer valid for some other reason, such as being revoked. To do so, we'll use `A0Lock` to fetch the user profile based on the current `idToken` we've got: - -```swift -guard let idToken = keychain.string(forKey: "id_token") else { - // Present A0Lock Login - return -} -// Validate idToken -let client = A0Lock.shared().apiClient() -client?.fetchUserProfile(withIdToken: idToken, - success: { profile in - // Our idToken is still valid... - // We store the fetched user profile - keychain.setData(NSKeyedArchiver.archivedDataWithRootObject(profile), forKey: "profile") - // ✅ At this point, you can log the user into your app, by navigating to the corresponding screen - }, - failure: { error in - // ⚠️ idToken has expired or is no longer valid - // See step 4 - }) -``` - -## Deal with a non-valid idToken - -How to deal with a non-valid idToken is up to you. You will normally choose between two scenarios: Either you ask users to re-enter theirs credentials, or you [use the refresh token to get a new valid idToken again](/refresh-token). - -If you aim for the former scenario, make sure you clear all the keychain stored values by doing: - -```swift -A0SimpleKeychain(service: "Auth0").clearAll() -``` - -However, in this tutorial, we'll focus on the latter scenario, where we still want to log users in without asking for their credentials again. - -In this case, we're going to leverage the `refreshToken`. The refresh token is another token string contained within the `A0Token` object that comes upon a successful login, which doesn't expire, and whose main purpose is retrieving new valid `idToken`s in spite of their having expired. - ->It's recommended that you read and understand the [refresh token documentation](/refresh-token) before proceeding. **You got to keep on mind, for example, that, even though the refresh token cannot expire, it can be revoked.** - -#### i. Store the refreshToken - -Besides storing the `idToken`, we need to store the `refreshToken`. To do so, you can, upon login: - -```swift -guard - let token = maybeToken, - let refreshToken = token.refreshToken - else { return } -let keychain = A0SimpleKeychain(service: "Auth0") -keychain.setString(token.idToken, forKey: "id_token") -keychain.setString(refreshToken, forKey: "refresh_token") // Add this line -``` - -> The `refreshToken` can be `nil` if `offline_access` is not sent in the `scope` parameter during authentication. - -#### ii. Use the refreshToken to get a new idToken - -We've used the `fetchNewIdTokenWithIdToken` function from `A0Lock.sharedLock().apiClient()` to get a new `idToken` based on a current valid `idToken`. What we're going to do now is pretty similar, but we'll use the `fetchNewIdTokenWithRefreshToken` function instead. - -```swift -// ⚠️ idToken has expired or is no longer valid -let keychain = A0SimpleKeychain(service: "Auth0") -guard let refreshToken = keychain.string(forKey: "refresh_token") else { - keychain.clearAll() - return -} -let client = A0Lock.shared().apiClient() -client.fetchNewIdToken(withRefreshToken: refreshToken, - parameters: nil, - success: { newToken in - // Just got a new idToken! - // Don't forget to store it... - keychain.setString(newToken.idToken, forKey: "id_token") - // ✅ At this point, you can log the user into your app, by navigating to the corresponding screen - }, - failure: { error in - // refreshToken is no longer valid (e.g. 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! - }) -``` - -That's it! You've already dealt with the basic concepts of session handling in your app. - -## On Logout: Clear the Keychain - -Whenever you need to log the user out, you just have to clear the keychain: - -```swift -let keychain = A0SimpleKeychain(service: "Auth0") -keychain.clearAll() -``` - -### Optional: Encapsulate session handling - -As you have probably realized by now, session handling is not a straightforward process. All this token-related information and processes can be encapsulated into a class that separates its logic from the View Controller layer. We recommend that you download the sample project from this tutorial and take a look at its implementation, focusing on the `SessionManager` class, which is in charge of dealing with these processes, and at the `Session` struct, which is a structure used for holding basic user profile data and tokens. diff --git a/articles/native-platforms/ios-swift/04-user-profile.md b/articles/native-platforms/ios-swift/04-user-profile.md deleted file mode 100644 index 2c3095b973..0000000000 --- a/articles/native-platforms/ios-swift/04-user-profile.md +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: User Profile -description: This tutorial will show you how to access the user profile from within your app, as well as how to update it. -budicon: 292 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-ios-swift-sample', - path: '04-User-Profile', - requirements: [ - 'CocoaPods 1.0.0', - 'XCode 7.3 (7D175)', - 'iPhone 6 - iOS 9.3 (13E230)' - ] -}) %> - -### Before Starting - -You should be familiar with previous tutorials. This tutorial assumes: - -- You're using the Lock library for handling login. Make sure you've integrated this library into your project and you're familiar with it. **If you're not sure, check out the [login tutorial](/quickstart/native/ios-swift/01-login) first.** -- You're using the Auth0.swift and SimpleKeychain dependencies. **It's recommended that you take a look at the [session handling tutorial](/quickstart/native/ios-swift/03-session-handling) first.** - -## Fetch the User Profile - -The first step is to fetch the user profile. To do so, you need a valid `idToken` first. - -> Check out the [session handling tutorial](/quickstart/native/ios-swift/03-session-handling) if you're not sure about the `idToken`. - -You need to call a function from the `Lock` module that allows you to fetch the user profile given an `idToken`: - -```swift -import Lock -``` - -```swift -let client = A0Lock.shared().apiClient() -client.fetchUserProfile(withIdToken: idToken, - success: { profile in - // You've got the user profile here! - // You might want to store it in a safe place. You can use SimpleKeychain: - let keychain = A0SimpleKeychain(service: "Auth0") - let profileData = NSKeyedArchiver.archivedDataWithRootObject(profile) - keychain.setData(profileData, forKey: "profile") - }, failure: { error in - // check the session handling tutorial for hints on what to do in case of a failure - }) -``` - -## Show User Profile's Data - -#### i. Default info - -Showing the information contained in the user profile is pretty simple. You only have to access its properties, for instance: - -```swift -let name = profile.name -let email = profile.email -let avatarURL = profile.picture -``` - -> Check out the [A0UserProfile](https://github.com/auth0/Lock.iOS-OSX/blob/master/Lock/Core/A0UserProfile.h) class documentation to learn more about its fields. - -#### ii. Additional info - -Besides the defaults, you can handle more information that is contained within any of the following dictionaries: - -##### a. User Metadata - -The `userMetadata` dictionary contains fields related to the user profile that can be added from client-side (e.g. when editing the profile). This is the one we're going to work with in this tutorial. You can access its fields as follows: - -```swift -let firstName = profile.userMetadata["first_name"] as? String -let lastName = profile.userMetadata["last_name"] as? String -let country = profile.userMetadata["country"] as? String -let isActive = profile.userMetadata["active"] as? Bool -``` - -> The strings you use for subscripting the `userMetadata` dictionary, and the variable types you handle, are up to you. - -##### b. App Metadata - -The `appMetadata` dictionary contains fields that are usually added via [a rule](/quickstart/native/ios-swift/06-rules), which is read-only for the native platform. - -##### c. Extra Info - -The `extraInfo` dictionary contains any other extra information stored in Auth0. That information is read-only for the native platform. - -> For further information on metadata, see [the full documentation](/rules/metadata-in-rules). - -## Update the User Profile - -You can only update the user metadata. In order to do so, you need to perform a `patch`: - -```swift -import Auth0 -import Lock -``` - -```swift -let idToken = ... // the idToken you obtained before -let profile = ... // the A0Profile instance you obtained before -Auth0 - .users(token: idToken) - .patch(profile.userId, userMetadata: ["first_name": "John", "last_name": "Appleseed", "country": "Canada"] - .start { result in - switch result { - case .success: - // deal with success - case .failure(let error): - // deal with failure - } -} -``` diff --git a/articles/native-platforms/ios-swift/05-linking-accounts.md b/articles/native-platforms/ios-swift/05-linking-accounts.md deleted file mode 100644 index 8e70306230..0000000000 --- a/articles/native-platforms/ios-swift/05-linking-accounts.md +++ /dev/null @@ -1,123 +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: '05-Linking-Accounts', - requirements: [ - 'CocoaPods 1.0.0', - 'XCode 7.3 (7D175)', - 'iPhone 6 - iOS 9.3 (13E230)' - ] -}) %> - -## Before Starting - -You should be familiar with previous tutorials. This tutorial assumes that: - -- You've integrated [Lock](https://github.com/auth0/Lock.iOS-OSX) and [Auth0.swift](https://github.com/auth0/Auth0.swift/) dependencies in your project and you're familiar with presenting the Lock login dialog. For further information, check out the [login tutorial](/quickstart/native/ios-swift/01-login) and the [session handling tutorial](/quickstart/native/ios-swift/03-session-handling) first. -- You're familiar with the concepts of `userId` and `idToken`. You can find info about them in the [session handling](/quickstart/native/ios-swift/03-session-handling) and [user profile](/quickstart/native/ios-swift/04-user-profile) tutorials. - -> **It is highly recommended that you take a look at the [linking accounts documentation](/link-accounts)** to understand the process of linking accounts. - -## Enter Account Credentials - -Here's the scenario: You have a user who is logged in and wants to link one (or multiple) accounts to that logged in account, such that the user can login with any of them and get into that account. - -Typically, you will need to present an extra login dialog to make users enter the credentials for any account they want to link with their main account. You can present this login as we saw in the [login tutorial](/quickstart/native/ios-swift/01-login): - -```swift -import Lock -``` - -```swift -let controller = A0Lock.shared().newLockViewController() -controller?.closable = true -controller?.onAuthenticationBlock = { profile, token in - // store token.idToken - controller?.dismiss(animated: true, completion: nil) -} -A0Lock.shared().present(controller, from: self) -``` - -Upon success, you need to store the `token.idToken` value for later use, which is the `idToken` for the secondary account that the user is linking with. - -## Link an Account - -Linking an account is simple. You have a user, and another account you want to link with that user. All you need to grab is these three values: - -- `userId`: The `id` from the user that is logged in. -- `idToken`: The `idToken` obtained upon your user login. -- `otherUserToken`: The `idToken` from the account you want to link the user with. This is the value you stored in step 1. - -```swift -import Auth0 -``` - -```swift -let userId = ... // the user id -let idToken = ... // the user idToken -let otherUserToken = ... // the idToken from the account you want to link the user with -Auth0 - .users(token: idToken) - .link(userId, withOtherUserToken: otherUserToken) - .start { result in - switch result { - case .success: - // linked account! - case .failure(let error): - // deal with error - } - } -``` - -## Retrieve Linked Accounts - -Linked accounts, a.k.a. user's identities, can be easily retrieved by fetching the user profile, a process that we already know from the [user profile](/quickstart/native/ios-swift/04-user-profile) tutorial: - -```swift -import Lock -``` - -```swift -let client = A0Lock.shared().apiClient() -client?.fetchUserProfile(withIdToken: idToken, - success: { profile in - let identities = profile.identities as! [A0UserIdentity] - // you've got the linked accounts here - // do something with them, e.g. display them on a table view - }, failure: { error in - // deal with error - }) -``` - -> Any linked account is handled as an `A0UserProfile` identity object. For further information on this object, check out its [class documentation](https://github.com/auth0/Lock.iOS-OSX/blob/master/Lock/Core/A0UserIdentity.h). - -## Unlink an Account - -The unlinking process is quite similar to the linking one. This time, you just need the `userId`, the user's `idToken`, and the `identity` object that you want to unlink (you will only use its `userId` and `provider` values): - -```swift -import Auth0 -``` - -```swift -let userId = ... // the user id -let idToken = ... // the user idToken -let identity: A0UserIdentity = ... // the identity (account) you want to unlink from the user -Auth0 - .users(token: idToken) - .unlink(identityId: identity.userId, provider: identity.provider, fromUserId: userId) - .start { result in - switch result { - case .success: - // unlinked account! - case .failure(let error): - // deal with error - } - } -``` \ No newline at end of file diff --git a/articles/native-platforms/ios-swift/06-rules.md b/articles/native-platforms/ios-swift/06-rules.md deleted file mode 100644 index 6b49d9475f..0000000000 --- a/articles/native-platforms/ios-swift/06-rules.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Rules -description: This tutorial will show you how to create a basic rule that you can use in your app. -budicon: 173 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-ios-swift-sample', - path: '06-Rules', - requirements: [ - 'CocoaPods 1.0.0', - 'XCode 7.3 (7D175)', - 'iPhone 6 - iOS 9.3 (13E230)' - ] -}) %> - -Rules are functions written in JavaScript that are executed in Auth0 as part of the transaction every time a user authenticates to your application. For more information about Auth0 rules, please refer to [the full documentation](/rules). - -## Create a Rule - -To create a rule, just go to the [new rule page](${manage_url}/#/rules/new). You can create it from scratch or use an existing template. These templates are written by Auth0 team to assist you complete common tasks. - -Let's use the template called "*Add country to the user profile*", under the *Enrich Profile* section: - -![Add country template](/media/articles/rules/rule-choose-add-country-template.png) - -This rule just gets the `country_name` from the context and adds it as a new `country` attribute to the user profile. - -![Country rule sample](/media/articles/angularjs2/rule-country-show.png) - -This is just a starting template, you can edit it to meet your business needs. Once you are done, save the rule and that's it. Whenever you login, the rule will be executed, and the country will be added. - -## Test the Rule - -To see the created rule results, just implement a login and fetch the user profile information (you can check out how to do it in the [login tutorial](/quickstart/native/ios-swift/01-login)). - -You can access the `country` added by the rule within the `extraInfo` dictionary from the `A0UserProfile` object, like so: - -```swift -import Lock -``` - -```swift -let profile: A0UserProfile = ... // the user profile you get upon login -guard let country = profile.extraInfo["country"] as? String else { - // test failed - return -} -print("user country is: \(country)") -``` diff --git a/articles/native-platforms/ios-swift/07-authorization.md b/articles/native-platforms/ios-swift/07-authorization.md deleted file mode 100644 index 53c751b06d..0000000000 --- a/articles/native-platforms/ios-swift/07-authorization.md +++ /dev/null @@ -1,67 +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: '07-Authorization', - requirements: [ - 'CocoaPods 1.0.0', - 'XCode 7.3 (7D175)', - 'iPhone 6 - iOS 9.3 (13E230)' - ] -}) %> - -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. - -> This tutorial assumes that you've already read the [rules tutorial](/quickstart/native/ios-swift/06-rules) and you know how to implement a basic rule in your app. - -## Before Starting - -It's required that you've got [Lock](https://github.com/auth0/Lock.iOS-OSX) integrated in your project. You can check out the [login tutorial](/quickstart/native/ios-swift/01-login) for more information about it. - -## Create a Rule to Assign Roles - -First, you will create a rule that assigns your users either an `admin` role, or a single `user` role. To do so, go to the [new rule page](${manage_url}/#/rules/new) and select the "*Set Roles To A User*" template, under *Access Control*. Then, replace this line from the default script: - -``` -if (user.email.indexOf('@example.com') > -1) -``` - -to match the condition that fits your needs. Notice that you can also set more roles other than `admin` and `user`, or customize the whole rule as you please. - -By default, it says that if a user email contains `@example.com`, that user will be given an `admin` role, otherwise a regular `user` role. - -## Test the Rule - -To test the rule, use the following code snippet once you've gotten the user profile. - -> Check out the [login](/quickstart/native/ios-swift/01-login) and [user profile](/quickstart/native/ios-swift/04-user-profile) tutorials for more information on how to get the user profile. - -```swift -import Lock -``` - -```swift -let profile: A0UserProfile = ... // the user profile you get upon login -guard let roles = profile.appMetadata["roles"] as? [String] else { - // test failed, make sure you've configured your rule properly (check step 1 thoroughly) - return -} -if roles.contains("admin") { - print("this user has admin access") -} else { - print("this user does not have admin access") -} -``` - -Notice that you'll find the `roles` information within the `appMetadata` dictionary from the `A0UserProfile` object, that's because of what's defined inside the rule. - -## Use the Rule - -At this point, you are able to distinguish the users' roles in your app to authorize or deny access to a certain feature. - -All you have to do here is to replace the `print` statements from the previous step with the instructions you need to execute depending on your business rules. diff --git a/articles/native-platforms/ios-swift/08-calling-apis.md b/articles/native-platforms/ios-swift/08-calling-apis.md deleted file mode 100644 index 3cc1d77fd3..0000000000 --- a/articles/native-platforms/ios-swift/08-calling-apis.md +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: Calling APIs -description: This tutorial will show you how to manage tokens to make authenticated API calls, using NSURLSession. -budicon: 546 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-ios-swift-sample', - path: '08-Calling-APIs', - requirements: [ - 'CocoaPods 1.0.0', - 'XCode 7.3 (7D175)', - 'iPhone 6 - iOS 9.3 (13E230)' - ] -}) %> - -The reason for implementing authentication, in the first place, is to protect information. In this case, your information is a resource served from a server of any sort. Auth0 provides a squad of tools to assist you with end-to-end authentication in an application. We recommend that you conform to RFC standards by sending valid authentication tokens through an authorization header. - -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. - -## Get a Token - -In order to make an authenticated request, you first need to obtain a token, against which your API can compare to detect whether or not the request is properly authenticated. - -You should already know how to get an [A0Token](https://github.com/auth0/Lock.iOS-OSX/blob/master/Lock/Core/A0Token.h) instance from the [login tutorial](/quickstart/native/ios-swift/01-login). Anyway, here's a quick recap: - -```swift -import Lock -``` - -```swift -let controller = A0Lock.shared().newLockViewController() -controller?.onAuthenticationBlock = { profile, token in - // Upon successfull login, you get an A0Token instance - // You will usually save it for later use - controller?.dismiss(animated: true, completion: nil) -} -A0Lock.shared().present(controller, from: self) -``` - -In order to make authenticated requests, you can use any of the token strings inside that `A0Token` instance you just obtained; which one is up to you. - -## Attach the Token - -Supposing you have decided to use the `idToken` value, here is what you would do: - -```swift -let token = ... // The A0Token instance you got upon login -let url = URL(string: "your api url")! -var request = URLRequest(url: url) -// Configure your request here (method, body, etc) -request.addValue("Bearer \(token.idToken)", forHTTPHeaderField: "Authorization") -let task = URLSession.shared.dataTask(with: request) { data, response, error in - // Parse the response -} -``` - -Notice that how you configure your authorization header should match the standards that you're using in your API; this is just an example of what it could look like. - -## Send the Request - -Don't forget to actually send the request you just created, by executing: - -```swift -task.resume() -``` - -### Sample Project Configuration - -When testing the sample project, make sure you configure your URL request in the `ProfileViewController.swift` file: - -```swift -let url = URL(string: "your api url")! -var request = URLRequest(url: url) -// Configure your request here (method, body, etc) -``` - -Once you send a request and your API returns a response, its status code is going to be displayed in an alert view. - -> You can use your own API to test, or, if you want, you can use [this sample server](https://github.com/auth0-samples/auth0-angularjs2-systemjs-sample/tree/master/Server), which is quickly configurable. -> -> For further information on authentication API on the server-side, check [the official documentation](/api/authentication). diff --git a/articles/native-platforms/ios-swift/09-mfa.md b/articles/native-platforms/ios-swift/09-mfa.md deleted file mode 100644 index d5660a825a..0000000000 --- a/articles/native-platforms/ios-swift/09-mfa.md +++ /dev/null @@ -1,123 +0,0 @@ ---- -title: Multifactor Authentication -description: This tutorial will show you how to configure Multi Factor Authentication (MFA) via Google Authenticator in your app. -budicon: 243 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-ios-swift-sample', - path: '09-MFA', - requirements: [ - 'CocoaPods 1.0.0', - 'XCode 7.3 (7D175)', - 'iPhone 6 - iOS 9.3 (13E230)' - ] -}) %> - -## Enable Multifactor Auth in Your Client - -First, you have to enable the MFA feature in your account. Go to the [MFA configuration page](${manage_url}/#/multifactor) and turn the **Google Authenticator** switch on, under the *Choose a Provider* section. - -![MFA Rule Screenshot](/media/articles/mfa/mfa-native/mfa-native-01.png) - -> MFA for native apps currently supports **Google Authenticator** only. - -Then, you have to specify on which clients you want to enable MFA; you accomplish this by editing the snippet that appears below, replacing the placeholder with your actual client ids. - -![MFA Rule Screenshot](/media/articles/mfa/mfa-native/mfa-native-02.png) - -Make sure this line looks like this: - -``` -var CLIENTS_WITH_MFA = ['${account.clientId}']; -``` - -If you want to use MFA in **all** of your clients, the easiest you can do is disabling this conditional in the script: - -```javascript -if (CLIENTS_WITH_MFA.indexOf(context.clientID) !== -1) -``` - -Make sure you hit the **save** button. - -## Configure the Flags - -To enable multifactor authentication and enrollment in your database connection, you must set the `options.mfa.active` and`options.mfa.return_enroll_settings` flags using the `PATCH /api/v2/connections/:id` endpoint. - -First, go to [Database Connections](${manage_url}/#/connections/database) and select the database you want to use MFA on. - -Then, copy the database `id` from the URL of the **Settings** page of your database. It will be in the form: `con_xxxxxxxxxxxxxxxx`. - -![MFA Rule Screenshot](/media/articles/mfa/mfa-native/mfa-native-03.png) - -Also, make sure that your client is enabled for this database: - -![MFA Rule Screenshot](/media/articles/mfa/mfa-native/mfa-native-04.png) - -After that, go to the [**PATCH /api/v2/connections/:id**](/api/management/v2#!/Connections/patch_connections_by_id) endpoint. - -![Patch Connections](/media/articles/mfa/mfa-native/mfa-native-05.png) - -On the top left, select the `connections: update` scope. - -In the `id` field, enter the connection `id` you previously obtained (`con_xxxxxxxxxxxxxxxx`). - -In the `body` field, enter the following: - -```json -{ - "options": { - "mfa": { "active" : true, "return_enroll_settings" : true } -}, - "enabled_clients": [ - "${account.clientId}" - ] -} -``` - -Click **TRY** to call the API and effectively set the flags. You should receive a response similar to this: - -```json -{ - "id": "con_xxxxxxxxxxxxxxxx", - "options": { - "mfa": { - "active": true, - "return_enroll_settings": true - }, - "brute_force_protection": true - }, - "strategy": "auth0", - "name": "Username-Password-Authentication", - "enabled_clients": [ - "YOUR_CLIENT_ID" - ] -} -``` - -## Test Multifactor Auth - -Now, you can run the simulator in your project and sign-in to your Auth0 app with MFA. - -1. In XCode, run your project using the simulator. - -2. Click **Sign-in**: - - ![Simulator](/media/articles/mfa/mfa-native/mfa-native-06.png) - -3. Select a provider (Google in this example): - - ![Simulator](/media/articles/mfa/mfa-native/mfa-native-07.png) - -4. Scan the QR code with Google Authenticator: - - ![Simulator](/media/articles/mfa/mfa-native/mfa-native-08.png) - -5. Enter the code provided by Google Authenticator: - - ![Simulator](/media/articles/mfa/mfa-native/mfa-native-09.png) - -6. You're in! - - ![Simulator](/media/articles/mfa/mfa-native/mfa-native-10.png) diff --git a/articles/native-platforms/ios-swift/10-customizing-lock.md b/articles/native-platforms/ios-swift/10-customizing-lock.md deleted file mode 100644 index 07b618b8e1..0000000000 --- a/articles/native-platforms/ios-swift/10-customizing-lock.md +++ /dev/null @@ -1,188 +0,0 @@ ---- -title: Customizing Lock -description: This tutorial will show you how to customize the Lock widget UI. -budicon: 285 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-ios-swift-sample', - path: '10-Customizing-Lock', - requirements: [ - 'CocoaPods 1.0.0', - 'XCode 7.3 (7D175)', - 'iPhone 6 - iOS 9.3 (13E230)' - ] -}) %> - -## Before Starting - -You need the [Lock](https://github.com/auth0/Lock.iOS-OSX) library integrated in your project. Make sure you've followed the [login tutorial](/quickstart/native/ios-swift/01-login) and you know how to present the login dialog. - -## Create a Theme - -Lock UI can be customized by creating your own `A0Theme` instance: - -```swift -import Lock -``` - -```swift -let theme = A0Theme() -``` - -## Configure the Theme - -Lock's widget UI is composed of several parts that can be customized. - -![Lock.png](/media/articles/libraries/lock-ios/customization/Lock-UI-Parts.png) - -You can configure these type of properties: - -- **Color**: By using a `UIColor` instance. -- **Image**: By using a `String` representing the image's name. -- **Font**: By using a `UIFont` instance. - -For instance: - -``` -theme.register(.red, forKey: A0ThemePrimaryButtonNormalColor); -``` - -So, for example, if you want to achieve something like this: - -
      Mobile example screenshot
      - -You will need to customize several parts... This is how you do it: - -```swift -// 1. Change the logo: -theme.registerImage(withName: "custom-logo", bundle: Bundle.main, forKey: A0ThemeIconImageName) -``` - -```swift -/// 2. Customize the 'Login' text appearance: -theme.register(.white, forKey: A0ThemeTitleTextColor) -theme.register(.systemFont(ofSize: 24, weight: UIFontWeightThin), forKey: A0ThemeTitleFont) -``` - -```swift -// 3. Customize the 'OR' text appearance: -theme.register(.white, forKey: A0ThemeSeparatorTextColor) -theme.register(.systemFont(ofSize: 12, weight: UIFontWeightSemibold), forKey: A0ThemeSeparatorTextFont) -``` - -```swift -// 4. Customize the text fields: -theme.register(.magenta, forKey: A0ThemeTextFieldIconColor) -theme.register(.magenta, forKey: A0ThemeTextFieldPlaceholderTextColor) -theme.register(.white, forKey: A0ThemeTextFieldTextColor) -theme.register(.systemFont(ofSize: 14, weight: UIFontWeightRegular), forKey: A0ThemeTextFieldFont) -``` - -```swift -// 5. Customize the primary button (ACCESS): -theme.register(.white, forKey: A0ThemePrimaryButtonNormalColor) -theme.register(.magenta, forKey: A0ThemePrimaryButtonHighlightedColor) -theme.register(.magenta, forKey: A0ThemePrimaryButtonTextColor) -theme.register(.systemFont(ofSize: 20, weight: UIFontWeightBold), forKey: A0ThemePrimaryButtonFont) -``` - -```swift -// 6. Configure the secondary buttons (sign up / reset password): -theme.register(.magenta, forKey: A0ThemeSecondaryButtonBackgroundColor) -theme.register(.white, forKey: A0ThemeSecondaryButtonTextColor) -``` - -```swift -// 7. Add a background image: -theme.registerImage(withName: "custom-background", bundle: Bundle.main, forKey: A0ThemeScreenBackgroundImageName) -``` - -```swift -// 8. Configure the X button: -theme.register(.magenta, forKey: A0ThemeCloseButtonTintColor) -``` - -```swift -// 9. Configure the status bar: -theme.statusBarStyle = .LightContent -``` - -### 3. Register the Theme - -Last, but not least: You still need to register your theme before presenting the login dialog: - -```swift -A0Theme.sharedInstance().register(theme) -``` - -### Done! - -In conclusion, here is the code snippet you need to keep on mind: - -```swift -let theme = A0Theme() -// customize your theme here -A0Theme.sharedInstance().register(theme) -``` - -### Appendix: Customizable Properties List - -Here is a list containing all the properties that can be customized: - -#### Primary Button - -- `A0ThemePrimaryButtonNormalColor` -- `A0ThemePrimaryButtonHighlightedColor` -- `A0ThemePrimaryButtonNormalImageName` -- `A0ThemePrimaryButtonHighlightedImageName` -- `A0ThemePrimaryButtonFont` -- `A0ThemePrimaryButtonTextColor` - -#### Secondary Button - -- `A0ThemeSecondaryButtonBackgroundColor` -- `A0ThemeSecondaryButtonNormalImageName` -- `A0ThemeSecondaryButtonHighlightedImageName` -- `A0ThemeSecondaryButtonFont` -- `A0ThemeSecondaryButtonTextColor` - -#### Text Field - -- `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` \ No newline at end of file diff --git a/articles/native-platforms/ios-swift/11-api-authorization.md b/articles/native-platforms/ios-swift/11-api-authorization.md deleted file mode 100644 index eba1a5d214..0000000000 --- a/articles/native-platforms/ios-swift/11-api-authorization.md +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: OAuth 2.0 API Authorization -description: This tutorial demonstrates how to use Auth0 to make authorized API calls from your web app. -budicon: 500 ---- - -At some point, your APIs may need to allow limited access to users, servers, or servers on behalf of users. This tutorial demonstrates how to use the [Authorization Code Flow with PKCE](https://auth0.com/docs/api-auth/tutorials/authorization-code-grant-pkce) to give your applications (or third-party applications) limited access to your APIs on behalf of users. For more information, check out [our documentation](https://auth0.com/docs/api-auth). - -<%= include('../../_includes/_compat_warning') %> - -### Before Starting - -## Enable OAuth 2.0 API Authorization - -<%= include('../../_includes/_configure_oauth2aas') %> - -## Create an Application - -<%= include('../_includes/_new_app_no_sample') %> - -![App Dashboard](/media/articles/native-platforms/native-app-client.png) - -Be sure to register the URL of your app in the Allowed Callback URLs in your Client Settings. - -## Create a Resource Server (API) - -<%= include('../../_includes/_new_api') %> - -![Create API](/media/articles/api-auth/api-5.png) -![Update Scopes](/media/articles/api-auth/api-6.png) - -Take note of the API Identifier and Scopes you defined in the Dashboard, as they will be used later. - -<%= include('./_includes/_api_authz') %> diff --git a/articles/native-platforms/ios-swift/_includes/_api_authz.md b/articles/native-platforms/ios-swift/_includes/_api_authz.md deleted file mode 100644 index f37cf9d3a2..0000000000 --- a/articles/native-platforms/ios-swift/_includes/_api_authz.md +++ /dev/null @@ -1,138 +0,0 @@ -## Configuring Your Application - -## Dependences - -This quickstart uses the Auth0.swift SDK to help you add authentication and API authorization to your iOS app. You will need to add this dependency to your project. - -#### Carthage - -If you are using Carthage, add the following lines to your `Cartfile`: - -```ruby -github "auth0/Auth0.swift" "~> 1.1" -``` - -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 - -If you are using [Cocoapods](https://cocoapods.org/), add these lines to your `Podfile`: - -```ruby -use_frameworks! -pod 'Auth0', '~> 1.1' -``` - -Then, run `pod install`. - -> For further reference on Cocoapods, check [their official documentation](http://guides.cocoapods.org/using/getting-started.html). - -## Configuration - -First, add a `Auth0.plist` file to your main bundle. This should contain the ClientId and Domain from your Auth0 tenant configuration: - -```xml - - - - - ClientId - {YOUR_CLIENT_ID} - Domain - {YOUR_DOMAIN} - - -``` - -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) - - - -``` - -Finally, open the Dashboard and make sure the Allowed Callback URLs for your client contains a URL with the following format: - -`{YOUR_BUNDLE_IDENTIFIER}://{YOUR_AUTH0_DOMAIN}/ios/{YOUR_BUNDLE_IDENTIFIER}/callback` - -## Initiate Authentication and Authorization - -Your Swift application will need to use Auth0.swift to kick off the OAuth flow using the code below: - -```swift -@IBAction func startAuthentication(sender: AnyObject?) { - -let params = [ - "audience":"{YOUR AUDIENCE}", - "scope":"{YOUR SCOPES}" - ] - -Auth0 - .webAuth - .parameters(params) - .start( { result in - switch result { - case .success(let credentials): - DispatchQueue.main.async { - // here you have the access token, id token - // and (optionally) refresh token available to your app - // credentials.accessToken - // credentials.idToken - // credentials.refreshToken - } - case .failure(let error): - print(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 add the following method to your application's `AppDelegate`: - -```swift -func application(_ app: UIApplication, open url: URL, options: [UIApplicationOpenURLOptionsKey : Any] = [:]) -> Bool { - return Auth0.resumeAuth(url, options:options) -} -``` - -## Making an Authenticated API Call - -Use the `access_token` to invoke your Resource Server (API): - -```swift -let accessToken = "{ACCESS_TOKEN}" -let headers = [ - "Content-Type": "application/json", - "Authorization": "Bearer \(accessToken)" -] - -let apiUrl = NSURL(string: "https://someapi.com/api")! -var request = URLRequest(url: apiUrl, cachePolicy: .useProtocolCachePolicy, timeoutInterval: 10.0) -request.httpMethod = "POST" -request.allHTTPHeaderFields = headers - -let session = URLSession.shared -let dataTask = session.dataTask(with: request) { data, response, error in - guard error != nil else { return print(error) } - guard let httpResponse = response as? HTTPURLResponse else { return } - print(httpResponse) -} - -``` - -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/native-platforms/ios-swift/_includes/_compat_warning.md b/articles/native-platforms/ios-swift/_includes/_compat_warning.md deleted file mode 100644 index 8ea32957af..0000000000 --- a/articles/native-platforms/ios-swift/_includes/_compat_warning.md +++ /dev/null @@ -1,3 +0,0 @@ -::: panel-warning Compatability Warning -The OAuth2 API Authorization quickstart tutorial uses new OAuth2 as a Service features in Auth0. As a result, not everything is fully backwards compatible, including native Lock. This quickstart tutorial uses Auth0 hosted Lock instead. -::: diff --git a/articles/native-platforms/ios-swift/_includes/_config.md b/articles/native-platforms/ios-swift/_includes/_config.md deleted file mode 100644 index b3e1418412..0000000000 --- a/articles/native-platforms/ios-swift/_includes/_config.md +++ /dev/null @@ -1,36 +0,0 @@ -## 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. - -That being said, go to your [Client's Dashboard](${manage_url}/#/applications/${account.clientId}/settings) and make sure that *Allowed Callback URLs* contains the following: -```shell - ${account.clientId}://\*.auth0.com/authorize -``` - -## Set Credentials - -The [dependencies](#dependencies) listed above requires that you set your credentials in two different `.plist` files in order for them to work. If you downloaded the seed project, or 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. - -You can add the following entries in your project's `Info.plist`: - -```xml -Auth0ClientId -${account.clientId} -Auth0Domain -${account.namespace} -``` - -Alternatively you can add your credentials in `Auth0.plist`. You have to create that file if it doesn't already exist: - -```xml - - - - - ClientId - ${account.clientId} - Domain - ${account.namespace} - - -``` diff --git a/articles/native-platforms/ios-swift/_includes/_login.md b/articles/native-platforms/ios-swift/_includes/_login.md deleted file mode 100644 index 7435f7f849..0000000000 --- a/articles/native-platforms/ios-swift/_includes/_login.md +++ /dev/null @@ -1,45 +0,0 @@ -## 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 login screen, like this: - -```swift -let controller = A0Lock.shared().newLockViewController() -controller?.closable = true -controller?.onAuthenticationBlock = { profile, token in - // Do something with token profile. e.g.: save them. - // Lock will not save these objects for you. - - // Don't forget to dismiss the Lock controller - controller?.dismiss(animated: true, completion: nil) -} -A0Lock.shared().present(controller, from: self) -``` - -[![Lock.png](/media/articles/native-platforms/ios-swift/Lock-Widget-Screenshot.png)](https://auth0.com) - -> 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](/libraries/lock-ios/use-your-own-ui). -> You can also try our passwordless Login Widgets: [SMS](/libraries/lock-ios#sms) or [TouchID](/libraries/lock-ios#touchid). - -As you can see, upon successful authentication, the `onAuthenticationBlock` callback will yield the user's `profile` and `token`. - -A basic example of how to use this information: - -```swift -self.usernameLabel.text = profile.name -self.emailLabel.text = profile.email -MyApplication.sharedInstance.accessToken = token.accessToken -``` - -> For further reference on the `profile` and `token` objects, check the [A0UserProfile](https://github.com/auth0/Lock.iOS-OSX/blob/master/Lock/Core/A0UserProfile.h) and [A0Token](https://github.com/auth0/Lock.iOS-OSX/blob/master/Lock/Core/A0Token.h) classes' documentation. -> -> To learn how to save and manage the tokens and profile in detail, please read [this guide](/libraries/lock-ios/save-and-refresh-jwt-tokens). Notice that Lock on its own will not save the tokens and profile for you. - -### Optional: Log In with Social Connections - -In order to have a simple login mechanism through social connections, all you have to do is enable them in your account's [connections dashboard](${manage_url}/#/connections/social). Every social connection you switch on there, will appear in the Login screen of your app. That's pretty much it! \ No newline at end of file diff --git a/articles/native-platforms/ios-swift/_includes/_prerequisite.md b/articles/native-platforms/ios-swift/_includes/_prerequisite.md deleted file mode 100644 index 2f4614dca1..0000000000 --- a/articles/native-platforms/ios-swift/_includes/_prerequisite.md +++ /dev/null @@ -1,7 +0,0 @@ -::: panel-info System Requirements -These tutorials and seed projects have been tested with the following: - -* CocoaPods 1.0.0 -* XCode 7.3 (7D175) -* iPhone 6 - iOS 9.3 (13E230) - ::: \ No newline at end of file diff --git a/articles/native-platforms/ios-swift/dashboard-default.md b/articles/native-platforms/ios-swift/dashboard-default.md deleted file mode 100644 index ad1b44aac4..0000000000 --- a/articles/native-platforms/ios-swift/dashboard-default.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Login -default: true -description: This tutorial demonstrates how to integrate Lock in your iOS Swift project in order to present a login screen. ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-ios-swift-sample', - path: '01-Login', - requirements: [ - 'CocoaPods 1.0.0', - 'XCode 7.3 (7D175)', - 'iPhone 6 - iOS 9.3 (13E230)' - ] -}) %> - -<%= include('_includes/_prerequisite') %> - -<%= include('_includes/_config') %> - -<%= include('_includes/_login') %> \ No newline at end of file diff --git a/articles/native-platforms/ios-swift/index.yml b/articles/native-platforms/ios-swift/index.yml deleted file mode 100644 index 309dc61fe4..0000000000 --- a/articles/native-platforms/ios-swift/index.yml +++ /dev/null @@ -1,25 +0,0 @@ -title: iOS-Swift -alias: - - ios - - swift -language: - - Swift -framework: - - Swift -image: /media/platforms/ios.png -tags: - - quickstart -seo_alias: swift -default_article: dashboard-default -articles: - - 00-introduction - - 01-login - - 02-custom-login - - 03-session-handling - - 04-user-profile - - 05-linking-accounts - - 06-rules - - 07-authorization - - 08-calling-apis - - 09-mfa - - 10-customizing-lock diff --git a/articles/native-platforms/phonegap/01-login.md b/articles/native-platforms/phonegap/01-login.md deleted file mode 100644 index 589110b588..0000000000 --- a/articles/native-platforms/phonegap/01-login.md +++ /dev/null @@ -1,106 +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: '00-Starter-Seed/phonegap-basic-sample', - requirements: [ - 'NodeJS 4.3', - 'Phonegap 5.5' - ] -}) %> - -### 1. Setting up the callback URL in Auth0 - -
      -

      Go to the Client 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: - -${snippet(meta.snippets.dependencies)} - -> **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](/client-platforms/jquery), [AngularJS](/client-platforms/angularjs) and [Vanilla JS](/client-platforms/vanillajs). - -> **Warning**: 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. - -> **Warning**: 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/native-platforms/phonegap/index.yml b/articles/native-platforms/phonegap/index.yml deleted file mode 100644 index 47f61e33e7..0000000000 --- a/articles/native-platforms/phonegap/index.yml +++ /dev/null @@ -1,20 +0,0 @@ -title: Phonegap -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/native-platforms/react-native-android/01-login.md b/articles/native-platforms/react-native-android/01-login.md deleted file mode 100644 index 0afd3240a6..0000000000 --- a/articles/native-platforms/react-native-android/01-login.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -title: Login -default: true -description: This tutorial demonstrates how to use the Auth0 React Native Android SDK to add authentication and authorization to your mobile app -budicon: 448 ---- - -<%= include('../../_includes/_package', { - org: 'auth0', - repo: 'Mobile-Samples.React', - path: 'Classic/Lock', - requirements: [ - 'NodeJS 6.5.0', - 'react-native-lock 0.4.0', - 'rnpm 1.9.0' - ] -}) %> - -## Install Lock - -First, you need to run the following command to install **react-native-lock** - -```bash -npm install --save react-native-lock -``` - -Then, install [rnpm](https://github.com/rnpm/rnpm) - -```bash -npm install rnpm -g -``` - -After that, link **react-native-lock** with your Android project: - -```bash -rnpm link react-native-lock -``` - -Open the file `android/app/build.gradle` and inside add the following into the `android {}` section - -```gradle -packagingOptions { - exclude 'META-INF/LICENSE' - exclude 'META-INF/NOTICE' -} -``` - -Then, check in `AndroidManifest.xml` that the application requests the `android.permission.INTERNET` permission. If is not already there, add it inside the `` tag: - -```xml - -``` - -And finally, you must add the following entries inside the `` tag of the same file: - -```xml - - - - - - - - - - - - - - -``` - -> If you need Facebook or Google+ native authentication please continue reading to learn how to configure them. Otherwise please go directly to **[Showing User Information](#showing-user-information)**. - -## Implement the login - -Now we're ready to implement the Login. First we need to require react-native-lock-android: - -${snippet(meta.snippets.setup)} - -Then, we can show **Lock**: - -${snippet(meta.snippets.use)} - -[![Lock.png](/media/articles/native-platforms/reactnative-android/Lock-Widget-Screenshot.png)](https://auth0.com) - -> **Note**: There are multiple ways of implementing the login box. What you see above is the Login Widget, but you can try our passwordless Login Widgets: [SMS](https://github.com/auth0/react-native-lock) or [Email](https://github.com/auth0/react-native-lock) - -On successful authentication, the callback function will yield the user's profile and tokens inside the parameters `profile` and `token` respectively. - -## Showing User Information - -After the user has logged in, we can use the `profile` object which has all the user information (Let's assume the profile is stored in a component's state object): - -```jsx - Welcome {this.state.profile.name} - Your email is: {this.state.profile.email} -``` - -> You can find all of the available properties for the user's profile [here](/user-profile). Please note that some of these depend on the social provider being used. - -### FAQ - -#### Error: duplicate files during packaging of APK - -If you observe an error like this when trying to run the project: - -``` -Error: duplicate files during packaging of APK //android/app/build/outputs/apk/app-debug-unaligned.apk - Path in archive: META-INF/NOTICE - Origin 1: //.gradle/caches/modules-2/files-2.1/com.fasterxml.jackson.core/jackson-databind/2.4.1/f07c773f7b3a03c3801d405cadbdc93f7548e321/jackson-databind-2.4.1.jar - Origin 2: //.gradle/caches/modules-2/files-2.1/com.fasterxml.jackson.core/jackson-core/2.4.1/b130bcfb5a9c410c3cbd2e0adec9437e69a39e2c/jackson-core-2.4.1.jar -You can ignore those files in your build.gradle: - android { - packagingOptions { - exclude 'META-INF/NOTICE' - } - } -:app:packageDebug FAILED -``` - -You must follow the advice and ignore the files adding the following to the `build.gradle` of the `app` module, inside the `android` section: - -``` -packagingOptions { - exclude 'META-INF/LICENSE' - exclude 'META-INF/NOTICE' -} -``` diff --git a/articles/native-platforms/react-native-android/index.yml b/articles/native-platforms/react-native-android/index.yml deleted file mode 100644 index e2f0515192..0000000000 --- a/articles/native-platforms/react-native-android/index.yml +++ /dev/null @@ -1,19 +0,0 @@ -title: React Native - Android -alias: - - reactnative - - react native -language: - - Javascript -framework: - - React Native -hybrid: true -image: /media/platforms/react.png -tags: - - quickstart -snippets: - setup: native-platforms/reactnative-android/setup - use: native-platforms/reactnative-android/use -seo_alias: react-native-android -default_article: 01-login -articles: - - 01-login diff --git a/articles/native-platforms/react-native-ios/01-login.md b/articles/native-platforms/react-native-ios/01-login.md deleted file mode 100644 index 424d82e9f9..0000000000 --- a/articles/native-platforms/react-native-ios/01-login.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: Login -default: true -description: This tutorial demonstrates how to use the Auth0 React Native iOS SDK to add authentication and authorization to your mobile app. -budicon: 448 ---- - -<%= include('../../_includes/_package', { - org: 'auth0', - repo: 'Mobile-Samples.React', - path: 'Classic/Lock', - requirements: [ - 'React Native 0.26.0', - 'CocoaPods 1.0.0', - 'NodeJS 4.3' - ] -}) %> - -## CocoaPods - -You'll need CocoaPods in order to fetch **Lock** native libraries dependencies for you and link them to your project. - -To install CocoaPods just run the following command: - -```bash -gem install cocoapods -``` - -> If you need help installing CocoaPods, please check this [guide](http://guides.cocoapods.org/using/getting-started.html) - -## Adding Lock - -First you need to run the following command to install **react-native-lock** - -```bash -npm install --save react-native-lock -``` - -Then install [rnpm](https://github.com/rnpm/rnpm) - -```bash -npm install rnpm -g -``` - -After that, link **react-native-lock** with your iOS project: - -```bash -rnpm link react-native-lock -``` - -If you get the following warning. - -``` -!] The ` [Debug]` target overrides the `OTHER_LDFLAGS` build setting defined in `Pods/Target Support Files/Pods/Pods.debug.xcconfig'. This can lead to problems with the CocoaPods installation - - Use the `$(inherited)` flag, or - - Remove the build settings from the target. - -[!] The ` [Release]` target overrides the `OTHER_LDFLAGS` build setting defined in `Pods/Target Support Files/Pods/Pods.release.xcconfig'. This can lead to problems with the CocoaPods installation - - Use the `$(inherited)` flag, or - - Remove the build settings from the target. -``` - -Click `.xcodeproj` in the project navigator and go the `Build Settings` tab. Make sure 'All' is toggled on (instead of 'Basic'). Look for `Other Linker Flags` and add the value `$(inherited)` for **all** configurations . - -Another error you might have while trying to run the project, if you are using a `react-native` version `>=0.26.0` - -``` -"std::terminate()", referenced from: - ___clang_call_terminate in libReact.a(RCTJSCExecutor.o) -``` - -To solve it, click `.xcodeproj` in the project navigator and go the `Build Settings` tab. Make sure 'All' is toggled on (instead of 'Basic'). Look for `Other Linker Flags` and add the flag `-lc++` for **all** configurations . - -## Implement the Login - -Now we're ready to implement the Login. First we need to require react-native-lock-ios: - -${snippet(meta.snippets.setup)} - -Then we can show **Lock**: - -${snippet(meta.snippets.use)} - -[![Lock.png](/media/articles/native-platforms/reactnative-ios/Lock-Widget-Screenshot.png)](https://auth0.com) - -> **Note**: There are multiple ways of implementing the login box. What you see above is the Login Widget, but you can try our passwordless Login Widgets: [SMS](https://github.com/auth0/react-native-lock-ios#sms-passwordless), [Email](https://github.com/auth0/react-native-lock-ios#email-passwordless) or [TouchID](https://github.com/auth0/react-native-lock#touchid-ios-only) - -On successful authentication, the callback function will yield the user's profile and tokens inside the parameters `profile` and `token` respectively. - -## Showing User Information - -After the user has logged in, we can use the `profile` object which has all the user information (Let's assume the profile is stored in a component's state object): - -```jsx - Welcome {this.state.profile.name} - Your email is: {this.state.profile.email} -``` - -> You can [click here](/user-profile) to find out all of the available properties from the user's profile. Please note that some of this depend on the social provider being used. \ No newline at end of file diff --git a/articles/native-platforms/react-native-ios/index.yml b/articles/native-platforms/react-native-ios/index.yml deleted file mode 100644 index accd35cc76..0000000000 --- a/articles/native-platforms/react-native-ios/index.yml +++ /dev/null @@ -1,19 +0,0 @@ -title: React Native - iOS -alias: - - reactnative - - react native -language: - - Javascript -framework: - - React Native -hybrid: true -image: /media/platforms/react.png -tags: - - quickstart -snippets: - setup: native-platforms/reactnative-ios/setup - use: native-platforms/reactnative-ios/use -seo_alias: react-native-ios -default_article: 01-login -articles: - - 01-login diff --git a/articles/native-platforms/windows-uwp-csharp/01-login.md b/articles/native-platforms/windows-uwp-csharp/01-login.md deleted file mode 100644 index e2a844df09..0000000000 --- a/articles/native-platforms/windows-uwp-csharp/01-login.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: Login -default: true -description: This tutorial will show you how to use the Auth0 Windows Universal App C# SDK to add authentication and authorization to your app. -budicon: 448 ---- - -<%= include('../../_includes/_package', { - org: 'auth0', - repo: 'Auth0.Windows.UWP', - path: 'samples/LoginClientSample.Cs', - requirements: [ - 'Microsoft Visual Studio 2015', - 'Windows 10 SDK (10.0.14393)' - ] -}) %> - -This tutorial explains how to integrate Auth0 login with a Windows UWP (Universal Windows Platform) C# application. The Nuget package `Auth0.Windows.UWP` helps you authenticate users with any [Auth0 supported identity provider](/identityproviders). - -## Install the Auth0.Windows.UWP NuGet Package - -Use the NuGet Package Manager Console (Tools -> Nuget Package Manager -> Package Manager Console) to install the Auth0.Windows.UWP package, running the command: - -${snippet(meta.snippets.dependencies)} - -## Set Up the Auth0 Callback URL - -
      -

      Go to the Client Settings section in the Auth0 dashboard and make sure that Allowed Callback URLs contains the following value:

      - -
      https://${account.namespace}/mobile
      -
      - -## Integration -There are three options to do the integration: - -1. Using the [Auth0 Login Widget](/libraries/lock) with the Web Authentication Broker (this is the simplest with only a few lines of code required). -2. Using the [Auth0 Login Widget](/libraries/lock) with the Web Authentication Broker, but specifying a specific Connection. -3. A custom user interface to ask username and password. - -### Option 1: Auth0 Lock - -To start, we recommend using the __Login Widget__. Here is a snippet of code to copy & paste on your project. -Since we are using `await` (.NET 4.5 or greater), your method needs to be `async`: - -${snippet(meta.snippets.setup)} - -${snippet(meta.snippets.use)} - -![](/media/articles/native-platforms/windows-uwp-csharp/lock-widget-screenshot.png) - -### Option 2: Auth0 Lock with a Specific Connection - -If you know which identity provider you want to use, you can add a `connection` parameter and the user will be sent straight to the specified `connection`: - -```cs -var user = await auth0.LoginAsync("auth0waadtests.onmicrosoft.com") // connection name here -``` - -> connection names can be found on Auth0 dashboard. E.g.: `facebook`, `linkedin`, `somegoogleapps.com`, `saml-protocol-connection`, etc. - -### Option 3: Custom User Interface - -The third option is to create your own custom user interface to prompt the user for their username and password. You can then pass this, along with the connection name to the `LoginAsync` method: - -```cs -var user = await auth0.LoginAsync( - "my-db-connection", // connection name here - "username", - "password"); -``` - -### Scope - -Optionally you can specify the `scope` parameter. There are various possible values 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. -* __scope: "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"`). - -You can get more information about this in the [Scopes documentation](/scopes). - -## Capabilities (Optional) - -In some cases, Auth0 may not be able to connect to an identity provider. Showing nothing more than a "Can't connect to the service" message. A reason for this may be that the identity provider endpoint resolves to an Intranet (that has an authenticated domain controller), home or work network. In this case it is required to enable the "Private Networks (Client & Server)" capability. - -Use the Package Manifest (Solution Explorer > Package.appxmanifest) to enable the capability within the "Capabilities" tab. - -## Accessing User Information - -The `Auth0User` has the following properties: - -* `Profile`: returns a `Newtonsoft.Json.Linq.JObject` object (from [Json.NET component](http://www.newtonsoft.com/json)) containing all available user attributes (e.g.: `user.Profile["email"].ToString()`). -* `IdToken`: is a Json Web Token (JWT) containing all of the user attributes and it is signed with your client secret. This is useful to call your APIs and flow the user identity. -* `Auth0AccessToken`: the `access_token` that can be used to access Auth0's APIs. For example, you could use this token to [Link Accounts](/link-accounts). diff --git a/articles/native-platforms/windows-uwp-csharp/index.yml b/articles/native-platforms/windows-uwp-csharp/index.yml deleted file mode 100644 index 5dd02cf6f4..0000000000 --- a/articles/native-platforms/windows-uwp-csharp/index.yml +++ /dev/null @@ -1,19 +0,0 @@ -title: Windows Universal App C# -community: true -hybrid: false -alias: - - windows app - - windows -language: - - C# -image: /media/platforms/windows-8.png -tags: - - quickstart -snippets: - dependencies: native-platforms/windows-uwp-csharp/dependencies - setup: native-platforms/windows-uwp-csharp/setup - use: native-platforms/windows-uwp-csharp/use -seo_alias: windows-uwp-csharp -default_article: 01-login -articles: - - 01-login diff --git a/articles/native-platforms/windows-uwp-javascript/01-login.md b/articles/native-platforms/windows-uwp-javascript/01-login.md deleted file mode 100644 index e06bd37c65..0000000000 --- a/articles/native-platforms/windows-uwp-javascript/01-login.md +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: Login -default: true -description: This tutorial will show you how to use the Auth0 Windows Universal App Javascript SDK to add authentication and authorization to your app. -budicon: 448 ---- - -<%= include('../../_includes/_package', { - org: 'auth0', - repo: 'Auth0.Windows.UWP', - path: 'samples/LoginClientSample.Js', - requirements: [ - 'Microsoft Visual Studio 2015', - 'Windows 10 SDK (10.0.14393)' - ] -}) %> - -This tutorial explains how to integrate Auth0 with a Windows UWP application written in JavaScript. `Auth0.Windows.UWP.JavaScript` helps you authenticate users with any [Auth0 supported Identity Provider](/identityproviders). - -## Install Auth0.Windows.UWP.JavaScript NuGet Package - -Use the NuGet Package Manager Console (Tools > Nuget Package Manager > Package Manager Console) to install the Auth0.Windows.UWP.JavaScript package by running the command: - -${snippet(meta.snippets.dependencies)} - -Also, add reference to the JavaScript code in the `default.html`, by including the following line in the `` element: - -${snippet(meta.snippets.setup)} - -## Set up the Auth0 Callback URL - -Go to the [Client Settings](${manage_url}/#/applications/${account.clientId}/settings) section of the Auth0 Admin app and make sure that **App Callbacks URLs** has the following value: - -`https://${account.namespace}/mobile` - -### 3. Integration -There are three options for implementing the integration: - -1. Use [Auth0 Lock](/libraries/lock) with the Web Authentication Broker - the simplest method with only a few lines of code required. -2. Use [Auth0 Lock](/libraries/lock) with the Web Authentication Broker with a specific Connection. -3. Build a custom user interface to ask for username and password. - -### Option 1: Auth0 Lock - -Lock is the recommended option. - -Here is a snippet of code to paste into your project: - -${snippet(meta.snippets.use)} - -![](/media/articles/native-platforms/windows-uwp-javascript/lock-widget-screenshot.png) - - -### Option 2: Auth0 Lock with a Specific Connection - -If you know which identity provider you want to use, you can add the `connection` parameter and the user will be directed to the specified `connection`: - -```javascript -auth0.Login({ connection: "auth0waadtests.onmicrosoft.com" }, function (err, result) { - if (err) return err; - /* - Use result to do wonderful things, e.g.: - - get user email => result.Profile.email - - get Windows Azure AD groups => result.Profile.groups - - etc. - */ -}); -``` - -**NOTE:** Connection names can be found on Auth0 dashboard (e.g. `facebook`, `linkedin`, `saml-protocol-connection`). - -### Option 3: Custom User Interface - -The third option is to create your own custom user interface to prompt the user for their username and password. You can then pass these credentials, along with the connection name, to the `LoginAsync` method: - -```javascript -auth0.Login({ - connection: "my-db-connection", - username: "username", - password: "password" - }, - function (err, result) { - if (err) return err; - /* - Use result to do wonderful things, e.g.: - - get user email => result.Profile.email - - get Windows Azure AD groups => result.Profile.groups - - etc. - */ - }); -``` - -#### Scope - -Optionally you can specify the `scope` parameter. There are two possible values for scope: - -* __scope: "openid"__ _(default)_ - this returns the `access_token`, and an `id_token` as a JSON Web Token (JWT). The JWT will only contain the user id. -* __scope: "openid {attr1} {attr2} {attrN}"__ - if you want only specific user attributes to be included in the `id_token` (for example: `scope: "openid name email picture"`). - -For more information, see: [Scopes](/scopes). - -## Accessing User Information - -The `Auth0User` has the following properties: - -* `Profile`: returns a `Newtonsoft.Json.Linq.JObject` object from [Json.NET component](http://www.newtonsoft.com/json) containing all available user attributes (e.g.:`user.Profile["email"].ToString()`). -* `IdToken`: a JSON Web Token (JWT) containing all of the user attributes and signed with your client secret. - -* `Auth0AccessToken`: the `access_token` that can be used to call the Auth0 API. For example, you could use this token to [Link Accounts](/link-accounts). diff --git a/articles/native-platforms/windows-uwp-javascript/index.yml b/articles/native-platforms/windows-uwp-javascript/index.yml deleted file mode 100644 index 96eeba30bf..0000000000 --- a/articles/native-platforms/windows-uwp-javascript/index.yml +++ /dev/null @@ -1,22 +0,0 @@ -title: Windows Universal App Javascript -community: true -hybrid: false -language: - - Javascript -image: /media/platforms/windows-8.png -tags: - - quickstart -snippets: - dependencies: native-platforms/windows-uwp-javascript/dependencies - setup: native-platforms/windows-uwp-javascript/setup - use: native-platforms/windows-uwp-javascript/use -alias: - - windows app - - windows - - windows-10 - - windows-tablet - - surface -seo_alias: windows-uwp-javascript -default_article: 01-login -articles: - - 01-login diff --git a/articles/native-platforms/windowsphone/01-login.md b/articles/native-platforms/windowsphone/01-login.md deleted file mode 100644 index 6b54a905dd..0000000000 --- a/articles/native-platforms/windowsphone/01-login.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: Login -default: true -description: This tutorial will show you how to use the Auth0 Windows Phone SDK to add authentication and authorization to your mobile app. -budicon: 448 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-WindowsPhone-samples', - path: '00-Starter-Seed/WindowsPhoneSilverlight', - requirements: [ - 'Microsoft Visual Studio 2015', - 'Auth0.WindowsPhone 1.4.1' - ] -}) %> - - - -### 1. Install the Auth0.WindowsPhone package - -You can either run the following command or install it via the **Package Manager** UI. - -${snippet(meta.snippets.dependencies)} - -### 2. Setting up the callback URL in Auth0 - -
      -

      Go to the Client Settings section in the Auth0 dashboard and make sure that the Allowed Callback URLs list contains the following value:

      - -
      https://${account.namespace}/mobile
      -
      - -### 3. Instantiate the Auth0 client - -${snippet(meta.snippets.setup)} - -### 4. Allow users to log in - -${snippet(meta.snippets.use)} - -### 5. Use server API if necessary: - -```cs -var client = new HttpClient(); - -// Accessing public resource -var response = await client.GetAsync(new Uri("{YOUR API URL}/{PUBLIC RESOURCE}")); - -// Accessing secured resource -// Initialize HTTP request message -var message = new HttpRequestMessage(HttpMethod.Get, new Uri("{YOUR API URL}/{SECURED RESOURCE}")); -// Add header so that server can recognize logged in user -message.Headers.Add("Authorization", "Bearer " + App.Auth0.CurrentUser.IdToken); -response = await client.SendRequestAsync(message); -``` - -### 6. Sit back and relax - -Now it's time to sit back and relax. You've implemented login and signup with Auth0 for your Windows Phone application. - - -### Additional information -You can also check out the [Github page](https://github.com/auth0/auth0.windowsphone) access the source code, and additional documentation. diff --git a/articles/native-platforms/windowsphone/index.yml b/articles/native-platforms/windowsphone/index.yml deleted file mode 100644 index 85fa58345a..0000000000 --- a/articles/native-platforms/windowsphone/index.yml +++ /dev/null @@ -1,23 +0,0 @@ -title: Windows Phone -community: true -language: - - Javascript - - C# -hybrid: false -image: /media/platforms/windows-phone.png -tags: - - quickstart -snippets: - dependencies: native-platforms/windows-phone/dependencies - setup: native-platforms/windows-phone/setup - use: native-platforms/windows-phone/use -alias: - - win8 - - wp8 - - windows-phone - - windows-phone-8 - - microsoft-phone -seo_alias: windowsphone -default_article: 01-login -articles: - - 01-login diff --git a/articles/native-platforms/wpf-winforms/01-login.md b/articles/native-platforms/wpf-winforms/01-login.md deleted file mode 100644 index 9dfb365130..0000000000 --- a/articles/native-platforms/wpf-winforms/01-login.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: Login -default: true -description: This tutorial will show you how to use the Auth0 WPF and Winforms SDK to add authentication and authorization to your app. -budicon: 448 ---- - -<%= include('../../_includes/_package', { - org: 'auth0-samples', - repo: 'auth0-winformsWPF-samples', - path: '00-Starter-Seed', - requirements: [ - 'Microsoft Visual Studio 2015', - '.NET Framework 4.6.1' - ] -}) %> - -This tutorial explains how to integrate Auth0 with a WPF or Winforms application. `Auth0.WinformsOrWPF` helps you authenticate users with any [Auth0 supported identity provider](/identityproviders). - -## Install Auth0.WinformsOrWPF NuGet Package - -Use the NuGet Package Manager (Tools -> Library Package Manager -> Package Manager Console) to install the Auth0.WinformsOrWPF package, running the command: - -${snippet(meta.snippets.dependencies)} - -## Set up the Auth0 Callback URL - -
      -

      Go to the Clients Settings section in the Auth0 dashboard and make sure that Allowed Callback URLs contains the following value:

      - -
      https://${account.namespace}/mobile
      -
      - -## Integration - -There are three options to do the integration: - -1. Using [Auth0 Lock](/lock) inside a Web View (this is the simplest way with only a few lines of code required). -2. Creating your own UI (more work, but higher control of the UI and overall experience). -3. Using specific username and password. - -### Option 1: Auth0 Lock - -To start, we recommend using __Lock__. Here is a snippet of code to copy & paste on your project. -Since we are using `await` (.NET 4.5 or greater), your method needs to be `async`: - -${snippet(meta.snippets.setup)} - -${snippet(meta.snippets.use)} - -![](/media/articles/native-platforms/wpf-winforms/wpf-winforms-step1.png) - -::: panel-warning Handle Exceptions -**Please note** that an `UnauthorizedAccessException` will be thrown when the user cancels the authentication dialog, so you will need to wrap the call to `LoginAsync` in a try-catch block. -::: - -::: panel-warning WPF Applications -For __WPF__ apps you should use `auth0.LoginAsync(new WindowWrapper(new WindowInteropHelper(this).Handle))` instead of `auth0.LoginAsync(this)` -::: - -### Option 2: Custom User Interface - -If you know which identity provider you want to use, you can add a `connection` parameter and the user will be sent straight to the specified `connection`: - -```cs -var user = await auth0.LoginAsync(this, "auth0waadtests.onmicrosoft.com") // connection name here -``` - -> connection names can be found on Auth0 dashboard. E.g.: `facebook`, `linkedin`, `somegoogleapps.com`, `saml-protocol-connection`, etc. - -### Option 3: Specific Username and Password - -```cs -var user = await auth0.LoginAsync( - "my-db-connection", // connection name here - "username", - "password"); -``` - -## Accessing User Information - -The `Auth0User` has the following properties: - -* `Profile`: returns a `Newtonsoft.Json.Linq.JObject` object (from [Json.NET component](http://components.xamarin.com/view/json.net/)) containing all available user attributes (e.g.: `user.Profile["email"].ToString()`). -* `IdToken`: is a Json Web Token (JWT) containing all of the user attributes and it is signed with your client secret. This is useful to call your APIs and flow the user identity. -* `Auth0AccessToken`: the `access_token` that can be used to access Auth0's API. You would use this, for example, to [link user accounts](/link-accounts). diff --git a/articles/native-platforms/wpf-winforms/index.yml b/articles/native-platforms/wpf-winforms/index.yml deleted file mode 100644 index 0a241b0b03..0000000000 --- a/articles/native-platforms/wpf-winforms/index.yml +++ /dev/null @@ -1,25 +0,0 @@ -title: WPF / Winforms -community: true -hybrid: false -language: - - Javascript - - C# -framework: - - WPF - - WinForms -image: /media/platforms/asp.png -tags: - - quickstart -snippets: - dependencies: native-platforms/wpf-winforms/dependencies - setup: native-platforms/wpf-winforms/setup - use: native-platforms/wpf-winforms/use -alias: - - wpf - - wiforms - - rich-client-application - - rich-client -seo_alias: wpf-winforms -default_article: 01-login -articles: - - 01-login diff --git a/articles/native-platforms/xamarin/01-login.md b/articles/native-platforms/xamarin/01-login.md deleted file mode 100644 index c8fd2e6f57..0000000000 --- a/articles/native-platforms/xamarin/01-login.md +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: Login -default: true -description: This tutorial will show you how to use the Auth0 Xamarin SDK to add authentication and authorization to your mobile app. -budicon: 448 ---- - -::: panel-info System Requirements -This tutorial has been tested with the following: -* Microsoft Visual Studio 2015 -* Xamarin for Visual Studio 4.2 -::: - - - -This tutorial explains how to integrate Auth0 with a Xamarin application. - -The `Xamarin.Auth0Client` helps you authenticate users with any [Auth0 supported identity provider](/identityproviders) via the OpenId Connect protocol built on top of OAuth2. The library is cross-platform, so this information can be applied to either iOS or Android. - -**NOTE:** An Objective-C Binding Library for Lock iOS implementations is available at: [Lock.Xamarin](https://github.com/auth0/Lock.Xamarin). - -## Install Xamarin.Auth0Client Component - -${snippet(meta.snippets.dependencies)} - -For more information, see: [How to include a Component in a Xamarin Project](http://docs.xamarin.com/guides/cross-platform/application_fundamentals/components_walkthrough). - -## Set up the Auth0 Callback URL - -Go to the [Client Settings](${manage_url}/#/applications/${account.clientId}/settings) section in the Auth0 dashboard and make sure that **Allowed Callback URLs** contains the following value: - -`https://${account.namespace}/mobile` - -## Integration - -There are three options for implementing the integration: - -1. Use the [Auth0 Lock](/lock) inside a Web View - the simplest option with only a few lines of code required. -2. Create your own UI - more work, but higher control over the UI. -3. Use a specific username and password. - -### Option 1: Auth0 Lock - -**Lock** is the recommended option. - -Here is a snippet of code to paste into your project: - -${snippet(meta.snippets.setup)} - -${snippet(meta.snippets.use)} - -::: panel-info Component info -`Xamarin.Auth0Client` is built on top of the `WebRedirectAuthenticator` in the Xamarin.Auth component. All rules for standard authenticators apply regarding how the UI will be displayed. -::: - -![](/media/articles/native-platforms/xamarin/xamarin.auth0client.png) - -### Option 2: Custom User Interface - -If you know which identity provider you want to use, you can add the `connection` parameter and the user will be directed to the specified `connection`: - -```cs -var user = await auth0.LoginAsync(this, "google-oauth2"); // connection name here -``` - -**NOTE:** Connection names can be found on Auth0 dashboard (e.g. `facebook`, `linkedin`, `saml-protocol-connection`). - -### Option 3: Specific Username and Password - -```cs -var user = await auth0.LoginAsync( - "sql-azure-database", // connection name here - "jdoe@foobar.com", // user name - "1234"); // password -``` - -## Access User Information - -The `Auth0User` has the following properties: - -* `Profile`: returns a `Newtonsoft.Json.Linq.JObject` object from [Json.NET component](http://components.xamarin.com/view/json.net/) containing all available user attributes (e.g.:`user.Profile["email"].ToString()`). -* `IdToken`: a JSON Web Token (JWT) containing all of the user attributes and signed with your client secret. -* `Auth0AccessToken`: the `access_token` that can be used to call the Auth0 APIs. For example, you could use this token to [Link Accounts](/link-accounts). - -## Download samples - -Android and iOS samples are available on GitHub at: [Xamarin.Auth0Client](https://github.com/auth0/Xamarin.Auth0Client/tree/master/samples). diff --git a/articles/native-platforms/xamarin/index.yml b/articles/native-platforms/xamarin/index.yml deleted file mode 100644 index e4bb7e54fe..0000000000 --- a/articles/native-platforms/xamarin/index.yml +++ /dev/null @@ -1,17 +0,0 @@ -title: Xamarin -language: - - C# -framework: - - Xamarin -hybrid: false -image: /media/platforms/xamarin.png -tags: - - quickstart -snippets: - dependencies: native-platforms/xamarin/dependencies - setup: native-platforms/xamarin/setup - use: native-platforms/xamarin/use -seo_alias: xamarin -default_article: 01-login -articles: - - 01-login diff --git a/articles/onboarding/appliance-sprint.md b/articles/onboarding/appliance-sprint.md index fe7ed2ba12..1beb874949 100644 --- a/articles/onboarding/appliance-sprint.md +++ b/articles/onboarding/appliance-sprint.md @@ -1,25 +1,33 @@ --- sitemap: false section: appliance -description: > - Appliance Sprint is Auth0’s onboarding program for enterprise customers choosing an Auth0 Appliance. It helps you achieve value quickly with your Auth0 enterprise subscription. The 6 steps in the onboarding program set both you and Auth0 up for success. +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 -# 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 Customer Onboarding Program +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: -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 appliance deployment project. Here's an overview of the main steps: +## PSaaS Appliance Deployment Project Overview -## 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 Auth0 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. +**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. -[Appliance Docs](/appliance) - Get up to speed on all things appliance in this high level overview doc. +[PSaaS Appliance Docs](/appliance) - Get up to speed on all things PSaaS Appliance in this high level overview doc. ### Step 2 - Infrastructure Ready @@ -27,25 +35,24 @@ Sprint is Auth0’s onboarding program for enterprise customers. For customers **What?** Your team prepares the relevant infrastructure based on our guidance. -[Appliance Infrastructure Requirements Docs](/appliance/infrastructure) +[PSaaS Appliance Infrastructure Requirements Docs](/appliance/infrastructure) -### Step 3 - Appliance Setup +### 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 appliance on your infrastructure. +**What?** Our team configures the PSaaS Appliance on your infrastructure. - -### Step 4 - Appliance Handover +### 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 appliance. +**What?** An operational handover session with your team to learn how to administer the PSaaS Appliance. -[Appliance Configuration](/appliance/dashboard) - See our Docs on the configuration settings within the Appliance. +[PSaaS Appliance Configuration](/appliance/dashboard) - See our Docs on the configuration settings within the Appliance. -[Appliance Administrator's Manual](/appliance/admin) +[PSaaS Appliance Administrator's Manual](/appliance/admin) -### What's next? +## What's next? -Once the 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 363bc23186..0000000000 --- a/articles/onboarding/cloud-sprint.md +++ /dev/null @@ -1,67 +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 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 - Further 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 (e.g. 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 focussed 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 7600d42b11..1a2979c5fe 100644 --- a/articles/onboarding/enterprise-support.md +++ b/articles/onboarding/enterprise-support.md @@ -1,62 +1,89 @@ --- -description: Outlines the Auth0 enterprise support options, definitions, coverage offered and procedures to follow for the best support experience. +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's relevant for customers only with enterprise subscription agreements which differ from the standard pay-as-you-go/self-service subscription offerings acquired directly from our website. +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 was included in your subscription. +Refer to your subscription agreement to confirm which support offering is included in your subscription. -## For general queries related to functionality, integration, best practice advice etc +## For General Queries -[Auth0 Support Forum](https://ask.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. +For general queries related to functionality, integration, best practice, or advice, you can use the following resources: -__Customer Success Manager__ - Your Auth0 Customer Success Manager is always a great source 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. +- 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) -[Auth0 Docs](https://auth0.com/docs) - Offers comprehensive documentation across the Auth0 platform. +## For Issues Impacting Production Environments (SLA Applicable) -[Search all resources](/search#gsc.tab=0) - Quering from this search page will return results across Docs, Ask.Auth0 and our popular [Auth0 blog](https://auth0.com/blog). +::: note -## For issues impacting or blocking production (SLA applied) +Critical Production issues should always be reported via the [Support Center](${env.DOMAIN_URL_SUPPORT}) for fastest response. -### Standard Enterprise Support (Gold, Silver and Home Grown plans) +[Learn more about creating tickets with Support Center](/support/tickets) +::: -![](/media/articles/onboarding/standard-enterprise-support.png) -### Premium Enterprise Support (Enterprise and Platinum plans) +For the purposes of the following descriptions, the following capitalized words and phrases are ascribed the following meanings: -![](/media/articles/onboarding/premium-enterprise-support.png) +**“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. -### Using Support Center -[Learn more about creating tickets with Support Center](/support/tickets) +**“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. -## Guidance for Logging a Support Issue +## Defect Resolution Procedures -### Validity of SLA +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: -To ensure your support issue is assigned the correct priority and SLA it must be logged via the methods outlined in the section “For issues impacting or blocking the ability to launch in production” above. Any other method may not be tracked correctly within our support systems. +| 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. | -### What to Expect +## Guidance for Logging Support Issues -When an issue has been logged correctly: +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. -* it will be acknowledged immediately in support center with confirmation it was submitted successfully and assigned a ticket ID number. You will also receive email confirmation. Additional information may be requested.  See the section below, “Information to provide”. -* A responding Auth0 support staff member may 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, etc 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. +## What to Expect -### What to Check Before Logging an Issue +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: (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 @@ -74,23 +101,23 @@ To speed resolution, please check the following before logging an issue: * 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 +## 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? (e.g. does issue happen before or after entering credentials, etc) +* 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](/har) +* HTTP trace in the form of a [HAR file](/troubleshoot/guides/generate-har-files) + +*For Private Cloud Customers*: -For Appliance Customers: -* Appliance version/build number (top left hand corner of configuration screen on config tenant, e.g. https://yourmanage.yourdomain.com/configuration#/) -* Status of nodes https://yourmanage.yourdomain.com/configuration#/nodes -* Status of health check https://yourmanage.yourdomain.com/configuration#/troubleshoot +* 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 317a573b53..0000000000 --- a/articles/onboarding/sprint.md +++ /dev/null @@ -1,124 +0,0 @@ ---- -sitemap: false -description: An overview of Auth0’s onboarding program for enterprise customers. ---- - -# Auth0 Sprint - -Sprint is Auth0’s corporate and 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 or corporate sales team will be offered access to Sprint Onboarding. However, the engagement varies slightly based on your subscription plan and support option. - -## Sprint Overview - -#### Goal - -During the onboarding process, the Auth0 Customer Success Team’s goal is to fulfill our obligation to: - -* Have your subscription account correctly provisioned and setup in our systems (including the [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 Benefits by Support Plan - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      SprintSprint Preferred
      Qualifying CustomersEnterprise Support planPreferred Support plan
      Customer Success engagementCustomer Success teamAllocated Customer Success Manager
      Orientationdelivered via online assetsLive 1:1 orientation session* and online assets
      Architecture guidancedelivered via online assets and webinarsLive 1:1 guidance sessions* (up to 4 hours) and online assets
      Auth0 foundations trainingdelivered via online assetsLive 1:1 training session* and online assets
      Auth0 advanced trainingLimited online assetsOptional Live 1:1 sessions* for additional fee and limited online assets
      Success PlanTemplated, self-serve. Completed plan reviewed with Customer Success TeamCustom, 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 after the Sprint program finishes? - -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 what level of subscription you have. - -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, customer forums, documentation, videos and webinars. - -The table below outlines the different benefits delivered by the Customer Success team based on the [support plan](/support) included with your subscription. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Enterprise SupportPreferred Support
      Customer Success engagementCustomer Success teamAllocated Customer Success Manager
      Pre-launch best practices reviewdelivered via online assetsLive 1:1 session* and online assets
      Success Plan management and reviewAt key subscription milestones and when off planOngoing with allocated Customer Success Manager
      Executive business reviewsAnnualQuarterly or as required
      Pre-release program accessNoYes, invited to Zero to Launch program
      -**Live sessions are delivered remotely via web conference.* diff --git a/articles/overview/apis.md b/articles/overview/apis.md deleted file mode 100644 index 6c4c1bf676..0000000000 --- a/articles/overview/apis.md +++ /dev/null @@ -1,101 +0,0 @@ ---- -url: /apis -title: APIs Overview -description: Learn the basics of APIs, their role in OAuth and how to configure an API in Auth0 Dashboard. ---- - -# APIs - -## Overview - -An API is an entity that represents an external resource, capable of accepting and responding to protected resource requests made by clients. At the [OAuth2 spec](https://tools.ietf.org/html/rfc6749) an API maps to the **Resource Server**. - -When a client 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. Clients 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 a client 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. - -> For more information on tokens please refer to: [Tokens used by Auth0](/tokens). - -## How to configure an API in Auth0 - -If this is your first API, you will have to enable the API functionality first. - -Navigate to your [Account Advanced Settings](${manage_url}/#/account/advanced), scroll down to the *Settings* section and toggle the **Enable APIs Section** switch. - -![Enable APIs Section](/media/articles/api/overview/enable-api-section.png) - -Click on the [APIs menu option](${manage_url}/#/apis) on the left. - -> 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. 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 go to the [Signing Algorithms paragraph](#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) - -**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 clients 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. - -- **Non Interactive Clients**: lists your Non Interactive Clients. You can authorize which Non Interactive Clients 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 client has. Only Non Interactive Clients require explicit permission. That is because, when you authorize a non-interactive Client to access an API, Auth0 is creating a Client Grant for that Client. 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). - -- **Test**: from this view you can execute a sample Client Credentials flow with any of your Authorized Non-Interactive Clients 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. - -- **Allow Skipping User Consent**: When a first party client 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 Client's **callbackURL** 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 clients 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. - -> 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/). diff --git a/articles/overview/deployment-models.md b/articles/overview/deployment-models.md deleted file mode 100644 index 723d231c7f..0000000000 --- a/articles/overview/deployment-models.md +++ /dev/null @@ -1,156 +0,0 @@ ---- -description: This page explains the differences of the four different deployment models in which Auth0 is offered. ---- - -# Auth0 Deployment Models - -Auth0 is offered in 4 deployment models: - -1. As a __multi-tenant cloud service__ running on Auth0's cloud. -2. As a __dedicated cloud service__ running on Auth0's cloud. -3. As a __dedicated cloud service__ running on Customer's cloud infrastructure. -4. As an __on-premises virtual appliance__ running on Customer's data centers. - -The following table describes operational and feature differences between each of these models. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Where It RunsAuth0's InfrastructureCustomer's Infrastructure
      How It RunsMulti-TenantDedicatedCloudOn-Premises
      Public FacingYesYesConfigurableConfigurable
      UpdatesUnscheduled.
      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 (e.g. vulnerabilities, security updates)      		Scheduled with Customer.

      Minimum 1/month, except critical updates (e.g. vulnerabilities, security updates)
      Deployment ConfigurationsN/AHigh Availability;
      Geo High Availability;
      High Capacity      		Single Node;
      High Availability;
      Geo High Availability;
      High Capacity      		Single Node;
      High Availability;
      Geo High Availability;
      High Capacity
      Service & Uptime Reportinghttp://status.auth0.com
      http://uptime.auth0.com      		Monitored by Auth0Monitored by Auth0 and Customer's toolsMonitored by Auth0 and Customer's tools
      Uptime SLA ProvidedYesYesNoNo
      Support Channels & LevelsSame across all models
      Features
      SSO LifetimeDefault SettingsConfigurableConfigurableConfigurable
      SearchLucene queriesSimple attribute searchSimple attribute searchSimple attribute search
      Code SandboxWebtask (Javascript and C#)Webtask or in-processWebtask or in-processWebtask or in-process
      WebtaskMulti-TenantDedicatedCloudOn-Premises
      Anomaly DetectionBrute Force and Breached PasswordsBrute ForceBrute ForceBrute Force
      ExtensionsYesYes *Yes *Yes *
      GeolocationYesYesYesYes
      Connecting IP Address Filtering RestrictionsNoNoYesYes
      Custom DomainsNoYesYesYes
      Shared Resources Among Multiple CustomersYesNoNoNo
      - -*__NOTE:__ See the [Auth0 Appliance: Extensions page](/appliance/extensions) to learn more about configuring extensions with the Appliance. diff --git a/articles/overview/index.md b/articles/overview/index.md deleted file mode 100644 index 46982275e1..0000000000 --- a/articles/overview/index.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: Auth0 Overview -description: Learn the basics of Auth0 including how it can help secure your application, how you can extend Auth0 to meet the exact needs of your project, and about the flexible deployment options in both the cloud and even your own datacenter. ---- -# Auth0 Overview - -Auth0 is a service that abstracts how users authenticate to applications. - -![](/media/articles/overview/overview.png) - -You can connect any application (written in any language or on any stack) to Auth0 and define its **Connection**, the method used to authenticate the users of that application: - -* **Custom** credentials: username + passwords -* **Social** network logins: Google, Facebook, Twitter, and any OAuth2, OAuth1 or OpenID Connect provider -* **Enterprise** directories: LDAP, Google Apps, Office 365, ADFS, AD, SAML-P, WS-Federation, etc. -* **Passwordless** systems: TouchID, one time codes on SMS, or email - -## Video: Developer Overview -This video will give you a quick walkthrough of Auth0 and how it will help save you time adding identity to your application. - -<%= include('../videos/_video', { id: 's15ysw45uy' }) %> - -## Integrating Auth0 Into Your Application - -The default [protocol](/protocols) between your application(s) and Auth0 is **OpenID Connect**, a modern, lightweight, simple to use, and simple to integrate protocol. - -Auth0 ships SDKs for all major platforms (.NET, Java, PHP, Python, node, iOS, and many more), but the use of Auth0 SDKs is not mandatory. - -> Virtually anything able to send HTTP requests can integrate with Auth0. - -Auth0 also supports other common identity protocols, such as WS-Federation and SAML. Applications that are already "claims enabled" can easily connect to Auth0. - -## An Extensible Platform -You can extend the functionality of Auth0 using any JavaScript or C# code through the use of [rules](/rules). Rules are custom functions that are executed just after successful authentication and before control returns to the app. They can be used for Access Control, Webhooks, Profile Enrichment, Multi-factor Authentication, and many other things. - -## Flexible Deployment Models -Auth0 is a service usually running in the [public cloud](${manage_url}), but it can also be deployed in **Private Instances** (PI). PIs are dedicated installations of Auth0. You may choose to run PIs in Auth0's datacenters (which are separate from those that run the multi-tenant services), in your own cloud hosting environments (e.g. AWS, Azure, Rackspace, DigitalOcean), or even on-premises. Customers often opt for a hybrid model. For example, some use the cloud service for their **development** and **test** environments and a PI for their **production** environment. - -## Custom Domain Names - -The public, multi-tenant cloud service version of Auth0 supports a domain name based off of `auth0.com`. Auth0 assigns Clients deployed using this service a domain name in one of the two formats: - -* `{account-name}.auth0.com` -* `{account-name}.{location}.auth0.com` - -For example, if your company is **My Company**, you would receive some or all of the following addresses: - -``` -mycompany.auth0.com -mycompany.eu.auth0.com -mycompany.au.auth0.com -``` - -> With the Auth0 public cloud service, the `*.auth0.com` endpoints are only used for authentication and the API, *not* user access to your Client. - -You may choose to use a custom domain name that obscures the Auth0 reference, such as `mycompany.com`. Using a custom domain name requires a *single-tenant* implementation of Auth0, which can be deployed in one of three locations: - -* The Auth0-managed cloud. -* A customer-managed cloud. -* An on-premise installation. - -Due to the additional features offered by these three options, these deployment options do come with a higher cost. - -If you are unable to use a multi-tenant cloud service due to compliance or other policy requirements, please take a look at [the Auth0 appliance](/appliance). diff --git a/articles/policies/billing.md b/articles/policies/billing.md index 351866c305..2de85a2518 100644 --- a/articles/policies/billing.md +++ b/articles/policies/billing.md @@ -1,5 +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 @@ -8,72 +16,105 @@ The following policy governs requests for billing mechanisms within the Auth0 da ## 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 Dashboard 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 Dashboard administrator, we will not process this request. +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 in an unexpected date. +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. -*Please note the following:* If you are having issues with the service, it is not due to the credit card failing. +::: 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. -2. Click on your account name in the top right corner to bring up the associated dropdown box. -3. Select `Account Settings`. -4. On the `Account Settings` 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. +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 signed up for a paid plan but haven't used my account since then, can I get a refund? +### I purchased more tenant subscriptions than desired/needed, can I get a refund? -We understand that sometimes developers create accounts 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 account 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 bought unneeded subscriptions, you are eligible for a refund. -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 account has not been used and for how long. Please note that this request must come from a Dashboard Administrator. +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. -We will evaluate the case and verify that the account has not been used in the aforementioned period in order to process the refund. Please note that if we consider the usage of the account not to be minimal, we reserve the right to not refund your card. +### 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 account settings and clicking on the Payments Tab. There, you will be able to see all your Payment History, and you can get the invoices by clicking on the corresponding month. Please note that only Dashboard administrators can see the invoices. +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 Dashboard admin to do this request. +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. -Also, more than often the email which receives the receipt is the one that created the Auth0 account. 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}). +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 (client in the Dashboard). +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 Client 1 through Facebook, then logs in to Client 2 through Google and then logs in to Client 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, `Account Settings`. 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/). +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/). -## How can I convert my account from a free trial to any other version? +## Can we combine billing for multiple tenants? -You can do this by heading to the upper right corner of the Dashboard, `Account 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/). +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 62176f6a9e..23d1a8d253 100644 --- a/articles/policies/dashboard-authentication.md +++ b/articles/policies/dashboard-authentication.md @@ -1,29 +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. -## Multifactor Authentication +## Multi-factor Authentication -Any customer can enable multifactor authentication to be implemented for dashboard access to their account. +You can enable multi-factor authentication for logging in to the dashboard with your account. -To enable multifactor authentication go to your [Account Settings page](${manage_url}/#/account) and scroll down to the **Multifactor** section. Click the **Enroll Your Device Now** link to get started. The process to setting up each form of authentication is the same as using MFA with a client, [click here for more information on each type of authentication.](/multifactor-authentication) +To enable multi-factor authentication for your account: -### Unenrolling a Device from Multifactor +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. -To stop using multifactor authentication to login to your dashboard, go to your [Account Setting page](${manage_url}/#/account) and scroll down to the **Multifactor** section and click the **REMOVE** button next to the enrolled device. To verify this request you will need to login once more with 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) -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) +### 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 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 a338b05aa6..e4442cef34 100644 --- a/articles/policies/data-export.md +++ b/articles/policies/data-export.md @@ -1,6 +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. You can use our [Import/Export Extension](/extensions/user-import-export) to export nearly all data in your Auth0 account. You can also use the [Management API](/api/management/v2) to export specific types of data. + +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/articles/policies/data-transfer.md b/articles/policies/data-transfer.md index dd99862522..e3cd3206a9 100644 --- a/articles/policies/data-transfer.md +++ b/articles/policies/data-transfer.md @@ -1,52 +1,27 @@ --- -description: Describes the Data Transfer Policy which governs requests for transfer of data from one Auth0 account to another. +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 -The following policy governs requests for transfer of data from one Auth0 account to another. +At this time, Auth0 will not transfer data from one Auth0 tenant to another. This applies to both Public Cloud and Private Cloud customers. -## Requests Allowed +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. -Auth0 will transfer customer data from one account to another in the following situations: +## Frequently made requests that are not supported -* Account move from US to EU hosting environment due to Safe Harbor invalidation. This is allowed for any plan. - -* Account move from US or EU regions and want to switch to the Australia Region. This is allowed for any plan. - -* Account move from an on-premise Auth0 appliance to a cloud account. This is allowed for any plan. - -* 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 Silver plan for one month. - -## Frequently asked requests that are not allowed - -* Transfer of data from one non-production account to a production account prior to transition to production status. - -* Rename of an account. - -* Rename of a database connection. - -## Limitations - -The following limitations apply to data transfers: - -* The data transfer must be done to a new, empty account. We unfortunately cannot undertake merges of data into accounts that already contain data. - -* The data transfer must bring all the data from the source to the destination. We unfortunately cannot undertake partial data transfers (such as a subset of the users). - -* The data transfer must be for either all data in the account or all users in the account. - -* Requests for transfers must be filed via the Auth0 support center (${env.DOMAIN_URL_SUPPORT}) at least five (5) business days in advance of the desired timeframe for the transfer. - -* Requests should include - - * Source account name and region (US, EU, AU) - * Destination account name and region (US, EU, AU) - * Desired timeframe (at least 5 business days from time of request) - * Whether to transfer all data in the account or just all users - - -## Customer’s responsibility - -Auth0 will make every effort to ensure the integrity of the data transfer, however it is the customer’s responsibility to validate the correctness of the data transfer and notify Auth0 about any issues. +* 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 9a24eb3144..f404b79512 100644 --- a/articles/policies/index.md +++ b/articles/policies/index.md @@ -1,17 +1,26 @@ --- 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 +# Operational Policies Auth0 has established the following operational policies. -- [Data Transfer](/policies/data-transfer) -- [Restoration of a Deleted Tenant](/policies/restore-deleted-tenant) +- [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) -- [Endpoints](/policies/endpoints) -- [Billing](/policies/billing) -- [Data Export](policies/data-export) +- [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 cdb547747a..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 a platinum 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. +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 account 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 account 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 new file mode 100644 index 0000000000..850efd2fc0 --- /dev/null +++ b/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/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 8a0c05f3d2..3c86e92079 100644 --- a/articles/policies/rate-limits.md +++ b/articles/policies/rate-limits.md @@ -1,188 +1,79 @@ --- -description: This page details Auth0's Rate Limit Policy with hitting Auth0 API endpoints. +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 -# Auth0 API 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. -To ensure the quality of Auth0's services, the Auth0 API is subject to rate limiting. +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. -If you are looking for information on the rate limits on user logins [click here.](/connections/database/rate-limits) +## API endpoint limits -## 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. -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. -Each endpoint is configured with a bucket that defines: +If your app triggers the rate limit, please refrain from making additional requests until the appropriate amount of time has elapsed. -- the request limit -- the rate limit window (per second, per minute, per hour, etc.) +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. -``` -bucket: - size: x - per_minute: y -``` +### Review HTTP response headers -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. +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. -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. +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. -## Exceeding the Rate Limit +* **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. -If you exceed the provided rate limit for a given API endpoint, you will receive the [429 Too Many Requests](http://tools.ietf.org/html/rfc6585#section-4) response with the following message: +### Handle rates limitations in code -```text -{ - "message": "Too many requests. Check the X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset headers." -} -``` +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. -Actions such as rapidly updating configuration settings, aggressive polling, or making highy concurrent API calls may result in your app being rate limited. +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. -If your app triggers the rate limit, please refrain from making additional requests until the appropriate amount of time has elapsed. +## 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 -## HTTP Response Headers - -API requests to selected Authentication or Management API endpoints will return HTTP Response Headers that provide relevant data on where you are at for a given rate limit. If you receive a rate limit-related response header, it will include numeric information detailing your status. - -* **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)) - -## Endpoints with Rate Limits - -> 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 - -Please note that there is a 50 requests per second limit on all [Management API v2](/api/management/v2) calls per tenant. The limit is 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). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      EndpointGETPOSTDELETEPATCH
      Client Grants/client-grants/client-grants/client-grants/{id}/client-grants/{id}
      Clients/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
      - -### Authentication API - -The following Auth0 Authenticaion API endpoints return rate limit-related headers. For additional information about these endpoints, please consult the [Authentication API docs](/api/authentication). - - - - - - - - - - - - - - - - - - - - - - -
      EndpointGETPOST
      User Profile/userinfo/tokeninfo
      Delegated Authentication/delegation
      Database and Active Directory / LDAP Authentication/dbconnections/change_password
      \ No newline at end of file +* [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/restore-deleted-tenant.md b/articles/policies/restore-deleted-tenant.md index ae6bc4dacc..a9e135d7c6 100644 --- a/articles/policies/restore-deleted-tenant.md +++ b/articles/policies/restore-deleted-tenant.md @@ -1,27 +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. +::: 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. +**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. -## Considerations: - -* We support tenant restoration for all paying customers. - -* Tenant restoration is generally not supported for non-paying customers, but we will evaluate the requests on a case-by-case basis. This means that tenant restoration is not guaranteed in this case. - -* The restoration can take up to seven days, for paying customers. For non paying customers, it can take longer and it will be specified if the request is accepted. - -* 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. - -* 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 new file mode 100644 index 0000000000..f06bf5038a --- /dev/null +++ b/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/articles/pre-deployment/index.html b/articles/pre-deployment/index.html new file mode 100644 index 0000000000..d3f15af976 --- /dev/null +++ b/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/articles/pre-deployment/prelaunch-tips.md b/articles/pre-deployment/prelaunch-tips.md new file mode 100644 index 0000000000..c82eac9222 --- /dev/null +++ b/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/articles/pre-deployment/tests/best-practice.md b/articles/pre-deployment/tests/best-practice.md new file mode 100644 index 0000000000..ff5bd52ff9 --- /dev/null +++ b/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/articles/pre-deployment/tests/recommended.md b/articles/pre-deployment/tests/recommended.md new file mode 100644 index 0000000000..77969efda4 --- /dev/null +++ b/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/articles/pre-deployment/tests/required.md b/articles/pre-deployment/tests/required.md new file mode 100644 index 0000000000..848f2ea432 --- /dev/null +++ b/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/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 54e0171fd7..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,20 +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.

      • @@ -51,7 +65,7 @@

        Protocols

      • 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 clients and web services. + 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.

      • diff --git a/articles/protocols/ldap/index.md b/articles/protocols/ldap/index.md index b7a1dfa27c..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 @@ -11,3 +18,7 @@ The function of LDAP is to enable access to an existing directory, like Active D 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/articles/protocols/oauth2/index.md b/articles/protocols/oauth2/index.md index 8f194b729a..528c308a9a 100644 --- a/articles/protocols/oauth2/index.md +++ b/articles/protocols/oauth2/index.md @@ -1,78 +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 +# 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. This is done without the users having to expose their credentials. According to [OAuth‘s website](http://oauth.net/about/) the protocol is not unlike a valet key. +[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. -> 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. +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. -The protocol's purpose is to provide a standard way for developers to offer a service via an API without forcing the users to expose their passwords. +::: 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`) -## OAuth Roles +For more information refer to [Scopes](/scopes). + +## OAuth roles -The [OAuth 2.0 Authorization Framework specification](https://tools.ietf.org/html/rfc6749) defines a set of 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. +- **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. +- **Authorization Server**: the server that authenticates the Resource Owner, and issues Access Tokens after getting proper authorization. In this case, Auth0. +## Protocol flow -## Access Token +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. -The Access Token, commonly referred to as `access_token` in code samples, is a credential that can be used by a client to access an API. The `access_token` should be used as a `Bearer` credential and transmitted in an HTTP `Authorization` header to the API. Auth0 uses access tokens to protect access to the Auth0 Management API. +![Generic OAuth Flow](/media/articles/protocols/oauth2-generic-flow.png) -By default, Auth0 generates access tokens in [JSON Web Token (JWT)](/jwt) format, an industry standard. 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. +1. The Application (Client) asks for authorization from the Resource Owner in order to access the resources. -It should be noted that other token formats are also available. For example, Auth0 Management API v1 (which has been deprecated) uses an opaque token format in which claims are referenced in a separate database, rather than directly in the token. Simple Web Token is an example of another token format, although it has not seen widespread adoption. Support for future tokens formats will be implemented if and when industry consensus develops around them. +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. -## Scopes +1. The Application requests an **Access Token** by authenticating with the Authorization Server and giving the Authorization Grant. -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. +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. -For example, a Contacts API may accept four different levels of authorization: reading contacts (scope `read:contacts`), creating contacts (scope `create:contacts`) and deleting contacts (scope `delete:contacts`). +1. The Application requests access to the protected resource by the Resource Server, and authenticates by presenting the Access Token. -When a client 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. +1. Provided that the Access Token is valid, the Resource Server serves the Application's request. -For more information refer to [Scopes](/scopes). +## 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. -## Protocol Flow +- [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). -We will now have a more detailed look on how the protocol works. As we will see in a while, OAuth has many "flavors" (actually called authorization grant types) that you can use. For now we will have a more generic look into the flow. +- [Implicit](/flows/concepts/implicit): used by JavaScript-centric apps (Single-Page Applications) executing on the user's browser. -![Generic OAuth Flow](/media/articles/protocols/oauth2-generic-flow.png) +- [Resource Owner Password Credentials](/api-auth/grant/password): used by trusted apps. -1. The Client asks for authorization from the Resource Owner in order to access the resources. +- [Client Credentials](/flows/concepts/client-credentials): used for machine-to-machine communication. -1. Provided that the Resource Owner authorizes this access, the Client receives an **Authorization Grant**. This is a credential representing the Resource Owner's authorization. +The specification also provides an extensibility mechanism for defining additional types. -1. The Client requests an **access token** by authenticating with the Authorization Server and giving the Authorization Grant. +For details on how each grant type works and when it should be used refer to [API Authorization](/api-auth). -1. Provided that the Client is successfully authenticated and the Authorization Grant is valid, the Authorization Server issues an access token and sends it to the Client. +## OAuth endpoints -1. The Client requests access to the protected resource by the Resource Server, and authenticates by presenting the access token. +OAuth 2.0 utilizes two endpoints: the **Authorization** endpoint and the **Token** endpoint. -1. Provided that the access token is valid, the Resource Server serves the Client's request. +### 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. -## Authorization Grant Types +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`. -The [OAuth 2.0 Authorization Framework specification](https://tools.ietf.org/html/rfc6749) defines four grant types. +#### How response type works -- **Authorization Code**: used by Web Apps executing on a server. -- **Implicit**: used by JavaScript-centric apps (SPAs) executing on the user's browser. -- **Resource Owner Password Credentials**: used by trusted apps. -- **Client Credentials**: used for machine-to-machine communication. +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**. -The specification also provides an extensibility mechanism for defining additional types. +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). -For details on how each grant type works and when it should be used refer to [API Authorization](/api-auth). +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/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-implicit-protocol.md b/articles/protocols/oauth2/oauth-implicit-protocol.md deleted file mode 100644 index e91a5dddf6..0000000000 --- a/articles/protocols/oauth2/oauth-implicit-protocol.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -description: How to integrate a mobile app or Javascript app with Auth0. ---- - -# Integrating a Mobile or a JavaScript App with Auth0 - -Auth0 supports the [OpenID Connect / OAuth2 Login implicit profile](http://openid.net/specs/openid-connect-implicit-1_0.html), which is typically used in situations where you can't store the secrets safely. JavaScript running in a browser and mobile devices are two common examples. - -The steps are quite simple though: - -1. Redirect the user to: - - 
        GET https://${account.namespace}/authorize/?
-        response_type=token
-        &client_id=${account.clientId}
-        &redirect_uri=${account.callback}
-        &state=VALUE_THAT_SURVIVES_REDIRECTS
-        &nonce=RANDOM_VALUE
-        &scope=openid
        - - > In a **JavaScript app** you can optionally use the [Login Widget](login-widget2) to trigger the login. Or you can do it manually and send a `connection` parameter in the querystring that will redirect the user straight to the desired connection. - In a **mobile/native app**, you would use a Web View or the browser. Also, you can optionally send a `connection` parameter in the querystring that will redirect the user straight to the desired connection. This is useful when you want to control the UI instead of relying on the [Login Widget](login-widget2). - -2. After the user authenticates, your app will be called to this endpoint with a `GET` - - 
        GET ${account.callback}#
-        access_token=2YotnF..........1zCsicMWpAA
-        &id_token=......Json Web Token......
-        &token_type=bearer
-        &state=VALUE_THAT_SURVIVES_REDIRECTS
        - - - Your code would then parse the hash segment of the URL and extract the parameters: `access_token` and `id_token`. The `access_token` can then be used to call Auth0's [/userinfo](/api/authentication/reference#get-user-info) endpoint to get the attributes of the user. - - > It is a good practice to check that the `state` value received and sent are the same. It can serve as a protection against XSRF attacks. Also, to avoid replay token attacks, you should send a nonce in the initial request. The nonce will be part of the Json Web Token and can be checked in your backend API. - -3. Finally, you can get the user profile by calling: - - 
        GET https://${account.namespace}/userinfo?access_token=2YotnF..........1zCsicMWpAA
        - - Note, that you can use the `access_token` to call [/userinfo](/api/authentication/reference#get-user-info) only if the `openid` scope was requested and approved. - -6. The [/userinfo](/api/authentication/reference#get-user-info) endpoint will return something like this: - - 
        {
-    "user_id": "google-oauth2|103547991597142817347",
-    "email": "johnfoo@gmail.com",
-    "family_name": "Foo",
-    "gender": "male",
-    "given_name": "John",
-    "identities": [
-      {
-        "access_token": "ya29.AsaS6ZQgRHlCHqzZ3....sFFBpQYpVVieSWur-7tmZbzEtwMkA",
-        "provider": "google-oauth2",
-        "user_id": "103547991597142817347",
-        "connection": "google-oauth2",
-        "isSocial": true
-      }
-    ],
-    "locale": "en",
-    "name": "John Foo",
-    "nickname": "matiasw",
-    "picture": "https://lh4.googleusercontent.com/-OdsbOXom9qE/AAAAAAAAAAI/AAAAAAAAADU/_j8SzYTOJ4I/photo.jpg"
-  }
        - -For more details on Auth0's normalized user profile, see [User Profile](/user-profile). diff --git a/articles/protocols/oauth2/oauth-state.md b/articles/protocols/oauth2/oauth-state.md index 90fc77f27e..4667907642 100644 --- a/articles/protocols/oauth2/oauth-state.md +++ b/articles/protocols/oauth2/oauth-state.md @@ -1,57 +1,51 @@ --- -description: Explains how to use the state parameter in authentication requests to help prevent XSRF 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 --- -# Using the State Parameter +# State Parameter -The `state` parameter is one of the supported Auth0 [Authentication Parameters](/libraries/lock/v10/sending-authentication-parameters). This page is to help you understand how to utilize this this parameter which is useful to help mitigate [XSRF attacks](https://en.wikipedia.org/wiki/Cross-site_request_forgery) and for providing any contextual information (such as a return url) that you might need after the authentication process is finished. +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. -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).** +## CSRF attacks -**Here is a basic use case scenario:** +The primary reason for using the `state` parameter is to mitigate [CSRF attacks](https://en.wikipedia.org/wiki/Cross-site_request_forgery). -Note: Depending on the application type or framework this may be included for the developer. Also the exact structure of the requests may differ. +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. -1. Before redirecting a request to the [IdP](/identityproviders), have the client generate a random string. +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). -``` -xyzABC123 -``` +![Diagram of CSRF attack](/media/articles/protocols/CSRF_Diagram.png) -2. Save this string to a variable in [web storage.](/security/store-tokens#web-storage-localstorage-sessionstorage-) +::: warning +The cookie in which the `state` value is stored should be signed to prevent attackers to forge it. +::: -``` -auth0-authorize = xyzABC123 -``` +## Redirect users -3. Encode this value and set it as the `state` parameter in the request. +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). -``` -// Encode the String -var encodedString = Base64.encode(string); -tenant.auth0.com/authorize?...&state=encodedString -``` +## Limitations -4. After the request is sent and when the user is redirected back by Auth0 to the client and the state value will be included. Note that depending on the type of connection used, this value might be in the body of the request or in the query string. +* 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. -``` -/login/callback?...&state=encodedString -``` - -5. Decode this returned state value to compare to the previously stored value. If the values match then approve the request, else deny the request. Using this field can help prevent cross-site request forgery - -``` -// Decode the String -var decodedString = Base64.decode(encodedString); -if(decodedString == auth0-authorize) { - // Authorized request -} else { - // Request Denied -} -``` -## Further Reading: - -[Protecting against other common threats.](/security/common-threats) - -[Using the `state` paramter for redirecting users.](/tutorials/redirecting-users#using-the-state-parameter) +## 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/articles/protocols/oauth2/oauth-web-protocol.md b/articles/protocols/oauth2/oauth-web-protocol.md deleted file mode 100644 index 8f4c77a251..0000000000 --- a/articles/protocols/oauth2/oauth-web-protocol.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -description: How to integrate a web application with Auth0. ---- - -# Integrating a Web App with Auth0 - -Auth0 supports the [OpenID Connect / OAuth2 Login](http://openid.net/specs/openid-connect-basic-1_0.html) protocol. This is the protocol used by companies like [Google](https://developers.google.com/accounts/docs/OAuth2Login), [Facebook](http://developers.facebook.com/docs/facebook-login/login-flow-for-web-no-jssdk/) and [Microsoft](http://msdn.microsoft.com/en-us/library/live/hh243647.aspx) among others so there are plenty of libraries implementing it on various platforms. - -The steps are quite simple though: - -1. Setting up the callback URL in Auth0 - -
        -

        After authenticating the user on Auth0, we will do a GET to a URL on your website. For security purposes, you have to register this URL on the Application Settings section on Auth0 Admin app.

        - -2. Triggering login manually or integrating the Auth0Lock - -<%= include('../../_includes/_lock-sdk') %> - -3. After the user authenticates, your app will be called to this endpoint with a `GET` - - 
        GET ${account.callback}?
-        code=AUTHORIZATION_CODE
-        &state=VALUE_THAT_SURVIVES_REDIRECTS
        - - > It is a good practice to check that the `state` value received and sent are the same. It can serve as a protection against XSRF attacks. - -4. Your app will have to send the `code` to the Auth0 server through a POST - - 
        POST https://${account.namespace}/oauth/token
-    Content-type: application/x-www-form-urlencoded
-
-    client_id=${account.clientId}
-    &redirect_uri=${account.callback}
-    &client_secret=${account.clientSecret}
-    &code=AUTHORIZATION_CODE
-    &grant_type=authorization_code
        - -5. The response from the server will look like this - - 
        {
-     "access_token":"2YotnF..........1zCsicMWpAA",
-     "id_token": "......JSON Web Token......"
-     "token_type": "Bearer",
-  }
        - - > The `access_token` can then be used to call Auth0's `userinfo` endpoint to get the attributes of the user. - -6. Finally, you can get the user profile by calling - - 
        GET https://${account.namespace}/userinfo/?access_token=2YotnF..........1zCsicMWpAA
        - - The `userinfo` endpoint will return something like this: - - 
        {
-    "sub": "google-oauth2|123",
-    "email": "johnfoo@gmail.com",
-    "family_name": "Foo",
-    "gender": "male",
-    "given_name": "John",
-    "locale": "en",
-    "name": "John Foo",
-    "nickname": "johnfoo",
-    "picture": "https://lh4.googleusercontent.com/-OdsbOXom9qE/AAAAAAAAAAI/AAAAAAAAADU/_j8SzYTOJ4I/photo.jpg"
-  }
        - -For more details on Auth0's normalized user profile, see [here](/user-profile). 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 new file mode 100644 index 0000000000..b0e4ca230e --- /dev/null +++ b/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/articles/protocols/oidc/index.md b/articles/protocols/oidc/index.md index 0da4999517..1c0ecdbdf1 100644 --- a/articles/protocols/oidc/index.md +++ b/articles/protocols/oidc/index.md @@ -1,51 +1,54 @@ --- -description: What is the OpenID Connect protocol and how it works. +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 identity tokens (JWT)](/jwt) delivered via the OAuth 2.0 protocol. +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) called an **ID Token**. +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. -## ID Token +## How it works -The ID token (usually referred to as `id_token`) is a [JSON Web Token (JWT)](/jwt) that contains identity data. It is consumed by the client and used to get user information like the user's name, email, and so forth, typically used for UI display. - -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 standard claims with registered names but 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 registered claims are: - - `iss`: the issuer of the token. - - `sub`: the subject of the token (a unique identifier for the user). - - `aud`: the audience that the token is intended for. - - `exp`: the time the token expires (in seconds). - - `iat`: the time the token was issued (in seconds). -- The signature is used by the recipient of a JWT to validate the integrity of the information conveyed in the JWT. - -To get an ID Token using `/authorize` you need to populate the `scope` request parameter with the value `openid` (`scope=openid`). - -For more information on ID tokens refer to [Auth0 id_token](/tokens/id_token). +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: -## Claims +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. -Each ID Token contains claims, which are statements about an entity (typically, the user) and additional metadata. A claim can be the user's name, email address, or roles. +## Access Tokens -There are three types of claims: reserved, public, and private claims. For details you can refer to [JSON Web Tokens (JWT) in Auth0](/jwt#payload). +[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). -The [OpenID Connect specification](https://openid.net/specs/openid-connect-core-1_0.html) defines a set of standard claims, like `name`, `email`, `picture`, `address`, `updated_at`, and more. For the complete list refer to the [paragraph 5.1 of the OpenID Connect specification](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). +## ID Tokens -In addition to these standard claims, other claims may be used as well. +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. -For example, we could add an extra property at our client's users using [User Metadata](/metadata). This property would be called `roles` and it would have either the value `ROLE_ADMIN` or the value `ROLE_USER`. The plan is to get this value upon user login and depending on the value customize the UI so the user can or cannot take admin actions. +### Claims -All we have to do now is specify this new metadata as part of the `scope` request parameter (`scope=openid roles`). Once we decode our ID Token the body payload will contain the property `roles` with the corresponding value for the logged in user. +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. -## How the protocol works +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). -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: +## Keep reading -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 ID Token, and usually an Access Token, back to Auth0. -1. Auth0 can retrieve user information from the ID Token or use the Access Token to invoke a Google API. +* [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 new file mode 100644 index 0000000000..8f2a93e9ca --- /dev/null +++ b/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/articles/protocols/saml/adfs.md b/articles/protocols/saml/adfs.md new file mode 100644 index 0000000000..1651e92e6f --- /dev/null +++ b/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/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 9c55eab195..aa6b9c3a9b 100644 --- a/articles/protocols/saml/identity-providers/okta.md +++ b/articles/protocols/saml/identity-providers/okta.md @@ -1,83 +1,78 @@ --- title: Okta -description: How to configure Okta as an identity provider. +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 -## On Okta dashboard +In this article, we will cover how you can configure Okta for use with Auth0 as a SAML Identity Provider. -Go to Okta dashboard and click on **Applications**. Click on **Create New App**. +## Configure Okta -![](/media/articles/saml/identity-providers/okta/okta-1.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. -Select **SAML 2.0**. +## Configure Auth0 -![](/media/articles/saml/identity-providers/okta/okta-2.png) +At this point, you will configure the integration from the Auth0 side. -Enter the name of your app and optionally a Logo and click **Next**. +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/okta/okta-3.png) +You will be prompted to provide the appropriate configuration settings for this Connection. -Enter the following values: +The only mandatory fields are as follows: -* **Single sign on URL**: `https://${account.namespace}/login/callback` -* **Audience URI (SP Entity ID)**: `urn:auth0:${account.tenant}:${connectionName}` -* Add an Attribute Statement to map "email" to <%= "${user.email}" %>" +* **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. -![](/media/articles/saml/identity-providers/okta/okta-4.png) +Click **Save** to persist your changes and proceed. -Select this is an internal application and then Finish. +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. -Click on **View Setup Instructions** +## Enable Access to the Connection -![](/media/articles/saml/identity-providers/okta/okta-5.png) +Now that you've created and configured your Connection, you'll need to enable access to the Connection for your Application(s). -Take note of the following: +Using the [Management Dashboard](${manage_url}), go to the [Applications](${manage_url}/#/applications) to see the list of Applications associated with your Auth0 account. -* **Identity Provider Single Sign-On URL** -* **Download certificate** +To enable your Connection for a given Application, click **Connections** on its associated row. -![](/media/articles/saml/identity-providers/okta/okta-6.png) +Scroll down to the *Enterprise* section, and click the slider to enable your Okta Connection for the associated Application. -## On Auth0 dashboard +## Test your Connection -Go to **Connections** -> **Enterprise** -> **SAMLP Identity Provider** and click **+NEW** +You can test your Okta-Auth0 integration using the [Management Dashboard](${manage_url}) if you are an Okta user. -* Give it a name identifier (e.g. okta-customer) and copy the **Identity Provider Single Sign-On URL** that you've got from Okta on the **Sign In URL** input +Go to **Connections** -> **Enterprise** -> **SAML**. On the row associated with Okta, click the **play** icon to *Try* your Connection. -* Upload the okta.cer certificate +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. -![](/media/articles/saml/identity-providers/okta/okta-7.png) - -Click on **Save** and close the next dialog. You will get asked which application you want to connect this to. - -## Test the Connection - -If you have a user on Okta you can now click on **Try** on your Auth0 dashboard and you should be redirected to Okta: - -![](/media/articles/saml/identity-providers/okta/okta-8.png) - -> **Note**: the **Try** button only works for users logged in to Auth0 dashboard. You can't send this to an anonymous user (e.g. a customer). If you don't have a Okta user, read the following section to configure IdP Initiated SignOn so the customer can try on their portal. - -![](/media/articles/saml/identity-providers/okta/okta-9.png) +::: 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 has an Application Portal / Launcher for their users. If you want to support that, you will have to change the Single sign on URL in Okta dashboard to be: - -* **Single sign on URL**: `https://${account.namespace}/login/callback?connection=okta-customer` +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` -Where `okta-customer` is the connection name you assigned in Auth0 dashboard. +Be sure to change `YOUR_CONNECTION_NAME` to the name of your Auth0 Connection. -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**. +See [IdP-Initiated SSO](/protocols/saml/idp-initiated-sso) for information on configuring your Auth0 Connection to route the incoming SAML Response. ## Troubleshooting -If a user is returned to the Okta dashboard after authenticating via Okta in a ServiceProvider-initiated login flow, check the following: - -1. If your application is integrated with Auth0 using the OpenID Connect protocol, Auth0 will take the value of the 'state' parameter and pass it on to Okta in the SAML "RelayState" parameter. Therefore, make sure you are setting the 'state' parameter to a value that Okta can use. - -2. In the Okta configuration screen titled "(2) Configure SAML", click on "Show Advanced Settings" and check the option for "Request Compression". The Okta documentation indicates this should be checked if the value of this parameter is compressed. Some Okta users have reported it should be checked for HTTP Redirect binding and uncompressed for HTTP POST binding. +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 584ead7868..373d099c62 100644 --- a/articles/protocols/saml/identity-providers/onelogin.md +++ b/articles/protocols/saml/identity-providers/onelogin.md @@ -1,133 +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** (e.g. 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}:${connectionName}` - -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 (e.g. `[-a-zA-Z0-9@:%._\+~#=]{2,256}\.[a-z]{2,6}\b([-a-zA-Z0-9@:%_\+.~#?&//=]*)`). - -![](/media/articles/saml/identity-providers/onelogin/onelogin-set-values.png) +* **SAML Audience**: `urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME` -## Testing +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: -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. +| Auth0 value | OneLogin configuration field | +| - | - | +| Post-back URL | ACS (Consumer) URL **and** Recipient | +| Entity ID | Audience | -We are now set to test the connection! On your **SAMLP Identity Provider** connection click the **Try** button. +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@:%_\+.~#?&//=]*)`) -![](/media/articles/saml/identity-providers/onelogin/auth0-try-conn.png) +## Step 3: Test your connection -You are redirected to a page informing you that the connection works. Well done! +Before testing your connection: -![](/media/articles/saml/identity-providers/onelogin/auth0-try-result.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) -> **Note**: the **Try** button only works for users logged in to Auth0 dashboard. You can't send this to an anonymous user (e.g. 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. +At this point, you are set to test the connection! Next to your **SAML** connection, click the **Try** button. -## IdP Initiated SignOn +If all goes well, you will be redirected to a page informing you that the connection works. -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: +::: 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. -* 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 -> 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 9b948e7485..1165cfb3d1 100644 --- a/articles/protocols/saml/identity-providers/ping7.md +++ b/articles/protocols/saml/identity-providers/ping7.md @@ -1,107 +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. -* __EntityID:__ `urn:auth0:${account.tenant}:${connectionName}` +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**, please make sure to include the connection parameter in the Assertion Consumer Service URL: `https://${account.namespace}/login/callback?connection=${connectionName}` - -### 1. Download Auth0 Metadata File - -Download the metadata file from [here](https://${account.namespace}/samlp/metadata?connection=${connectionName}). 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=${connectionName}) 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 d267b64425..35bbe93e2b 100644 --- a/articles/protocols/saml/identity-providers/salesforce.md +++ b/articles/protocols/saml/identity-providers/salesforce.md @@ -1,87 +1,89 @@ --- -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**. -**NOTE:** You can always access the metadata for an Auth0 SAML connection with this URL syntax: `https://${account.namespace}/samlp/metadata?connection=${connectionName}`. +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. -## 3. Configure the SalesForce Identity Provider +::: 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`. +::: -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. +## 3. Configure the Salesforce Identity Provider -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: +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. - **Entity ID:** `urn:auth0:${account.namespace}:${connectionName}` +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` @@ -93,43 +95,44 @@ 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. +::: 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 +## 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. -**NOTE:** The **Try** button only works for users logged into the Auth0 dashboard. +::: note +The **Try** button only works for users logged into the Auth0 dashboard. +::: -## 6. Troubleshooting. +## 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 *GET*s. 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 65f21207dd..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`, etc. 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 4a573f5827..b5b1f0448e 100644 --- a/articles/protocols/saml/identity-providers/ssocircle.md +++ b/articles/protocols/saml/identity-providers/ssocircle.md @@ -1,66 +1,67 @@ --- -title: ssocircle -description: Tutorial for creating an Auth0 app that uses SAML SSO with 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 --- +# Configure SSOCircle as an Identity Provider -# SAML SSO with 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. -This tutorial will create a sample application that uses Auth0 for SAML Single Sign On (SSO), authenticating users against identity provider **SSOCircle**. - -## 1. Obtain the SSOCircle Metadata - -::: panel-info SSOCircle Metadata +::: 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. ::: -Navigate to [SSOCircle's IDP page](https://idp.ssocircle.com/) to see the metadata required for integration. You will be shown an XML file. +## 1. Obtain the SSOCircle Metadata -![Metadata XML Display](/media/articles/saml/identity-providers/ssocircle/metadata-xml.png) +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. -![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) - -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: - -* **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 - -Finally, upload the **SSOCircle CA Certificate** you saved in [step 1](#1-obtain-the-ssocircle-metadata) as the *X509 Signing Certificate*. +To do so, see [Connect Your App to SAML Identity Providers](/connections/enterprise/saml). -You can leave the rest of the fields on the page blank. Click **Save**. +While setting up your connection, make sure you use the following settings: -![Auth0 Configure SSOCircle Connection Screen](/media/articles/saml/identity-providers/ssocircle/configure-ssocircle-connection.png) +| 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. | -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. +When setting up mappings, use the following JSON to properly map SAML attributes from SSO Circle, and click **Save**: -![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) +```json +{ + "email": "EmailAddress", + "given_name": "FirstName", + "family_name": "LastName" +} +``` -> 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=${connectionName}`. +::: 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 @@ -68,87 +69,53 @@ 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**. -Returning to the top of *Settings*, click on **Connections**. +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. - -![Auth0 Create Enterprise Connection Screen](/media/articles/saml/identity-providers/ssocircle/create-enterprise-connection.png) - -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**. +To test your connection, see [Test Enterprise Connections](/dashboard/guides/connections/test-connections-enterprise). -![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. +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. -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 Client +## 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. -Create an HTML file with the following HTML and JavaScript: - ```html @@ -157,32 +124,32 @@ Create an HTML file with the following HTML and JavaScript: ``` -Be sure to replace `YOUR_CLIENT_ID` with the actual value for the [Client you created](#4-create-an-auth0-client-to-test-the-connection). To find the Client ID, go to *[Auth0 Dashboard](${manage_url}) > [Clients](${manage_url}/#/clients)* and click the **Settings** icon to the right of your Client name. Copy the **Client ID** value. +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. +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. @@ -190,9 +157,9 @@ 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) - -> 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 Client you previously configured. +::: 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. @@ -200,27 +167,22 @@ 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) -> 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`. +::: 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 Client receives. +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 Client 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: - +* 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 Client. +* 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/articles/protocols/saml/idp-initiated-sso.md b/articles/protocols/saml/idp-initiated-sso.md new file mode 100644 index 0000000000..bf2e5617b9 --- /dev/null +++ b/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/articles/protocols/saml/index.html b/articles/protocols/saml/index.html index 098cd69798..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.

        @@ -19,36 +25,42 @@

        SAML

        This article explains the various configuration options of SAML available with Auth0.

        -
        • -
      • - Auth0 as Identity Provider -

        - How to configure Auth0 to serve as an Identity Provider in a SAML federation. -

        • -
      • - Auth0 as Service Provider -

        - How to configure Auth0 to serve as a Service Provider in a SAML federation. -

        -
        • -
      • - SAML SSO with Auth0 as Service Provider and as an Identity Provider -

        - Learn how to use SAML SSO with Auth0 as both the Service Provider and Identity Provider, using two Auth0 accounts, allowing you to test your Auth0 SAML without configuring another provider to do so! -

        -
        • -
      • - SAML Identity Provider Configuration -

        - How to configure a SAML Identity Provider. -

        -
      • List of SAML-P Identity Providers

        @@ -64,28 +76,14 @@

        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 Microsoft Active Directory Federations Services (ADFS).

        -
      • Identity Providers @@ -103,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 7dd0b97555..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 SAMLConfiguration: +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 579fa5ed89..4c32cef3d7 100644 --- a/articles/protocols/saml/saml-apps/cisco-webex.md +++ b/articles/protocols/saml/saml-apps/cisco-webex.md @@ -1,11 +1,20 @@ --- 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 { "mappings": { "email": ["email", "uid", "Name_ID"] @@ -21,4 +30,8 @@ ${include('./\_header')} } ``` -Notice that Webex has an option to automatically provision new users. You will need to send that info along as claims (lastname, etc). +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/articles/protocols/saml/saml-apps/datadog.md b/articles/protocols/saml/saml-apps/datadog.md index 8fd2edf525..45b50ab027 100644 --- a/articles/protocols/saml/saml-apps/datadog.md +++ b/articles/protocols/saml/saml-apps/datadog.md @@ -1,11 +1,19 @@ --- title: Datadog SAML Configuration description: Datadog SAML Configuration +topics: + - saml + - identity-providers + - datadog +contentType: + - how-to +useCase: + - add-idp --- -${include('./\_header')} +<%= include('./_header') %> -``` +```json { "audience": "https://app.datadoghq.com/account/saml/metadata.xml", "mappings": { @@ -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 new file mode 100644 index 0000000000..6fbc053c54 --- /dev/null +++ b/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/articles/protocols/saml/saml-apps/eloqua.md b/articles/protocols/saml/saml-apps/eloqua.md new file mode 100644 index 0000000000..cabc886eb5 --- /dev/null +++ b/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/articles/protocols/saml/saml-apps/freshdesk.md b/articles/protocols/saml/saml-apps/freshdesk.md index b8ef37dc04..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 new file mode 100644 index 0000000000..1bb7255078 --- /dev/null +++ b/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/articles/protocols/saml/saml-apps/heroku.md b/articles/protocols/saml/saml-apps/heroku.md index a4d8cfe88b..2cefaeeea2 100644 --- a/articles/protocols/saml/saml-apps/heroku.md +++ b/articles/protocols/saml/saml-apps/heroku.md @@ -1,60 +1,75 @@ --- -title: Configuring SSO with Heroku -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 --- -# Configuring SSO with Heroku +# Configure Single Sign-on with Heroku -Follow these simple steps to configure SSO for Heroku's dashboard. Once enabled you will be able to login into Heroku using any of the [Auth0 supported identity providers](identityproviders). +::: 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. +::: -## 1. Login to Heroku +You can configure Single Sign-on (SSO) so that your users can log into Heroku using any of Auth0's supported [identity providers](/identityproviders). -Go to your organization settings page in Heroku, and scroll to the SSO settings: +## 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) -Keep this page open. The two parameters you will need in the next step are: +You will need the following two parameters from this section to integrate with Auth0: * __Heroku Entity ID__ * __ACS URL__ -## 2. Register Heroku in Auth0 +## 2. Register Heroku with Auth0 -Log in to your dashboard and [create a new application](${manage_url}/#/applications). Pick a name (e.g. Heroku), select the __Addons__ section of the new app, and enable __SAML2__: +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__. Then enter the following settings: +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}", + "audience":"THE-HEROKU-ENTITY-ID", "mappings": { - "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", + "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" }, - "createUpnClaim": false, + "createUpnClaim": false, "passthroughClaimsWithNoMapping": false, "mapUnknownClaimsAsIs": false, - "mapIdentities": 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", - ], + "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" + ] } ``` ![](/media/articles/saml/saml-apps/heroku/auth0-dashboard-saml.png) -> Notice the `audience` parameter is the __Heroku Entity ID__ value from step 1. It will be of the form: `https://sso.heroku.com/saml/{YOUR HEROKU ORG}` +::: note +The `audience` parameter is the __Heroku Entity ID__. It will be formatted like this: `https://sso.heroku.com/saml/YOUR-HEROKU-ORG` +::: -Scroll down and click on "Save". Now select the __Usage__ section in the __SAML__ configuration and download the __Identity Provider Metadata__: +Click **Save**. ![](/media/articles/saml/saml-apps/heroku/auth0-dashboard-saml-usage.png) -## 3. Complete configuration in Heroku +## 3. Provide Auth0 Metadata to Heroku -Back on Heroku, click on __Upload Metadata__ and select the file you downloaded in the previous step: +Open up the __Usage__ section of the SAML2 Web App Configuration pop-up and download the __Identity Provider Metadata__. -![](/media/articles/saml/saml-apps/heroku/heroku-dashboard-metadata.png) +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) -You are done, congratulations! +Once you've uploaded your metadata, your SSO integration is fully set up. \ No newline at end of file diff --git a/articles/protocols/saml/saml-apps/hosted-graphite.md b/articles/protocols/saml/saml-apps/hosted-graphite.md new file mode 100644 index 0000000000..cbeb6da827 --- /dev/null +++ b/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/articles/protocols/saml/saml-apps/index.md b/articles/protocols/saml/saml-apps/index.md index fcfa78ae98..472ae21b8d 100644 --- a/articles/protocols/saml/saml-apps/index.md +++ b/articles/protocols/saml/saml-apps/index.md @@ -1,293 +1,44 @@ --- -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 and Pluralsight. ---- - -# SAML Configurations for SSO Integrations - -## Google Apps - -``` -{ - "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, - "nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:email", - "nameIdentifierProbes": [ - "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" - ], -} -``` -**Callback URL**: `https://www.google.com/a/{YOUR-GOOGLE-DOMAIN}/acs` - ---- - -## Hosted Graphite - -``` -{ - "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" - ] -} -``` - -**Callback URL**: `https://www.hostedgraphite.com/complete/saml/{YOUR-USER-ID}/` - ---- - -## Litmos - -``` -{ - "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" - ] -} -``` - -**Callback URL**: `https://{YOUR DOMAIN}.litmos.com/integration/samllogin` - ---- - -## Cisco WebEx - -``` -{ - "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", - ] -} -``` - ---- - -## SproutVideo - -``` -{ - "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", - ], -} -``` -**Callback URL**: `https://{YOUR SPROUT VIDEO ACCOUNT}.vids.io` - ---- - -## FreshDesk - -``` -{ - "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" - ] -} -``` - -**Callback URL**: `https://{FD Domain}.freshdesk.com/login/saml` - ---- - -## Tableau Server - -``` -{ - "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" - ] -} -``` - -**Callback URL**: `http://{YOUR TABLEAU SERVER}/wg/saml/SSO/index.html` - ---- - -## Datadog - -``` -{ - "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", - ], -} -``` - -**Callback URL**: `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. - ---- - -## Egencia - -```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", - ], -} -``` - -**Callback URL**: `https://www.egencia.com/auth/v1/artifactConsumer` - ---- - -## Workday - -``` -{ - "audience": "http://www.workday.com", - "recipient": "https://www.myworkday.com//login-saml.htmld", - "mappings": { - }, - "createUpnClaim": false, - "passthroughClaimsWithNoMapping": false, - "mapUnknownClaimsAsIs": false, - "mapIdentities": false, - "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", -} -``` - -**Callback URL**: `https://impl.workday.com//fx/home.flex` - ---- - -## Pluralsight - -``` -{ - "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" - ] -} -``` - -**Callback URL**: `https://prod-pf.pluralsight.com/sp/ACS.saml2` - ---- - -## Eloqua (Oracle Eloqua Marketing Cloud) - -``` -{ -"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" - } - -``` - -**Callback URL**: `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. - ---- - +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/articles/protocols/saml/saml-apps/litmos.md b/articles/protocols/saml/saml-apps/litmos.md index 28625efe7d..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 new file mode 100644 index 0000000000..ea769d56c2 --- /dev/null +++ b/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/articles/protocols/saml/saml-apps/sprout-video.md b/articles/protocols/saml/saml-apps/sprout-video.md index fa1ba0d4fb..fd4ada302c 100644 --- a/articles/protocols/saml/saml-apps/sprout-video.md +++ b/articles/protocols/saml/saml-apps/sprout-video.md @@ -1,11 +1,19 @@ --- 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 { "audience": "https://{YOUR SPROUT VIDEO ACCOUNT}.vids.io", "mappings": { 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 new file mode 100644 index 0000000000..e299a22d92 --- /dev/null +++ b/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/articles/protocols/saml/saml-apps/workday.md b/articles/protocols/saml/saml-apps/workday.md new file mode 100644 index 0000000000..1e3f3f6970 --- /dev/null +++ b/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/articles/protocols/saml/saml-apps/workpath.md b/articles/protocols/saml/saml-apps/workpath.md new file mode 100644 index 0000000000..60e2f170b2 --- /dev/null +++ b/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/articles/protocols/saml/saml-configuration.md b/articles/protocols/saml/saml-configuration.md deleted file mode 100644 index 071bba1c86..0000000000 --- a/articles/protocols/saml/saml-configuration.md +++ /dev/null @@ -1,372 +0,0 @@ ---- -title: SAML Configuration in Auth0 -description: This article explains the various configuration options of SAML available with Auth0. ---- - -# SAML Configuration - -## Overview - -In a SAML federation there is 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. - -Auth0 supports the SAML protocol and can serve in either a SAML Service Provider (SP) role, a SAML Identity Provider (IDP) role or both. - - -### SAML Identity Provider - -Some Applications, such as Salesforce, Box, Workday, can be configured to allow users to authenticate against an external Identity Provider using the SAML protocol. Such applications can be integrated with Auth0 and in this case Auth0 will serve as the SAML IDP for the application. - -Users of the application 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 even other SAML IDPs or Social Providers. Once the user is authenticated, Auth0 will return a SAML assertion to the application indicating that the user has been successfully authenticated. - -![](/media/articles/saml/saml-configuration/saml-case2.png) - -### SAML Service Provider - -Other applications, especially custom applications, may externalize authentication against an external Identity Provider using a protocol such as OpenID Connect or OAuth2. In such cases, even though the application was written to utilize the OpenID Connect or OAuth2 protocol, it may be desirable to leverage an enterprise SAML provider for authentication. - -In this situation, Auth0 will receive an authentication request from the application using the OpenID Connect or OAuth2 protocol, and Auth0 will translate the request into a SAML Authentication Request and send it on to a SAML Identity Provider. In this case, Auth0 serves as a SAML Service Provider in the federation with the Identity Provider. - -![](/media/articles/saml/saml-configuration/saml-case1.png) - -### SAML Service Provider and Identity Provider - -Auth0 can also serve as an authentication hub between applications making a SAML request and backend SAML Identity Providers. In this case, Auth0 would serve as a SAML Identity Provider to the applications, and it would also serve as a SAML Service Provider to backend SAML Identity Providers. This use case is advantageous when applications need to support multiple backend Identity Providers. - -![](/media/articles/saml/saml-configuration/saml-case3.png) - -## Configuring Auth0 as a Service Provider - -We have a video with a quick overview of configuring Auth0 as a SAML service provider: - - - - -If Auth0 will serve as a SAML Service Provider, an Auth0 Connection is used to configure the Auth0 side (Service Provider) of each SAML federation. - -There are instructions for several specific providers below: - -* [ADFS](/adfs) -* [Okta](/okta) -* [OneLogin](/onelogin) -* [Ping7](/ping7) -* [SalesForce](/saml/identity-providers/salesforce) -* [SiteMinder](/siteminder) -* [SSOCircle](/ssocircle) - -Auth0 can be configured as a Service Provider to any other SAML-compliant Identity Provider using the following generic instructions: [Generic Service Provider Configuration](/saml-sp-generic) - - -## Configuring Auth0 as a SAML Identity Provider - -Configuring Auth0 to serve as a SAML Identity Provider is done in a couple different places, depending on the type of application. - -For some SSO Integrations that support SAML, the Auth0 side of the configuration is done using the "SSO Integrations" link in the dashboard, clicking on "CREATE SSO INTEGRATION", and selecting the specific integration. Instructions specific to the chosen SSO Integration are provided in the **Tutorial** section: [Using Auth0 in SAML2 Web Apps](/saml2webapp-tutorial). - - -For any application not listed on the "SSO Integrations" page(click "CREATE SSO INTEGRATION" to see the list) the Auth0 side of the configuration can be added. Go to the "Applications" link on the dashboard, choose your application, click on the "Addons" tab, and then toggle on the "SAML2 WEB APP" box. - -Generic instructions for configuring Auth0 as an IDP: [Generic Identity Provider Configuration](/saml-idp-generic). - -The SAML2 Web App screen ("Settings" tab) can be used to specify various SAML parameters for the SAML Authentication Response. SSO Integrations that require special settings are documented at: [SAML settings needed for some SSO Integrations](/saml-apps). - -Once Auth0 has been configured to serve as a SAML Identity Provider to client applications, it needs a way to authenticate users. It can use any of the supported connection types for this. Auth0 can authenticate users against ldap directories, databases, other SAML Identity Providers or even Social providers and once a user is authenticated, Auth0 can translate the authentication result into a SAML Authentication Assertion to send back to the application client. - -## Configuring Auth0 as both Service Provider and Identity Provider - -In this situation, there are two federations to configure. The federation between the application and Auth0 will follow the instructions above for Configuring Auth0 as an Identity Provider. The federation between Auth0 and any backend SAML Identity providers would follow the instructions for Configuring Auth0 as a Service Provider. - -A different, but similar, use case is setting up one Auth0 account to serve as a SAML Service Provider and then setting up a second Auth0 account to serve as a SAML Identity Provider for the first account. This configuration would typically just be used for testing purposes. The steps to set this up are described in: [Auth0 as Identity Provider for itself](/samlsso-auth0-to-auth0). - -**NOTE**: A list of [Identity Providers](/samlp-providers) that are believed to be SAML compliant. - -## Special Configuration Situations - -Once a basic SAML setup has been done, there are a number of additional requirements that may need to be implemented to refine the setup to a particular situation. The instructions below assume a connection has been set up (for Auth0 as Service Provider) or an Application has been set up (Auth0 as Identity Provider) and instructions are given for the specific settings to alter for each requirement. - -### IDP-initiated SSO - -Most of the instructions for setting up a SAML federation start with Service-Provider-Initiated Single Sign On which involves a user first invoking a URL on the Service Provider which returns a browser redirect to send the user to the Identity Provider for authentication. After authentication, the user browser is redirected back to the Service Provider with a SAML assertion indicating authentication status. This is common for consumer-facing scenarios. - -An alternative sequence is called Identity-Provider-Initiated Single Sign On where a user first invokes a URL on the Identity Provider and is prompted to authenticate and then is redirected to the Service Provider with a SAML assertion. This is common in enterprise scenarios where an enterprise sets up a portal with links to outsourced or cloud-hosted applications to ensure users go to the correct application. In this case the user first goes to the portal URL, which redirects to the IDP, where the user authenticates. After authentication, the user clicks on links on the portal and their browser is redirected to the Service Provider with a SAML assertion. - -#### Auth0 as Service Provider -If Auth0 is acting as a Service Provider, the following is needed to support IDP-Initiated Single Sign On. - -* Ensure the IDP includes the connection parameter in the ACS (Assertion Consumer Service) URL. -* In the connection configuration, use the IDP-Initiated tab to specify 1) the application to which the user will be redirected after IDP login, 2) the protocol by which to return to that application and 3) any query parameters to pass to the application. - -#### Auth0 as Identity Provider -If Auth0 is acting as an Identity Provider, the following is needed to support IDP-initiated Single Sign On. - - -* The URL to invoke for IDP-initiated login, if Auth0 will authenticate the users is of the form: `https://${account.namespace}/samlp/${account.clientId}` -* The `RelayState parameter` can be appended to specify a URL to which the Service Provider should redirect the user after processing the SAML response. Example: `https://{accountname}.auth0.com/samlp/${account.clientId}?RelayState=http://FINAL_DESTINATION_URL` - - -### Signing and Encryption - -#### Auth0 as Service Provider - -##### Signing SAML Authentication Requests - -If Auth0 is acting as a SAML Service Provider, the Authentication Request sent to the Identity Provider can be signed by doing the following for the SAML connection: - -* Connections -> Enterprise -> SAMLP Identity Provider -> Settings (gear icon) -* Turn on the **"Sign Request"** toggle -* Download the certificate underneath the **"Sign Request"** toggle and give it to the Identity Provider for use in validating the signature. - -###### Turning Deflate encoding on and off -Note that by default, SAML Authentication Requests are sent via HTTP-Redirect and using deflate encoding, which puts the signature in a query parameter. To turn deflate encoding off, one can use the Auth0 Management APIv2 **"Update a connection"** endpoint to set the "deflate" option to false. - -First use the Management APIv2 Get a Connection to see and copy the list of all options. Then use Update a Connection, adding the "deflate" option and setting it to false, and paste in the rest of the options and their values: - -``` -{ - "name":"NAME_OF_CONNECTION" - "options" : { - ""deflate":false - ...include all other options... - } -} -``` - -##### Receiving Signed SAML Authentication Responses - -When Auth0 is acting as a SAML Service Provider, all SAML Responses from an Identity Provider should be signed to ensure the response has not been tampered with. Auth0 should be configured to validate the signature of the responses by: - -* Obtain a signing certificate from the Identity Provider -* Load the certificate from the Identity Provider into the Auth0 Connection: -* Connections -> Enterprise -> SAMLP Identity Providers -> Settings (gear icon) for the desired connection -> **"UPLOAD CERTIFICATE"** - -Auth0 can accept a SAML response with signature for either the assertion, the response or both. - - -##### Receiving Encrypted SAML Authentication Assertions - -When Auth0 is acting as a SAML Service Provider, it may need to receive encrypted assertions from an Identity Provider. To do this, the Service Provider public key/certificate must be given to the Identity Provider. The Identity Provider will encipher the SAML assertion with the public key and then Auth0 as the Service Provider will use its private key to decipher the assertion. - -To prepare a connection for this: - -* Connections -> Enterprise -> SAMLP Identity Providers -> Setup (pencil icon) for the desired connection -* See the "Optional: Assertions can be encrypted..." line which provides the ability to download a certificate in three different formats. -* Download and send to the Identity Provider administrator the certificate format needed by the Identity Provider. - - -#### Auth0 as Identity Provider - -##### Receiving signed SAML Authentication Requests - -When Auth0 is acting as a SAML Identity Provider, it can receive signed authentication requests, signed with the Service Provider's private key, and use the Service Provider's public key/certificate to validate the signature. - -##### Sending Signed SAML Authentication Responses/Assertions - -When Auth0 is acting as a SAML Identity Provider, it will sign responses or assertions with its private key and the receiving Service Provider will validate the signature with the corresponding public key/certificate. To do this: - -* Go to *Dashboard > Clients > Settings (gear icon) > Show Advanced Settings*. -* Under **Certificates** use **DOWNLOAD CERTIFICATE** to obtain the Identity Provider signing certificate. -* Send this certificate to the Service Provider for use in validating the signature. -* Then go to *Clients > Addons > SAML2 WEB APP > Settings* tab. -* By default the SAML Assertion will be signed. -* To sign the SAML Response, uncomment the `signResponse` line and set it to `true`. - -At present, Auth0 will sign either the assertion **or** the response, but not both simultaneously. - - -##### Sending Encrypted SAML Authentication Assertions - -When Auth0 is acting as a SAML Identity Provider, it is possible for it to encrypt the SAML assertion it sends by using a Rule. - -You will need to obtain the certificate and public key from the Service Provider. - -```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"; - - callback(null, user, context); -} -``` - -### Logout - - -For information on how to log out the user's session in Auth0, or in both Auth0 and federated identity providers, see: - -* [Logout](/logout) - -When Auth0 is serving as a SAML Identity Provider, it is necessary to specify a logout callback URL in the Application Addon Settings in order for logout to work. To do this, go to: - -* Auth0 Dashboard -> Apps/APIs -> {Name of Application} -> Addons -> SAML2 WEB APP -> Settings - -In the "Settings" field, enter a specification for logout callback URL: - -``` -"logout": { "callback" : "http://your-callback-goes-here" }, -``` - -### Selecting between multiple Identity Providers (Auth0 connections) - -If you have a multi-tenant application, or even a single-tenant application, that needs to select between multiple Identity Providers (Auth0 connections), this is called Home Realm Discovery. This can be done by programmatically specifying the connection in the call which invokes authentication, or by specifying the email domain(s) for each connection in the connection settings, or by adding custom buttons to the Lock widget. - -Information on how to do each of these options is at: [Home Realm Discovery](/hrd) - -## Customizing SAML assertions (Auth0 as IDP) - -The "Configuring Auth0 as a SAML Identity Provider" section above contains information on basic configuration for Auth0 to serve as a SAML Identity Provider. - -This section explains how to customize the SAML Assertions and the SAML and WS-Fed protocol parameters when Auth0 is configured to serve as an Identity Provider. - - -### Via Application Addons - -In the Auth0 dashboard, the **""Apps/APIs"** -> **"Settings"** -> **"Addons"** -> **"SAML2WebApp"** -> **"Settings"** tab can be used for several types of customizations, including the following common cases: - -* 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 to sign the assertion or the entire response - -The tab contains a description of each setting. - -### Via Rules - -Auth0 rules can also be used to add more extensive or dynamic customizations to the SAML response. Note that customizations done in Rules will override customizations done in the Apps/APIs Addons tab. - -You can customize the SAML Assertion by creating a [rule](/rules) like this: - -```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" - } - } - - callback(null, user, context); -} -``` - -To include user_metadata attributes in an assertion, you can create a [rule](/rules) like this: - -```js -function (user, context, callback) { - user.user_metadata = user.user_metadata || {}; - user.user_metadata.color2 = "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", - }; - callback(null, user, context); -} -``` - - -### Configuration options - -Below are all the customizations you can do and they can be done using either of the above two options. - -* __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 (`Array`):__ 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](/user-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](/user-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 add more information in the token like the provider used (google, adfs, ad, etc.) 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 `sha1`. 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`). - - -## Design Considerations - -### SAML Provisioning - -In designing a SAML SSO implementation, it is often helpful to consider which system(s) will serve as authoritative sources for user profile information, what user profile attributes each application will need, and how the user profile information will be distributed to all systems that need it. - -#### Auth0 as Service Provider - -If Auth0 is serving as the Service Provider in a SAML federation, it does not require any out-of-band process to create user accounts in Auth0 in advance of user authentication. Auth0 can route authentication requests to an Identity Provider without already having an account pre-created for a specific user. Auth0 will capture user profile information from the assertion returned by the Identity Provider and create a user profile for the user in Auth0. This is sometimes called Just-In-Time provisioning. - -There are several mechanisms available to route a request to an IdP. See: [Selecting the Connection in Auth0](/hrd). - -A popular option is specifying e-mail domains as part of the IDP configuration. For example: adding the email domain "companyx.com" to the IDP configuration for company X will result in all users with that email domain being routed to that IDP. - -When a user authenticates at an Identity Provider, the user attributes returned by the Identity Provider in the SAML Authentication Assertion will be used to create a user profile for the user in Auth0 at the time of authentication. That user profile will contain the attributes sent by the IDP. - -The user profile received by Auth0 will also be relayed to the application. - -Note, however, that while Auth0 does not require any process to pre-create accounts in Auth0 prior to user authentication, an application integrated with Auth0 may still require this. If this is the case, several options exist: - -* When a user is created at the Identity Provider, an out-of-band process can create the user in the application or Auth0 and add any user profile attributes needed by the application. After the user is authenticated, if attributes are still missing in the profile, the application can obtain the attributes from the appropriate source and then store these in the Auth0 user profile. Upon next login, those extra attributes will be sent to the application in addition to the Identity Provider's attributes. - -* An Auth0 rule can be written to call an API to retrieve any missing information and add it dynamically to the Auth0 profile, which is returned to the application. Rules are executed after successful authentication. Profile attributes can be retrieved each time from a remote source or persisted in the Auth0 profile. - -* Auth0 can simply pass the basic user profile information from the Identity Provider to the application and the application can retrieve any missing information from another source to populate a user profile that is local to the application. - -In selecting an approach, careful consideration should be given to utilize an appropriate authoritative source for any user profile attributes used for access control. For example, an Identity Provider may be able to supply basic user profile attributes such as email address, name, and possibly access control groups for a user. There may, however, be additional administrative functions within the application that are needed to grant application-specific privileges to users. - -#### Auth0 as Identity Provider - -If Auth0 is serving as the Identity Provider in a SAML federation, user accounts may be created in a variety of ways. - - * Users created in a backend authentication system used by Auth0 such as an LDAP directory, a database, or another SAML Identity Provider. - * Use of the Auth0 Dashboard by administrators to create users in Auth0 - * Calls to the Auth0 API to create users in Auth0 - * Self-service user signup to create users in Auth0 - -Once accounts have been created in Auth0, or any authentication system it uses in a connection, it may be necessary to create an account and user profile for users in an application using Auth0 as an Identity Provider, if the application was written to retrieve user profile information from a local application store. - -Several options exist: - - * An out-of-band process can create user profile information in the application. - * An Auth0 rule that executes on first login could call an application API to create the user profile in the application. - * The application can be modified to create user profiles dynamically, based on information in the SAML assertion. - -In selecting an approach, careful consideration should be given to utilize an appropriate authoritative source for any user profile attributes used for access control. - -### Deprovisioning - -Deprovisioning of accounts should be done, at minimum, at the Identity Provider. Once an account is removed or disabled at the Identity Provider, the user will not be able to log in. - -It may also be desirable to remove accounts at Auth0 if it is acting as Service Provider or an application integrated with Auth0. Regardless of whether Auth0 is acting as a Service Provider or an Identity Provider, user accounts can be removed from Auth0 via the Auth0 dashboard or via the Auth0 API. - -**NOTE:** The following extension is useful for troubleshooting SAML authentication: [SAML debugger extension for Firefox](https://addons.mozilla.org/en-US/firefox/addon/saml-tracer/). - - -## SAML options and bindings - -Supported SAML options: -* Web Browser SSO Profile -* Single Logout Profile -* Name Identifier Management Profile -* Name Identifier Mapping Profile - -Not supported SAML options: -* Enhanced Client and Proxy (ECP) Profile -* Identity Provider Discovery Profile -* Assertion Query/Request Profile -* Artifact Resolution Profile - -Supported SAML bindings: -* HTTP Redirect Binding -* HTTP POST Binding - -Not supported SAML bindings: -* HTTP Artifact Binding -* SAML SOAP Binding -* Reverse SOAP (PAOS) Binding -* SAML URI Binding 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 new file mode 100644 index 0000000000..999e7a133b --- /dev/null +++ b/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/articles/protocols/saml/saml-configuration/auth0-as-identity-provider.md b/articles/protocols/saml/saml-configuration/auth0-as-identity-provider.md new file mode 100644 index 0000000000..56178f72e1 --- /dev/null +++ b/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/articles/protocols/saml/saml-configuration/auth0-as-service-provider.md b/articles/protocols/saml/saml-configuration/auth0-as-service-provider.md new file mode 100644 index 0000000000..7ed558c5f6 --- /dev/null +++ b/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/articles/protocols/saml/saml-configuration/deprovision-users.md b/articles/protocols/saml/saml-configuration/deprovision-users.md new file mode 100644 index 0000000000..08d1523ec3 --- /dev/null +++ b/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/articles/protocols/saml/saml-configuration/design-considerations.md b/articles/protocols/saml/saml-configuration/design-considerations.md new file mode 100644 index 0000000000..68ac4fbf90 --- /dev/null +++ b/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/articles/protocols/saml/saml-configuration/index.md b/articles/protocols/saml/saml-configuration/index.md new file mode 100644 index 0000000000..0c6ff2b5b3 --- /dev/null +++ b/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/articles/protocols/saml/saml-configuration/logout.md b/articles/protocols/saml/saml-configuration/logout.md new file mode 100644 index 0000000000..efc2414f46 --- /dev/null +++ b/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/articles/protocols/saml/saml-configuration/saml-assertions.md b/articles/protocols/saml/saml-configuration/saml-assertions.md new file mode 100644 index 0000000000..797c742986 --- /dev/null +++ b/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/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 new file mode 100644 index 0000000000..09ec481adf --- /dev/null +++ b/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/articles/protocols/saml/saml-configuration/special-configuration-scenarios/index.md b/articles/protocols/saml/saml-configuration/special-configuration-scenarios/index.md new file mode 100644 index 0000000000..d27d7e9011 --- /dev/null +++ b/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/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 new file mode 100644 index 0000000000..dc76d7a160 --- /dev/null +++ b/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/articles/protocols/saml/saml-configuration/supported-options-and-bindings.md b/articles/protocols/saml/saml-configuration/supported-options-and-bindings.md new file mode 100644 index 0000000000..64d9449197 --- /dev/null +++ b/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/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-idp.md b/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-idp.md new file mode 100644 index 0000000000..39fa5e5c5b --- /dev/null +++ b/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/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-sp.md b/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-sp.md new file mode 100644 index 0000000000..b80302d710 --- /dev/null +++ b/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/articles/protocols/saml/saml-configuration/troubleshoot/common-saml-errors.md b/articles/protocols/saml/saml-configuration/troubleshoot/common-saml-errors.md new file mode 100644 index 0000000000..6f438059d8 --- /dev/null +++ b/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/articles/protocols/saml/saml-configuration/troubleshoot/index.md b/articles/protocols/saml/saml-configuration/troubleshoot/index.md new file mode 100644 index 0000000000..044c1a5c7c --- /dev/null +++ b/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/articles/protocols/saml/saml-idp-eloqua.md b/articles/protocols/saml/saml-idp-eloqua.md index 863cb73ade..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 @@ -8,11 +16,11 @@ These instructions explain how to configure Auth0 to serve as an Identity Provid ## Configure the Addon: SAML2 Web App -Login to [Auth0 dashboard](${manage_url}) and create a new [Client](${manage_url}/#/clients). +Login to [Auth0 dashboard](${manage_url}) and create a new [Application](${manage_url}/#/applications). -Navigate to the [Addons](${manage_url}/#/clients/${account.clientId}/addons) tab and enable the **SAML2 Web App** using the toggle switch. +Navigate to the [Addons](${manage_url}/#/applications/${account.clientId}/addons) tab and enable the **SAML2 Web App** using the toggle switch. -![Client Addons](/media/articles/protocols/saml/eloqua/client-addons.png) +![Application Addons](/media/articles/protocols/saml/eloqua/client-addons.png) The *Settings* window will be displayed. Set the following values: @@ -75,7 +83,7 @@ Edit the newly added identity provider and complete the following steps: 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 > Clients > select your client > Addons > SAML2 Web App > Settings* and set the `audience` to the value you copied. +Navigate to __Dashboard > Applications > select your application > Addons > SAML2 Web App > Settings__ and set the `audience` to the value you copied. ## Test @@ -83,13 +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 -For IDP Initiated login use the **Identity Provider Login URL** defined under the *Dashboard > Clients > select your client > Addons > SAML 2 Web App > Usage*. +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 f0e754ef86..5c5576a8e3 100644 --- a/articles/protocols/saml/saml-idp-generic.md +++ b/articles/protocols/saml/saml-idp-generic.md @@ -1,98 +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. - -There are **5 sections**, including a troubleshooting section at the end. - -1. Obtain information from the Service Provider/Application -2. Configure Auth0 as IDP -3. Configure the Service Provider -4. Test -5. Troubleshooting +These instructions explain how to configure Auth0 to serve as an Identity Provider in a SAML federation. ## 1. Obtain Information from the Service Provider -1. 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 the Assertion Consumer Service URL, or the Post-back URL or the Callback URL. +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. - -**In the Auth0 dashboard:** - -1. Click on **"Clients"** link at left. - -2. Click on the red **"+ CREATE CLIENT"** button on the right. - -3. In the **Name** field, enter a name like "MySAMLApp". - -4. Press the blue **"SAVE"** button. - -5. In the **Auth0 dashboard**, click again on the **"Clients"** link at left - -6. 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) - -7. Scroll down and click on the **"Advanced Settings"** link. - -8. 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 this file when configuring the Service Provider. - -![](/media/articles/saml/saml-idp-generic/saml-idp-generic1.png) +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 -9. Scroll down further to the **"ENDPOINTS"** section and click on the blue **"SAML"** tab within that section. Copy the entire contents of the **"SAML Protocol URL"** field and save it as you will need to provide it to the Service Provider. - -![](/media/articles/saml/saml-idp-generic/saml-idp-generic2.png) - -10. Scroll back up and click on the "Addons" tab. Then click on the box labeled "SAML2 WEB APP". - -![](/media/articles/saml/saml-idp-generic/saml-idp-generic3.png) - -11. In the "Application Callback URL" field, enter the URL at the Service Provider (or application) to which the SAML assertions should be sent after Auth0 has authenticated the user. - -![](/media/articles/saml/saml-idp-generic/saml-idp-generic4.png) - -12. 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. +In this section you will add some information to the Service Provider so they know how to send SAML-based authentication requests to Auth0. -![](/media/articles/saml/saml-idp-generic/saml-idp-generic5.png) +The instructions provided here are generic. You will need to find the appropriate screens and fields on the Service Provider. -## 3. Configure 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**). -In this section you will add some information to the Service Provider so the Service Provider knows how to send SAML-based authentication requests to the Auth0 Identity Provider. The instructions provided here are generic. You will need to find the appropriate screens and fields on the Service Provider. +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: -If the Service Provider supports uploading a metadata file, you can simply provide the metadata URL obtained in the step above. (Apps/APIs -> Addons -> Usage) +- **Identity Provider Login URL**: This is the URL to which the Service Provider should send its SAML Authentication Requests. -If the Service Provider does not support uploading a metadata file, you can configure it manually, using the information from the Auth0 Apps/APIs -> Addons -> Usage screen as follows: +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`. -Identity Provider Login URL: This is the URL to which the Service Provider should send its SAML Authentication Requests. +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. -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. -The Service Provider will need a certificate from the Auth0 Identity Provider. You can download this certificate from the Auth0 Apps/APIs -> Addons -> Usage screen. This certificate will be used to validate the signature of the SAML Authentication Assertions sent from Auth0 Identity Provider to the Service Provider application. +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. +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. +## 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 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. +- 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. -Be sure to check to make sure cookies and javascript are enabled for your browser. +- 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. +- The [http://samltool.io](http://samltool.io) tool can decode a SAML assertion and is a useful debugging tool. diff --git a/articles/protocols/saml/saml-sp-generic.md b/articles/protocols/saml/saml-sp-generic.md index 865aa239c7..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. @@ -15,82 +21,68 @@ There are **5 sections**, including a troubleshooting section at the end. 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 an 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. - +* **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. -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 - - -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-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. - -**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. +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. -**Save:** 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.) +Click on the blue **"SAVE"** button at the bottom. -![](/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}:${connectionName}__. +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. e.g. 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=${connectionName}`. +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. +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. @@ -98,24 +90,31 @@ If the Identity Provider supports uploading a metadata file, you can simply prov 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: +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 -If the Identity Provider has a field called "Audience" or "Entity ID", you should enter into that field the **Entity ID** from Auth0: +```text +https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME +``` +The `connection` URL parameter is required for identity provider-initiated flows. -``` - "audience":"urn:auth0:${account.tenant}:${connectionName}" +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: -``` - https://${account.namespace}/logout +```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. @@ -124,41 +123,42 @@ The **Single Logout Service URL**, where SAML logout requests and/or responses f 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. -* In the **Auth0 dashboard**, 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 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. +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. +::: 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: +Here is a sample of the **It Works** screen: ![](/media/articles/saml/saml-sp-generic/saml-auth0-9.png) - -## 5. Troubleshooting. +## 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. +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. -Check to make sure that the callback URL specified by your application in its authentication request is listed in the **Allowed Callback URLs** field in the __"Settings"__ tab of the application registered in the Auth0 Dashboard. (In dashboard, Click on __"Apps/APIs"__ link, then on the __"Settings"__ icon to the right of the application name.) +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. +The [http://samltool.io](http://samltool.io) tool can decode a SAML assertion and is a useful debugging tool. ## Supported algorithms for signatures @@ -173,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 285ab44334..26cc31a6f7 100644 --- a/articles/protocols/saml/saml2webapp-tutorial.md +++ b/articles/protocols/saml/saml2webapp-tutorial.md @@ -1,7 +1,82 @@ --- description: How to use Auth0 in a SAML2 web application. +topics: + - saml + - web-apps +contentType: + - how-to +useCase: + - add-idp --- -# Using Auth0 in SAML2 Web App +# Using Auth0 with a SAML2 Web App -Please enable and configure `SAML2 Web App` from [Application Add-ons](${manage_url}/#/clients/${account.clientId}/addons) section and follow the instructions displayed. +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/articles/protocols/saml/samlp-providers.md b/articles/protocols/saml/samlp-providers.md index d46838505b..b42a172665 100644 --- a/articles/protocols/saml/samlp-providers.md +++ b/articles/protocols/saml/samlp-providers.md @@ -1,14 +1,18 @@ --- 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 + The following providers have participated in a Kantara inter-operability test and are therefore likely to conform well to the SAML spec. * __adAS__ @@ -31,3 +35,4 @@ The following providers have participated in a Kantara inter-operability test an * __Tivoli Federated Identity Manager__ * __TrustBuilder__ * __Ubisecure SSO__ + * __WSO2 Identity Server__ diff --git a/articles/protocols/saml/samlp.md b/articles/protocols/saml/samlp.md index 65c5c756e2..3b32321d29 100644 --- a/articles/protocols/saml/samlp.md +++ b/articles/protocols/saml/samlp.md @@ -1,34 +1,74 @@ --- 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` -* The __Entity ID__ of the Service Provider is: `urn:auth0:${account.tenant}:${connectionName}` -* The __SAML Request Binding__ (sent to the IdP from Auth0): `HTTP-Redirect` -* The __SAML Response Binding__ (how the SAML token is received by Auth0 from IdP): `HTTP-Post` +* 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`. Note: SAML logout requests must be signed by the Identity Provider. +* 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 -## Encrypted Assertions: +By default, SAML assertions for IdP connections are signed, which we recommend. You can use the following public keys to configure the IdP: -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) +* [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 SSO +## IdP-initiated Single Sign-on -If you want **IdP-Initiated SSO**, please make sure to include the `connection` parameter in the post-back URL: `https://${account.namespace}/login/callback?connection=${connectionName}` +[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=${connectionName} +https://${account.namespace}/samlp/metadata?connection=YOUR_CONNECTION_NAME ``` diff --git a/articles/protocols/saml/samlsso-auth0-to-auth0.md b/articles/protocols/saml/samlsso-auth0-to-auth0.md index e2a6dc761c..6440d44a11 100644 --- a/articles/protocols/saml/samlsso-auth0-to-auth0.md +++ b/articles/protocols/saml/samlsso-auth0-to-auth0.md @@ -1,16 +1,24 @@ --- -description: Learn how to use SAML SSO with Auth0 as both the Service Provider and Identity Provider, using two Auth0 accounts, 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 account (account 1) as a SAML Service Provider(SP), and authenticating users against a second Auth0 account (account 2) serving as SAML Identity Provider(IDP). This gives you a way to test your Auth0 SAML account (account 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. -1. [Establish two Auth0 accounts](#1-establish-two-auth0-accounts) -2. [Set up the Auth0 Identity Provider (IDP) (account 2)](#2-set-up-the-auth0-idp-account-2-) -3. [Set up the Auth0 Service Provider (SP) (account 1)](#3-set-up-the-auth0-service-provider-account-1-) +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-) @@ -19,31 +27,31 @@ There are **9 steps** to this sample and the tenth is a troubleshooting section 9. [Test your sample application](#9-test-your-sample-application) 10. [Troubleshooting](#10-troubleshooting) -## 1. Establish two Auth0 Accounts +## 1. Establish two Auth0 Tenants -If you do not already have two Auth0 accounts, you will need to create them. If you do already have two accounts, you can skip to step #2. +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 account and in the popup menu which appears, select **"New Account"**. +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 account in the **"Your Auth0 domain"** field and press the **"SAVE"** button. +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 accounts by going to the upper right corner of the dashboard, clicking on the name of the current account, and using the popup menu which appears to switch between your accounts. +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 (account 2) +## 2. Set up the Auth0 IDP (tenant 2) -In this section you will configure one Auth0 account (account 2) to serve as an Identity Provider. You will do this by registering a client, but in this case, the 'client' you register is really a representation of account 1, the SAML Service Provider. +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 **Account 2** +Log into **Tenant 2** **In the Auth0 dashboard:** -1. Click on **"Clients"** link at left. +1. Click on **"Applications"** link at left. -2. Click on the red **"+ CREATE CLIENT"** button on the right. +2. Click on the red **"+ CREATE APPLICATION"** button on the right. ![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-02.png) @@ -55,11 +63,11 @@ Log into **Account 2** 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 account, account 1. +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 account, account 1. +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) @@ -79,11 +87,11 @@ Next, create a user to use in testing the SAML SSO sequence. 5. Press the blue **"SAVE"** button. -## 3. Set up the Auth0 service provider (account 1) +## 3. Set up the Auth0 service provider (tenant 1) -In this section you will configure another Auth0 account (account 1) so it knows how to communicate with the second Auth0 account (account 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. -Log out of **Account 2** and log into **Account 1**. +Switch to **Tenant 1**. You can do this using the **Switch tenant** option in the upper-right menu. **In the Auth0 dashboard:** @@ -101,15 +109,15 @@ 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 account 2 dashboard, Apps/APIs link, Settings tab, Advanced Settings, ENDPOINTS section, SAML tab, "SAML Protocol URL" field.) +**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 account 2 in section 2 above. +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. @@ -117,41 +125,43 @@ 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 (account 1) is displayed. You will need to collect two pieces of information about this Auth0 account (the service provider) that you will then paste into the other Auth0 account 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}:${connectionName}__. +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=${connectionName}`. +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 account 1 (service provider side of the federation. It will look something like the following with your account 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}.auth0.com/login/callback?connection=${connectionName}__. +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 account 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 (account 1) to the Identity Provider (account 2) so the Identity Provider Auth0 account knows how to receive and respond to SAML-based authentication requests from the Service Provider Auth0 account. +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. -* Log out of **Account 1** and log back into **Account 2**. +* Switch back to **Tenant 2**. -**In the Auth0 dashboard:** for Account 2 +**In the Auth0 dashboard:** for Tenant 2 -1. Click on **"Clients"** link at left. +1. Click on **"Applications"** link at left. -2. Find the row for the client you created earlier, and click on the **"Add Ons"** icon to the right of the client name. (the angle bracket and slash icon) +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) @@ -166,12 +176,12 @@ 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: -``` - "audience":"urn:auth0:${account.tenant}:${connectionName}" +```text +"audience":"urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME" ``` 7. Click on the blue **"SAVE"** button at the bottom of the screen @@ -180,9 +190,9 @@ Next, replace the original value (urn:foo) with the **Entity ID** value you save In the same screen, click on the red **"DEBUG"** button. -That will trigger a login screen from account 2, the Identity Provider. +That will trigger a login screen from tenant 2, the Identity Provider. -Log in with the credentials for account 2. +Log in with the credentials for the user you created above. ![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-13.png) @@ -198,37 +208,39 @@ Click on **"Close this window"** at the bottom of the screen. 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 **Account 1 Auth0 dashboard**. +Make sure you are logged into the **Tenant 1 Auth0 dashboard**. -* In the **Auth0 dashboard**, click on the **"Clients"** link at left. +* 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 JASON 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. -* In the same screen, click on the blue **"Connections"** tab (In the row that says Quick Start, Settings etc. +* 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"**. -![](/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 -In this section, you will test to make sure the SAML configuration between Auth0 account 1 (Service Provider) and Auth0 account 2 (Identity Provider) is working. +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. -* In the **Auth0 dashboard**, navigate to: __Connections -> Enterprise -> SAMLP Identity Provider__. +* On the [Dashboard](${manage_url}), navigate to: __Connections -> Enterprise -> SAMLP Identity Provider__. ![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-14.jpg) @@ -236,18 +248,18 @@ 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 account 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. -> 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. +::: 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 @@ -264,9 +276,10 @@ Create an HTML page and insert the following HTML and javascript code: +``` + +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..81994f425e --- /dev/null +++ b/articles/quickstart/native/ionic-vue/interactive.md @@ -0,0 +1,108 @@ +--- +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: https://github.com/auth0-samples/auth0-ionic-samples/tree/main/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. + +<%= include('../_includes/ionic/_note_storage') %> + +:::: checkpoint +:::checkpoint-default +Now that you have configured your app with the Auth0 Vue SDK, run your application to verify that the SDK is initializing without error, and that your application runs as it did before. +::: + +:::checkpoint-failure +Sorry about that. Here's a couple things to double check: + +- ensure the correct application is selected +- did you save after entering your URLs? +- make sure the domain and Client ID imported correctly + +Still having issues? Check out our documentation 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/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/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/index.yml b/articles/quickstart/native/ios-swift/index.yml new file mode 100755 index 0000000000..db922d99d6 --- /dev/null +++ b/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/articles/quickstart/native/ios-swift/interactive.md b/articles/quickstart/native/ios-swift/interactive.md new file mode 100644 index 0000000000..03e38eef14 --- /dev/null +++ b/articles/quickstart/native/ios-swift/interactive.md @@ -0,0 +1,195 @@ +--- +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: https://github.com/auth0-samples/auth0-ios-swift-sample/tree/master/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.

        + +Use the interactive selector to create a new Auth0 application or select an existing **Native** Auth0 application. Auth0 assigns every application an alphanumeric, unique Client ID that your app uses to call Auth0 APIs through the SDK. + +Any settings you configure using this quickstart automatically update your Auth0 application in the Dashboard, which is where you can manage your applications in the future. + +If you would rather explore a complete configuration, you can view a sample app instead. + +### Configure callback and logout URLs + +Auth0 invokes the callback and logout URLs to redirect users back to your app. Auth0 invokes the callback URL after authenticating the user and the logout URL after removing the session cookie. If you do not set the callback and login URLs, users will not be able to log in and out of the app, and your app will produce an error. + +::: note +On iOS 17.4+ and macOS 14.4+ it is possible to use Universal Links as callback and logout URLs. When enabled, Auth0.swift will fall back to using a custom URL scheme on older iOS / macOS versions. + +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**. +::: + +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 + +```text +https://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback, +YOUR_BUNDLE_IDENTIFIER://${account.namespace}/ios/YOUR_BUNDLE_IDENTIFIER/callback +``` + +#### macOS + +```text +https://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback, +YOUR_BUNDLE_IDENTIFIER://${account.namespace}/macos/YOUR_BUNDLE_IDENTIFIER/callback +``` + +For example, if your iOS bundle identifier was `com.example.MyApp` and your Auth0 domain was `example.us.auth0.com`, then this value would be: + +```text +https://example.us.auth0.com/ios/com.example.MyApp/callback, +com.example.MyApp://example.us.auth0.com/ios/com.example.MyApp/callback +``` + +### Configure the associated domain + +::: warning +This step requires a paid Apple Developer account. It is needed to use Universal Links as callback and logout URLs. Skip this step to use a custom URL scheme instead. +::: + +#### Configure the Team ID and bundle identifier + +Go to the settings page 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 + +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 your Auth0 tenant’s domain. + +::: note +For the associated domain to work, your app must be signed with your team certificate **even when building for the iOS simulator**. Make sure you are using the Apple Team whose Team ID is configured in the settings page of your Auth0 application. +::: + +## Install the SDK + + +

        Using the Swift Package Manager

        Open the following menu item in Xcode:

        File > Add Package Dependencies...

        In the Search or Enter Package URL search box enter this URL:

        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.

        + +
        + +### 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 {{{ 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. + +::: note +You can also configure the SDK programmatically. Check the README to learn more. +::: + +::::checkpoint +:::checkpoint-default +You configured the Auth0.swift SDK. Run your app to verify that it is not producing any errors related to the SDK. +::: + +:::checkpoint-failure +If your app produces errors related to the SDK: +- Make sure you selected the correct Auth0 application +- Verify you saved your URL updates +- Ensure you set the Auth0 domain and Client ID correctly + +Still having issues? Check out our documentation 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..7e7e0aa404 --- /dev/null +++ b/articles/quickstart/native/maui/interactive.md @@ -0,0 +1,160 @@ +--- +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: https://github.com/auth0-samples/auth0-maui-samples/tree/master/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..7bd2c84c09 --- /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: https://github.com/auth0-samples/auth0-xamarin-oidc-samples/tree/master/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/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..10c1117ad1 --- /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: https://github.com/auth0-samples/auth0-angular-samples/tree/main/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/config.yml b/articles/quickstart/spa/config.yml new file mode 100644 index 0000000000..51f64e8751 --- /dev/null +++ b/articles/quickstart/spa/config.yml @@ -0,0 +1,2 @@ +sample_download_required_data: + - client 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..593acedc79 --- /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: https://github.com/auth0-samples/auth0-flutter-samples/tree/main/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/react/01-login.md b/articles/quickstart/spa/react/01-login.md new file mode 100644 index 0000000000..9c4223667a --- /dev/null +++ b/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 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 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. +::: + 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/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 new file mode 100644 index 0000000000..591b6725fe --- /dev/null +++ b/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/articles/quickstart/spa/react/interactive.md b/articles/quickstart/spa/react/interactive.md new file mode 100644 index 0000000000..afd67c79dc --- /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: https://github.com/auth0-samples/auth0-react-samples/tree/master/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.

        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/vanillajs/01-login.md b/articles/quickstart/spa/vanillajs/01-login.md new file mode 100644 index 0000000000..dc9497c854 --- /dev/null +++ b/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/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/_includes/_centralized_login.md b/articles/quickstart/spa/vanillajs/_includes/_centralized_login.md
new file mode 100644
index 0000000000..8d85dd25fe
--- /dev/null
+++ b/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. 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.
+:::
+
+## Create the server
+
+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).
+
+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` 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. 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. 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/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
new file mode 100644
index 0000000000..69ef28e4e9
--- /dev/null
+++ b/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/articles/quickstart/spa/vanillajs/interactive.md b/articles/quickstart/spa/vanillajs/interactive.md
new file mode 100644
index 0000000000..eab7b5deba
--- /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: https://github.com/auth0-samples/auth0-javascript-samples/tree/master/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
new file mode 100644
index 0000000000..3ba7176094
--- /dev/null
+++ b/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 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 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/_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
new file mode 100644
index 0000000000..878c0ed504
--- /dev/null
+++ b/articles/quickstart/spa/vuejs/_includes/_centralized_login.md
@@ -0,0 +1,203 @@
+
+
+## Install the SDK
+
+Install the Auth0 Vue SDK 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 and 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/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
new file mode 100644
index 0000000000..ead0c3b600
--- /dev/null
+++ b/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/articles/quickstart/spa/vuejs/interactive.md b/articles/quickstart/spa/vuejs/interactive.md
new file mode 100644
index 0000000000..8c73a299b4
--- /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: https://github.com/auth0-samples/auth0-vue-samples/tree/master/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/_callbackRegularWebApp.md b/articles/quickstart/webapp/_callbackRegularWebApp.md
new file mode 100644
index 0000000000..574fec99d9
--- /dev/null
+++ b/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/articles/quickstart/webapp/_includes/_auth0_authorize.md b/articles/quickstart/webapp/_includes/_auth0_authorize.md
new file mode 100644
index 0000000000..9da2f5a327
--- /dev/null
+++ b/articles/quickstart/webapp/_includes/_auth0_authorize.md
@@ -0,0 +1,16 @@
+## Integrate auth0.js
+
+```html
+
+
+
+```
\ No newline at end of file
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/server-platforms/_includes/_callback-url-introduction.md b/articles/quickstart/webapp/_includes/_callback-url-introduction.md
similarity index 100%
rename from articles/server-platforms/_includes/_callback-url-introduction.md
rename to articles/quickstart/webapp/_includes/_callback-url-introduction.md
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
new file mode 100644
index 0000000000..cf81e08a55
--- /dev/null
+++ b/articles/quickstart/webapp/_includes/_getting_started.md
@@ -0,0 +1,13 @@
+
+
+::: note
+**New to Auth?** Learn How Auth0 works, how it integrates with Regular Web Applications and which protocol 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/articles/quickstart/webapp/_includes/_install_auth0js.md b/articles/quickstart/webapp/_includes/_install_auth0js.md
new file mode 100644
index 0000000000..ddb3c65520
--- /dev/null
+++ b/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/articles/quickstart/webapp/_includes/_mfa-enable.md b/articles/quickstart/webapp/_includes/_mfa-enable.md
new file mode 100644
index 0000000000..4814dee4fc
--- /dev/null
+++ b/articles/quickstart/webapp/_includes/_mfa-enable.md
@@ -0,0 +1,5 @@
+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 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
new file mode 100644
index 0000000000..2a60dfc0f4
--- /dev/null
+++ b/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.
diff --git a/articles/quickstart/webapp/_includes/_mfa-login.md b/articles/quickstart/webapp/_includes/_mfa-login.md
new file mode 100644
index 0000000000..0e91d41282
--- /dev/null
+++ b/articles/quickstart/webapp/_includes/_mfa-login.md
@@ -0,0 +1,6 @@
+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 Guardian.
+
diff --git a/articles/quickstart/webapp/_includes/_profile-metadata-explanation.md b/articles/quickstart/webapp/_includes/_profile-metadata-explanation.md
new file mode 100644
index 0000000000..9dfb6eee06
--- /dev/null
+++ b/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.
\ No newline at end of file
diff --git a/articles/quickstart/webapp/apache/01-login.md b/articles/quickstart/webapp/apache/01-login.md
new file mode 100644
index 0000000000..106a587320
--- /dev/null
+++ b/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 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 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/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
new file mode 100644
index 0000000000..867ba92073
--- /dev/null
+++ b/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/articles/quickstart/webapp/apache/interactive.md b/articles/quickstart/webapp/apache/interactive.md
new file mode 100644
index 0000000000..94d3234ae5
--- /dev/null
+++ b/articles/quickstart/webapp/apache/interactive.md
@@ -0,0 +1,51 @@
+---
+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
+github:
+  path: https://github.com/zmartzone/mod_auth_openidc/releases
+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..98f0a6eff8
--- /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: https://github.com/auth0-samples/auth0-aspnetcore-blazor-server-samples/tree/main/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/.
        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/01-login.md b/articles/quickstart/webapp/aspnet-core/01-login.md
new file mode 100644
index 0000000000..deaadad0c4
--- /dev/null
+++ b/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, 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/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
new file mode 100644
index 0000000000..3b3a20f345
--- /dev/null
+++ b/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/articles/quickstart/webapp/aspnet-core/interactive.md b/articles/quickstart/webapp/aspnet-core/interactive.md
new file mode 100644
index 0000000000..7230ff03f6
--- /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: https://github.com/auth0-samples/auth0-aspnetcore-mvc-samples/tree/master/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/01-login.md b/articles/quickstart/webapp/aspnet-owin/01-login.md
new file mode 100644
index 0000000000..15e4c11ef5
--- /dev/null
+++ b/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 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/_includes/_setup.md b/articles/quickstart/webapp/aspnet-owin/_includes/_setup.md
new file mode 100644
index 0000000000..5db5d77940
--- /dev/null
+++ b/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/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
new file mode 100644
index 0000000000..a14bac0006
--- /dev/null
+++ b/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/articles/quickstart/webapp/aspnet-owin/interactive.md b/articles/quickstart/webapp/aspnet-owin/interactive.md
new file mode 100644
index 0000000000..ebd984644a
--- /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: https://github.com/auth0-samples/auth0-aspnet-owin-mvc-samples/tree/master/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/.
        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/config.yml b/articles/quickstart/webapp/config.yml
new file mode 100644
index 0000000000..51f64e8751
--- /dev/null
+++ b/articles/quickstart/webapp/config.yml
@@ -0,0 +1,2 @@
+sample_download_required_data:
+  - client
diff --git a/articles/quickstart/webapp/django/01-login.md b/articles/quickstart/webapp/django/01-login.md
new file mode 100644
index 0000000000..542e1a597b
--- /dev/null
+++ b/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 and Authlib. 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.
+
+## 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.
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
new file mode 100644
index 0000000000..a44e0e28d1
--- /dev/null
+++ b/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/articles/quickstart/webapp/django/interactive.md b/articles/quickstart/webapp/django/interactive.md
new file mode 100644
index 0000000000..3f1adde192
--- /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: https://github.com/auth0-samples/auth0-django-web-app/tree/master/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/.
        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..9bb9f18b72
--- /dev/null
+++ b/articles/quickstart/webapp/express/interactive.md
@@ -0,0 +1,66 @@
+---
+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: https://github.com/auth0-samples/auth0-express-webapp-sample/tree/master/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/.
        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.
+
+:::note
+You can generate a suitable string for `LONG_RANDOM_STRING` using `openssl rand -hex 32` on the command line.
+:::
+
+::::checkpoint
+:::checkpoint-default
+A user can now log into your application by visiting the `/login` route provided by the library. If you are running your project on `localhost:3000` that link would be `http://localhost:3000/`.
+:::
+:::checkpoint-failure
+Sorry about that. You should check the error details on the Auth0 login page to make sure you have entered the callback URL correctly.
+
+Still having issues? Check out our documentation 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
new file mode 100644
index 0000000000..7be35ad94b
--- /dev/null
+++ b/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 and 
+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. 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 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.
+
+## 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.
+
+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.
+:::
+
+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 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/articles/quickstart/webapp/golang/download.md b/articles/quickstart/webapp/golang/download.md
new file mode 100644
index 0000000000..b2a7add4d8
--- /dev/null
+++ b/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 to:
+
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the Application Settings to:
+
+```text
+http://localhost:3000
+```
+
+3) Make sure Go 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 image with the following commands:
+
+```bash
+# In Linux / macOS
+sh exec.sh
+# In Windows' Powershell
+./exec.ps1
+```
diff --git a/articles/quickstart/webapp/golang/files/auth.md b/articles/quickstart/webapp/golang/files/auth.md
new file mode 100644
index 0000000000..bd316c62dc
--- /dev/null
+++ b/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/articles/quickstart/webapp/golang/files/callback.md b/articles/quickstart/webapp/golang/files/callback.md
new file mode 100644
index 0000000000..c0abe39ef0
--- /dev/null
+++ b/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/articles/quickstart/webapp/golang/files/env.md b/articles/quickstart/webapp/golang/files/env.md
new file mode 100644
index 0000000000..e777b2df02
--- /dev/null
+++ b/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/articles/quickstart/webapp/golang/files/go-mod.md b/articles/quickstart/webapp/golang/files/go-mod.md
new file mode 100644
index 0000000000..636aa7c45f
--- /dev/null
+++ b/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/articles/quickstart/webapp/golang/files/go.md b/articles/quickstart/webapp/golang/files/go.md
new file mode 100644
index 0000000000..ccdace1ba9
--- /dev/null
+++ b/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/articles/quickstart/webapp/golang/files/isAuthenticated.md b/articles/quickstart/webapp/golang/files/isAuthenticated.md
new file mode 100644
index 0000000000..9613366e02
--- /dev/null
+++ b/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/articles/quickstart/webapp/golang/files/login.md b/articles/quickstart/webapp/golang/files/login.md
new file mode 100644
index 0000000000..67dc5740d9
--- /dev/null
+++ b/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/articles/quickstart/webapp/golang/files/logout.md b/articles/quickstart/webapp/golang/files/logout.md
new file mode 100644
index 0000000000..a239d207be
--- /dev/null
+++ b/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/articles/quickstart/webapp/golang/files/main.md b/articles/quickstart/webapp/golang/files/main.md
new file mode 100644
index 0000000000..5dcf244bcd
--- /dev/null
+++ b/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/articles/quickstart/webapp/golang/files/router.md b/articles/quickstart/webapp/golang/files/router.md
new file mode 100644
index 0000000000..bcb15eb5ff
--- /dev/null
+++ b/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/articles/quickstart/webapp/golang/files/user.md b/articles/quickstart/webapp/golang/files/user.md
new file mode 100644
index 0000000000..9976a1a8a3
--- /dev/null
+++ b/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/articles/quickstart/webapp/golang/index.yml b/articles/quickstart/webapp/golang/index.yml
new file mode 100644
index 0000000000..38a4052a43
--- /dev/null
+++ b/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/articles/quickstart/webapp/golang/interactive.md b/articles/quickstart/webapp/golang/interactive.md
new file mode 100644
index 0000000000..a621fc3149
--- /dev/null
+++ b/articles/quickstart/webapp/golang/interactive.md
@@ -0,0 +1,83 @@
+---
+title: Add Login to your Go Application
+description: This guide demonstrates how to integrate Auth0 with any new or existing Go web application.
+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: https://github.com/auth0-samples/auth0-golang-web-app/tree/master/01-Login
+locale: en-US
+---
+
+# Add Login to your Go Application
+
+
+
        Auth0 allows you to add authentication and gain access to user profile information in your application. This guide demonstrates how to integrate Auth0 with any new or existing Go web application.
        
+
+## 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.
        
+
+## Install dependencies {{{ data-action="code" data-code="go.mod" }}}
+
+
+
        Create a go.mod file to list all the dependencies in your application.
        To integrate Auth0 in a Go application, add the coreos/go-oidc/v3 and x/oauth2 packages.
        In addition to the OIDC and OAuth2 packages, add joho/godotenv, gin-gonic/gin, and gin-contrib/sessions.
        This example uses gin for routing, but you can use whichever router you want.
        Save the go.mod file with the necessary dependencies and install them using the following command in your terminal:
        go mod download
+
+
        
+
+
        
+
+## Configure the environment variables {{{ data-action="code" data-code=".env" }}}
+
+
+
        You must set the following environment variables in .env within the root of your project directory:
        • AUTH0_DOMAIN: The domain of your Auth0 tenant. Find your Auth0 Domain in the Auth0 Dashboard under your Application's Settings in the Domain field. For custom domains, set this to the value of your custom domain instead.
        • AUTH0_CLIENT_ID: The ID of the Auth0 Application you set up earlier in this quickstart. Find this in the Auth0 Dashboard under your Application's Settings in the Client ID field.
        • AUTH0_CLIENT_SECRET: The Secret of the Auth0 Application you set up earlier in this quickstart. Find this in the Auth0 Dashboard under your Application's Settings in the Client Secret field.
        • AUTH0_CALLBACK_URL: The URL used by Auth0 to redirect the user after successful authentication.
        
+
+## Configure OAuth2 and OpenID Connect packages {{{ data-action="code" data-code="auth.go" }}}
+
+
+
        Next, configure the OAuth2 and OpenID Connect packages.
        Create a file called auth.go in the platform/authenticator folder. In this package, create a method to configure and return OAuth2 and OIDC clients, and another one to verify an ID Token.
        
+
+## Set up your application routes {{{ data-action="code" data-code="router.go" }}}
+
+
+
        Create a file called router.go in the platform/router folder. In this package, create a method to configure and return our routes using github.com/gin-gonic/gin. You will be passing an instance of Authenticator to the method, for use with the login and callback handlers.
        
+
+## Add login to your application {{{ data-action="code" data-code="login.go" }}}
+
+
+
        For the user to authenticate themselves, we need to create a handler function to handle the /login route.
        Create a file called login.go in the web/app/login folder, and add a Handler function. Upon executing the handler, the user will be redirected to Auth0 where they can enter their credentials.
        To call the /login route, add a link to /login in the home.html template located in the web/template directory.
        
+
+## Handle authentication callback {{{ data-action="code" data-code="callback.go" }}}
+
+
+
        Once users have authenticated using Auth0's Universal Login Page, they will return to the app at the /callback route.
        Create a file called callback.go in the web/app/callback folder, and add a Handler function.
        This handler will take the code query string, provided by Auth0, and exchange it for an ID token and an access token.
        If the ID token is valid, it will store the profile information and access token in the session. The profile information is based on the claims contained in the ID token. Session storage allows the application to access that information as needed.
        
+
+## Display user profile information {{{ data-action="code" data-code="user.go" }}}
+
+
+
        Now that your users can log in, you will likely want to be able to retrieve and use the profile information associated with authenticated users.
        You can access that profile information, such as their nickname or profile picture, through the profile that was stored in the session previously.
        Create a handler for the /user endpoint in web/app/user/user.go and return the corresponding HTML file. As the profile is being passed to ctx.HTML(), you can access the profile information such as picture and nickname inside that same HTML file.
        An example of such an HTML file could look like the example below, but you can retrieve any profile information, including custom claims.
        
+
+## Add logout to your application {{{ data-action="code" data-code="logout.go" }}}
+
+
+
        To log the user out, clear the data from the session and redirect the user to the Auth0 logout endpoint. You can find more information about this in the logout documentation.
        Create a file called logout.go in the folder web/app/logout, and add the function Handler to redirect the user to Auth0's logout endpoint.
        The returnTo URL needs to be in the list of Allowed Logout URLs in the settings section of the application, For more information, see Redirect Users After Logout.
        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.
        
+
+## Protect routes {{{ data-action="code" data-code="isAuthenticated.go" }}}
+
+
+
        Recommended practice dictates certain routes are accessible only to authenticated users. When unauthenticated users try accessing protected routes, your application should redirect them.
        In this case, you will implement middleware to hook into the HTTP request. The middleware function determines if the request should route to the endpoint handler or block the request.
        Create a file called isAuthenticated.go in platform/middleware and add a function that checks if the user is authenticated or not based on the profile session key. If the user is not authenticated, the middleware will redirect the user to the root of the application.
        With the middleware created, we can set it up for any route that needs authentication by adding it to the router.
        
+
+## Serve your application {{{ data-action="code" data-code="main.go" }}}
+
+
+
        With both the authenticator and router configured, we can wire things up using our application's entry point. Inside main.go, create an instance of the authenticator and the router, which gets passed the authenticator instance.
        If you are using a .env file, you must call godotenv.Load() at the very beginning of the main() function.
        Serve your application by using the following command in your terminal:
        go run main.go
        
diff --git a/articles/quickstart/webapp/java-ee/01-login.md b/articles/quickstart/webapp/java-ee/01-login.md
new file mode 100644
index 0000000000..c788d7b41a
--- /dev/null
+++ b/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/articles/quickstart/webapp/java-ee/_includes/_login.md b/articles/quickstart/webapp/java-ee/_includes/_login.md
new file mode 100644
index 0000000000..9e4cc4722b
--- /dev/null
+++ b/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).
+- `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:
+
+```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 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.
+:::
+
+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 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 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 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 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..da9f06eb97
--- /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: https://github.com/auth0-samples/auth0-java-ee-sample/tree/master/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..f56ec70bb7
--- /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: https://github.com/auth0-samples/auth0-spring-boot-login-samples/tree/master/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/01-login.md b/articles/quickstart/webapp/java/01-login.md
new file mode 100644
index 0000000000..e8a096df04
--- /dev/null
+++ b/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/articles/quickstart/webapp/java/_includes/_login.md b/articles/quickstart/webapp/java/_includes/_login.md
new file mode 100644
index 0000000000..754b9e4d74
--- /dev/null
+++ b/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 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 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 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.
+
+![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/articles/quickstart/webapp/java/_includes/_setup.md b/articles/quickstart/webapp/java/_includes/_setup.md
new file mode 100644
index 0000000000..753e49ee3a
--- /dev/null
+++ b/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 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.+'
+```
+
+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.
+
+
+::: 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/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
new file mode 100644
index 0000000000..77afc30ff0
--- /dev/null
+++ b/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/articles/quickstart/webapp/java/interactive.md b/articles/quickstart/webapp/java/interactive.md
new file mode 100644
index 0000000000..4043517a9f
--- /dev/null
+++ b/articles/quickstart/webapp/java/interactive.md
@@ -0,0 +1,165 @@
+---
+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: https://github.com/auth0-samples/auth0-servlet-sample/tree/master/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/.
        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.
+
+
+::: panel Check populated attributes
+If you downloaded this sample using the **Download Sample** button, the `domain`, `clientId` and `clientSecret` attributes will be populated for you. You should verify that the values are correct, especially if you have multiple Auth0 applications in your account.
+:::
+
+### Project structure
+
+The example project, which can be downloaded using the **Download Sample** button, has the following structure:
+
+```text
+- src
+-- main
+
+---- java
+
+------ com
+
+-------- auth0
+
+---------- example
+
+------------ Auth0Filter.java
+
+------------ AuthenticationControllerProvider.java
+
+------------ HomeServlet.java
+
+------------ CallbackServlet.java
+
+------------ LoginServlet.java
+
+------------ LogoutServlet.java
+
+---- webapp
+
+------ WEB-INF
+
+-------- jsp
+
+---------- home.jsp
+
+-------- web.xml
+
+- build.gradle
+
+
        
+
+
        The project contains a single JSP: the home.jsp which will display the tokens associated with the user after a successful login and provide the option to logout.
        The project contains a WebFilter: the Auth0Filter.java which will check for existing tokens before giving the user access to our protected /portal/* path. If the tokens don't exist, the request will be redirected to the LoginServlet.
        The project contains also four servlets:
        • LoginServlet.java: Invoked when the user attempts to log in. The servlet uses the client_id and domain parameters to create a valid Authorize URL and redirects the user there.
        • CallbackServlet.java: The servlet captures requests to our Callback URL and processes the data to obtain the credentials. After a successful login, the credentials are then saved to the request's HttpSession.
        • HomeServlet.java: The servlet reads the previously saved tokens and shows them on the home.jsp resource.
        • LogoutServlet.java: Invoked when the user clicks the logout link. The servlet invalidates the user session and redirects the user to the login page, handled by the LoginServlet.
        • AuthenticationControllerProvider.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 {{{ data-action=code data-code="LogoutServlet.java#13:30" }}}
+
+To run the sample from a terminal, change the directory to the root folder of the project and execute the following line:
+
+```bash
+./gradlew clean appRun
+```
+
+After a few seconds, the application will be accessible on `http://localhost:3000/`. Try to access the protected resource http://localhost:3000/portal/home 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.
+
+![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/articles/quickstart/webapp/laravel/01-login.md b/articles/quickstart/webapp/laravel/01-login.md
new file mode 100644
index 0000000000..13bcb2ef85
--- /dev/null
+++ b/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:
+
+```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:
+
+```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 SDKs 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:
+
+```php
+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:
+
+```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. 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 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.
+
+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.
+
+```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.
+
+## 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 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.
+
+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.
+
+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/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
new file mode 100644
index 0000000000..3379252e0f
--- /dev/null
+++ b/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/articles/quickstart/webapp/laravel/interactive.md b/articles/quickstart/webapp/laravel/interactive.md
new file mode 100644
index 0000000000..2078a374eb
--- /dev/null
+++ b/articles/quickstart/webapp/laravel/interactive.md
@@ -0,0 +1,61 @@
+---
+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: https://github.com/auth0-samples/laravel/tree/bf356d877b5dae566286fc8400da94b8b4b0ac76/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.
        
+
+## 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:
        You should also create a new API:
        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.
        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.
        You can also require authenticated users to have specific permissions by combining this with Laravel's can middleware.
        
+
+## 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:
        
+
+## 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.
        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/nextjs/01-login.md b/articles/quickstart/webapp/nextjs/01-login.md
new file mode 100644
index 0000000000..7bffa91d5f
--- /dev/null
+++ b/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@3
+```
+
+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, add the file `.env.local` with the following 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, 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.
+
+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. If you're using the Pages Router, check out the example in the SDK's README.
+:::
+
+### 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 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. 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 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. Add a link that points to the `/api/auth/logout` API route. Clicking it redirects your users to your Auth0 logout endpoint (`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 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/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 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 `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 in more advanced use cases:
+
+- Protecting a Server Side Rendered (SSR) Page
+- Protecting a Client Side Rendered (CSR) Page
+- Protect an API Route
+- Access an External API from an API Route
diff --git a/articles/quickstart/webapp/nextjs/download.md b/articles/quickstart/webapp/nextjs/download.md
new file mode 100644
index 0000000000..e1adb730a4
--- /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/api/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..515f3b4950
--- /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_ISSUER_BASE_URL='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..ad6a5b3b9a
--- /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 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/articles/quickstart/webapp/nextjs/interactive.md b/articles/quickstart/webapp/nextjs/interactive.md
new file mode 100644
index 0000000000..9ce73ba2a8
--- /dev/null
+++ b/articles/quickstart/webapp/nextjs/interactive.md
@@ -0,0 +1,64 @@
+---
+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: https://github.com/auth0-samples/auth0-nextjs-samples/tree/main/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:
+
+```sh
+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_ISSUER_BASE_URL: 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..85e6a01551
--- /dev/null
+++ b/articles/quickstart/webapp/nginx-plus/interactive.md
@@ -0,0 +1,75 @@
+---
+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
+github:
+  path: https://github.com/nginxinc/nginx-openid-connect
+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/php/01-login.md b/articles/quickstart/webapp/php/01-login.md
new file mode 100644
index 0000000000..a9fcff579a
--- /dev/null
+++ b/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 for a more robust example.
+
+### Installing HTTP Client and Messaging Factories
+
+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.
+
+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
+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->usernickname`, or their email address from `$session->useremail`. The structure is a normalized user profile, which you can learn more about here.
+
+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 (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
new file mode 100644
index 0000000000..2613a515a4
--- /dev/null
+++ b/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/articles/quickstart/webapp/php/interactive.md b/articles/quickstart/webapp/php/interactive.md
new file mode 100644
index 0000000000..7f4905f4b5
--- /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: https://github.com/auth0-samples/auth0-php-web-app/tree/main/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
new file mode 100644
index 0000000000..63d9cca243
--- /dev/null
+++ b/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 OAuth library and Flask.
+
+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.
+
+## 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.
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
new file mode 100644
index 0000000000..b94c1a9d6d
--- /dev/null
+++ b/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/articles/quickstart/webapp/python/interactive.md b/articles/quickstart/webapp/python/interactive.md
new file mode 100644
index 0000000000..546b91f9d5
--- /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: https://github.com/auth0-samples/auth0-python-web-app/tree/master/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
new file mode 100644
index 0000000000..b7bc1e8981
--- /dev/null
+++ b/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, 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 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, 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. 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.  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 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/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/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
new file mode 100644
index 0000000000..35e85c2158
--- /dev/null
+++ b/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/articles/quickstart/webapp/rails/interactive.md b/articles/quickstart/webapp/rails/interactive.md
new file mode 100644
index 0000000000..680d7f6677
--- /dev/null
+++ b/articles/quickstart/webapp/rails/interactive.md
@@ -0,0 +1,133 @@
+---
+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: https://github.com/auth0-samples/auth0-rubyonrails-sample/tree/master/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.
+
+
        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/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/_includes/_context-prop-request.md b/articles/rules/_includes/_context-prop-request.md
new file mode 100644
index 0000000000..7ebe99591c
--- /dev/null
+++ b/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/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/context.md b/articles/rules/context.md
deleted file mode 100644
index 59cd460ddb..0000000000
--- a/articles/rules/context.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-description: Lists the properties that are available for the context argument when creating rules.
----
-
-# Context Argument Properties in Rules
-
-When creating [Rules](/rules), the following properties are available for the `context' argument:
-
-* `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`: is an object, whose keys and values are strings, for holding other client properties.
-* `connection`: the name of the connection used to authenticate the user (e.g.: `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), etc.
-* `jwtConfiguration`: an object to configure how Json Web Tokens (JWT) will be generated:
-  * `lifetimeInSeconds`: expiration of the token.
-  * `scopes`: predefined scopes values (e.g.: `{ 'images': ['picture', 'logo'] }` this scope value will request access to the picture and logo claims).
-* `protocol`: 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
-  * `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
-* `request`: an object containing useful information of the request. It has the following properties:
-  * `query`: the querystring 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.
-  * `userAgent`: the user-agent of the client that is trying to log in.
-  * `ip`: the originating IP address of the user trying to log in.
-* `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).
-* `sso`: 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.
-* `stats`: an object containing specific user stats, like `stats.loginsCount`.
-* `hostname`: the hostname that is being used for the authentication flow.
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
index 1448037c9b..87116867e7 100644
--- a/articles/rules/index.md
+++ b/articles/rules/index.md
@@ -1,252 +1,76 @@
 ---
-url: /rules
+description: Learn what Rules are and how you can use them to customize and extend Auth0's capabilities.
 toc: true
-description: 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.
+topics:
+  - rules
+  - extensibility
+contentType:
+  - reference
+  - concept
+  - index
+useCase: 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.
+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.
 
-![](/media/articles/rules/flow.png)
+Please note that rules also run during the [token refresh](/tokens/concepts/refresh-tokens) flow.
 
-* **Step 1:** An app initiates an authentication request to Auth0.
-* **Step 2:** Auth0 routes the request to an Identity Provider through a configured connection.
-* **Step 3:** The user authenticates successfully.
-* **Step 4:** The `user` object representing the logged in user is passed through the Rules pipeline, and returned to the app.
+## Authentication transaction flow
 
-Among many possibilities, Rules can be used to:
+![Rule Flow](/media/articles/rules/flow.png)
 
-* __Profile enrichment__: query for information on the user from a database/API, and add it to the user profile object.
+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/metadata-in-rules).)
-* Enable __multifactor__ authentication, based on context (e.g. last login, IP address of the user, location, etc.).
-
-**NOTE:** You can find more examples of common Rules on Github at [auth0/rules](https://github.com/auth0/rules).
+* 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.
 
-## Video: Using Rules
-Watch this video learn all about rules in just a few minutes.
+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.
 
-<%= include('../videos/_video', { id: 'g7dy1fpwc3' }) %>
+::: 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).
+:::
 
-## Rule Syntax
+## 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. (A complete list of context properties is available here: [Context Argument Properties in Rules](/rules/context).)
-* `callback`: a function to send back the potentially modified `user` and `context` objects back to Auth0 (or an error).
-
-**NOTE:** 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.
-
-### *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.
-
-### 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
-}
-```
-
-> 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);
-}
-```
+* `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.)
 
-This will cause a redirect to your callback url with an `error` querystring parameter containing the message you set. (e.g.: `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`).
+* `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.
 
-> 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`.
+* `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.
 
-### Creating a new Rule using the Management API
+## Execution order
 
-Rules can also be created by creating a POST request to `/api/v2/rules` using the [Management APIv2](/api/management/v2#!/Rules/post_rules).
+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.
 
-This will creates a new rule according to the JSON object received in body, which contains:
-
-**name**: A `string` value, this field is the name of the rule. Can only contain alphanumeric characters, spaces and '-'. Can neither start nor end with '-' or spaces.
-
-**script**: A `string` value this is the script that contains the rule's code, as seen in some of the examples on this page. 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 if the rule will be turned on, false otherwise.
-
-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}"
-  }
-}
-```
-
-## Debugging
-
-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:
-
-![](/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.
-
-![](/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.
-
-## Caching 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.
+::: 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
 
-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).
+<%= include('./_includes/_supported-modules.md') %> 
 
-## Further reading
+## Keep reading
 
-* [Redirecting users from within rules](/rules/redirect)
+* [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/metadata-in-rules.md b/articles/rules/metadata-in-rules.md
deleted file mode 100644
index a489c021b4..0000000000
--- a/articles/rules/metadata-in-rules.md
+++ /dev/null
@@ -1,432 +0,0 @@
----
-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`
-
-`client_metadata` is an optional, top-level property of the Client object. Existing clients will have no value for this property.
-
-```js
-function(client, context, callback){
-  client.client_metadata = client.client_metadata || {};
-  if (client.client_metadata.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 clients with `client_metadata` properties**
-
-A `client_metadata` object can be included when creating a new client via the `POST /api/v2/`clients endpoint.
-
-**Creating `client_metadata` properties in the dashboard**
-
-`client_metadata` key value pairs can also be added in [the dashboard](${manage_url}/#/clients), by going to **Clients**. Then select the settings(the gear icon) of the client 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 client 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`
-
-Client metadata can be updated using the [`PATCH /api/v2/clients/{id}`](/api/management/v2#!/Users/patch_users_by_id) endpoint, supplying a client object with the `client_metadata property`, whose value is an object containing the metadata you'd like to change.
-
-*Client Before*
-```
-{
-  ...
-  "name": "myclient",
-  "client_metadata": {
-    "mycolor": "red",
-    "myflavor": "grape"
-  }
-  ...
-}
-```
-
-Request: `PATCH /api/v2/client/myclientid123` with body:
-
-```
-{ "client_metadata": { "mycolor": "blue" } }
-```
-
-*Client After*
-```
-{
-  "name": "myclient",
-  "client_metadata": {
-    "mycolor": "blue",
-    "myflavor": "grape"
-  }
-  ...
-}
-```
-
-**Updating `client_metadata` in the dashboard**
-
-Client metadata can also be updated in [the dashboard](${manage_url}/#/clients), by going to **Clients**. Then select the settings(the gear icon) of the client 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-client_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}/#/clients), by going to **Clients**. Then select the settings(the gear icon) of the client 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 client 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.
diff --git a/articles/rules/redirect.md b/articles/rules/redirect.md
deleted file mode 100644
index 0cf9467810..0000000000
--- a/articles/rules/redirect.md
+++ /dev/null
@@ -1,143 +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 (e.g. proprietary multifactor authentication providers).
-* Forcing users to change passwords.
-
-::: panel-danger Caution:
-Redirect rules won't work for the [Resource Owner endpoint](/api/authentication/reference#resource-owner) authentication endpoint.
-You can detect resource owner logins from a rule by checking `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.
-
-## What to do after redirecting
-
-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
-```
-
-When a user has been redirected to the `/continue` endpoint, all rules will be run again.
-
-::: panel-danger Caution:
-Make sure to send back the original state to the `/continue` endpoint, otherwise Auth0 will lose the context of the login transaction.
-:::
-
-
-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
-    }
-}
-```
-
-## Securely processing results after redirecting
-
-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
-      };
-    }
-  } 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
-
-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 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.
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
new file mode 100644
index 0000000000..e510f4a386
--- /dev/null
+++ b/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/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/index.md b/articles/scopes/index.md
deleted file mode 100644
index c04d52d2e8..0000000000
--- a/articles/scopes/index.md
+++ /dev/null
@@ -1,64 +0,0 @@
----
-description: Overview of scopes with a client-side authorization transaction.
----
-
-# Scopes
-
-When initiating a [client-side authorization transaction](/protocols#oauth-for-native-clients-and-javascript-in-the-browser) 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.
-
-
        -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:
-
-
-
        -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` (not recommended): will return all the user attributes in the token.
-This can cause problems when sending or receiving tokens in URLs (e.g. 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.
-
-> The `scope` parameter can used in the same way when calling the [Resource Owner endpoint](/api/authentication/reference#resource-owner).
-
-
-## Further reading
-
-* [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/articles/scopes/index.yml b/articles/scopes/index.yml
new file mode 100644
index 0000000000..effcc8c22d
--- /dev/null
+++ b/articles/scopes/index.yml
@@ -0,0 +1,9 @@
+versioning:
+  baseUrl: scopes
+  current: current
+  versions:
+    - legacy
+    - current
+  defaultArticles:
+    legacy: index
+    current: index
diff --git a/articles/scopes/legacy/index.md b/articles/scopes/legacy/index.md
new file mode 100644
index 0000000000..7fceba1b84
--- /dev/null
+++ b/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/articles/security/blacklisting-attributes.md b/articles/security/blacklisting-attributes.md
new file mode 100644
index 0000000000..32b85c318a
--- /dev/null
+++ b/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/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
new file mode 100644
index 0000000000..2dd3913dfc
--- /dev/null
+++ b/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/articles/security/bulletins/cve-2017-17068.md b/articles/security/bulletins/cve-2017-17068.md
new file mode 100644
index 0000000000..9721c1184b
--- /dev/null
+++ b/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/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
new file mode 100644
index 0000000000..546d8d75b7
--- /dev/null
+++ b/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/articles/security/bulletins/cve-2018-6874.md b/articles/security/bulletins/cve-2018-6874.md
new file mode 100644
index 0000000000..c90b549af7
--- /dev/null
+++ b/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/articles/security/bulletins/cve-2018-7307.md b/articles/security/bulletins/cve-2018-7307.md
new file mode 100644
index 0000000000..7887c5fd03
--- /dev/null
+++ b/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/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
new file mode 100644
index 0000000000..63ad7bf6e1
--- /dev/null
+++ b/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/articles/security/common-threats.md b/articles/security/common-threats.md
index 35aeec5b3c..2da556c201 100644
--- a/articles/security/common-threats.md
+++ b/articles/security/common-threats.md
@@ -1,42 +1,63 @@
 ---
-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. 
+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 client 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, etc. This could also lead to the compromise of other network assets.
+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 client and the server. Using encryption the server authenticates the client'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.
+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 client base can support. The more modern configurations provide stronger ciphers to help prevent attacks.
+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)
\ No newline at end of file
+## 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 583633efd2..829e78deb8 100644
--- a/articles/security/index.md
+++ b/articles/security/index.md
@@ -1,29 +1,47 @@
 ---
 url: /security
 classes: topic-page
-title: Auth0 Security Fundamentals
-description: Learn about various topics regarding how to handle sensitive data when using Auth0 services.
+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 Fundamentals
        
+  
        Auth0 Security
        
   
        
-    Learn about various topics regarding how to handle sensitive data when using Auth0 services.
+    Read about various security-related topics and keep up-to-date with released Auth0 security bulletins
   
        
 
        
 
-## Handling Tokens
+## Security bulletins
+
+<%= include('../_includes/_topic-links', { links: [
+  'security/bulletins'
+] }) %>
+
+## Handling tokens
 
 <%= include('../_includes/_topic-links', { links: [
-  'security/store-tokens',
-  'security/token-exp',
-  'tokens/refresh-token'
+  'tokens',
+  'tokens/concepts/token-storage'
 ] }) %>
 
-## Preventing Security Attacks
+## Preventing security attacks
 
 <%= include('../_includes/_topic-links', { links: [
   'security/common-threats'
 ] }) %>
 
+## Data privacy
+
+<%= include('../_includes/_topic-links', { links: [
+  'security/blacklisting-attributes'
+] }) %>
diff --git a/articles/security/store-tokens.md b/articles/security/store-tokens.md
deleted file mode 100644
index 856dee1555..0000000000
--- a/articles/security/store-tokens.md
+++ /dev/null
@@ -1,41 +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
-
-We strongly recommend that you store your tokens in session storage/local storage or a cookie.
-
-### Web Storage (localStorage/sessionStorage)
-
-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.
-
-### 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.
-
-**Additional Resources:**
-
-[Auth0 Blog: 10 Things You Should Know about Tokens](https://auth0.com/blog/ten-things-you-should-know-about-tokens-and-cookies/)
diff --git a/articles/security/token-exp.md b/articles/security/token-exp.md
deleted file mode 100644
index 513edd5ca7..0000000000
--- a/articles/security/token-exp.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-description: Lists the expiration of different types of tokens that are referenced in Auth0 documentation. 
----
-
-# Token Expiration 
-
-This document states the expiration of different types of tokens that are referenced in Auth0 documentation. [Click here to learn more about the types of tokens.](/tokens)
-
-## The Management APIv1 Access Token
-
- The default token expiration for APIv1 access tokens is 24 hours. For tokens issued for user defined APIs the expiration can be changed in the [Auth0 Management API Settings](${manage_url}/#/apis/management/settings) section in the dashboard.
-
-[Learn more about Auth0 access tokens](tokens/access_token)
-
-## Auth0 Management APIv2 Token
-
- The default token expiration for APIv2 access tokens is 24 hours. For tokens issued for user defined APIs the expiration can be changed in the [Auth0 Management API Settings](${manage_url}/#/apis/management/settings) section in the dashboard.
-
-[Learn more about the Auth0 Management APIv2 Token](/api/management/v2/tokens)
-
-## Identity Provider Access Tokens
-
-Since these 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. 
-
-[Learn more about IdP tokens](tokens/idp)
-
-## Id Tokens Issued by Auth0
-
-An `id_token` issued by Auth0 is valid for **10 hours (36000 seconds) by default**. The expiration of this token can be set in the Apps/APIs -> Settings screen using the JWT expiration field.
-
-[Learn more about id_tokens issued by Auth0](id_token)
-
-## Auth0 Refresh Tokens 
-
-An Auth0 `refresh_token` **never expires** it is used to obtain a new `id_token` which do expire. Refresh tokens must be stored securely by an application since they allow a user to remain authenticated essentially forever. If you think a refresh token may have been compromised, you can [revoke or obtain a new token.](/refresh-token#obtain-a-refresh-token).
-
-[Learn more about Auth0 refresh tokens](refresh-token)
-
-## Delegation Tokens
-
-For customer application APIs registered in Auth0, the validity of a delegation token issued for that target is governed by the JWT Expiration (seconds) value. This is set for each application in Applications > Settings.
-
-For APIs registered as Addons in Auth0, the validity period of the token will vary by individual Addon. The documentation available from the provider of any Addon API should be consulted for further information on tokens and expirations.
-
-[Learn more about Delegation Tokens](/tokens/delegation)
diff --git a/articles/server-apis/_thirdPartyApi.md b/articles/server-apis/_thirdPartyApi.md
deleted file mode 100644
index 54810dd7f3..0000000000
--- a/articles/server-apis/_thirdPartyApi.md
+++ /dev/null
@@ -1,24 +0,0 @@
-# <%= meta.name %> API
-
-Please follow the steps below to configure your Auth0 account 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/articles/server-apis/aspnet-core-webapi/00-intro.md b/articles/server-apis/aspnet-core-webapi/00-intro.md
deleted file mode 100644
index 1596a99c77..0000000000
--- a/articles/server-apis/aspnet-core-webapi/00-intro.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: Introduction
-name: Introduction to the Quickstart, and configuring environment
-description: This Quickstart will guide you through the various tasks related to using Auth0-issued JSON Web Tokens to secure your ASP.NET Core Web API.
-budicon: 715
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnetcore-webapi-sample',
-  path: '00-Starter-Seed',
-  requirements: [
-    '.NET Core 1.0',
-    'Visual Studio 2015 Update 3 (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 & 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-sample/tree/master/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 [Sample repository](https://github.com/auth0-samples/auth0-aspnetcore-webapi-sample). You can find the final result for each step in the relevant folder inside the repository.
-
-## 1. Enable OAuth 2.0 API Authorization
-
-<%= include('../../_includes/_configure_oauth2aas') %>
-
-## 2. Create a Resource Server (API)
-
-In the [APIs section](${manage_url}/#/apis) of the Auth0 Dashboard, click the **Create API** button. Provide a **Name** and **Identifier** for your API. Be sure to choose the RS256 signing algorithm.
-
-![Create API](/media/articles/server-apis/aspnet-core-webapi/create-api-rs256.png)
-
-Also, update the `appsettings.json` file in your project with the correct **Domain** and **API Identifier** for your API, e.g.
-
-```json
-{
-  "Auth0": {
-    "Domain": "${account.namespace}",
-    "ApiIdentifier": "YOUR_API_IDENTIFIER"
-  }
-}
-```
-
-## 3. 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
-```
-
-This was already done for you in the seed project, so no need to add it if you are using the seed project as a starting point.
-
-That's all you need to start working with Auth0 in your Web API!
-
-Please continue with the [Authentication](/quickstart/backend/aspnet-core-webapi/01-authentication) tutorial to secure your Web API.
diff --git a/articles/server-apis/aspnet-core-webapi/01-authentication.md b/articles/server-apis/aspnet-core-webapi/01-authentication.md
deleted file mode 100644
index b3fb2af6d7..0000000000
--- a/articles/server-apis/aspnet-core-webapi/01-authentication.md
+++ /dev/null
@@ -1,117 +0,0 @@
----
-title: Authentication
-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',
-  repo: 'auth0-aspnetcore-webapi-sample',
-  path: '01-Authentication',
-  requirements: [
-    '.NET Core 1.0',
-    'Visual Studio 2015 Update 3 (Optional)',
-    'Visual Studio Code (Optional)'
-  ]
-}) %>
-
-## 1. Configure the JWT Middleware
-
-Add the JWT middleware to your application's middleware pipeline in order to enable authentication with a JSON Web Token.
-
-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
-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();
-}
-```
-
-### Signature Validation
-
-Before we carry on, a quick word about the verification of the JWT, as the configuration above may at first glance seem very simplistic.
-
-The JWT middleware will automatically use the `Authority` to verify the issuer of the JWT, and the `Audience` to verify the audience. These values need match the values in the token exactly, so ensure you specify the trailing backslash (`/`) for the `Authority` as this is a fairly common reason for tokens not verifying correctly.
-
-Next, it will seem as though the JWT middleware configuration above is insecure since the signature is not explicitly verified anywhere. This is however not true, as the JWT middleware will interrogate the `/.well-known/openid-configuration` endpoint at the URL specified in the `Authority` property to discover the JSON Web Key Set (JWKS) document. It will then download the JSON Web Key which is subsequently used to verify the token.
-
-This can be confirmed by looking at the Fiddler trace in the screenshot below. Notice that the first time a call is made to the API, that the JWT middleware downloads the JWKS document:
-
-![Fiddler trace of retrieval of JWK](/media/articles/server-apis/aspnet-core-webapi/fiddler.png)
-
-If someone tries to create a JWT with another key, the signature verification will fail:
-
-![Console output with incorrectly signed JWT](/media/articles/server-apis/aspnet-core-webapi/console-output.png)
-
-## 2. Securing an API endpoint
-
-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.
-
-You only need to decorate your controller action with the `[Authorize]` attribute to secure an endpoint:
-
-```csharp
-[Route("api")]
-public class PingController : Controller
-{
-    [Authorize]
-    [HttpGet]
-    [Route("ping/secure")]
-    public string PingSecured()
-    {
-        return "All good. You only get this message if you are authenticated.";
-    }
-}
-```
-
-## 3. Using your API
-
-In order to make calls to your API, you will need to obtain an `access_token`. An `access_token` can be obtained in a number of ways, depending on the type of application you are building. These are referred to as authorization grant flows, and you can refer to the [API Authorization section](/api-auth) for more information of the types of flows and to determine which one is most appropriate for your client application.
-
-Once you have obtained an `access_token` you can pass that along in the `Authorization` header of requests to your API as a Bearer token.
-
-Here is a sample RAW request:
-
-```text
-GET /api/ping/secure HTTP/1.1
-Host: localhost:5000
-Authorization: Bearer 
-```
-
-Or using [RestSharp](http://restsharp.org/):
-
-```csharp
-var client = new RestClient("http://localhost:5000/api/ping/secure");
-var request = new RestRequest(Method.GET);
-request.AddHeader("authorization", "Bearer ");
-IRestResponse response = client.Execute(request);
-```
-
-## 4. Testing your API in Postman
-
-During development, you may want to test your API with Postman. If you make a request to the `/ping/secure` endpoint you will notice that the API returns an HTTP status code 401 (Unauthorized):
-
-![Unauthorized request in Postman](/media/articles/server-apis/aspnet-core-webapi/postman-not-authorized.png)
-
-As mentioned in the previous step, you will need to pass along an `access_token` in the HTTP Authorization header. A quick and easy way to obtain an `access_token` for test purposes is from the __Test__ tab of your API settings: 
-
-![Obtain a JWT](/media/articles/server-apis/aspnet-core-webapi/request-access-token.png)
-
-You can then use the `access_token` and pass it along in the Authorization header as a Bearer token:
-
-![Authorized request in Postman](/media/articles/server-apis/aspnet-core-webapi/postman-authorized.png)
-
-## Next Step
-
-To learn how to allow only clients who were granted a certain `scope` access to a particular API endpoint, please continue with the [Authorization](/quickstart/backend/aspnet-core-webapi/02-authorization) tutorial.
diff --git a/articles/server-apis/aspnet-core-webapi/02-authorization.md b/articles/server-apis/aspnet-core-webapi/02-authorization.md
deleted file mode 100644
index b15aebe1f7..0000000000
--- a/articles/server-apis/aspnet-core-webapi/02-authorization.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-title: API Authorization 
-description: This tutorial will show you how authorize or deny a user to access certain API endpoints based on the scope of the access token.
-budicon: 500
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnetcore-webapi-sample',
-  path: '02-Authorization',
-  requirements: [
-    '.NET Core 1.0',
-    'Visual Studio 2015 Update 3 (Optional)',
-    'Visual Studio Code (Optional)'
-  ]
-}) %>
-
-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 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 query the `scope` claim to ensure that the required permissions were granted in order to call the particular API endpoint. The `scope` claim will contain the list of scopes separated by a space, as can be seen in the example JWT payload below:
-
-```json
-{
-  "iss": "https://auth0pnp.auth0.com/",
-  "sub": "5fJ...",
-  "aud": "https://api.myapp.com/timesheets",
-  "exp": 1479957385,
-  "iat": 1479870985,
-  "scope": "delete:timesheets update:timesheets create:timesheets read:timesheets"
-}
-```
-
-## 1. Define scopes
-
-You will need to define to list of scopes available in your application. In the [APIs section](${manage_url}/#/apis) of the Auth0 Dashboard, select your API and then go to the __Scopes__ tab of the API. Configure the list of Scopes available in your API:
-
-![Configure Scopes](/media/articles/server-apis/aspnet-core-webapi/create-api-scopes.png)
-
-Once you have created the list of scopes, go to the __Non Interactive Clients__ tab. For each client which is able to access your API, ensure that you have Authorized the client and selected the Scopes which can be granted to the Client. Be sure the click the **Update** button once you have configured the Client:
-
-![Configure Client](/media/articles/server-apis/aspnet-core-webapi/configure-api-client-scopes.png)
-
-## 2. Enforcing scopes in your ASP.NET Core API 
-
-To ensure that a correct `scope` is present in order to execute a particular API endpoint, you can make use of the new Policy-Based Authorization in ASP.NET Core. 
-
-::: panel-info ASP.NET Core Policy-Based Authorization
-For a better understanding of the code which follows, it is suggested that you read the ASP.NET Core documentation on [Policy-Based Authorization](https://docs.microsoft.com/en-us/aspnet/core/security/authorization/policies).
-:::
-
-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
-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
-public void ConfigureServices(IServiceCollection services)
-{
-    // Add framework services.
-    services.AddMvc();
-
-    string domain = $"https://{Configuration["Auth0:Domain"]}/";
-    services.AddAuthorization(options =>
-    {
-        options.AddPolicy("read:timesheets",
-            policy => policy.Requirements.Add(new HasScopeRequirement("read:timesheets", domain)));
-        options.AddPolicy("create:timesheets",
-            policy => policy.Requirements.Add(new HasScopeRequirement("create:timesheets", domain)));
-    });
-}
-```
-
-Finally, to ensure that a scope is present in order to call a particular API endpoint, you simply need to decorate the action with the `Authorize` attribute, and pass the name of the Policy for that `scope` in the `policy` parameter:
-
-```csharp
-[Route("api/timesheets")]
-public class TimesheetsController : Controller
-{
-    [Authorize("read:timesheets")]
-    [HttpGet]
-    public IActionResult GetAll()
-    {
-        // Return the list of timesheets
-    }
-
-    [Authorize("create:timesheets")]
-    [HttpPost]
-    public IActionResult Create(Timesheet timeheet)
-    {
-        // Create a new timesheet entry
-    }
-}
-```
-
-## 3. Testing the Authorization Postman
-
-You can test the API endpoints by generating a token with the required scopes, and passing the `access_token` as a Bearer token in the Authorization header. 
-
-If the required `scope` is present, the API call will succeed:
-
-![](/media/articles/server-apis/aspnet-core-webapi/scope-success.png)
-
-If the required `scope` is not present, an HTTP Status 403 (Forbidden) will be returned: 
-
-![](/media/articles/server-apis/aspnet-core-webapi/scope-forbidden.png)
diff --git a/articles/server-apis/aspnet-core-webapi/03-authentication-hs256.md b/articles/server-apis/aspnet-core-webapi/03-authentication-hs256.md
deleted file mode 100644
index 81334152f7..0000000000
--- a/articles/server-apis/aspnet-core-webapi/03-authentication-hs256.md
+++ /dev/null
@@ -1,137 +0,0 @@
----
-title: Authentication with HS256
-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',
-  repo: 'auth0-aspnetcore-webapi-sample',
-  path: '03-Authentication-HS256',
-  requirements: [
-    '.NET Core 1.0',
-    'Visual Studio 2015 Update 3 (Optional)',
-    'Visual Studio Code (Optional)'
-  ]
-}) %>
-
-::: panel-warning Signing Algorithm
-Auth0 can sign JSON Web Tokens (JWT) using either a symmetric key (HS256) or an asymmetric key (RS256). This document demonstrates how to use tokens signed with the HS256 Algorithm. 
-
-It is however recommended that you [rather use RS256](/quickstart/backend/aspnet-core-webapi/01-authentication) tutorial.
-:::
-
-## 1. Enable OAuth 2.0 API Authorization
-
-<%= include('../../_includes/_configure_oauth2aas') %>
-
-## 2. Create a Resource Server (API)
-
-In the [APIs section]("${manage_url}/#/apis) of the Auth0 Dashboard, click the **Create API** button. Provide a **Name** and **Identifier** for your API. Be sure to choose the HS256 signing algorithm.
-
-![Create API](/media/articles/server-apis/aspnet-core-webapi/create-api-hs256.png)
-
-After you have created the API, navigate to the **Settings** tab of the API, and take note of the **API Identifier** and **Signing Secret**, as it will be used configuring the JWT middleware.
-
-## 3. Update your settings
-
-When using HS256, you will need your API's **Signing Secret** when configuring the JWT middleware, so be sure update the `appsettings.json` file included in the seed project to also add an **ApiSecret** attribute with the value of the **Signing Secret**, and be sure to set the correct values for the **Domain** and **ApiIdentifier** attributes:
-
-```json
-{
-  "Auth0": {
-    "Domain": "${account.namespace}",
-    "ApiIdentifier": "YOUR_API_IDENTIFIER",
-    "ApiSecret": "YOUR_API_SECRET"
-  }
-}
-```
-
-## 4. Configure the JWT Middleware
-
-You will need 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 Domain as the `ValidIssuer`, the API Identifier as the `ValidAudience`, and the Signing Secret as the `IssuerSigningKey`:
-
-```csharp
-public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
-{
-    loggerFactory.AddConsole(Configuration.GetSection("Logging"));
-    loggerFactory.AddDebug();
-
-    var options = new JwtBearerOptions
-    {
-        TokenValidationParameters =
-        {
-            ValidIssuer = $"https://{Configuration["Auth0:Domain"]}/",
-            ValidAudience = Configuration["Auth0:ApiIdentifier"],
-            IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(Configuration["Auth0:ApiSecret"]))
-        }
-    };
-    app.UseJwtBearerAuthentication(options);
-
-    app.UseMvc();
-}
-```
-
-::: 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.
-:::
-
-## 5. Securing an API endpoint
-
-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.
-
-You only need to decorate your controller action with the `[Authorize]` attribute to secure an endpoint:
-
-```csharp
-[Route("api")]
-public class PingController : Controller
-{
-    [Authorize]
-    [HttpGet]
-    [Route("ping/secure")]
-    public string PingSecured()
-    {
-        return "All good. You only get this message if you are authenticated.";
-    }
-}
-```
-
-## 6. Using your API
-
-In order to make calls to your API, you will need to obtain an `access_token`. An `access_token` can be obtained in a number of ways, depending on the type of application you are building. These are referred to as authorization grant flows. Please see the [API Authorization section](/api-auth) for more information of the types of flows and to determine which one is most appropriate for your application.
-
-Once you have obtained an `access_token` you can pass that along in the `Authorization` header of requests to your API as a Bearer token.
-
-Here is a sample RAW request:
-
-```text
-GET /api/ping/secure HTTP/1.1
-Host: localhost:5000
-Authorization: Bearer 
-```
-
-Or using [RestSharp](http://restsharp.org/):
-
-```csharp
-var client = new RestClient("http://localhost:5000/api/ping/secure");
-var request = new RestRequest(Method.GET);
-request.AddHeader("authorization", "Bearer ");
-IRestResponse response = client.Execute(request);
-```
-
-## 7. Testing your API in Postman
-
-During development, you may want to test your API with Postman. If you make a request to the `/ping/secure` endpoint you will notice that the API returns an HTTP status code 401 (Unauthorized):
-
-![Unauthorized request in Postman](/media/articles/server-apis/aspnet-core-webapi/postman-not-authorized.png)
-
-As mentioned in the previous step, you will need to pass along an `access_token` in the HTTP Authorization header. A quick and easy way to obtain an `access_token` for test purposes is from the __Test__ tab of your API settings: 
-
-![Obtain a JWT](/media/articles/server-apis/aspnet-core-webapi/request-access-token.png)
-
-You can then use the `access_token` and pass it along in the Authorization header as a Bearer token:
-
-![Authorized request in Postman](/media/articles/server-apis/aspnet-core-webapi/postman-authorized.png)
diff --git a/articles/server-apis/aspnet-core-webapi/04-authentication-rs256-deprecated.md b/articles/server-apis/aspnet-core-webapi/04-authentication-rs256-deprecated.md
deleted file mode 100644
index 767a8cc57a..0000000000
--- a/articles/server-apis/aspnet-core-webapi/04-authentication-rs256-deprecated.md
+++ /dev/null
@@ -1,120 +0,0 @@
----
-title: Authentication
-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',
-  repo: 'auth0-aspnetcore-webapi-sample',
-  path: '04-Authentication-RS256-Deprecated',
-  requirements: [
-    '.NET Core 1.0'
-  ]
-}) %>
-
-Auth0 can sign JSON Web Tokens (JWT) using either a symmetric key (HS256) or an asymmetric key (RS256). This particular document will describe how to configure Auth0 to sign tokens using RS256.
-
-> If you want to use HS256 then please go to the [Authentication using HS256](/quickstart/backend/aspnet-core-webapi/05-authentication-hs256-deprecated) tutorial.
-
-## 1. Configure JSON Web Token Signature Algorithm
-
-To configure the JWT Signature Algorithm, 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.
-
-![Configure JWT Signature Algorithm as RS256](/media/articles/server-apis/aspnet-core-webapi/jwt-signature-rs256.png)
-
-## 2. Configure the JWT Middleware
-
-You will need 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 Client ID as the `Audience`, and the full path to your Auth0 domain as the `Authority`:
-
-```csharp
-public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
-{
-    var options = new JwtBearerOptions
-    {
-        Audience = Configuration["auth0:clientId"],
-        Authority = $"https://{Configuration["auth0:domain"]}/"
-    };
-    app.UseJwtBearerAuthentication(options);
-
-    app.UseMvc();
-}
-```
-
-### Signature Validation
-
-Before we carry on, a quick word about the verification of the JWT, as the configuration above may at first glance seem very simplistic.
-
-The JWT middleware will automatically use the `Authority` to verify the issuer of the JWT, and the `Audience` to verify the audience. These values need match the values in the token exactly, so ensure you specify the trailing backslash (`/`) for the `Authority` as this is a fairly common reason for tokens not verifying correctly.
-
-Next, it will seem as though the JWT middleware configuration above is insecure since the signature is not explicitly verified anywhere. This is however not true, as the JWT middleware will go to the `/.well-known/openid-configuration` endpoint at the URL specified in the `Authority` property to discover the JSON Web Key Set (JWK) document. It will then download the JSON Web Key which is used to subsequently verify the token.
-
-This can be confirmed by looking and the Fiddler trace in the screenshot below:
-
-![Fiddler trace of retrieval of JWK](/media/articles/server-apis/aspnet-core-webapi/fiddler.png)
-
-If someone tries to create a JWT with another key set the signature verification will fail:
-
-![Console output with incorrectly signed JWT](/media/articles/server-apis/aspnet-core-webapi/console-output.png)
-
-## 3. Secure an API endpoint
-
-The JWT middleware integrates with the standard ASP.NET Core [Authentication](https://docs.asp.net/en/latest/security/authentication/index.html) and [Authorization](https://docs.asp.net/en/latest/security/authorization/index.html) mechanisms.
-
-You only need to decorate your controller action with the `[Authorize]` attribute to secure an endpoint:
-
-```csharp
-[Route("api")]
-public class PingController : Controller
-{
-    [Authorize]
-    [HttpGet]
-    [Route("ping/secure")]
-    public string PingSecured()
-    {
-        return "All good. You only get this message if you are authenticated.";
-    }
-}
-```
-
-## 4. Use your API
-
-You can make calls to your API by authenticating a user using any of our Lock integrations and then using the `id_token` obtained during authentication and passing that in the `Authorization` header of requests to your API as a Bearer token.
-
-Here is a sample RAW request:
-
-```bash
-GET /ping/secure HTTP/1.1
-Host: localhost:5000
-Authorization: Bearer 
-```
-
-Or using [RestSharp](http://restsharp.org/):
-
-```csharp
-var client = new RestClient("http://localhost:5000/ping/secure");
-var request = new RestRequest(Method.GET);
-request.AddHeader("authorization", "Bearer ");
-IRestResponse response = client.Execute(request);
-```
-
-## 5. Test your API with Postman
-
-During development, you may want to test your API with Postman.
-
-If you make a request to the `/ping/secure` endpoint you will notice that the API returns an HTTP status code 401 (Unauthorized):
-
-![Unauthorized request in Postman](/media/articles/server-apis/aspnet-core-webapi/postman-not-authorized.png)
-
-As mentioned in the previous step, you will need to pass along an `id_token` in the HTTP Authorization header. A quick and easy way to obtain an `id_token` is to call the `/oauth/ro` endpoint using the Auth0 [Authentication API Explorer](/api/authentication/reference#resource-owner):
-
-![Obtain a JWT](/media/articles/server-apis/aspnet-core-webapi/request-jwt.png)
-
-Now you can use the `id_token` and pass it along in the Authorization header as a Bearer token:
-
-![Authorized request in Postman](/media/articles/server-apis/aspnet-core-webapi/postman-authorized.png)
diff --git a/articles/server-apis/aspnet-core-webapi/05-authentication-hs256-deprecated.md b/articles/server-apis/aspnet-core-webapi/05-authentication-hs256-deprecated.md
deleted file mode 100644
index 8ae5d6642d..0000000000
--- a/articles/server-apis/aspnet-core-webapi/05-authentication-hs256-deprecated.md
+++ /dev/null
@@ -1,132 +0,0 @@
----
-title: Authentication (HS256)
-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',
-  repo: 'auth0-aspnetcore-webapi-sample',
-  path: '05-Authentication-HS256-Deprecated',
-  requirements: [
-    '.NET Core 1.0'
-  ]
-}) %>
-
-Auth0 can sign JSON Web Tokens (JWT) using either a symmetric key (HS256) or an asymmetric key (RS256). This particular document will describe how to configure Auth0 to sign tokens using HS256.
-
-> If you want to use RS256 then please go to the [Authentication using RS256](/quickstart/backend/aspnet-core-webapi/01-authentication-rs256) tutorial.
-
-## 1. Configure JSON Web Token Signature Algorithm
-
-To configure the JWT Signature Algorithm, 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 **HS256**.
-
-Save your changes.
-
-![Configure JWT Signature Algorithm as HS256](/media/articles/server-apis/aspnet-core-webapi/jwt-signature-hs256.png)
-
-## 2. Update your settings
-
-When using HS256, you will need your application's **Client Secret** when configuring the JWT middleware, so be sure update the `appsettings.json` file included in the seed project to also add a **ClientSecret** attribute, and be sure to set the correct values for the **Domain**, **ClientId** and **ClientSecret** attributes:
-
-```json
-{
-  "Auth0": {
-    "Domain": "${account.namespace}",
-    "ClientId": "${account.clientId}",
-    "ClientSecret": "${account.clientSecret}"
-  }
-}
-```
-
-## 3. Configure the JWT Middleware
-
-You will need 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 Domain as the issuer, the Client ID as the Audience, and the Base64-decoded Client Secret as the issuer signing key:
-
-```csharp
-public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
-{
-    var secret = Encoding.UTF8.GetBytes(Configuration["auth0:clientSecret"]);
-
-    var options = new JwtBearerOptions
-    {
-        TokenValidationParameters =
-        {
-            ValidIssuer = $"https://{Configuration["auth0:domain"]}/",
-            ValidAudience = Configuration["auth0:clientId"],
-            IssuerSigningKey = new SymmetricSecurityKey(secret)
-        }
-    };
-    app.UseJwtBearerAuthentication(options);
-
-    app.UseMvc();
-}
-```
-
-::: 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.
-:::
-
-## 4. Secure an API endpoint
-
-The JWT middleware integrates with the standard ASP.NET Core [Authentication](https://docs.asp.net/en/latest/security/authentication/index.html) and [Authorization](https://docs.asp.net/en/latest/security/authorization/index.html) mechanisms.
-
-You only need to decorate your controller action with the `[Authorize]` attribute to secure an endpoint:
-
-```csharp
-[Route("api")]
-public class PingController : Controller
-{
-    [Authorize]
-    [HttpGet]
-    [Route("ping/secure")]
-    public string PingSecured()
-    {
-        return "All good. You only get this message if you are authenticated.";
-    }
-}
-```
-
-## 5. Use your API
-
-You can make calls to your API by authenticating a user using any of our Lock integrations and then using the `id_token` obtained during authentication and passing that in the `Authorization` header of requests to your API as a Bearer token.
-
-Here is a sample RAW request:
-
-```bash
-GET /ping/secure HTTP/1.1
-Host: localhost:5000
-Authorization: Bearer 
-```
-
-Or using [RestSharp](http://restsharp.org/):
-
-```csharp
-var client = new RestClient("http://localhost:5000/ping/secure");
-var request = new RestRequest(Method.GET);
-request.AddHeader("authorization", "Bearer ");
-IRestResponse response = client.Execute(request);
-```
-
-## 6. Test your API with Postman
-
-During development, you may want to test your API with Postman.
-
-If you make a request to the `/ping/secure` endpoint you will notice that the API returns an HTTP status code `401 Unauthorized`:
-
-![Unauthorized request in Postman](/media/articles/server-apis/aspnet-core-webapi/postman-not-authorized.png)
-
-As mentioned in the previous step, you will need to pass along an `id_token` in the HTTP Authorization header. A quick and easy way to obtain an `id_token` is to call the `/oauth/ro` endpoint using the Auth0 [Authentication API Explorer](/api/authentication/reference#resource-owner):
-
-![Obtain a JWT](/media/articles/server-apis/aspnet-core-webapi/request-jwt.png)
-
-Now you can use the `id_token` and pass it along in the Authorization header as a Bearer token:
-
-![Authorized request in Postman](/media/articles/server-apis/aspnet-core-webapi/postman-authorized.png)
-
-## Next Step
-
-To learn how to allow only users in a certain role to access a particular endpoint, please continue with the [Authorization](/quickstart/backend/aspnet-core-webapi/06-authorization-deprecated) tutorial.
diff --git a/articles/server-apis/aspnet-core-webapi/06-authorization-deprecated.md b/articles/server-apis/aspnet-core-webapi/06-authorization-deprecated.md
deleted file mode 100644
index 5f26307bf5..0000000000
--- a/articles/server-apis/aspnet-core-webapi/06-authorization-deprecated.md
+++ /dev/null
@@ -1,68 +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 API endpoints.
-budicon: 500
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnetcore-webapi-sample',
-  path: '06-Authorization-Deprecated',
-  requirements: [
-    '.NET Core 1.0'
-  ]
-}) %>
-
-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.
-
-## 1.Create a Rule to assign roles
-
-First, you must create a rule that assigns users either an `admin` role, or a single `user` role. To do so, go to the [new rule page](${manage_url}/#/rules/new) and select the "*Set Roles To A User*" template, under *Access Control*. Then, replace this line from the default script:
-
-```
-if (user.email.indexOf('@example.com') > -1)
-```
-
-to match the condition that fits your needs. Notice that you can also set more roles other than `admin` and `user`, or customize the whole rule as you please.
-
-By default, it says that if the user email contains `@example.com` he will be given an `admin` role, otherwise a regular `user` role.
-
-## 2. Restrict an action based on a user's roles
-
-ASP.NET Core will automatically map claims contained in the JWT to claims on the `ClaimsIdentity`. Specifically, it will look for a `roles` claim on the `id_token`, and then for each role inside the array on the "roles" claim, it will add a `http://schemas.microsoft.com/ws/2008/06/identity/claims/role` claim to the `ClaimsIdentity`.
-
-This means that it integrates seamlessly with the [Role based authorization](https://docs.asp.net/en/latest/security/authorization/roles.html) inside ASP.NET Core.
-
-Once the correct claims are returned from Auth0, all you have to do is decorate your controller actions with the `[Authorize(Roles = ?)]` attribute.
-
-The sample code below will restrict the particular action only to user who have the "admin" role:
-
-```csharp
-[Authorize(Roles = "admin")]
-[HttpGet]
-[Route("ping/admin")]
-public string PingAdmin()
-{
-    return "All good. Only admins will be able to see this message.";
-}
-```
-
-### Debug Claims
-
-The sample source code for this quickstart contains a very handy API endpoint which allows you to view the claims associated with a particular JWT. You simply make a call to the `/api/claims` endpoint and it will return all the claims associated with the JWT.
-
-The source code for this action is very simple, so you can easily add it to your own projects as well to assist when debugging JSON Web Tokens:
-
-```csharp
-[Authorize]
-[HttpGet("claims")]
-public object Claims()
-{
-    return User.Claims.Select(c =>
-    new
-    {
-        Type = c.Type,
-        Value = c.Value
-    });
-}
-```
diff --git a/articles/server-apis/aspnet-core-webapi/index.yml b/articles/server-apis/aspnet-core-webapi/index.yml
deleted file mode 100644
index eb34480c44..0000000000
--- a/articles/server-apis/aspnet-core-webapi/index.yml
+++ /dev/null
@@ -1,18 +0,0 @@
-title: ASP.NET Core Web API
-alias:
-  - asp.net core webapi
-  - aspnet core webapi
-language:
-  - C#
-framework:
-  - ASP.NET Core
-thirdParty: false
-image: /media/platforms/asp.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-apis/aspnet-core-webapi/dependencies
-articles:
-  - 04-authentication-rs256-deprecated
-  - 05-authentication-hs256-deprecated
-  - 06-authorization-deprecated
diff --git a/articles/server-apis/aspnet-webapi/authenticate.md b/articles/server-apis/aspnet-webapi/authenticate.md
deleted file mode 100644
index 2894be60da..0000000000
--- a/articles/server-apis/aspnet-webapi/authenticate.md
+++ /dev/null
@@ -1,76 +0,0 @@
----
-title: Authenticate
-description: This tutorial will show you how to use the Auth0 ASP.NET Web API SDK to add authentication and authorization to your API.
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0',
-  repo: 'auth0-aspnet',
-  path: 'examples/webapi',
-  requirements: [
-    'Microsoft Visual Studio 2015',
-    'WebApi.JsonWebToken NuGet Package v0.2.0',
-    'Auth0-ASPNET NuGet Package v1.4.0',
-    'Microsoft.AspNet.WebApi.Cors NuGet Package v5.2.3'
-  ]
-}) %>
-
-**Otherwise, please follow the steps below to configure your existing ASP.NET Web API app to use it with Auth0.**
-
-### 1. Install the WebApi.JsonWebToken & Auth0-ASPNET packages
-
-You can either run the following commands or install them via **Package Manager**.
-
-${snippet(meta.snippets.dependencies)}
-
-### 2. Configure the JsonWebToken message handler
-
-Open the **WebApiConfig.cs** file located in the **App_Start** folder and add the following `using` statements:
-```cs
-using YOUR_WEBAPI_PROJECT_NAME.App_Start;
-using System.Web.Configuration;
-```
-Remember to replace the placeholder with your project name in the first `using` statement.
-
-Add the following code snippet inside the `Register` method.
-
-${snippet(meta.snippets.use)}
-
-### 3. Update the web.config file with your app's credentials
-Open the **Web.config** file located at the project's root.
-
-Locate the following entries inside the `` section.
-
-${snippet(meta.snippets.setup)}
-
-Set the respective values.
-
-### 4. Secure your API
-All you need to do now is add the `[System.Web.Http.Authorize]` attribute to the controllers/actions for which you want to verify if users are authenticated.
-
-### 5. Call Your API
-You can now make requests against your secure API by providing the Authorization header in your requests with a valid `id_token` ([See our id_token documentation](/tokens/id_token) for more information on how to obtain an `id_token`).
-
-```har
-{
-  "method": "GET",
-  "url": "http://localhost:8000/path_to_your_api",
-  "headers": [
-    { "name": "Authorization", "value": "Bearer YOUR_ID_TOKEN_HERE" }
-  ]
-}
-```
-
-### 6. You're done!
-
-Now you have both your frontend and backend configured to use Auth0. Congrats, you're awesome!
-
-### Optional Steps
-
-#### Configuring CORS
-
-One of the requirements is package Microsoft.AspNet.WebApi.Cors. You can use the following command from VS2013 Package Manager Console:
-
-`Install-Package Microsoft.AspNet.WebApi.Cors`
-
-For more details, you can follow [this article](http://www.asp.net/web-api/overview/security/enabling-cross-origin-requests-in-web-api) to configure CORS in your application.
diff --git a/articles/server-apis/aspnet-webapi/index.yml b/articles/server-apis/aspnet-webapi/index.yml
deleted file mode 100644
index a7c21ec769..0000000000
--- a/articles/server-apis/aspnet-webapi/index.yml
+++ /dev/null
@@ -1,20 +0,0 @@
-title: ASP.NET Web API (System.Web)
-alias:
-  - webapi
-  - asp.net webapi
-  - aspnet webapi
-language:
-  - Visual Basic .Net
-  - C#
-framework:
-  - WebAPI
-thirdParty: false
-image: /media/platforms/asp.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-apis/aspnet-webapi/dependencies
-  setup: server-apis/aspnet-webapi/setup
-  use: server-apis/aspnet-webapi/use
-articles:
-  - authenticate
diff --git a/articles/server-apis/falcor/authenticate.md b/articles/server-apis/falcor/authenticate.md
deleted file mode 100644
index c7df7a5a42..0000000000
--- a/articles/server-apis/falcor/authenticate.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: Authenticate
-description: This tutorial will show you how to use the Auth0 Falcor SDK to add authentication and authorization to your API.
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0',
-  repo: 'node-auth0',
-  path: 'examples/falcor-api',
-  requirements: [
-    'Node.js 5.6.0'
-  ]
-}) %>
-
-**Otherwise, Please follow the steps below to configure your existing Falcor app to use it with Auth0.**
-
-### 1. Add express-jwt dependency
-
-You need to add a few dependencies, including `express-jwt`. Also, If you haven't already done so, you need to install `falcor-express` and `falcor-router`.
-
-Just run the following code to install the dependencies and add them to your `package.json`.
-
-${snippet(meta.snippets.dependencies)}
-
-### 2. Configure express-jwt with your Auth0 account
-
-You need to set the ClientID and ClientSecret in `express-jwt`'s configuration so that it can validate and sign [JWT](/jwt)s for you.
-
-${snippet(meta.snippets.setup)}
-
-### 3. Secure your API
-
-In your Falcor app, you serve a virtual JSON resource from a single endpoint. You can protect this endpoint globally with the `express-jwt` middleware.
-
-${snippet(meta.snippets.use)}
-
-### 4. Send Authorization header from the front end
-
-When you send a request to the Falcor model, you need to include the JWT as an `Authorization` header.
-
-```js
-var token = localStorage.getItem('id_token');
-
-var model = new falcor.Model({
-  source: new falcor.HttpDataSource('/api/model.json', {
-    // Send the token as an Authorization header
-    headers: {
-      'Authorization': 'Bearer ' + token
-    }
-  })
-});
-
-```
-
-Don't forget to include [falcor.browser](https://github.com/Netflix/falcor#retrieving-data-from-the-virtual-json-resource) to your front end:
-
-```html
-
-
-
-
-```
-
-### 5. You're done!
-
-Your Falcor app is now secure with Auth0 and `express-jwt`. Congrats, you're awesome!
-
-### Optional steps
-
-#### Configuring CORS
-
-If you want to configure CORS, just add this code to your Falcor app (assuming your Falcor app is hosted on `http://localhost:3000`):
-
-```js
-app.use(function(req, res, next) {
-  res.header("Access-Control-Allow-Origin", "http://localhost:3000");
-  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/server-apis/falcor/index.yml b/articles/server-apis/falcor/index.yml
deleted file mode 100644
index d02f7572c8..0000000000
--- a/articles/server-apis/falcor/index.yml
+++ /dev/null
@@ -1,16 +0,0 @@
-title: Falcor API
-community: true
-thirdParty: false
-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:
-  - authenticate
diff --git a/articles/server-apis/golang/authenticate.md b/articles/server-apis/golang/authenticate.md
deleted file mode 100644
index deff5ebf82..0000000000
--- a/articles/server-apis/golang/authenticate.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: Authenticate
-description: This tutorial will show you how to use the Auth0 Go SDK to add authentication and authorization to your API.
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-golang-web-api',
-  path: '00-Starter-Seed'
-}) %>
-
-### 1. Install the `go-jwt-middleware` dependency
-
-Install `go-jwt-middleware` to check for JWTs on HTTP requests.
-
-Just run the following code to install the dependency
-
-${snippet(meta.snippets.dependencies)}
-
-### 2. Configure `go-jwt-middleware` to use your Auth0 Account
-
-You need to set the ClientSecret in `go-jwt-middleware`'s configuration so that it can validate [JWTs](/jwt) for you.
-
-${snippet(meta.snippets.setup)}
-
-### 3. Secure your API
-
-Now, you can use the `go-jwt-middleware` to secure your API. You can do so using either `net/http` handlers or `negroni` middlewares.
-${snippet(meta.snippets.use)}
-
-
-### 4. 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:3001/path_to_your_api",
-  "headers": [
-    { "name": "Authorization", "value": "Bearer YOUR_ID_TOKEN_HERE" }
-  ]
-}
-```
-
-### 5. You're done!
-
-Now you have both your frontend and backend configured to use Auth0. Congrats, you're awesome!
diff --git a/articles/server-apis/golang/index.yml b/articles/server-apis/golang/index.yml
deleted file mode 100644
index 0d0950c589..0000000000
--- a/articles/server-apis/golang/index.yml
+++ /dev/null
@@ -1,16 +0,0 @@
-title: Go
-thirdParty: false
-alias:
-  - go
-  - golang
-languages:
-  - Go
-image: /media/platforms/golang.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-apis/golang/dependencies
-  setup: server-apis/golang/setup
-  use: server-apis/golang/use
-articles:
-  - authenticate
diff --git a/articles/server-apis/hapi/authenticate.md b/articles/server-apis/hapi/authenticate.md
deleted file mode 100644
index 8f429c3549..0000000000
--- a/articles/server-apis/hapi/authenticate.md
+++ /dev/null
@@ -1,55 +0,0 @@
----
-title: Authenticate
-description: This tutorial will show you how to use the Auth0 Node.js Hapi SDK to add authentication and authorization to your API.
----
-
-In this tutorial you will learn how to use Auth0 to secure your [Hapi](http://hapijs.com/) API.
-
-<%= include('../../_includes/_package', {
-  org: 'auth0',
-  repo: 'node-auth0',
-  path: 'examples/hapi-api',
-  requirements: [
-    'Node.js 4.6.0',
-    'Hapi.js 13.5.3',
-    'hapi-auth-jwt 4.0.0'
-  ]
-}) %>
-
-### 1. Add hapi-auth-jwt dependency
-
-You need to add the hapi-auth-jwt dependency.
-
-Just run the following code to install the dependency and add it to your `package.json`
-
-${snippet(meta.snippets.dependencies)}
-
-### 2. Configure hapi-auth-jwt with your Auth0 account
-
-You need to set the ClientID and ClientSecret in `hapi-auth-jwt`'s configuration so that it can validate and sign [JWT](/jwt)s for you.
-
-${snippet(meta.snippets.setup)}
-
-### 3. Secure your API
-
-Now, you need to specify one or more routes or paths that you want to protect so that only users with a valid JWT will be able to do the request.
-
-${snippet(meta.snippets.use)}
-
-### 4. 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" }
-  ]
-}
-```
-
-### 5. You're done!
-
-Now you have both your Hapi API secured with Auth0. Congrats, you're awesome!
diff --git a/articles/server-apis/hapi/index.yml b/articles/server-apis/hapi/index.yml
deleted file mode 100644
index faf3bca87d..0000000000
--- a/articles/server-apis/hapi/index.yml
+++ /dev/null
@@ -1,17 +0,0 @@
-title: Hapi API
-thirdParty: false
-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:
-  - authenticate
diff --git a/articles/server-apis/java-spring-security/00-intro.md b/articles/server-apis/java-spring-security/00-intro.md
deleted file mode 100644
index 38a45336e3..0000000000
--- a/articles/server-apis/java-spring-security/00-intro.md
+++ /dev/null
@@ -1,55 +0,0 @@
----
-title: Introduction
-name: Introduction to the Quickstart, and configuring environment
-budicon: 715
----
-
-This quickstart will guide you through the various tasks related to using Auth0-issued JSON Web Tokens to secure your Java Spring Security API.
-
-
-## Seed and Samples
-
-If you prefer to follow along with this quickstart you can download the [seed project](https://github.com/auth0-samples/auth0-spring-security-api-sample/tree/master/00-Starter-Seed). The seed project is just a basic Spring Security API.
-
-The final project after each of the steps is also available in the [Sample repository](https://github.com/auth0-samples/auth0-spring-security-api-sample). You can find the final result for each step in the relevant folder inside the repository.
-
-<%= include('../../_includes/_new_app') %>
-
-## Setup dependencies
-
-You need to add the `auth0-spring-security-api` dependency.
-
-If you are using maven, add the dependency to your `pom.xml`:
-
-${snippet(meta.snippets.dependencies)}
-
-If you are using Gradle, add it to the dependencies block:
-
-${snippet(meta.snippets.dependenciesGradle)}
-
-## Configure your Spring Security API
-
-Your Spring Security API needs some information in order to authenticate against your Auth0 account. We have created a file for you but you may need to update some of the entries with the valid values for your Client. The file is `/src/main/resources/auth0.properties` and it contains the following:
-
-${snippet(meta.snippets.setup)}
-
-Let's see what each attribute means.
-
-| Attribute | Description|
-| --- | --- |
-| `auth0.domain` | Your auth0 domain. You can find the correct value on the Settings tab of your client on the [dashboard](${manage_url}/#/applications). * |
-| `auth0.issuer` | The issuer of the JWT Token. This is typically your auth0 domain with a `https://` prefix and a `/` suffix. For example, if your `auth0.domain` is `example.auth0.com` then the `auth0.issuer` should be set to `https://example.auth0.com/` (the trailing slash is important). |
-| `auth0.clientId` | The unique identifier for your client. You can find the correct value on the Settings tab of your client on the [dashboard](${manage_url}/#/applications). * |
-| `auth0.clientSecret` | The secret used to sign and validate the tokens that will be used in the different authentication flows. You can find the correct value on the Settings tab of your client on the [dashboard](${manage_url}/#/applications). * |
-| `auth0.securedRoute` | The URL pattern that should map to the URL endpoint you wish to secure. You should replace its value with the correct value for your implementation. It should start with `/`. * |
-| `auth0.base64EncodedSecret` | A boolean value indicating whether the Secret used to verify the JWT is `base64` encoded. The default is `false`. |
-| `auth0.authorityStrategy` | Indicates whether authorization claims against the Principal shall be `GROUPS`, `ROLES` or `SCOPE` based. The default is `ROLES`. |
-| `auth0.defaultAuth0ApiSecurityEnabled` | A boolean value that switches having the default config enabled. It should be set to `false`. |
-| `auth0.signingAlgorithm: HS256` | Used when you want to use HS256 as a signing algorithm. We will see more about this on the next steps. |
-| `#auth0.signingAlgorithm: RS256` | Used when you want to use RS256 as a signing algorithm. We will see more about this on the next steps. |
-| `#auth0.publicKeyPath: certificate/cert.pem` | Indicates the certification in case you use RS256. We will see more about this on the next steps. |
-
-**NOTE**: If you download the seed project 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 client. In any case, you should verify that the values are correct, if you have multiple clients in your account and you might want to use another than the one we set the information for. Do not forget to manually set the `issuer` attribute!
-
-
-That's all you need to start working with Auth0 in your Spring Security API!
diff --git a/articles/server-apis/java-spring-security/01-authentication.md b/articles/server-apis/java-spring-security/01-authentication.md
deleted file mode 100644
index 94a12d407b..0000000000
--- a/articles/server-apis/java-spring-security/01-authentication.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-title: Authentication
-name: Shows how to secure your API
-budicon: 500
----
-
-You can get started by either downloading the seed project or if you would like to add Auth0 to an existing application you can follow the tutorial steps.
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-spring-security-api-sample',
-  path: '01-Authentication',
-  requirements: [
-    'Java 7 or above',
-    'Maven 3.0.x or above'
-  ]
-}) %>
-
-Auth0 can sign JSON Web Tokens (JWT) using either a symmetric key (HS256) or an asymmetric key (RS256).
-
-> For more information on the signing algorithms see: [JSON Web Token (JWT) Signing Algorithms Overview](https://auth0.com/blog/json-web-token-signing-algorithms-overview/)
-
-## 1. Configure JSON Web Token Signature Algorithm
-
-To configure the JWT Signature Algorithm, go to the settings for your client in the Auth0 Dashboard, scroll down and click on **Show Advanced Settings**. Go to the **OAuth** tab and set the **JsonWebToken Signature Algorithm** to the algorithm you want to use: `RS256` or `HS256`.
-
-Save your changes.
-
-![Configure JWT Signature Algorithm as RS256](/media/articles/server-apis/aspnet-core-webapi/jwt-signature-rs256.png)
-
-The next step is to configure your API to use the algorithm you chose. If you downloaded our seed project, `HS256` is configured by default. To change this, edit the `/src/main/resources/auth0.properties` file as follows:
-
-```properties
-#auth0.signingAlgorithm: HS256
-auth0.signingAlgorithm: RS256
-auth0.publicKeyPath: certificate/cert.pem
-```
-
-The [library](https://github.com/auth0/auth0-spring-security-api) uses the `signingAlgorithm` property to determine which algorithm to use. The `publicKeyPath` property specifies the location of the certificate.
-
-## 2. Configure the endpoints
-
-In our example, we will assume two endpoints: `ping` and `secured/ping`. The former will not require authentication, while the later will do.
-
-First, we need to create the controller for our endpoints: `PingController.java`.
-
-${snippet(meta.snippets.PingController)}
-
-Next we need to configure which endpoint is secure and which is not. Edit the `AppConfig.java` file.
-
-${snippet(meta.snippets.SecurePingController)}
-
-## 3. Using the API
-
-To test your endpoints you need to start the API and then send the relevant HTTP requests.
-
-In order to build and run our seed project use the command: `mvn spring-boot:run`.
-
-To test the non-secure endpoint send a `GET` request at `http://localhost:3001/ping`.
-
-```bash
-curl -X GET -H "Content-Type: application/json" -H "Cache-Control: no-cache" "http://localhost:3001/ping"
-```
-
-You should get the message: `All good. You DO NOT need to be authenticated to call /ping`.
-
-To test the secure endpoint send a `GET` request at `http://localhost:3001/secured/ping`. In this case, you will also have to add a valid `id_token` to your request.
-
-```bash
-curl -X GET -H "Authorization: Bearer {YOUR_ID_TOKEN}" -H "Cache-Control: no-cache" "http://localhost:3001/secured/ping"
-```
-
-You should get the message: `All good. You DO need to be authenticated to call /secured/ping`.
-
-If the token is not specified you will get the following JSON as a response.
-
-```json
-{
-  "timestamp":1473245148067,
-  "status":403,
-  "error":"Forbidden",
-  "message":"Access Denied",
-  "path":"/secured/ping"
-}
-```
-
-A quick and easy way to obtain an `id_token` is to call the `/oauth/ro` endpoint using the Auth0 [Authentication API Explorer](/api/authentication/reference#resource-owner):
-
-![Obtain a JWT](/media/articles/server-apis/java-spring-security/request-jwt.png)
-
-Now you can use the `id_token` and pass it along in the Authorization header as a Bearer token.
-
-## 4. You're done!
-
-You have secured your Java Spring Security API endpoints using Auth0. Congrats, you're awesome!
diff --git a/articles/server-apis/java-spring-security/02-authorization.md b/articles/server-apis/java-spring-security/02-authorization.md
deleted file mode 100644
index 601a4f173c..0000000000
--- a/articles/server-apis/java-spring-security/02-authorization.md
+++ /dev/null
@@ -1,75 +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 API endpoints.
-budicon: 500
----
-
-You can get started by either downloading the seed project or if you would like to add Auth0 to an existing application you can follow the tutorial steps.
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-spring-security-api-sample',
-  path: '02-Authorization',
-  requirements: [
-    'Java 7 or above',
-    'Maven 3.0.x or above'
-  ]
-}) %>
-
-In this step we will see how we can add role-based authorization to our API, using [Rules](/rules).
-
-## 1. Create a Rule to assign roles
-
-In our example, we will create a simple rule that assigns two roles (`ROLE_ADMIN` and `ROLE_USER`) to any user. Of course, you can change our sample code to match your needs.
-
-To create a new rule, navigate to the [new rule page](${manage_url}/#/rules/new) and select the __Set Roles To A User__ template, under _Access Control_. Then, replace the sample script with the following:
-
-${snippet(meta.snippets.newRule)}
-
-The first condition of this rule makes sure that it runs only for a specific `CLIENT_ID`. Make sure the value matches the `CLIENT_ID` of the Client you are using for this API.
-
-What this rule does is add a `roles` property at the `app_metadata`. To customize your API based on its value, first you need to retrieve this information. This can be retrieved as part of the token.
-
-When you ask for a token you need to add this new property, `roles`, as part of the `scope` parameter. For example, if your front-end is using Lock, the code should look like this:
-
-```js
-var lock = new Auth0Lock('${account.clientId}', '${account.namespace}');
-lock.showSignin({
-    authParams: {
-        scope: 'openid roles'
-    },
-    // ... other params
-});
-```
-
-For more details on the `scope` parameter refer to: [Scopes](/scopes).
-
-## 2. Secure the endpoints
-
-For our sample, we will allow anyone to call our `ping` endpoint. We will also allow both `ROLE_USER` and `ROLE_ADMIN` to perform `GET` operations on our `/api/v1/profiles/**` endpoints. However, we will restrict the `POST`, `PUT` and `DELETE` operations to strictly `ROLE_ADMIN` role privilege.
-
-Add the following code at the `AppConfig.java`:
-
-${snippet(meta.snippets.AppConfig)}
-
-### 3. 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](/tokens#auth0-id_token-jwt-).
-
-```har
-{
-"method": "GET",
-"url": "http://localhost:8000/path_to_your_api",
-"headers": [
-{ "name": "Authorization", "value": "Bearer YOUR_ID_TOKEN_HERE" }
-]
-}
-```
-
-Before making the request you should replace the port (`8000`) with the one on which your app is listening.
-
-If the roles functionality is not working properly for you, make sure that the `roles` property is included in the token. To ensure this you can log your token and use the [JWT home page](https://jwt.io/) to decode it and review its contents.
-
-### 4. You're done!
-
-You have configured your Java Spring Security API to use Auth0. Congrats, you're awesome!
diff --git a/articles/server-apis/java-spring-security/index.yml b/articles/server-apis/java-spring-security/index.yml
deleted file mode 100644
index a604c93ef8..0000000000
--- a/articles/server-apis/java-spring-security/index.yml
+++ /dev/null
@@ -1,26 +0,0 @@
-title: Spring Security Java API
-thirdParty: false
-alias:
-  - spring security
-  - spring
-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:
-  - 00-intro
-  - 01-authentication
-  - 02-authorization
diff --git a/articles/server-apis/nginx/authenticate.md b/articles/server-apis/nginx/authenticate.md
deleted file mode 100644
index 0533ed0af3..0000000000
--- a/articles/server-apis/nginx/authenticate.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-title: Authenticate
-description: This tutorial will show you how to use the Auth0 Nginx SDK to add authentication and authorization to your API.
----
-
-::: 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.**
-
-### 1. 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:
-
-${snippet(meta.snippets.dependencies)}
-
-### 2. Configure `nginx-jwt` with your Auth0 account
-
-1. Export the `JWT_SECRET` environment variable on the Nginx host, setting it equal to your Auth0 Client Secret (`${account.clientSecret}`).
-1. Export the `JWT_SECRET_IS_BASE64_ENCODED` environment variable on the Nginx host, setting it equal to `false`.
-1. Expose both environment variables to the Nginx server:
-
-${snippet(meta.snippets.setup)}
-
-### 3. 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):
-
-${snippet(meta.snippets.use)}
-
-Click [here](https://github.com/auth0/nginx-jwt#usage) for more usage examples.
-
-
-### 4. 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" }
-  ]
-}
-```
-
-### 5. You're done!
-
-Now you have both your frontend and backend configured to use Auth0. Congrats, you're awesome!
diff --git a/articles/server-apis/nginx/index.yml b/articles/server-apis/nginx/index.yml
deleted file mode 100644
index 510d4c906a..0000000000
--- a/articles/server-apis/nginx/index.yml
+++ /dev/null
@@ -1,17 +0,0 @@
-title: Nginx API
-thirdParty: false
-community: true
-alias:
-  - nginx
-  - openresty
-languages:
-  - Lua
-image: /media/platforms/nginx.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-apis/nginx/dependencies
-  setup: server-apis/nginx/setup
-  use: server-apis/nginx/use
-articles:
-  - authenticate
diff --git a/articles/server-apis/nodejs/01-getting-started.md b/articles/server-apis/nodejs/01-getting-started.md
deleted file mode 100644
index b130430b70..0000000000
--- a/articles/server-apis/nodejs/01-getting-started.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-title: Getting Started
-description: This tutorial demonstrates how to verify JSON Web Tokens and protect endpoints in an Express API
----
-
-To restrict access to the resources served by your API, a check needs to be made to determine whether the incoming request contains valid authentication information. There are various methods for including authentication information in a request, but for integration with Auth0, the server needs to check for a valid JSON Web Token (JWT).
-
-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 an Express 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.
-
-## Check the Signing Algorithm
-
-This tutorial demonstrates how to verify a JWT signed by Auth0 using two different algorithms: HS256 and RS256. By default, ID tokens issued by Auth0 are signed with HS256. However, if you have implemented a custom login screen in your application with auth0.js v8+, you need to change your token's signing algorithm to RS256. If you are using auth0.js < v8, tokens signed with HS256 may be used.
-
-::: panel-warning Before Changing the Signing Algorithm
-Please note that altering the signing algorithm for your client will immediately change the way your user's tokens are signed. This means that if you have already implemented JWT verification for your client somewhere, your tokens will not be verifiable until you update the logic to account for the new signing algorithm.
-:::
-
-The token signing algorithm is specified in the advanced settings for your client in the OAuth configuration area.
-
-![Configure JWT Signature Algorithm as HS256](/media/articles/server-apis/aspnet-core-webapi/jwt-signature-hs256.png)
-
-If you are unsure about which algorithm your token is signed with, paste your token in the [JWT.io](https://jwt.io) debugger and look in the `header`.
-
-
diff --git a/articles/server-apis/nodejs/02-authenticate-hs256.md b/articles/server-apis/nodejs/02-authenticate-hs256.md
deleted file mode 100644
index c11ac45da4..0000000000
--- a/articles/server-apis/nodejs/02-authenticate-hs256.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-title: Authentication (HS256)
-description: This tutorial demonstrates how to verify an HS256-signed JSON Web Token and protect endpoints in an Express API
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-express-api-samples',
-  path: '01-Authenticate-HS256',
-  branch: 'p1',
-  requirements: [
-    'NodeJS 4.3',
-    'Express 4.11'
-  ]
-}) %>
-
-## Installation
-
-Install the **express-jwt** package.
-
-${snippet(meta.snippets.dependencies)}
-
-## Configuration
-
-Configure the **express-jwt** middleware with the **ID** (as the `audience`) and **secret** for your Auth0 client.
-
-${snippet(meta.snippets.setup)}
-
-## Apply the Middleware
-
-With the **express-jwt** middleware configured, add it to any endpoints you wish to protect.
-
-${snippet(meta.snippets.use)}
-
-## Call the API
-
-Requests to your API's protected endpoints now require that a JWT signed with your client's secret be included in the `Authorization` header using the `Bearer` scheme.
-
-```har
-{
-  "method": "GET",
-  "url": "http://localhost:8000/path_to_your_api",
-  "headers": [
-    { "name": "Authorization", "value": "Bearer YOUR_ID_TOKEN_HERE" }
-  ]
-}
-```
diff --git a/articles/server-apis/nodejs/03-authenticate-rs256.md b/articles/server-apis/nodejs/03-authenticate-rs256.md
deleted file mode 100644
index 5b97ad57e0..0000000000
--- a/articles/server-apis/nodejs/03-authenticate-rs256.md
+++ /dev/null
@@ -1,74 +0,0 @@
----
-title: Authentication (RS256)
-description: This tutorial demonstrates how to verify an RS256-signed JSON Web Token and protect endpoints in an Express API
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-express-api-samples',
-  path: '02-Authenticate-RS256',
-  branch: 'p1',
-  requirements: [
-    'NodeJS 4.3',
-    'Express 4.11'
-  ]
-}) %>
-
-To verify tokens signed with the RS256 algorithm, the remote JSON Web Key Set (JWKS) for your application must be consulted. This is handled with the **jwks-rsa** package.
-
-## Installation
-
-Install the **express-jwt** and **jwks-rsa** package.
-
-```bash
-npm install express-jwt jwks-rsa --save
-```
-
-## Configuration
-
-Configure the **express-jwt** middleware to use the remote JWKS for your Auth0 account.
-
-```js
-const express = require('express');
-const app = express();
-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 jwtCheck = 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: '${account.clientId}',
-  issuer: `https://${account.namespace}/`,
-  algorithms: ['RS256']
-});
-```
-
-## Apply the Middleware
-
-With the **express-jwt** middleware configured, add it to any endpoints you wish to protect.
-
-${snippet(meta.snippets.use)}
-
-## Call the API
-
-Requests to your API's protected endpoints now require that a JWT signed with your client's secret be included in the `Authorization` header using the `Bearer` scheme.
-
-```har
-{
-  "method": "GET",
-  "url": "http://localhost:8000/path_to_your_api",
-  "headers": [
-    { "name": "Authorization", "value": "Bearer YOUR_ID_TOKEN_HERE" }
-  ]
-}
-```
diff --git a/articles/server-apis/nodejs/index.yml b/articles/server-apis/nodejs/index.yml
deleted file mode 100644
index 6474bc8de7..0000000000
--- a/articles/server-apis/nodejs/index.yml
+++ /dev/null
@@ -1,20 +0,0 @@
-title: Node (Express) API
-thirdParty: false
-alias:
-  - node
-  - nodejs
-  - node.js
-  - express
-languages:
-  - Javascript
-image: /media/platforms/node.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-apis/nodejs/dependencies
-  setup: server-apis/nodejs/setup
-  use: server-apis/nodejs/use
-articles:
-  - 01-getting-started
-  - 02-authenticate-hs256
-  - 03-authenticate-rs256
diff --git a/articles/server-apis/php-laravel/authenticate.md b/articles/server-apis/php-laravel/authenticate.md
deleted file mode 100644
index 39949ce283..0000000000
--- a/articles/server-apis/php-laravel/authenticate.md
+++ /dev/null
@@ -1,257 +0,0 @@
----
-title: Authenticate
-description: This tutorial will show you how to use the Auth0 PHP Laravel SDK to add authentication and authorization to your API.
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-laravel-php-web-api',
-  path: '00-Starter-Seed',
-  requirements: [
-    'Composer 1.0-dev',
-    'PHP 5.6.18',
-    'Laravel 5.1.31'
-  ]
-}) %>
-
-## Laravel Compatibility
-
-The latest version (4.x) targets Laravel 5.3 compatibility.
-
-If you are working with an older version (Laravel 4.x) you need to point to composer.json to the version 1.0.*
-
-### 1. Install the plugin and its dependencies
-
-${snippet(meta.snippets.dependencies)}
-
-> 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 and it will install them in your project for you.
-
-### 2. Enable it in Laravel
-Add the following to the list of service providers, located in `config/app.php`
-
-${snippet(meta.snippets.setup)}
-
-Optionally, if you want to use the [facade](http://laravel.com/docs/facades) called `Auth0` you should also add an alias in the same file
-
-```php
-'aliases' => array(
-    // ...
-    'Auth0' => 'Auth0\Login\Facade\Auth0'
-);
-```
-
-You will now be able to access to the logged user info with `Auth0::getUser()`.
-
-Finally, you will need to bind a class that provides the users (your app model user) 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 (which should implement the `\Auth0\Login\Contract\Auth0UserRepository` interface, this is covered later).
-For this you need to add to your `AppServiceProvider` the following line:
-
-```php
-...
-
-public function register()
-{
-
-    $this->app->bind(
-        '\Auth0\Login\Contract\Auth0UserRepository',
-        '\Auth0\Login\Repository\Auth0UserRepository');
-
-}
-
-...
-```
-
-### 3. Configure it
-
-To configure the plugin, you need to publish the plugin configuration and complete the file `config/laravel-auth0.php` using the information of your Auth0 account.
-
-To publish the example configuration file use this command
-
-```bash
-php artisan vendor:publish
-```
-
-### 4. Configure APACHE
-
-By default, Apache doesn't provide the `Authorization header` to the request, we can solve that by enabling `mod_rewrite` and adding the following rule to your `.htaccess`:
-
-```bash
-RewriteCond %{HTTP:Authorization} ^(.*)
-RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]
-```
-
-### 5. Defining a user and a user provider
-
-The [Laravel authentication system](https://laravel.com/docs/5.3/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.
-
-The 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, and it doesn't actually persist the object, it just stores it in the session for future calls.
-
-This works fine for basic testing or if you don't really need to persist the user. 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.
-
-To enable this driver, you need to change the following line in `/config/auth.php`:
-
-```php
-...
-    'providers' => [
-        'users' => [
-            'driver' => 'auth0'
-        ],
-    ],
-...
-```
-
-If you need a more advanced custom solution, you can always extend the `Auth0UserRepository` class.
-
-For example, if you want to use the default `User` model and store the user profile in your database, you can use the following Repository:
-
-```php
-user_id = $jwt->sub;
-
-      return $this->upsertUser($jwt);
-    }
-
-    public function getUserByUserInfo($userInfo) {
-      return $this->upsertUser($userInfo['profile']);
-    }
-
-    protected function upsertUser($profile) {
-
-      $user = User::where("auth0id", $profile->user_id)->first();
-
-      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();
-      }
-
-      return $user;
-    }
-
-    public function getUserByIdentifier($identifier) {
-        //Get the user info of the user logged in (probably in session)
-        $user = \App::make('auth0')->getUser();
-
-        if ($user === null) return null;
-
-        // build the user
-        $user = $this->getUserByUserInfo($user);
-
-        // it is not the same user as logged in, it is not valid
-        if ($user && $user->auth0id == $identifier) {
-            return $auth0User;
-        }
-    }
-
-}
-```
-
-And change the binding in the second step:
-
-```php
-...
-
-public function register()
-{
-
-    $this->app->bind(
-        '\Auth0\Login\Contract\Auth0UserRepository',
-        '\App\Repository\MyCustomUserRepository');
-
-}
-
-...
-```
-
-### 6. Authenticate your requests without Laravel Passport
-
-If you don't want to use Laravel Passport, you can use the Middlewares provided by this package.
-
-To register the middlewares, you need to go to `app/Http/Kernel.php` and add these lines to the `routeMiddleware` collection:
-
-```php
-protected $routeMiddleware = [
-  ...
-  'auth0.jwt' => '\Auth0\Login\Middleware\Auth0JWTMiddleware',
-  'auth0.jwt_verification' => '\Auth0\Login\Middleware\Auth0OptionalJWTMiddleware',
-  'auth0.jwt_force' => '\Auth0\Login\Middleware\ForceAuthMiddleware',
-  ...
-];
-```
-
-#### Auth0JWTMiddleware
-
-This middleware with extract the token from the request headers, decode and verify it. If the token is not present it will reject the login with an HTTP 401 code.
-
-#### Auth0OptionalJWTMiddleware & ForceAuthMiddleware
-
-`Auth0OptionalJWTMiddleware` with extract the token from the request headers, decode and verify it. If the token is not present it will not set the user.
-
-`ForceAuthMiddleware` will check if there is a user set up, if there is not it will reject the login with an HTTP 401 code.
-
-The idea of using these middlewares is to be able to set `Auth0OptionalJWTMiddleware` to all your API routes and for those that should be secured, you can add `ForceAuthMiddleware`.
-
-### 5. Use it & Run it
-
-Now you can secure your REST calls like this:
-
-${snippet(meta.snippets.use)}
-
-You can run the server by doing `php artisan serve --port=3001` to try all this out.
-
-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" }
-]
-}
-```
-
-### 6. You're done!
-
-Now you have both your frontend and backend configured to use Auth0. Congrats, you're awesome!
-
-### Options Steps
-
-#### Configure CORS
-
-To configure CORS, you should add the `laravel-cors` dependency. You can [check it out here](https://github.com/barryvdh/laravel-cors).
-
-After you've installed it, just set the following in the configuration file for `CORS`:
-
-```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')
-    ),
-),
-```
diff --git a/articles/server-apis/php-laravel/index.yml b/articles/server-apis/php-laravel/index.yml
deleted file mode 100644
index 86230eb7d1..0000000000
--- a/articles/server-apis/php-laravel/index.yml
+++ /dev/null
@@ -1,18 +0,0 @@
-title: PHP (Laravel) API
-thirdParty: false
-alias:
-  - laravel
-languages:
-  - PHP
-framework:
-  - Laravel
-image: /media/platforms/php.png
-tags:
-  - 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
-articles:
-  - authenticate
diff --git a/articles/server-apis/php-symfony/authenticate.md b/articles/server-apis/php-symfony/authenticate.md
deleted file mode 100644
index 6de2489f2b..0000000000
--- a/articles/server-apis/php-symfony/authenticate.md
+++ /dev/null
@@ -1,111 +0,0 @@
----
-title: Authenticate
-description: This tutorial will show you how to use the Auth0 PHP Symfony SDK to add authentication and authorization to your API.
----
-
-
-<%= include('../../_includes/_package', {
-  org: 'auth0',
-  repo: 'jwt-auth-bundle',
-  path: 'example',
-  requirements: [
-    'PHP 5.3.9',
-    'Symfony 2.8'
-  ]
-}) %>
-
-**Otherwise, please follow the steps below to configure your existing PHP (Symfony) API app to use it with Auth0.**
-
-This bundle helps you integrate your Symfony WebApp with [Auth0](https://auth0.com/) to achieve Single Sign On with a few simple steps. You can see an example of usage [here](https://github.com/auth0/jwt-auth-bundle/tree/master/example)
-
-## Tutorial
-
-### 1. Install dependencies
-
-We need to add the **jwt-auth-bundle** dependency to your composer.json.
-
-Once that's done, just run the following:
-
-${snippet(meta.snippets.dependencies)}
-
-> v2.x.x provides compatibility with Symfony 3, for Symfony 2.x, stick to v1 branch.
-
-> 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 and it will install them in your project for you.
-
-### 2. Add the bundle to your AppKernel.php file
-
-```php
-
-class AppKernel extends Kernel
-{
-    public function registerBundles()
-    {
-        $bundles = array(
-
-            ...
-
-            new \Auth0\JWTAuthBundle\JWTAuthBundle(),
-
-            ...
-
-        );
-
-        ...
-
-        return $bundles;
-    }
-
-```
-
-### 3. Configure your Auth0 app data
-
-Modify the file /app/config/config.yml
-
-${snippet(meta.snippets.setup)}
-
-### 4. Setup your User and UserProvider
-
-Create your User and UserProvider.
-
-The UserProvider must implement the JWTUserProviderInterface (see /source/AppBundle/Security/A0UserProvider). This class should implement 2 methods:
-
-- loadUserByJWT: This method receives the decoded JWT (but overloaded with the encoded token on the token attribute) and should return a User.
-
-- getAnonymousUser: This method should return an anonymous user that represents an unauthenticated one (usually represented by the role *IS_AUTHENTICATED_ANONYMOUSLY*).
-*Both methods can throw an AuthenticationException exception in case that the user is not found, in the case of the loadUserByJWT method, or you don't want to handle unauthenticated users on your app, in the case of the getAnonymousUser method.*
-
-Then configure your UserProvider on /app/config/services.yml
-
-```yml
-services:
-    a0_user_provider:
-        class: AppBundle\Security\A0UserProvider
-        arguments: ["@jwt_auth.auth0_service"]
-```
-
-### 5. Setup the SecurityProvider
-
-Modify the file /app/config/security.yml:
-
-- define your user provider
-- define the secured area that you want to authenticate using JWT
-- define the access_control section with the roles needed for each route
-
-${snippet(meta.snippets.use)}
-
-### 6. 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" }
-]
-}
-```
-
-## 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.
diff --git a/articles/server-apis/php-symfony/index.yml b/articles/server-apis/php-symfony/index.yml
deleted file mode 100644
index dd04e5a319..0000000000
--- a/articles/server-apis/php-symfony/index.yml
+++ /dev/null
@@ -1,17 +0,0 @@
-title: PHP (Symfony) API
-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:
-  - authenticate
diff --git a/articles/server-apis/php/authenticate.md b/articles/server-apis/php/authenticate.md
deleted file mode 100644
index 282a3bf8f7..0000000000
--- a/articles/server-apis/php/authenticate.md
+++ /dev/null
@@ -1,64 +0,0 @@
----
-title: Authenticate
-description: This tutorial will show you how to use the Auth0 PHP SDK to add authentication and authorization to your API.
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0',
-  repo: 'auth0-PHP',
-  path: 'examples/basic-api',
-  requirements: [
-    'PHP 5.6.14',
-    'Composer 1.0-dev'
-  ]
-}) %>
-
-**Otherwise, Please follow the steps below to configure your existing PHP app to use it with Auth0.**
-
-### 1. Add the needed dependencies
-
-We need 2 dependencies to make this work:
-
-* **auth0-php**: this will take care of checking the JWT
-* **router**: we'll use this for creating simple routes
-
-${snippet(meta.snippets.dependencies)}
-
-> 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 and it will install them in your project for you.
-
-### 2. Create the JWT Validation filter
-
-Now, you need to validate the [JWT](/jwt). For that, we'll create a filter that will run on the routes we need.
-
-${snippet(meta.snippets.setup)}
-
-### 3. Create a `/secured` route that will use this filter
-
-Now, you can just create routes under `/secured` route which will check the JWT
-
-${snippet(meta.snippets.use)}
-
-### 4. 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" }
-]
-}
-```
-
-### 5. You're done!
-
-Now you have both your frontend and backend configured to use Auth0. Congrats, you're awesome!
-
-### Optional Steps
-#### Configure CORS
-
-You can configure CORS, by just adding [these lines](https://github.com/auth0/auth0-PHP/blob/master/examples/basic-api/index.php#L47-L58) to your `index.php`
-
-#### Define `apache_request_headers` if not available
-
-If the function is not available, just [copy these lines](https://github.com/auth0/auth0-PHP/blob/master/examples/basic-api/index.php#L8-L29) to your `index.php`
diff --git a/articles/server-apis/php/index.yml b/articles/server-apis/php/index.yml
deleted file mode 100644
index 71807498fe..0000000000
--- a/articles/server-apis/php/index.yml
+++ /dev/null
@@ -1,15 +0,0 @@
-title: PHP API
-alias:
-  - php
-languages:
-  - PHP
-thirdParty: false
-image: /media/platforms/php.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-apis/php/dependencies
-  setup: server-apis/php/setup
-  use: server-apis/php/use
-articles:
-  - authenticate
diff --git a/articles/server-apis/python/authenticate.md b/articles/server-apis/python/authenticate.md
deleted file mode 100644
index 9107ac075b..0000000000
--- a/articles/server-apis/python/authenticate.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-title: Authenticate
-description: This tutorial will show you how to use the Auth0 Python SDK to add authentication and authorization to your API.
----
-
-You can get started by either downloading the seed project or if you would like to add Auth0 to an existing application you can follow the tutorial steps.
-
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-python-api-samples',
-  path: '00-Starter-Seed',
-  requirements: [
-    'Python 2.7',
-    'Flask 0.10.1',
-    'Flask-Cors 2.1.0',
-    'PyJWT 1.4.0'
-  ]
-}) %>
-
-
-**If you have an existing application, please follow the steps below.**
-
-### 1. Add the needed dependencies
-
-In this example, we'll be using Flask and we'll be validating the JWT. For that, add the following dependencies to your `requirements.txt`.
-
-${snippet(meta.snippets.dependencies)}
-
-### 2. Create the JWT Validation decorator
-
-Now, you need to validate the [JWT](/jwt). For that, we'll create a custom decorator.
-
-${snippet(meta.snippets.setup)}
-
-### 3. Use this decorator in your methods
-
-Now, you can just decorate any route's method that requires authentication
-
-${snippet(meta.snippets.use)}
-
-### 4. 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" }
-  ]
-}
-```
-
-### 5. You're done!
-
-Now you have both your frontend and backend configured to use Auth0. Congrats, you're awesome!
-
-### Note for Python 2.7
-
-If you're using Python 2.7 and you already have the `jwt` package installed, you need to do the following to get this working:
-
-```bash
-pip uninstall jwt
-pip uninstall pyjwt
-pip install pyjwt
-```
diff --git a/articles/server-apis/python/index.yml b/articles/server-apis/python/index.yml
deleted file mode 100644
index 4b3b94b63b..0000000000
--- a/articles/server-apis/python/index.yml
+++ /dev/null
@@ -1,15 +0,0 @@
-title: Python API
-alias:
-  - python
-languages:
-  - Python
-thirdParty: false
-image: /media/platforms/python.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-apis/python/dependencies
-  setup: server-apis/python/setup
-  use: server-apis/python/use
-articles:
-  - authenticate
diff --git a/articles/server-apis/rails/authenticate.md b/articles/server-apis/rails/authenticate.md
deleted file mode 100644
index add4a9dab0..0000000000
--- a/articles/server-apis/rails/authenticate.md
+++ /dev/null
@@ -1,121 +0,0 @@
----
-title: Authenticate
-description: This tutorial will show you how to use the Auth0 Ruby on Rails SDK to add authentication and authorization to your API.
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-rubyonrails-api-sample',
-  path: '',
-  requirements: [
-    'Ruby 2.1.8',
-    'Rails 4.2.5.1'
-  ]
-}) %>
-
-### 1. Set up the knock gem
-
-Add this line to your application's Gemfile:
-
-#### Install
-
-${snippet(meta.snippets.dependencies)}
-
-And then execute:
-```
-bundle install
-```
-
-Finally, run the install generator:
-```
-rails generate knock:install
-```
-
-It will create the following initializer `config/initializers/knock.rb`.
-This file contains all the information about the existing configuration options.
-
-#### Usage
-
-Then include the `Knock::Authenticable` module in your `ApplicationController`
-
-${snippet(meta.snippets.setup)}
-
-You can now protect your resources by adding the `authenticate_user` before_action
-to your controllers like this:
-
-${snippet(meta.snippets.use)}
-
-If no valid token is passed with the request, Knock will respond with:
-
-```
-head :unauthorized
-```
-
-If a token is given, Knock makes two assumptions by default:
-
-1. Your app defines a `User` model with an `id` field.
-2. The 'sub' claim in the token payload contains the user id.
-
-To retrieve the current user you should implement within your entity model a class method from_token_payload that takes the payload in argument:
-
-```ruby
-class User < ActiveRecord::Base
-  def self.from_token_payload payload
-    # Returns a valid user, `nil` or raise
-    # e.g.
-    #   self.find payload["sub"]
-  end
-end
-```
-
-### 2. Add your Auth0 account information to secrets.yml
-
-You need to set the ClientID and ClientSecret in `config/secrets.yml` file so they can be used to validate and sign [JWT](/jwt)s for you.
-
-```yaml
-development:
-  secret_key_base: 3342e9faedd8fe9ea360c0af568d00a46917923791c23e144d66849b272d2ff63e743f9bb209dab7d6e732bb5f919e46e3fe552b8919140805bb89c346e68876,
-  auth0_client_id: <%= account.clientId %>
-  auth0_client_secret: <%= account.clientSecret %>
-
-production:
-  secret_key_base: ENV["SECRET_KEY_BASE"]
-  auth0_client_id: <%= account.clientId %>
-  auth0_client_secret: <%= account.clientSecret %>
-```
-
-**Warning:**
-If you share your code, you should use environment variable to protect your ClientID and ClientSecret.
-
-### 3. Tell knock to use your Auth0 account information
-
-In `config/initializer/knock.rb`, uncomment the following lines:
-
-```ruby
-config.token_audience = -> { Rails.application.secrets.auth0_client_id }
-```
-
-```ruby
-config.token_secret_signature_key = -> { JWT.base64url_decode Rails.application.secrets.auth0_client_secret }
-```
-
-### 4. 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" }
-]
-}
-```
-
-### 5. You're done!
-
-Now you have both your frontend and backend configured to use Auth0. Congrats, you're awesome!
-
-### Optional Steps
-#### Configure CORS
-
-In order to configure CORS, install [rack-cors](https://github.com/cyu/rack-cors) gem and follow [these instructions](https://github.com/cyu/rack-cors#rails).
diff --git a/articles/server-apis/rails/index.yml b/articles/server-apis/rails/index.yml
deleted file mode 100644
index fef0f54343..0000000000
--- a/articles/server-apis/rails/index.yml
+++ /dev/null
@@ -1,18 +0,0 @@
-title: Ruby On Rails API
-alias:
-  - rails
-  - ror
-languages:
-  - Ruby
-framework:
-  - Ruby on Rails
-thirdParty: false
-image: /media/platforms/rails.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-apis/rails/dependencies
-  setup: server-apis/rails/setup
-  use: server-apis/rails/use
-articles:
-  - authenticate
diff --git a/articles/server-apis/relay/authenticate.md b/articles/server-apis/relay/authenticate.md
deleted file mode 100644
index 593195970e..0000000000
--- a/articles/server-apis/relay/authenticate.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-title: Authenticate
-description: This tutorial will show you how to use the Auth0 Relay SDK to add authentication and authorization to your API.
----
-
-You can get started by either downloading the seed project or if you would like to add Auth0 to an existing application you can follow the tutorial steps.
-
-<%= include('../../_includes/_package', {
-  org: 'auth0',
-  repo: 'node-auth0',
-  path: 'examples/relay-api',
-  requirements: [
-    'NodeJS 4.3',
-    'React 0.14.0-rc1',
-    'Express 4',
-    'React Relay 0.3.2',
-    'Graphql 0.4.4'
-  ]
-}) %>
-
-**If you have an existing application, please follow the steps below.**
-
-### 1. Add express-jwt Dependency
-
-You need to add  `express-jwt` as a dependency. Also, If you haven't already done so, you need to install `express-graphql`.
-
-Just run the following code to install the dependencies and add them to your `package.json`.
-
-${snippet(meta.snippets.dependencies)}
-
-### 2. Configure express-jwt With your Auth0 Account
-
-You need to set the ClientID and ClientSecret in `express-jwt`'s configuration so that it can validate and sign [JWT](/jwt)s for you.
-
-${snippet(meta.snippets.setup)}
-
-### 3. 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)}
-
-### 4. Send Authorization Header from the Front End
-
-When you send a request to the GraphQL endpoint, you need to include the JWT 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)}
-
-### 5. You're done!
-
-Your Relay app is now secure with Auth0 and `express-jwt`. Congrats, you're awesome!
diff --git a/articles/server-apis/relay/index.yml b/articles/server-apis/relay/index.yml
deleted file mode 100644
index 58365cb514..0000000000
--- a/articles/server-apis/relay/index.yml
+++ /dev/null
@@ -1,17 +0,0 @@
-title: Relay API
-thirdParty: false
-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:
-  - authenticate
diff --git a/articles/server-apis/ruby/authenticate.md b/articles/server-apis/ruby/authenticate.md
deleted file mode 100644
index b48288ea7e..0000000000
--- a/articles/server-apis/ruby/authenticate.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-title: Authenticate
-description: This tutorial will show you how to use the Auth0 Ruby SDK to add authentication and authorization to your API.
----
-
-You can get started by either downloading the seed project or if you would like to add Auth0 to an existing application you can follow these tutorial steps.
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ruby-api-samples',
-  path: '',
-  requirements: [
-    'Ruby 2.1.7'
-  ]
-}) %>
-
-> Note: If you're creating a Ruby On Rails app, please check [this other tutorial](/server-apis/rails).
-
-Otherwise, Please follow the steps below to configure your existing Ruby app to use it with Auth0.
-
-### 1. Add jwt dependency to your Gemfile
-
-You need to add the jwt dependency.
-
-Open your Gemfile and add the following:
-
-${snippet(meta.snippets.dependencies)}
-
-### 2. Validate JWT token
-
-You need to validate the [JWT](/jwt)s to make sure the user is authenticated. For that, you can use the following code:
-
-${snippet(meta.snippets.use)}
-
-### 3. 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" }
-  ]
-}
-```
-
-### 4. You're done!
-
-Now you have both your frontend and backend configured to use Auth0. Congrats, you're awesome!
diff --git a/articles/server-apis/ruby/index.yml b/articles/server-apis/ruby/index.yml
deleted file mode 100644
index 13986f08a8..0000000000
--- a/articles/server-apis/ruby/index.yml
+++ /dev/null
@@ -1,15 +0,0 @@
-title: Ruby API
-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:
-  - authenticate
diff --git a/articles/server-apis/wcf-service/authenticate.md b/articles/server-apis/wcf-service/authenticate.md
deleted file mode 100644
index 79d338a26a..0000000000
--- a/articles/server-apis/wcf-service/authenticate.md
+++ /dev/null
@@ -1,84 +0,0 @@
----
-title: Authenticate
-description: This tutorial will show you how to use the Auth0 WCF SDK to add authentication and authorization to your API.
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0',
-  repo: 'auth0-wcf-rest-sample',
-  path: '',
-  requirements: [
-    'Microsoft Visual Studio 2015',
-    'Auth0-WCF-Service-JWT 1.0.3'
-  ]
-}) %>
-
-This tutorial explains how to consume a WCF service, validating the identity of the caller.
-
-When calling a Web Service (or an API in general) there are two ways users are typically authenticated:
-
-* Through a client that has access to a key that can be used to obtain a token.
-* Through a client that has access to a token that was obtained through some other method.
-
-The first scenario usually happens on trusted clients (e.g. a script, a desktop application). The second scenario is more often a browser, or a mobile native app.
-
-For this tutorial, we will assume the standard WCF template with a `basicHttpBinding`.
-
-## Using Auth0 generated JsonWebTokens with WCF services
-
-The integration consists of adding a `ServiceAuthorizationManager` (which is an extensibility point offered by WCF). This class intercepts all calls to a specific service and extracts the HTTP `Authorization` header that contains the JsonWebToken. Then it validates the token using a symmetric or asymmetric key, checks that it's not expired, and finally, verifies that the `audience` is correct. If all these are correct, control is transferred to the user code with a `ClaimsPrincipal` object set for the app to use.
-
-### 1. Install Auth0-WCF-Service-JWT NuGet package
-
-Use the NuGet Package Manager (Tools -> Library Package Manager -> Package Manager Console) to install the **Auth0-MVC** package, running the command:
-
-${snippet(meta.snippets.dependencies)}
-
-> This package creates the `ServiceAuthorizationManager` and will add a set of configuration settings.
-
-### 2. Completing your app Web.Config with Auth0 settings
-
-${snippet(meta.snippets.setup)}
-
-### 3. Accessing user information
-
-Once the user is successfully authenticated with the application, a `ClaimsPrincipal` will be generated which can be accessed through the `User` or `Thread.CurrentPrincipal` properties:
-
-${snippet(meta.snippets.use)}
-
-### 4. Attaching a token on the client
-
-Install the NuGet package on the client side
-
-```
-Install-Package Auth0-WCF-Client
-```
-
-Extract the `id_token` from the `ClaimsPrincipal` and attach it to the WCF request
-
-```cs
-// get JsonWebToken from logged in user
-string token = ClaimsPrincipal.Current.FindFirst("id_token").Value;
-
-// attach token to WCF request
-client.ChannelFactory.Endpoint.Behaviors.Add(new AttachTokenEndpointBehavior(token));
-
-// call WCF service
-// client.CallService();
-```
-
-> **Note**: the above assumes that the WCF service is protected by the same client secret as the website. If you want to call a service protected by a different secret you can obtain a delegation token as shown below:
-
-```cs
-// get JsonWebToken from logged in user
-string token = ClaimsPrincipal.Current.FindFirst("id_token").Value;
-
-// create an Auth0 client to call the /delegation endpoint using the client id and secret of the caller application
-var auth0 = new Auth0.Client("...caller client id...", "...caller client secret...", "${account.namespace}");
-var result = auth0.GetDelegationToken(token, "${account.clientClient}");
-
-// attach token to WCF request
-client.ChannelFactory.Endpoint.Behaviors.Add(new AttachTokenEndpointBehavior(result));
-```
-
-**Congratulations!**
diff --git a/articles/server-apis/wcf-service/index.yml b/articles/server-apis/wcf-service/index.yml
deleted file mode 100644
index 73f5738aaa..0000000000
--- a/articles/server-apis/wcf-service/index.yml
+++ /dev/null
@@ -1,18 +0,0 @@
-title: .NET WCF
-community: true
-languages:
-  - C#
-  - Visual Basic .Net
-thirdParty: false
-image: /media/platforms/wcf.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-apis/wcf-service/dependencies
-  setup: server-apis/wcf-service/setup
-  use: server-apis/wcf-service/use
-alias:
-  - wcf
-  - windows-communication-foundation
-articles:
-  - authenticate
diff --git a/articles/server-apis/webapi-owin/00-intro.md b/articles/server-apis/webapi-owin/00-intro.md
deleted file mode 100644
index f06bfab067..0000000000
--- a/articles/server-apis/webapi-owin/00-intro.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-title: Introduction
-name: Introduction to the Quickstart, and configuring environment
-budicon: 715
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnet-owin-webapi-sample',
-  path: '00-Starter-Seed/WebApi',
-  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'
-  ]
-}) %>
-
-<%= include('../../_includes/_api_auth_intro') %>
-
-This Quickstart will guide you through the various tasks related to using Auth0-issued JSON Web Tokens to secure your ASP.NET (OWIN) Web API.
-
-## Seed & Samples
-
-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-sample/tree/master/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-sample). You can find the final result for each step in the relevant folder inside the repository.
-
-## 1. Enable OAuth 2.0 API Authorization
-
-<%= include('../../_includes/_configure_oauth2aas') %>
-
-## 2. Create a Resource Server (API)
-
-In the [APIs section](${manage_url}/#/apis) of the Auth0 Dashboard, click the **Create API** button. Provide a **Name** and **Identifier** for your API. Be sure to choose the RS256 signing algorithm.
-
-![Create API](/media/articles/server-apis/webapi-owin/create-api-rs256.png)
-
-Also update the `web.config` file in your project with the correct **Domain** and **API Identifier** for your API, e.g.
-
-```xml
-
-  
-  
-
-```
-
-## 3. Install Dependencies
-
-To use Auth0 Access Tokens with ASP.NET Core you will use the 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.
-
-```bash
-Install-Package Microsoft.Owin.Security.Jwt
-Install-Package Auth0.OpenIdConnectSigningKeyResolver
-```
-
-The seed project contains both these NuGet packages, but if you are adding it to your own existing project you will only need to add the one which is relevant for your scenario.
-
-That's all you need to start working with Auth0 in your Web API!
-
-Please continue with the [Authentication](/quickstart/backend/webapi-owin/01-authentication) tutorial to secure your Web API.
diff --git a/articles/server-apis/webapi-owin/01-authentication.md b/articles/server-apis/webapi-owin/01-authentication.md
deleted file mode 100644
index 970c5bf66a..0000000000
--- a/articles/server-apis/webapi-owin/01-authentication.md
+++ /dev/null
@@ -1,118 +0,0 @@
----
-title: Authentication
-name: Shows how to secure your API using the standard JWT middeware
-budicon: 500
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnet-owin-webapi-sample',
-  path: '01-Authentication/WebApi',
-  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'
-  ]
-}) %>
-
-## 1. Configure the JWT Middleware
-
-To assist in verifying the signature of RS256 tokens you will need to install the `Auth0.OpenIdConnectSigningKeyResolver` NuGet package:
-
-```text
-Install-Package Auth0.OpenIdConnectSigningKeyResolver
-```
-
-This package 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 Signin Key, as will be demonstrated in the JWT registration code below.
-
-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
-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, identifier, parameters) => keyResolver.GetSigningKey(identifier)
-            }
-        });
-
-    // 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.
-:::
-
-## 2. Securing an API endpoint
-
-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
-[RoutePrefix("api")]
-public class PingController : ApiController
-{
-    [Authorize]
-    [HttpGet]
-    [Route("ping/secure")]
-    public IHttpActionResult PingSecured()
-    {
-        return Ok(new
-        {
-            Message = "All good. You only get this message if you are authenticated."
-        }
-        );
-    }
-}
-```
-
-## 3. Using your API
-
-In order to make calls to your API, you will need to obtain an `access_token`. An `access_token` can be obtained in a number of ways, depending on the type of application you are building. These are referred to as authorization grant flows. Please see the [API Authorization section](/api-auth) for more information of the types of flows and to determine which one is most appropriate for your application.
-
-Once you have obtained an `access_token` you can pass that along in the `Authorization` header of requests to your API as a Bearer token.
-
-Here is a sample RAW request:
-
-```text
-GET /api/ping/secure HTTP/1.1
-Host: localhost:58105
-Authorization: Bearer 
-```
-
-Or using [RestSharp](http://restsharp.org/):
-
-```csharp
-var client = new RestClient("http://localhost:58105/api/ping/secure");
-var request = new RestRequest(Method.GET);
-request.AddHeader("authorization", "Bearer ");
-IRestResponse response = client.Execute(request);
-```
-
-## 4. Testing your API in Postman
-
-During development, you may want to test your API with Postman. If you make a request to the `/ping/secure` endpoint you will notice that the API returns an HTTP status code 401 (Unauthorized):
-
-![Unauthorized request in Postman](/media/articles/server-apis/webapi-owin/postman-not-authorized.png)
-
-As mentioned in the previous step, you will need to pass along an `access_token` in the HTTP Authorization header. A quick and easy way to obtain an `access_token` for test purposes is from the __Test__ tab of your API settings: 
-
-![Obtain a JWT](/media/articles/server-apis/webapi-owin/request-access-token.png)
-
-You can then use the `access_token` and pass it along in the Authorization header as a Bearer token:
-
-![Authorized request in Postman](/media/articles/server-apis/webapi-owin/postman-authorized.png)
diff --git a/articles/server-apis/webapi-owin/02-authorization.md b/articles/server-apis/webapi-owin/02-authorization.md
deleted file mode 100644
index 883903eac8..0000000000
--- a/articles/server-apis/webapi-owin/02-authorization.md
+++ /dev/null
@@ -1,120 +0,0 @@
----
-title: API Authorization 
-description: This tutorial will show you how authorize or deny a user to access certain API endpoints based on the scope of the access token.
-budicon: 500
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnet-owin-webapi-sample',
-  path: '02-Authorization/WebApi',
-  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'
-  ]
-}) %>
-
-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 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 query the `scope` claim to ensure that the required permissions were granted in order to call the particular API endpoint. The `scope` claim will contain the list of scopes separated by a space, as can be seen in the example JWT payload below:
-
-```json
-{
-  "iss": "https://auth0pnp.auth0.com/",
-  "sub": "5fJ...",
-  "aud": "https://api.myapp.com/timesheets",
-  "exp": 1479957385,
-  "iat": 1479870985,
-  "scope": "delete:timesheets update:timesheets create:timesheets read:timesheets"
-}
-```
-
-## 1. Define scopes
-
-You will need to define to list of scopes available in your application. In the [APIs section](${manage_url}/#/apis) of the Auth0 Dashboard, select your API and then go to the __Scopes__ tab of the API. Configure the list of Scopes available in your API:
-
-![Configure Scopes](/media/articles/server-apis/webapi-owin/create-api-scopes.png)
-
-Once you have created the list of scopes, go to the __Non-Interactive Clients__ tab. For each client which is able to access your API, ensure that you have Authorized the client and selected the Scopes which can be granted to the Client. Be sure to click the **Update** button once you have configured the Client:
-
-![Configure Client](/media/articles/server-apis/webapi-scopes/configure-api-client-scopes.png)
-
-## 2. Enforcing scopes in your ASP.NET Web API 
-
-To ensure that a correct `scope` is present in order to execute a particular API endpoint, you can create a custom Authorization Attribute. 
-
-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
-public class ScopeAuthorizeAttribute : AuthorizeAttribute
-{
-    private readonly string scope;
-
-    public ScopeAuthorizeAttribute(string scope)
-    {
-        this.scope = scope;
-    }
-    public override void OnAuthorization(HttpActionContext actionContext)
-    {
-        base.OnAuthorization(actionContext);
-
-        ClaimsPrincipal principal = actionContext.ControllerContext.RequestContext.Principal as ClaimsPrincipal;
-        if (principal != null)
-        {
-            // If user does not have the scope claim, get out of here
-            if (principal.HasClaim(c => c.Type == "scope"))
-            {
-
-                // Split the scopes string into an array
-                var scopes = principal.Claims.FirstOrDefault(c => c.Type == "scope").Value.Split(' ');
-
-                // Succeed if the scope array contains the required scope
-                if (scopes.Any(s => s == scope))
-                    return;
-            }
-        }
-
-        HandleUnauthorizedRequest(actionContext);
-    }
-}
-``` 
-
-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
-[RoutePrefix("api/timesheets")]
-public class TimesheetsController : ApiController
-{
-    [ScopeAuthorize("read:timesheets")]
-    [Route("")]
-    [HttpGet]
-    public IHttpActionResult GetAll()
-    {
-        // Return the list of timesheets
-    }
-
-    [ScopeAuthorize("create:timesheets")]
-    [Route("")]
-    [HttpPost]
-    public IHttpActionResult Create(Timesheet timeheet)
-    {
-        // Create a new timesheet entry
-    }
-}
-```
-
-## 3. Testing the Authorization Postman
-
-You can test the API endpoints by generating a token with the required scopes, and passing the `access_token` as a Bearer token in the Authorization header. 
-
-If the required `scope` is present, the API call will succeed:
-
-![](/media/articles/server-apis/aspnet-core-webapi/scope-success.png)
-
-If the required `scope` is not present, an HTTP Status 403 (Forbidden) will be returned: 
-
-![](/media/articles/server-apis/aspnet-core-webapi/scope-forbidden.png)
diff --git a/articles/server-apis/webapi-owin/03-authentication-hs256.md b/articles/server-apis/webapi-owin/03-authentication-hs256.md
deleted file mode 100644
index 053554b5d3..0000000000
--- a/articles/server-apis/webapi-owin/03-authentication-hs256.md
+++ /dev/null
@@ -1,139 +0,0 @@
----
-title: Authentication with HS256
-name: Shows how to secure your API using the standard JWT middeware
-budicon: 500
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnet-owin-webapi-sample',
-  path: '03-Authentication-HS256/WebApi',
-  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'
-  ]
-}) %>
-
-::: panel-warning Signing Algorithm
-Auth0 can sign JSON Web Tokens (JWT) using either a symmetric key (HS256) or an asymmetric key (RS256). This document demonstrates how to use tokens signed with the HS256 Algorithm. 
-
-It is however recommended that you [rather use RS256](/quickstart/backend/webapi-owin/01-authentication) tutorial.
-:::
-
-## 1. Enable OAuth 2.0 API Authorization
-
-<%= include('../../_includes/_configure_oauth2aas') %>
-
-## 2. Create a Resource Server (API)
-
-In the [APIs section]("${manage_url}/#/apis) of the Auth0 Dashboard, click the **Create API** button. Provide a **Name** and **Identifier** for your API. Be sure to choose the HS256 signing algorithm.
-
-![Create API](/media/articles/server-apis/webapi-owin/create-api-hs256.png)
-
-After you have created the API, navigate to the **Settings** tab of the API, and take note of the **API Identifier** and **Signing Secret**, as it will be used configuring the JWT middleware.
-
-## 3. Update your settings
-
-When using HS256, you will need your API's **Signing Secret** when configuring the JWT middleware, so be sure update the `web.config` file included in the seed project to also add a **Auth0ApiSecret** key with the value of the Signing Secret. Be sure to set the correct values for the **Auth0Domain** and **Auth0ApiIdentifier** elements as well:
-
-```xml
-
-    
-    
-    
-
-```
-
-## 4. Configure the JWT Middleware
-
-You will need to add the JWT middleware to your application's middleware pipeline.
-
-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 the API Identifier in the `AllowedAudiences` property and the Auth0 Domain as the `issuer` and the API's Signing Secret as the `key` parameters of the `SymmetricKeyIssuerSecurityTokenProvider`:
-
-```csharp
-public void Configuration(IAppBuilder app)
-{
-    var issuer = $"https://{ConfigurationManager.AppSettings["Auth0Domain"]}/";
-    var audience = ConfigurationManager.AppSettings["Auth0ApiIdentifier"];
-    var secret = Encoding.UTF8.GetBytes(ConfigurationManager.AppSettings["Auth0ApiSecret"]);
-
-    // Api controllers with an [Authorize] attribute will be validated with JWT
-    app.UseJwtBearerAuthentication(
-        new JwtBearerAuthenticationOptions
-        {
-            AuthenticationMode = AuthenticationMode.Active,
-            AllowedAudiences = new[] { audience },
-            IssuerSecurityTokenProviders = new IIssuerSecurityTokenProvider[]
-            {
-                new SymmetricKeyIssuerSecurityTokenProvider(issuer, secret)
-            },
-        });
-
-    // Configure Web API
-    WebApiConfig.Configure(app);
-}
-```
-
-::: panel-warning Do not forget the trailing backslash
-Please ensure that the URL specified for the `issuer` parameter 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.
-:::
-
-## 5. Securing an API endpoint
-
-The JWT middleware integrates with the standard ASP.NET Authentication and Authorization mechanisms. You only need to decorate your controller action with the `[Authorize]` attribute to secure an endpoint:
-
-```csharp
-[RoutePrefix("api")]
-public class PingController : Controller
-{
-    [Authorize]
-    [HttpGet]
-    [Route("ping/secure")]
-    public IHttpActionResult PingSecured()
-    {
-        return Ok(new
-        {
-            Message = "All good. You only get this message if you are authenticated."
-        }
-        );
-    }
-}
-```
-
-## 6. Using your API
-
-In order to make calls to your API, you will need to obtain an `access_token`. An `access_token` can be obtained in a number of ways, depending on the type of application your are building. These are referred to as authorization grant flows. Please see the [API Authorization section](/api-auth) for more information of the types of flows and to determine which one is most appropriate for your application.
-
-Once you have obtained an `access_token` you can pass that along in the `Authorization` header of requests to your API as a Bearer token.
-
-Here is a sample RAW request:
-
-```text
-GET /api/ping/secure HTTP/1.1
-Host: localhost:58105
-Authorization: Bearer 
-```
-
-Or using [RestSharp](http://restsharp.org/):
-
-```csharp
-var client = new RestClient("http://localhost:58105/api/ping/secure");
-var request = new RestRequest(Method.GET);
-request.AddHeader("authorization", "Bearer ");
-IRestResponse response = client.Execute(request);
-```
-
-## 7. Testing your API in Postman
-
-During development you may want to test your API with Postman. If you make a request to the `/ping/secure` endpoint you will notice that the API returns an HTTP status code 401 (Unauthorized):
-
-![Unauthorized request in Postman](/media/articles/server-apis/webapi-owin/postman-not-authorized.png)
-
-As mentioned in the previous step, you will need to pass along an `access_token` in the HTTP Authorization header. A quick and easy way to obtain an `access_token` for test purposes is from the __Test__ tab of your API settings: 
-
-![Obtain a JWT](/media/articles/server-apis/webapi-owin/request-access-token.png)
-
-You can then use the `access_token` and pass it along in the Authorization header as a Bearer token:
-
-![Authorized request in Postman](/media/articles/server-apis/webapi-owin/postman-authorized.png)
diff --git a/articles/server-apis/webapi-owin/04-authentication-rs256-deprecated.md b/articles/server-apis/webapi-owin/04-authentication-rs256-deprecated.md
deleted file mode 100644
index ca7627ca97..0000000000
--- a/articles/server-apis/webapi-owin/04-authentication-rs256-deprecated.md
+++ /dev/null
@@ -1,129 +0,0 @@
----
-title: Authentication
-name: Shows how to secure your API using the standard JWT middeware
-budicon: 500
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnet-owin-webapi-sample',
-  path: '04-Authentication-RS256-Deprecated/WebApi',
-  requirements: [
-    'Microsoft Visual Studio 2015 Update 3',
-    'Microsoft.Owin.Security.ActiveDirectory V3.0.1',
-    'System.IdentityModel.Tokens.Jwt NuGet Package v4.0.2'
-  ]
-}) %>
-
-Auth0 can sign JSON Web Tokens (JWT) using either a symmetric key (HS256) or an asymmetric key (RS256). This particular document will describe how to configure Auth0 to sign tokens using RS256.
-
-> If you want to use HS256 then please go to the [Authentication using HS256](/quickstart/backend/webapi-owin/02-authentication-hs256) tutorial.
-
-## 1. Configure JSON Web Token Signature Algorithm
-
-To configure the JWT Signature Algorithm, 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.
-
-![Configure JWT Signature Algorithm as RS256](/media/articles/server-apis/webapi-owin/jwt-signature-rs256.png)
-
-## 2. Configure the JWT Middleware
-
-You will need to add the Active Directory Services Bearer Token middleware to your application's middleware pipeline.
-
-Go to the `Configuration` method of your `Startup` class and add a call to `UseActiveDirectoryFederationServicesBearerAuthentication` passing in the configured `ActiveDirectoryFederationServicesBearerAuthenticationOptions`.
-
-The `ActiveDirectoryFederationServicesBearerAuthenticationOptions` needs to specify your Auth0 Client ID in the `ValidAudience` property, and the full path to your Auth0 domain as the `ValidIssuer`. You will also need to specify the `MetadataEndpoint` property which will allow the middleware to automatically download the public key from Auth0 in order to verify the signature of the JSON Web Tokens.
-
-```csharp
-public void Configuration(IAppBuilder app)
-{
-    var issuer = $"https://{ConfigurationManager.AppSettings["Auth0Domain"]}/";
-    var audience = ConfigurationManager.AppSettings["Auth0ClientID"];
-
-    // Api controllers with an [Authorize] attribute will be validated with JWT
-    app.UseActiveDirectoryFederationServicesBearerAuthentication(
-        new ActiveDirectoryFederationServicesBearerAuthenticationOptions
-        {
-            TokenValidationParameters = new TokenValidationParameters
-            {
-                ValidAudience = audience,
-                ValidIssuer = issuer,
-                IssuerSigningKeyResolver = (token, securityToken, identifier, parameters) => parameters.IssuerSigningTokens.FirstOrDefault()?.SecurityKeys?.FirstOrDefault()
-            },
-            // Setting the MetadataEndpoint so the middleware can download the RS256 certificate
-            MetadataEndpoint = $"{issuer.TrimEnd('/')}/wsfed/{audience}/FederationMetadata/2007-06/FederationMetadata.xml"
-        });
-
-
-    // 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.
-:::
-
-## 3. Securing an API endpoint
-
-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
-[RoutePrefix("api")]
-public class PingController : ApiController
-{
-    [Authorize]
-    [HttpGet]
-    [Route("ping/secure")]
-    public IHttpActionResult PingSecured()
-    {
-        return Ok(new
-        {
-            Message = "All good. You only get this message if you are authenticated."
-        }
-        );
-    }
-}
-```
-
-## 4. Using your API
-
-You can make calls to your API by authenticating a user using any of our Lock integrations and then using the `id_token` obtained during authentication and passing that in the `Authorization` header of requests to your API as a Bearer token.
-
-Here is a sample RAW request:
-
-```bash
-GET /api/ping/secure HTTP/1.1
-Host: localhost:58105
-Authorization: Bearer 
-```
-
-Or using [RestSharp](http://restsharp.org/):
-
-```csharp
-var client = new RestClient("http://localhost:58105/api/ping/secure");
-var request = new RestRequest(Method.GET);
-request.AddHeader("authorization", "Bearer ");
-IRestResponse response = client.Execute(request);
-```
-
-## 5. Testing your API in Postman
-
-During development you may want to test your API with Postman.
-
-If you make a request to the `/api/ping/secure` endpoint you will notice that the API returns an HTTP status code 401 (Unauthorized):
-
-![Unauthorized request in Postman](/media/articles/server-apis/webapi-owin/postman-not-authorized.png)
-
-As mentioned in the previous step, you will need to pass along an `id_token` in the HTTP Authorization header. A quick and easy way to obtain an `id_token` is to call the `/oauth/ro` endpoint using the Auth0 [Authentication API Explorer](/api/authentication/reference#resource-owner):
-
-![Obtain a JWT](/media/articles/server-apis/webapi-owin/request-jwt.png)
-
-Now you can use the `id_token` and pass it along in the Authorization header as a Bearer token:
-
-![Authorized request in Postman](/media/articles/server-apis/webapi-owin/postman-authorized.png)
-
-## Next Step
-
-To learn how to allow only users in a certain role to access a particular endpoint, please continue with the [Authorization](/quickstart/backend/webapi-owin/03-authorization) tutorial.
diff --git a/articles/server-apis/webapi-owin/05-authentication-hs256-deprecated.md b/articles/server-apis/webapi-owin/05-authentication-hs256-deprecated.md
deleted file mode 100644
index ed7e5709d1..0000000000
--- a/articles/server-apis/webapi-owin/05-authentication-hs256-deprecated.md
+++ /dev/null
@@ -1,137 +0,0 @@
----
-title: Authentication (HS256)
-name: Shows how to secure your API using the standard JWT middeware
-budicon: 500
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnet-owin-webapi-sample',
-  path: '05-Authentication-HS256-Deprecated/WebApi',
-  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 can sign JSON Web Tokens (JWT) using either a symmetric key (HS256) or an asymmetric key (RS256). This particular document will describe how to configure Auth0 to sign tokens using HS256.
-
-> If you want to use RS256 then please go to the [Authentication using RS256](/quickstart/backend/webapi-owin/01-authentication-rs256) tutorial.
-
-## 1. Configure JSON Web Token Signature Algorithm
-
-To configure the JWT Signature Algorithm, 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 **HS256**.
-
-Save your changes.
-
-![Configure JWT Signature Algorithm as HS256](/media/articles/server-apis/webapi-owin/jwt-signature-hs256.png)
-
-## 2. Update your settings
-
-When using HS256, you will need your application's **Client Secret** when configuring the JWT middleware, so be sure update the `web.config` file included in the seed project to also add a **Auth0ClientSecret** key, and be sure to set the correct values for the **Auth0Domain**, **Auth0ClientID** and **Auth0ClientSecret** elements:
-
-```json
-
-  
-  
-  
-
-```
-
-## 3. Configure the JWT Middleware
-
-You will need to add the JWT middleware to your application's middleware pipeline.
-
-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 the Client ID in the `AllowedAudiences` property and the Auth0 Domain as the `issuer` and the Base64-decoded Client Secret as the `key` parameters of the `SymmetricKeyIssuerSecurityTokenProvider`:
-
-```csharp
-public void Configuration(IAppBuilder app)
-{
-    var issuer = $"https://{ConfigurationManager.AppSettings["Auth0Domain"]}/";
-    var audience = ConfigurationManager.AppSettings["Auth0ClientID"];
-    var secret = Encoding.UTF8.GetBytes(ConfigurationManager.AppSettings["Auth0ClientSecret"]);
-
-    // Api controllers with an [Authorize] attribute will be validated with JWT
-    app.UseJwtBearerAuthentication(
-        new JwtBearerAuthenticationOptions
-        {
-            AuthenticationMode = AuthenticationMode.Active,
-            AllowedAudiences = new[] { audience },
-            IssuerSecurityTokenProviders = new IIssuerSecurityTokenProvider[]
-            {
-                new SymmetricKeyIssuerSecurityTokenProvider(issuer, secret)
-            },
-        });
-
-    // Configure Web API
-    WebApiConfig.Configure(app);
-}
-```
-
-::: panel-warning Do not forget the trailing backslash
-Please ensure that the URL specified for the `issuer` parameter 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.
-:::
-
-## 4. Securing an API endpoint
-
-The JWT middleware integrates with the standard ASP.NET Authentication and Authorization mechanisms. You only need to decorate your controller action with the `[Authorize]` attribute to secure an endpoint:
-
-```csharp
-[RoutePrefix("api")]
-public class PingController : Controller
-{
-    [Authorize]
-    [HttpGet]
-    [Route("ping/secure")]
-    public IHttpActionResult PingSecured()
-    {
-        return Ok(new
-        {
-            Message = "All good. You only get this message if you are authenticated."
-        }
-        );
-    }
-}
-```
-
-## 5. Using your API
-
-You can make calls to your API by authenticating a user using any of our Lock integrations and then using the `id_token` obtained during authentication and passing that in the `Authorization` header of requests to your API as a Bearer token.
-
-Here is a sample RAW request:
-
-```bash
-GET /api/ping/secure HTTP/1.1
-Host: localhost:58105
-Authorization: Bearer 
-```
-
-Or using [RestSharp](http://restsharp.org/):
-
-```csharp
-var client = new RestClient("http://localhost:58105/api/ping/secure");
-var request = new RestRequest(Method.GET);
-request.AddHeader("authorization", "Bearer ");
-IRestResponse response = client.Execute(request);
-```
-
-## 6. Testing your API in Postman
-
-During development you may want to test your API with Postman.
-
-If you make a request to the `/api/ping/secure` endpoint you will notice that the API returns an HTTP status code 401 (Unauthorized):
-
-![Unauthorized request in Postman](/media/articles/server-apis/webapi-owin/postman-not-authorized.png)
-
-As mentioned in the previous step, you will need to pass along an `id_token` in the HTTP Authorization header. A quick and easy way to obtain an `id_token` is to call the `/oauth/ro` endpoint using the Auth0 [Authentication API Explorer](/api/authentication/reference#resource-owner):
-
-![Obtain a JWT](/media/articles/server-apis/webapi-owin/request-jwt.png)
-
-Now you can use the `id_token` and pass it along in the Authorization header as a Bearer token:
-
-![Authorized request in Postman](/media/articles/server-apis/webapi-owin/postman-authorized.png)
-
-## Next Step
-
-To learn how to allow only users in a certain role to access a particular endpoint, please continue with the [Authorization](/quickstart/backend/webapi-owin/03-authorization) tutorial.
diff --git a/articles/server-apis/webapi-owin/06-authorization-deprecated.md b/articles/server-apis/webapi-owin/06-authorization-deprecated.md
deleted file mode 100644
index 8b401b5dce..0000000000
--- a/articles/server-apis/webapi-owin/06-authorization-deprecated.md
+++ /dev/null
@@ -1,85 +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 API endpoints.
-budicon: 500
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnet-owin-webapi-sample',
-  path: '06-Authorization-Deprecated/WebApi',
-  requirements: [
-    'Microsoft Visual Studio 2015 Update 3',
-    'Microsoft.Owin.Security.ActiveDirectory V3.0.1',
-    'System.IdentityModel.Tokens.Jwt NuGet Package v4.0.2'
-  ]
-}) %>
-
-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.
-
-## 1.Create a Rule to assign roles
-
-First, you must create a rule that assigns users either an `admin` role, or a single `user` role. To do so, go to the [new rule page](${manage_url}/#/rules/new) and select the "*Set Roles To A User*" template, under *Access Control*. Then, replace this line from the default script:
-
-```
-if (user.email.indexOf('@example.com') > -1)
-```
-
-to match the condition that fits your needs. Notice that you can also set more roles other than `admin` and `user`, or customize the whole rule as you please.
-
-By default, it says that if the user email contains `@example.com` he will be given an `admin` role, otherwise a regular `user` role.
-
-## 2. Restrict an action based on a user's roles
-
-The JWT middleware will automatically map claims contained in the JWT to claims on the `ClaimsIdentity`. Specifically, it will look for a "roles" claim on the `id_token`, and then for each role inside the array on the "roles" claim, it will add a "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" claim to the `ClaimsIdentity`.
-
-This means that it integrates seamlessly with the Role based authorization inside ASP.NET.
-
-Once the correct claims are being returned from Auth0, all you therefore have to do is decorate your controller actions with the `[Authorize(Roles = ?)]` attribute.
-
-The sample code below will restrict the particular action only to user who have the "admin" role:
-
-```csharp
-[RoutePrefix("api")]
-public class PingController : ApiController
-{
-    [Authorize(Roles = "admin")]
-    [HttpGet]
-    [Route("ping/admin")]
-    public IHttpActionResult PingAdmin()
-    {
-        return Ok(new
-        {
-            Message = "All good. Only administrators will be able to call this endpoint."
-        }
-        );
-    }
-}
-```
-
-### Debugging Claims
-
-The sample source code for this quickstart contains a very handy API endpoint which allows you to view the claims associated with a particular JWT. You simply make a call to the `/api/claims` endpoint and it will return all the claims associated with the JWT.
-
-The source code for this action is very simple, so you can easily add it to your own projects as well to assist when debugging JSON Web Tokens:
-
-```csharp
-[RoutePrefix("api")]
-public class PingController : ApiController
-{
-    [Authorize]
-    [Route("claims")]
-    [HttpGet]
-    public object Claims()
-    {
-        var claimsIdentity = User.Identity as ClaimsIdentity;
-
-        return claimsIdentity.Claims.Select(c =>
-            new
-            {
-                Type = c.Type,
-                Value = c.Value
-            });
-    }
-}
-```
diff --git a/articles/server-apis/webapi-owin/index.yml b/articles/server-apis/webapi-owin/index.yml
deleted file mode 100644
index 83adc7f061..0000000000
--- a/articles/server-apis/webapi-owin/index.yml
+++ /dev/null
@@ -1,15 +0,0 @@
-title: ASP.NET Web API (OWIN)
-alias:
-  - owin
-languages:
-  - C#
-thirdParty: false
-framework:
-  - OWIN
-image: /media/platforms/asp.png
-tags:
-  - quickstart
-articles:
-  - 04-authentication-rs256-deprecated
-  - 05-authentication-hs256-deprecated
-  - 06-authorization-deprecated
\ No newline at end of file
diff --git a/articles/server-platforms/_callbackRegularWebApp.md b/articles/server-platforms/_callbackRegularWebApp.md
deleted file mode 100644
index c78d9e14ba..0000000000
--- a/articles/server-platforms/_callbackRegularWebApp.md
+++ /dev/null
@@ -1,11 +0,0 @@
-
        
-<% if (account.callback) { %>
-
        For security purposes, you must add the callback URL of your app to your Client 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 Client Settings.
        
-<% } %>
-
-
        
diff --git a/articles/server-platforms/_includes/_authorization-introduction.md b/articles/server-platforms/_includes/_authorization-introduction.md
deleted file mode 100644
index a09c294213..0000000000
--- a/articles/server-platforms/_includes/_authorization-introduction.md
+++ /dev/null
@@ -1,15 +0,0 @@
-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.
-
-> This tutorial assumes that you've already read the [rules tutorial](${ruleslink}) and you know how to implement a basic rule in your app.
-
-### 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 select the "*Set Roles To A User*" template, under *Access Control*. Then, replace this line from the default script:
-
-```
-if (user.email.indexOf('@example.com') > -1)
-```
-
-to match the condition that fits your needs. Notice that you can also set more roles other than `admin` and `user`, or customize the whole rule as you please.
-
-By default, it says that if the user email contains `@example.com` they will be given an `admin` role, otherwise a regular `user` role.
diff --git a/articles/server-platforms/_includes/_mfa-enable.md b/articles/server-platforms/_includes/_mfa-enable.md
deleted file mode 100644
index 187dca8f25..0000000000
--- a/articles/server-platforms/_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.
\ No newline at end of file
diff --git a/articles/server-platforms/_includes/_mfa-introduction.md b/articles/server-platforms/_includes/_mfa-introduction.md
deleted file mode 100644
index 2be68687f7..0000000000
--- a/articles/server-platforms/_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/server-platforms/_includes/_mfa-login.md b/articles/server-platforms/_includes/_mfa-login.md
deleted file mode 100644
index e868c33478..0000000000
--- a/articles/server-platforms/_includes/_mfa-login.md
+++ /dev/null
@@ -1,7 +0,0 @@
-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: [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/server-platforms/_includes/_rules-create-section.md b/articles/server-platforms/_includes/_rules-create-section.md
deleted file mode 100644
index 48c7a0796e..0000000000
--- a/articles/server-platforms/_includes/_rules-create-section.md
+++ /dev/null
@@ -1,11 +0,0 @@
-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 you may use one of the existing templates. These templates are written by Auth0 to cover common scenarios and use cases.
-
-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, as 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/articles/server-platforms/_includes/_rules-introduction.md b/articles/server-platforms/_includes/_rules-introduction.md
deleted file mode 100644
index fe9d2b6a6c..0000000000
--- a/articles/server-platforms/_includes/_rules-introduction.md
+++ /dev/null
@@ -1,15 +0,0 @@
-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).
-
-## Create a Rule
-
-To create a rule, go to the [new rule page](${manage_url}/#/rules/new). You can create a new rule from scratch or use an existing template. These templates are written by Auth0 team to assist you complete common tasks.
-
-Select the template called "Add country to the user profile"
-
-![Empty rule](/media/articles/rules/rule-choose-add-country-template.png)
-
-This rule simply gets the `country_name` from the context and adds it as a new `country` attribute to the user profile.
-
-![Add country rule](/media/articles/rules/rule-create-add-country-country.png)
-
-This is just a starting template, and you can edit it to meet your business needs. Once you are done, save the rule and that's it. Whenever a user logs in, the rule will be executed, and the country will be added to the user's profile.
diff --git a/articles/server-platforms/apache/01-login.md b/articles/server-platforms/apache/01-login.md
deleted file mode 100644
index f31e7cff15..0000000000
--- a/articles/server-platforms/apache/01-login.md
+++ /dev/null
@@ -1,71 +0,0 @@
----
-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
----
-
-::: panel-info 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/pingidentity/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/pingidentity/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 client 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/articles/server-platforms/apache/index.yml b/articles/server-platforms/apache/index.yml
deleted file mode 100644
index dae49cc267..0000000000
--- a/articles/server-platforms/apache/index.yml
+++ /dev/null
@@ -1,13 +0,0 @@
-title: Apache
-community: true
-image: /media/platforms/apache.jpg
-tags:
-  - 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
diff --git a/articles/server-platforms/asp-classic/01-login.md b/articles/server-platforms/asp-classic/01-login.md
deleted file mode 100644
index d5b07a0688..0000000000
--- a/articles/server-platforms/asp-classic/01-login.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to use the Auth0 ASP Classic SDK to add authentication and authorization to your web app.
-budicon: 448
----
-
-::: panel-info System Requirements
-This tutorial and seed project have been tested with the following:
-* Microsoft Internet Information Services (IIS)
-:::
-
-
-
-**Please follow the steps below to configure your existing ASP.Net Classic WebApp to use it with Auth0.**
-
-## Showing the Login Widget
-
-First, we need to create the `default.asp` which will show the Login Widget from Auth0.
-
-${snippet(meta.snippets.setup)}
-
-After logging in with any provider, Auth0 will redirect the user to `/callback.asp`.
-
-## Processing the Callback Response
-
-For parsing JSON response, we'll download [json2.js](http://cdnjs.cloudflare.com/ajax/libs/json2/20130526/json2.js) and put it in the project directory.
-
-We need to add the handler for the Auth0 callback so that we can authenticate the user and get their information. For that, we'll create the `callback.asp` file.
-
-It will implement the basic OAuth 2 flow:
-
-1. Exchanges the **code** for an **access_token**
-1. Calls the **Userinfo** endpoint to get the current logged in user profile using the access_token as credentials.
-
-${snippet(meta.snippets.use)}
diff --git a/articles/server-platforms/asp-classic/index.yml b/articles/server-platforms/asp-classic/index.yml
deleted file mode 100644
index fad7e5e116..0000000000
--- a/articles/server-platforms/asp-classic/index.yml
+++ /dev/null
@@ -1,11 +0,0 @@
-title: ASP Classic
-image: /media/platforms/asp-classic.jpg
-tags:
-  - quickstart
-snippets:
-  setup: server-platforms/asp-classic/setup
-  use: server-platforms/asp-classic/use
-seo_alias: asp-classic
-default_article: 01-login
-articles:
-  - 01-login
diff --git a/articles/server-platforms/aspnet-core/00-intro.md b/articles/server-platforms/aspnet-core/00-intro.md
deleted file mode 100644
index e5fc4c3bf9..0000000000
--- a/articles/server-platforms/aspnet-core/00-intro.md
+++ /dev/null
@@ -1,32 +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-info System Requirements
-This tutorial and seed project have been tested with the following:
-
-* .NET Core 1.0
-
-This tutorial can be completed with the command line tools and your code editor of choice, or alternatively you can use Microsoft Visual Studio 2015 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-sample/tree/master/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 [Sample repository](https://github.com/auth0-samples/auth0-aspnetcore-sample). You can find the final result for each step in the relevant folder inside the repository.
-
-## Create an Application
-
-<%= include('../../_includes/_new_app') %>
-
-![App Dashboard](/media/articles/angularjs/app_dashboard.png)
-
-<%= include('_includes/_setup') %>
-
-Please continue with the [Login](/quickstart/webapp/aspnet-core/01-login) tutorial for instruction on how to implement basic login.
diff --git a/articles/server-platforms/aspnet-core/01-login.md b/articles/server-platforms/aspnet-core/01-login.md
deleted file mode 100644
index e88b511d79..0000000000
--- a/articles/server-platforms/aspnet-core/01-login.md
+++ /dev/null
@@ -1,13 +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-sample',
-  path: '01-Login'
-}) %>
-
-<%= include('_includes/_login') %>
diff --git a/articles/server-platforms/aspnet-core/02-login-embedded-lock.md b/articles/server-platforms/aspnet-core/02-login-embedded-lock.md
deleted file mode 100644
index c189b00437..0000000000
--- a/articles/server-platforms/aspnet-core/02-login-embedded-lock.md
+++ /dev/null
@@ -1,244 +0,0 @@
----
-title: Login with Embedded Lock
-description: This tutorial will show you can host the Lock widget inside your application instead of using the Lock widget which is hosted on the Auth0 domain.
-budicon: 448
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnetcore-sample',
-  path: '02-Login-Embedded-Lock'
-}) %>
-
-## Background
-
-When using the normal OIDC middleware, when a user wants to log in and the middleware is called, the user will be redirected to the Auth0 website to sign in using the hosted version of Lock. This may not be the user experience you are looking for. You may for example want to embed Lock inside your application so it has more of the look-and-feel of your own application. In this instance, you can use both Lock and the OIDC middleware together, but it requires a bit of extra work on your side.
-
-Normally when the OIDC middleware initiates the 1st leg of the authentication, it will send along information contained in `state` and `nonce` parameters. After the user has authenticated and Auth0 redirects back to the redirect URL inside your application, in will pass back this `state` and `nonce` parameters. The OIDC middleware is going to pick up that callback to the redirect URL because it will need to exchange the `code` for an `access_token`. It will, however, validate the `state` and `nonce` parameters to protect against CSRF.
-
-This poses a problem. When you embed Lock in your application, the OIDC middleware is not initiating the 1st leg of the OAuth flow. Instead, the embedded Lock widget is initiating that first step.
-
-You will therefore need to construct correct `state` and `nonce` parameters (as if the OIDC middleware did it so that it can validate it correctly), and then be sure to specify the `state` and `nonce` parameters on Lock so that Auth0 can send back the correct values for these parameters after the user has authenticated.
-
-## Configure OpenID Connect middleware
-
-In the `ConfigureServices` method of your `Startup` class, ensure that you add the authentication services. You will also need to register the `OpenIdConnectOptions` with the Dependency Injection (DI) framework.
-
-The `OpenIdConnectOptions` will contain the configuration settings required for the OIDC middleware to communicate with Auth0 correctly:
-
-```csharp
-public void ConfigureServices(IServiceCollection services)
-{
-  // Add authentication services
-  services.AddAuthentication(
-    options => options.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme);
-
-  // Configure OIDC
-  services.Configure(options =>
-  {
-    // Specify Authentication Scheme
-    options.AuthenticationScheme = "Auth0";
-
-    // 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"];
-
-    // Do not automatically authenticate and challenge
-    options.AutomaticAuthenticate = false;
-    options.AutomaticChallenge = false;
-
-    // Set response type to code
-    options.ResponseType = "code";
-
-    // Set the callback path, so Auth0 will call back to http://localhost:60856/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";
-  });
-
-  // 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"));
-}
-```
-
-The reason we configure the OIDC options with the DI Framework is because we will need to obtain it later in order to construct the correct State parameter.
-
-## Configure OpenID Connect middleware
-
-Next, you must configure the Cookie and OIDC middleware in the `Configure` method.
-
-First, be sure to change the signature of your `Configure` method to accept a parameter called `oidcOptions` of type `IOptions`. The DI framework will inject the `OpenIdConnectOptions` registered in the `ConfigureServices` method as the value of this parameter.
-
-Next, register the Cookie middleware by making a call to the `UseCookieAuthentication` method. Then register the OIDC middleware by making a call to the `UseOpenIdConnectAuthentication` method, passing along the value of the `oidcOptions` parameter which was injected by the DI framework.
-
-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
-public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory, IOptions oidcOptions)
-{
-    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
-    app.UseOpenIdConnectAuthentication(oidcOptions.Value);
-
-    app.UseMvc(routes =>
-    {
-        routes.MapRoute(
-            name: "default",
-            template: "{controller=Home}/{action=Index}/{id?}");
-    });
-}
-```
-
-## Add the OpenID Connect helper classes
-
-In order to configure the `state` parameter and save the correct Cookies for the OIDC middleware to work correctly when the redirect URL is called, you will need to add 2 helper classes to your project. You can download the source code for these helper files classes from the following locations:
-
-* [Auth0Extensions.cs](https://github.com/auth0-samples/auth0-aspnetcore-sample/blob/master/02-Login-Embedded-Lock/SampleMvcApp/Auth0Extensions.cs)
-* [LockContext.cs](https://github.com/auth0-samples/auth0-aspnetcore-sample/blob/master/02-Login-Embedded-Lock/SampleMvcApp/LockContext.cs)
-
-::: panel-warning Fix namespaces
-Be sure fix the namespaces in the files above to correlate with the namespace of your own project
-:::
-
-## Add Login and Logout methods
-
-Next, you will need to add `Login` and `Logout` actions to the `AccountController`.
-
-First though, add a constructor to the `AccountController` which will accept a parameter of `IOptions` (this will be injected by the DI framework). Be sure to save this parameter to an instance variable, as you will need to use it in the `Login` action.
-
-The `Login` method must call the `GenerateLockContext` extension method which will create the correct `state` and `nonce` parameters and set the correct Cookies for the OIDC middleware to function correctly. It will return a `LockContext` parameter which you must pass along to the View.
-
-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:
-
-``` csharp
-public class AccountController : Controller
-{
-    IOptions _options;
-
-    public AccountController(IOptions options)
-    {
-        _options = options;
-    }
-
-    // GET: //
-    public IActionResult Login(string returnUrl = null)
-    {
-        var lockContext = HttpContext.GenerateLockContext(_options.Value, returnUrl);
-
-        return View(lockContext);
-    }
-
-    public async Task Logout()
-    {
-        // Sign the user out of the authentication middleware (i.e. it will clear the Auth cookie)
-        HttpContext.Authentication.SignOutAsync("Auth0");
-        await HttpContext.Authentication.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme);
-
-        // Redirect the user to the home page after signing out
-        return RedirectToAction("Index", "Home");
-    }
-}
-```
-
-## Create the Login View
-
-For the Login screen you can create a Razor view and embed the code for Lock. You can head over to our [Lock Library page](/libraries/lock#start-using-auth0lock) and configure Lock the way you want, and then copy and paste the code it generated into your Login page:
-
-```html
-@model LockContext
-
-
        
-	embeded area
-
        
-
-
-```
-
-Be sure to set the Client ID, Domain and Callback URL values from the ones supplied by the `LockContext` model. Also be sure to set the correct `state` and `nonce` parameters as shown above, as this is the key to getting everything to work together.
-
-## 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. This will link to the `Logout` and `Login` actions of the `AccountController` respectively:
-
-```html
-
        
-    
        
-        
        
-            
-            SampleMvcApp
-        
        
-        
        
-            
-            
          
-                @if (User.Identity.IsAuthenticated)
-                {
-                    
        • Logout
          • 
-                }
-                else
-                {
-                    
        • Login
          • 
-                }
-            
        
-        
        
-    
        
-
        
-```
-
-## Run your application
-
-Now, when you run the application you can select the Login link to log in to the application. This will take you to the Login view containing the embedded Lock widget. After the user has logged in they can click on the Logout link to log them out of the application.
diff --git a/articles/server-platforms/aspnet-core/03-login-custom.md b/articles/server-platforms/aspnet-core/03-login-custom.md
deleted file mode 100644
index 6e1368a970..0000000000
--- a/articles/server-platforms/aspnet-core/03-login-custom.md
+++ /dev/null
@@ -1,310 +0,0 @@
----
-title: Custom Login
-description: This tutorial will show you how to create a custom login page for your web application by using the Auth0 .NET SDK and OpenID Connect middleware.
-budicon: 448
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnetcore-sample',
-  path: '03-Login-Custom'
-}) %>
-
-
-## Add the Auth0 Authentication SDK
-
-To log in the user you will be using the Auth0 Authentication SDK for .NET, so install the NuGet package:
-
-```bash
-Install-package Auth0.AuthenticationApi
-```
-
-## Register the Middlware
-
-First you need to register the cookie middleware. Update the `ConfigureServices` method in your `Startup` class to register the relevant services for the cookie middleware:
-
-```csharp
-// Add authentication services
-services.AddAuthentication(
-    options => options.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme);
-```
-
-Also update the `Configure` method in your `Startup` class to register the cookie middleware:
-
-```csharp
-// Add the cookie middleware
-app.UseCookieAuthentication(new CookieAuthenticationOptions
-{
-  AutomaticAuthenticate = true,
-  AutomaticChallenge = true
-});
-```
-
-It is best to register the Cookie middleware just before you register the MVC middleware.
-
-## Create the Login Form
-
-You need to create a Login form which will capture the user's email address and password and then use the Authentication SDK to sign the user it.
-
-First create a view model called `LoginViewModel` to bind the values in the form to:
-
-```csharp
-public class LoginViewModel
-{
-  [Required]
-  [EmailAddress]
-  [Display(Name = "Email Address")]
-  public string EmailAddress { get; set; }
-
-  [Required]
-  [DataType(DataType.Password)]
-  [Display(Name = "Password")]
-  public string Password { get; set; }
-}
-```
-
-Create a Razor view called `Login.cshtml` in your `\Views\Account` folder which will allow the user to enter their email address and password:
-
-```html
-@model SampleMvcApp.ViewModels.LoginViewModel
-@{
-  ViewData["Title"] = "Log In";
-}
-
-
        
-  
        
-    
        
-      
        
-        
        Log In
        
-        
        
-        
        
-        
        
-          
-          
-          
-        
        
-        
        
-          
-          
-          
-        
        
-
-        
        
-          
-        
        
-      
        
-    
        
-  
        
-
        
-```
-
-Next, you will need to update your `AccountController` as per the code below:
-
-```csharp
-public class AccountController : Controller
-{
-  private readonly Auth0Settings _auth0Settings;
-
-  public AccountController(IOptions auth0Settings)
-  {
-    _auth0Settings = auth0Settings.Value;
-  }
-
-  [HttpGet]
-  public IActionResult Login(string returnUrl = "/")
-  {
-    ViewData["ReturnUrl"] = returnUrl;
-    return View();
-  }
-
-  [HttpPost]
-  public async Task Login(LoginViewModel vm, string returnUrl = null)
-  {
-    if (ModelState.IsValid)
-    {
-      try
-      {
-        AuthenticationApiClient client = new AuthenticationApiClient(new Uri($"https://{_auth0Settings.Domain}/"));
-
-        var result = await client.AuthenticateAsync(new AuthenticationRequest
-        {
-          ClientId = _auth0Settings.ClientId,
-          Scope = "openid",
-          Connection = "Database-Connection", // Specify the correct name of your DB connection
-          Username = vm.EmailAddress,
-          Password = vm.Password
-        });
-
-        // Get user info from token
-        var user = await client.GetTokenInfoAsync(result.IdToken);
-
-        // Create claims principal
-        var claimsPrincipal = new ClaimsPrincipal(new ClaimsIdentity(new[]
-        {
-          new Claim(ClaimTypes.NameIdentifier, user.UserId),
-          new Claim(ClaimTypes.Name, user.FullName)
-
-        }, CookieAuthenticationDefaults.AuthenticationScheme));
-
-        // Sign user into cookie middleware
-        await HttpContext.Authentication.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, claimsPrincipal);
-
-        return RedirectToLocal(returnUrl);
-      }
-      catch (Exception e)
-      {
-        ModelState.AddModelError("", e.Message);
-      }
-    }
-
-    return View(vm);
-  }
-
-  [Authorize]
-  public IActionResult Logout()
-  {
-    HttpContext.Authentication.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme);
-
-    return RedirectToAction("Index", "Home");
-  }
-
-  #region Helpers
-
-  private IActionResult RedirectToLocal(string returnUrl)
-  {
-    if (Url.IsLocalUrl(returnUrl))
-    {
-      return Redirect(returnUrl);
-    }
-    else
-    {
-      return RedirectToAction(nameof(HomeController.Index), "Home");
-    }
-  }
-
-  #endregion
-}
-```
-
-This code does the following:
-
-1. First the `AccountController` constructor is changed to take a parameter called `auth0Settings` of type `IOptions`. This will be injected by the DI framework.
-2. Create a `Login` action for GET requests which will return the Login view.
-3. Create a `Login` action for POST requests which will call the Authentication API to authenticate the user. If the user is successfully authenticated, the user's information is obttained from the token and a new `ClaimsPrincipal` is created with the relevant claims. Finally the user is signed in to the Cookie middleware.
-4. Create a `Logout` method which will sign the user out of the cookie middleware.
-
-## Signing in with Google
-
-If you would like the user to sign in with their Google accounts you will need to use the OpenID Connect middleware.
-
-First update the `AccountController` to add a `LoginExternal` action that will be called from the Login view. This action takes a `connection` parameter which will be passed along in the `Properties` of the `ChallengeResult`:
-
-```csharp
-[HttpGet]
-public IActionResult LoginExternal(string connection, string returnUrl = "/")
-{
-  var properties = new AuthenticationProperties() { RedirectUri = returnUrl };
-
-  if (!string.IsNullOrEmpty(connection))
-    properties.Items.Add("connection", connection);
-
-  return new ChallengeResult("Auth0", properties);
-}
-```
-
-Update your `Login.cshtml` view to add a button inside the `
        ` element with the text "Login with Google". This will invoke the `LoginExternal` action created above and pass along "google-oauth2" in the `connection` parameter as the social identity provider to invoke:
-
-```html
-
        
-  
-    Login with Google
-  
-
        
-```
-
-If you want to allow your users to sign in with other social identity providers, simply add extra buttons and pass in the correct value for the `connection` parameter to invoke the correct indentity provider, for example "twitter", "linkedin", "facebook", etc.
-
-Finally, update the `Configure` method in your `Startup` class to register the OIDC middleware. Normally when challenging the OIDC middleware, the OAuth Lock will be displayed but this is not the desired behaviour in this case. Instead you need to invoke the requested social identity provider which was passed in the `AuthenticationProperties` of the `ChallengeResult`.
-
-In order to do this, handle the `OnRedirectToIdentityProvider` event when registering the OIDC middleware and look at that `Properties` for the requested `connection`. Add the parameter to the OIDC request which is passed along to Auth0. This will ensure that Auth0 invoke the correct social identity provider directly, instead of displaying the Lock widget:
-
-```csharp
-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",
-
-    Events = new OpenIdConnectEvents
-    {
-        OnRedirectToIdentityProvider = context =>
-        {
-            if (context.Properties.Items.ContainsKey("connection"))
-                context.ProtocolMessage.SetParameter("connection", context.Properties.Items["connection"]);
-
-            return Task.FromResult(0);
-        }
-    }
-};
-options.Scope.Clear();
-options.Scope.Add("openid");
-app.UseOpenIdConnectAuthentication(options);
-```
-
-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 this can result in a large `id_token` being returned. It is suggested that you be more explicit about the scopes you want 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/05-user-profile).
-
-## Adding 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. This will link to the `Logout` and `Login` actions of the `AccountController` respectively:
-
-```html
-
        
-  
        
-    
        
-      
-      SampleMvcApp
-    
        
-    
        
-      
-      
          
-        @if (User.Identity.IsAuthenticated)
-        {
-          
        • Logout
          • 
-        }
-        else
-        {
-          
        • Login
          • 
-        }
-      
        
-    
        
-  
        
-
        
-```
-
-## Run the application
-
-You can now run your application. When you click on the Login link you will be taken to the new Login page where you can sign in with either your email address and password, or with your Google account.
diff --git a/articles/server-platforms/aspnet-core/04-storing-tokens.md b/articles/server-platforms/aspnet-core/04-storing-tokens.md
deleted file mode 100644
index 9db0f35abb..0000000000
--- a/articles/server-platforms/aspnet-core/04-storing-tokens.md
+++ /dev/null
@@ -1,96 +0,0 @@
----
-title: Storing Tokens
-description: This tutorial will show you how store the tokens returned from Auth0 in order to use them later on.
-budicon: 280
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnetcore-sample',
-  path: '04-Storing-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.
-
-## Storing the Tokens as Claims
-
-You may, however, want to save the actual tokens as claims, so you can use these tokens to authenticate against API calls.
-
-The first thing you must do is to set the `SaveTokens` property of `OpenIdConnectOptions` to true. This will save the tokens to the Properties. You can then subsequently retrieve the tokens from the Properties in the `OnTicketReceived` event.
-
-The names of the tokens will be saved as a semicolon-separated list inside the ".TokenNames" property. You will need to extract those names, and then for each of them extract the value of the token from the Properties.
-
-The value will be stored as a property with the name ".Token." suffixed with the name of the token. So, for example, the "access_token" will be stored in a property with the name ".Token.access_token".
-
-Once you have retrieved the value of the token, you can then simply store it as a claim for the `ClaimsIdentity`:
-
-```csharp
-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",
-
-    // Saves tokens to the AuthenticationProperties
-    SaveTokens = true,
-
-    Events = new OpenIdConnectEvents()
-    {
-        OnTicketReceived = context =>
-        {
-            // Get the ClaimsIdentity
-            var identity = context.Principal.Identity as ClaimsIdentity;
-            if (identity != null)
-            {
-                // Check if token names are stored in Properties
-                if (context.Properties.Items.ContainsKey(".TokenNames"))
-                {
-                    // Token names a semicolon separated
-                    string[] tokenNames = context.Properties.Items[".TokenNames"].Split(';');
-
-                    // Add each token value as Claim
-                    foreach (var tokenName in tokenNames)
-                    {
-                        // Tokens are stored in a Dictionary with the Key ".Token."
-                        string tokenValue = context.Properties.Items[$".Token.{tokenName}"];
-
-                        identity.AddClaim(new Claim(tokenName, tokenValue));
-                    }
-                }
-            }
-
-            return Task.FromResult(0);
-        }
-    }
-};
-options.Scope.Clear();
-options.Scope.Add("openid");
-app.UseOpenIdConnectAuthentication(options);
-```
-
-The `access_token` will now be stored as a claim called "access_token", so to retrieve it inside a controller you can simply use `User.Claims.FirstOrDefault("access_token").Value`
-
-::: warning-banner Beware of your cookie size
-You need to note that saving the tokens will increase the size of your authentication cookie, so be careful with adding unnecessary claims to the ClaimsIdentity as this cookie is sent back to the server with every request.
-:::
diff --git a/articles/server-platforms/aspnet-core/05-user-profile.md b/articles/server-platforms/aspnet-core/05-user-profile.md
deleted file mode 100644
index 30a8a4aa67..0000000000
--- a/articles/server-platforms/aspnet-core/05-user-profile.md
+++ /dev/null
@@ -1,160 +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-sample',
-  path: '05-User-Profile'
-}) %>
-
-## 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
-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
-[Authorize]
-public IActionResult Profile()
-{
-  return View(new UserProfileViewModel()
-  {
-    Name = User.Claims.FirstOrDefault(c => c.Type == ClaimTypes.Name)?.Value,
-    EmailAddress = User.Claims.FirstOrDefault(c => c.Type == ClaimTypes.Email)?.Value,
-    ProfileImage = User.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 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 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
-
-```
-
-A remaining issue is that the `User.Identity.Name` property used in the Navbar snippet above will look for a claim of type `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name` on the user, but hat claim will not be set and the property will therefor be null.
-
-Added to that, none of the user's profile details will be returned in the `id_token` as we a currently only requesting the `openid` scope. Ensure to also request the `name`, `email` and `picture` scopes to ensure that the user's Name, Email address and Profile Image is returned as claims in the `id_token`.
-
-Once Auth0 passed back the `name` claim, you will have to retrieve the value of the `name` claim in the `OnTicketReceived` event and add a new claim of type `ClaimTypes.Name` (which resolves to `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name`). This will ensure that the user's name is returned when accessing the `User.Identity.Name` property.
-
-```csharp
-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",
-
-    // Saves tokens to the AuthenticationProperties
-    SaveTokens = true,
-
-    Events = new OpenIdConnectEvents
-    {
-        OnTicketReceived = context =>
-        {
-            // Get the ClaimsIdentity
-            var identity = context.Principal.Identity as ClaimsIdentity;
-            if (identity != null)
-            {
-                // Add the Name ClaimType. This is required if we want User.Identity.Name to actually return something!
-                if (!context.Principal.HasClaim(c => c.Type == ClaimTypes.Name) &&
-                    identity.HasClaim(c => c.Type == "name"))
-                    identity.AddClaim(new Claim(ClaimTypes.Name, identity.FindFirst("name").Value));
-            }
-
-            return Task.FromResult(0);
-        }
-    }
-};
-options.Scope.Clear();
-options.Scope.Add("openid");
-options.Scope.Add("name");
-options.Scope.Add("email");
-options.Scope.Add("picture");
-app.UseOpenIdConnectAuthentication(options);
-```
-
-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/server-platforms/aspnet-core/07-rules.md b/articles/server-platforms/aspnet-core/07-rules.md
deleted file mode 100644
index d39192fb1f..0000000000
--- a/articles/server-platforms/aspnet-core/07-rules.md
+++ /dev/null
@@ -1,103 +0,0 @@
----
-title: Rules
-description: This tutorial will show you how to use Auth0 rules to extend what Auth0 has to offer.
-budicon: 173
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnetcore-sample',
-  path: '07-Rules'
-}) %>
-
-<%= include('../_includes/_rules-introduction') %>
-
-## Display the Country in the User Profile
-
-Now that the user's country is returned by Auth0, you can display this inside the user profile page created in the previous step.
-
-Update the `UserProfileViewModel` and add a `Country` property:
-
-```csharp
-public class UserProfileViewModel
-{
-  public string Country { get; set; }
-
-  public string EmailAddress { get; set; }
-
-  public string Name { get; set; }
-
-  public string ProfileImage { get; set; }
-}
-```
-
-Update the `Profile` action in your `AccountController` to retrieve the country from the "country" claim:
-
-```csharp
-[Authorize]
-public IActionResult Profile()
-{
-  return View(new UserProfileViewModel()
-  {
-    Name = User.Claims.FirstOrDefault(c => c.Type == ClaimTypes.Name)?.Value,
-    EmailAddress = User.Claims.FirstOrDefault(c => c.Type == ClaimTypes.Email)?.Value,
-    ProfileImage = User.Claims.FirstOrDefault(c => c.Type == "picture")?.Value,
-    Country = User.Claims.FirstOrDefault(c => c.Type == "country")?.Value
-  });
-}
-```
-
-And finally display the country in the profile view:
-
-```html
-@model SampleMvcApp.ViewModels.UserProfileViewModel
-@{
-  ViewData["Title"] = "User Profile";
-}
-
-
        
-  
        
-    
        
-      
        @ViewData["Title"].
        
-
-      
        
-        
-      
        
-      
        
-        
        @Model.Name
        
-        
        
-           @Model.EmailAddress
-        
        
-        
        
-           @Model.Country
-        
        
-      
        
-    
        
-  
        
-
        
-```
-
-## Ensure the Country scope is requested
-
-You will also need to ensure that you request the `country` scope. This will ensure that the `country` claim is returned in the `id_token`. Go back to the `Configure` method of the `Startup` class and update the registration of the OIDC middleware to request the `country` scope:
-
-```csharp
-var options = new OpenIdConnectOptions("Auth0")
-{
-    // Code omitted for brevity...
-};
-options.Scope.Clear();
-options.Scope.Add("openid");
-options.Scope.Add("name");
-options.Scope.Add("email");
-options.Scope.Add("picture");
-options.Scope.Add("country");
-app.UseOpenIdConnectAuthentication(options);
-```
-
-## Run the application
-
-Now when you run the application you will be able to see the user's country displayed:
-
-![](/media/articles/server-platforms/aspnet-core/user-profile-country.png)
diff --git a/articles/server-platforms/aspnet-core/08-authorization.md b/articles/server-platforms/aspnet-core/08-authorization.md
deleted file mode 100644
index 86f209a1ca..0000000000
--- a/articles/server-platforms/aspnet-core/08-authorization.md
+++ /dev/null
@@ -1,52 +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-sample',
-  path: '08-Authorization'
-}) %>
-
-<%= include('../_includes/_authorization-introduction', { ruleslink: '/quickstart/webapp/aspnet-core/07-rules' }) %>
-
-## Restrict an Action Based on a User's Roles
-
-As mentioned before, the claims returned in the ID Token will automatically be mapped to claims on the `ClaimsIdentity`. ASP.NET Core will also map roles correctly.
-
-Specifically, it will look for a "roles" claim on the ID Token, and then for each role inside the array on the "roles" claim, it will add a "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" claim to the `ClaimsIdentity`.
-
-This means that it integrates seamlessly with the [Role based authorization](https://docs.asp.net/en/latest/security/authorization/roles.html) inside ASP.NET Core.
-
-Once the correct claims are being returned from Auth0, all you have to do therefore, is decorate 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
-[Authorize(Roles = "admin")]
-public IActionResult Admin()
-{
-  return View();
-}
-```
-
-## Ensure the Roles scope is requested
-
-You will also need to ensure that you request the `roles` scope. This will ensure that the `roles` claim is returned in the `id_token`. Go back to the `Configure` method of the `Startup` class and update the registration of the OIDC middleware to request the `roles` scope:
-
-```csharp
-var options = new OpenIdConnectOptions("Auth0")
-{
-    // Code omitted for brevity...
-};
-options.Scope.Clear();
-options.Scope.Add("openid");
-options.Scope.Add("name");
-options.Scope.Add("email");
-options.Scope.Add("picture");
-options.Scope.Add("country");
-options.Scope.Add("roles");
-app.UseOpenIdConnectAuthentication(options);
-```
diff --git a/articles/server-platforms/aspnet-core/_includes/_login.md b/articles/server-platforms/aspnet-core/_includes/_login.md
deleted file mode 100644
index 68906153eb..0000000000
--- a/articles/server-platforms/aspnet-core/_includes/_login.md
+++ /dev/null
@@ -1,158 +0,0 @@
-## 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
-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
-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/05-user-profile). 
-
-## 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
-public class AccountController : Controller
-{
-    public IActionResult Login()
-    {
-        return new ChallengeResult("Auth0", new AuthenticationProperties() { RedirectUri = "/" });
-    }
-
-    public IActionResult Logout()
-    {
-        HttpContext.Authentication.SignOutAsync("Auth0");
-        HttpContext.Authentication.SignOutAsync(CookieAuthenticationDefaults.AuthenticationScheme);
-
-        return RedirectToAction("Index", "Home");
-    }
-}
-```
-
-## 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.
-
-If you prefer to embed Lock inside your application then please refer to the [Embedded Lock step](/quickstart/webapp/aspnet-core/02-login-embedded-lock). If you prefer to create a custom Login screen, refer to the [Custom Login step](/quickstart/webapp/aspnet-core/03-login-custom). 
-
-Alternatively, you can simply carry on to the [Storing Tokens step](/quickstart/webapp/aspnet-core/04-storing-tokens) which will demonstrate how you can store the tokens returned by Auth0.
diff --git a/articles/server-platforms/aspnet-core/_includes/_setup.md b/articles/server-platforms/aspnet-core/_includes/_setup.md
deleted file mode 100644
index b9d7102af8..0000000000
--- a/articles/server-platforms/aspnet-core/_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/server-platforms/aspnet-core/dashboard-default.md b/articles/server-platforms/aspnet-core/dashboard-default.md
deleted file mode 100644
index 3673371f21..0000000000
--- a/articles/server-platforms/aspnet-core/dashboard-default.md
+++ /dev/null
@@ -1,15 +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-sample',
-  path: '01-Login'
-}) %>
-
-<%= include('_includes/_setup') %>
-
-<%= include('_includes/_login') %>
diff --git a/articles/server-platforms/aspnet-core/index.yml b/articles/server-platforms/aspnet-core/index.yml
deleted file mode 100644
index 318882f4d8..0000000000
--- a/articles/server-platforms/aspnet-core/index.yml
+++ /dev/null
@@ -1,19 +0,0 @@
-title: ASP.NET Core
-image: /media/platforms/asp.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-platforms/aspnet-core/dependencies
-alias:
-  - aspnetcore
-seo_alias: aspnet-core
-default_article: dashboard-default
-articles:
-  - 00-intro
-  - 01-login
-  - 02-login-embedded-lock
-  - 03-login-custom
-  - 04-storing-tokens
-  - 05-user-profile
-  - 07-rules
-  - 08-authorization
diff --git a/articles/server-platforms/aspnet-owin/00-intro.md b/articles/server-platforms/aspnet-owin/00-intro.md
deleted file mode 100644
index 946ced2724..0000000000
--- a/articles/server-platforms/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-info System Requirements
-This tutorial and seed project have been tested with the following:
-
-* Microsoft Visual Studio 2015 Update 3
-* Auth0-ASPNET-Owin NuGet Package v1.0.4
-:::
-
-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-sample/tree/master/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 [sample repository](https://github.com/auth0-samples/auth0-aspnet-owin-mvc-sample) where you can find the final result for each step in the relevant folder.
-
-<%= include('../../_includes/_new_app') %>
-
-<%= include('_includes/_setup') %>
\ No newline at end of file
diff --git a/articles/server-platforms/aspnet-owin/01-login.md b/articles/server-platforms/aspnet-owin/01-login.md
deleted file mode 100644
index 0a4d9f5cec..0000000000
--- a/articles/server-platforms/aspnet-owin/01-login.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: Login
-description: This tutorial demonstrates how to use the Auth0 OAuth2 middleware to add authentication to your web app
-budicon: 448
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnet-owin-mvc-sample',
-  path: '01-Login'
-}) %>
-
-<%= include('_includes/_login') %>
-
-If you prefer to create a custom Login screen, refer to the [Custom Login step](/quickstart/webapp/aspnet-owin/02-login-custom).
-
-Alternatively, you can simply carry on to the [Storing Tokens step](/quickstart/webapp/aspnet-owin/03-storing-tokens) which will demonstrate how you can store the tokens returned by Auth0.
diff --git a/articles/server-platforms/aspnet-owin/02-login-custom.md b/articles/server-platforms/aspnet-owin/02-login-custom.md
deleted file mode 100644
index fc47cf79ab..0000000000
--- a/articles/server-platforms/aspnet-owin/02-login-custom.md
+++ /dev/null
@@ -1,209 +0,0 @@
----
-title: Custom Login
-description: This tutorial demonstrates how to create a custom login page for your web application by using the Auth0 .NET SDK and OpenID Connect middleware.
-budicon: 448
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnet-owin-mvc-sample',
-  path: '02-Custom-Login'
-}) %>
-
-## Add the Auth0 Authentication SDK
-
-To log the user in you will be using the Auth0 Authentication SDK for .NET, so install the NuGet package:
-
-```bash
-Install-package Auth0.AuthenticationApi
-```
-
-## Create the Login Form
-
-You need to create a Login form which will capture the user's email address and password and then use the Authentication SDK to sign the user it.
-
-First, create a `ViewModels` folder in your project and add a class called `LoginViewModel` to bind the values in the form to:
-
-```csharp
-public class LoginViewModel
-{
-    [Required]
-    [EmailAddress]
-    [Display(Name = "Email Address")]
-    public string EmailAddress { get; set; }
-
-    [Required]
-    [DataType(DataType.Password)]
-    [Display(Name = "Password")]
-    public string Password { get; set; }
-}
-```
-
-Create a Razor view called `Login.cshtml` in your `\Views\Account` folder which will allow the user to enter their email address and password:
-
-```html
-@model global::MvcApplication.ViewModels.LoginViewModel
-@{
-    ViewData["Title"] = "Log In";
-}
-
-
        @ViewBag.Title.
        
-
-
        
-    
        
-        
        
-            @using (Html.BeginForm("Login", "Account", new { ReturnUrl = ViewBag.ReturnUrl }, FormMethod.Post, new { role = "form" }))
-            {
-                @Html.AntiForgeryToken()
-                @Html.ValidationSummary(true, "", new { @class = "text-danger" })
-                
        
-                    @Html.LabelFor(m => m.EmailAddress)
-                    @Html.TextBoxFor(m => m.EmailAddress, new { @class = "form-control" })
-                    @Html.ValidationMessageFor(m => m.EmailAddress, "", new { @class = "text-danger" })
-                
        
-                
        
-                    @Html.LabelFor(m => m.Password)
-                    @Html.PasswordFor(m => m.Password, new { @class = "form-control" })
-                    @Html.ValidationMessageFor(m => m.Password, "", new { @class = "text-danger" })
-                
        
-                
-            }
-        
        
-    
        
-
        
-```
-
-Next, you will need to update your `AccountController` as per the code below:
-
-```csharp
-public class AccountController : Controller
-{
-    private IAuthenticationManager AuthenticationManager
-    {
-        get
-        {
-            return HttpContext.GetOwinContext().Authentication;
-        }
-    }
-
-    [HttpGet]
-    public ActionResult Login(string returnUrl = "/")
-    {
-        ViewData["ReturnUrl"] = returnUrl;
-
-        return View();
-    }
-
-    [HttpPost]
-    public async Task Login(LoginViewModel vm, string returnUrl = null)
-    {
-        if (ModelState.IsValid)
-        {
-            try
-            {
-                AuthenticationApiClient client =
-                    new AuthenticationApiClient(
-                        new Uri($"https://{ConfigurationManager.AppSettings["auth0:Domain"]}/"));
-
-                var result = await client.AuthenticateAsync(new AuthenticationRequest
-                {
-                    ClientId = ConfigurationManager.AppSettings["auth0:ClientId"],
-                    Scope = "openid",
-                    Connection = "Database-Connection", // Specify the correct name of your DB connection
-                    Username = vm.EmailAddress,
-                    Password = vm.Password
-                });
-
-                // Get user info from token
-                var user = await client.GetTokenInfoAsync(result.IdToken);
-
-                // Create claims principal
-                var claimsIdentity = new ClaimsIdentity(new[]
-                {
-                    new Claim(ClaimTypes.NameIdentifier, user.UserId),
-                    new Claim(ClaimTypes.Name, user.FullName ?? user.Email),
-                    new Claim("http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider", "ASP.NET Identity", "http://www.w3.org/2001/XMLSchema#string")
-                }, DefaultAuthenticationTypes.ApplicationCookie);
-
-                // Sign user into cookie middleware
-                AuthenticationManager.SignIn(new AuthenticationProperties { IsPersistent = false }, claimsIdentity);
-
-                return RedirectToLocal(returnUrl);
-            }
-            catch (Exception e)
-            {
-                ModelState.AddModelError("", e.Message);
-            }
-        }
-
-        return View(vm);
-    }
-
-    [Authorize]
-    public ActionResult Logout()
-    {
-        HttpContext.GetOwinContext().Authentication.SignOut();
-
-        return RedirectToAction("Index", "Home");
-    }
-
-    private ActionResult RedirectToLocal(string returnUrl)
-    {
-        if (Url.IsLocalUrl(returnUrl))
-        {
-            return Redirect(returnUrl);
-        }
-        else
-        {
-            return RedirectToAction("Index", "Home");
-        }
-    }
-}
-```
-
-This code does the following:
-
-1. First, and `AuthenticationManager` property is added which will simply get the Authentication Manager from the OWIN context. This is needed to sign the user in.
-2. Create a `Login` action for GET requests which will return the Login view.
-3. Create a `Login` action for POST requests which will call the Authentication API to authenticate the user. If the user is successfully authenticated, the user's information is obtained from the token and a new `ClaimsIdentity` is created with the relevant claims. Finally, the user is signed in to the Authentication Manager.
-4. Create a `Logout` method which will sign the user out of the Authentication Manager.
-
-## 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 your application
-
-You can now run your application. When you click on the Login link you will be taken to the new Login page where you can sign in with your email address and password.
-
-Next up, you can move on to the [Storing Tokens step](/quickstart/webapp/aspnet-owin/03-storing-tokens) which will demonstrate how you can store the tokens returned by Auth0.
diff --git a/articles/server-platforms/aspnet-owin/03-storing-tokens.md b/articles/server-platforms/aspnet-owin/03-storing-tokens.md
deleted file mode 100644
index 108c9f2be9..0000000000
--- a/articles/server-platforms/aspnet-owin/03-storing-tokens.md
+++ /dev/null
@@ -1,26 +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-sample',
-  path: '03-Storing-Tokens'
-}) %>
-
-
-The Auth0 OAuth2 middleware will automatically add the `id_token` and `access_token` as claims on the `ClaimsIdentity`.
-
-This means that inside any of your controllers you can 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` and `id_token` respectively:
-
-``` csharp
-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;
-```
diff --git a/articles/server-platforms/aspnet-owin/04-user-profile.md b/articles/server-platforms/aspnet-owin/04-user-profile.md
deleted file mode 100644
index 646cc8f3fc..0000000000
--- a/articles/server-platforms/aspnet-owin/04-user-profile.md
+++ /dev/null
@@ -1,101 +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-sample',
-  path: '04-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.
-
-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
-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
-[Authorize]
-public ActionResult Profile()
-{
-    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/Profile` 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 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-owin/navbar-userprofile.png)
diff --git a/articles/server-platforms/aspnet-owin/05-rules.md b/articles/server-platforms/aspnet-owin/05-rules.md
deleted file mode 100644
index 898d3c7522..0000000000
--- a/articles/server-platforms/aspnet-owin/05-rules.md
+++ /dev/null
@@ -1,116 +0,0 @@
----
-title: Rules
-description: This tutorial demonstrates how to use Auth0 rules to extend what Auth0 has to offer.
-budicon: 173
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-aspnet-owin-mvc-sample',
-  path: '05-Rules'
-}) %>
-
-<%= include('../_includes/_rules-introduction') %>
-
-## Add the country as a claim
-
-The Auth0 OAuth2 middleware will not add the country as a claim, so you will need to do this manually. You can alter the middleware registration in the `Startup` class to pass in an `Auth0AuthenticationOptions`, and then add an `OnAuthenticated` event handler which extracts the country from the `User` object and add it as a claim:
-
-```csharp
-var options = new Auth0AuthenticationOptions
-{
-    ClientId = System.Configuration.ConfigurationManager.AppSettings["auth0:ClientId"],
-    ClientSecret = System.Configuration.ConfigurationManager.AppSettings["auth0:ClientSecret"],
-    Domain = System.Configuration.ConfigurationManager.AppSettings["auth0:Domain"],
-    RedirectPath = new PathString("/Auth0Account/ExternalLoginCallback"),
-    Provider = new Auth0AuthenticationProvider
-    {
-        OnAuthenticated = context =>
-        {
-            // Get the user's country
-            JToken countryObject = context.User["country"];
-            if (countryObject != null)
-            {
-                string country = countryObject.ToObject();
-
-                context.Identity.AddClaim(new Claim("country", country, ClaimValueTypes.String, context.Connection));
-            }
-
-            return Task.FromResult(0);
-        }
-    }
-};
-app.UseAuth0Authentication(options);
-```
-
-## Display the country in the user profile
-
-Now that the user's country is returned by Auth0, you can display this inside the user profile page created in the previous step.
-
-Update the `UserProfileViewModel` and add a `Country` property:
-
-```csharp
-public class UserProfileViewModel
-{
-    public string Country { get; set; }
-
-    public string EmailAddress { get; set; }
-
-    public string Name { get; set; }
-
-    public string ProfileImage { get; set; }
-}
-```
-
-Update the `Profile` action in your `AccountController` to retrieve the country from the "country" claim:
-
-```csharp
-[Authorize]
-public ActionResult Profile()
-{
-    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,
-        Country = claimsIdentity?.Claims.FirstOrDefault(c => c.Type == "country")?.Value
-    });
-}
-```
-
-And finally display the country in the profile view:
-
-```html
-@model global::MvcApplication.ViewModels.UserProfileViewModel
-@{
-    ViewData["Title"] = "User Profile";
-}
-
-
        
-    
        
-        
        
-            
        @ViewData["Title"].
        
-
-            
        
-                
-            
        
-            
        
-                
        @Model.Name
        
-                
        
-                     @Model.EmailAddress
-                
        
-                
        
-                     @Model.Country
-                
        
-            
        
-        
        
-    
        
-
        
-```
-
-Now when you run the application you will be able to see the user's country displayed:
-
-![](/media/articles/server-platforms/aspnet-owin/user-profile-country.png)
diff --git a/articles/server-platforms/aspnet-owin/06-authorization.md b/articles/server-platforms/aspnet-owin/06-authorization.md
deleted file mode 100644
index 7dab3e1269..0000000000
--- a/articles/server-platforms/aspnet-owin/06-authorization.md
+++ /dev/null
@@ -1,85 +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-sample',
-  path: '06-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.
-
-> This tutorial assumes that you've already read the [rules tutorial](/quickstart/webapp/aspnet-owin/05-rules) and you know how to implement a basic rule in your app.
-
-### 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 select the "*Set Roles To A User*" template, under *Access Control*. Then, replace this line from the default script:
-
-```
-if (user.email.indexOf('@example.com') > -1)
-```
-
-to match the condition that fits your needs. Notice that you can also set more roles other than `admin` and `user`, or customize the whole rule as you please.
-
-By default, it says that if the user email contains `@example.com` he will be given an `admin` role, otherwise a regular `user` role.
-
-## 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
-var options = new Auth0AuthenticationOptions
-{
-    ClientId = System.Configuration.ConfigurationManager.AppSettings["auth0:ClientId"],
-    ClientSecret = System.Configuration.ConfigurationManager.AppSettings["auth0:ClientSecret"],
-    Domain = System.Configuration.ConfigurationManager.AppSettings["auth0:Domain"],
-    RedirectPath = new PathString("/Auth0Account/ExternalLoginCallback"),
-    Provider = new Auth0AuthenticationProvider
-    {
-        OnAuthenticated = context =>
-        {
-            // Get the user's country
-            JToken countryObject = context.User["country"];
-            if (countryObject != null)
-            {
-                string country = countryObject.ToObject();
-
-                context.Identity.AddClaim(new Claim("country", country, ClaimValueTypes.String, context.Connection));
-            }
-
-            // Get the user's roles
-            var rolesObject = context.User["app_metadata"]["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
-[Authorize(Roles = "admin")]
-public ActionResult Admin()
-{
-    return View();
-}
-```
diff --git a/articles/server-platforms/aspnet-owin/_includes/_login.md b/articles/server-platforms/aspnet-owin/_includes/_login.md
deleted file mode 100644
index 75be56a418..0000000000
--- a/articles/server-platforms/aspnet-owin/_includes/_login.md
+++ /dev/null
@@ -1,128 +0,0 @@
-## 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
-```
-
-Now go to the `Configuration` method of your `Startup` class and configure the cookie middleware, external cookie middleware as well as the Auth0 middleware:
-
-```cs
-public void Configuration(IAppBuilder app)
-{
-    // Register the cookie middleware
-    app.UseCookieAuthentication(new CookieAuthenticationOptions
-    {
-        AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
-        LoginPath = new PathString("/Account/Login")
-    });
-
-    // Register external cookie middleware. This cookie is used to temporarily store information about a user logging in with a third party login provider
-    app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie);
-
-    // Register the Auth0 (OAuth 2.0) middleware
-    app.UseAuth0Authentication(
-        clientId: System.Configuration.ConfigurationManager.AppSettings["auth0:ClientId"],
-        clientSecret: System.Configuration.ConfigurationManager.AppSettings["auth0:ClientSecret"],
-        domain: System.Configuration.ConfigurationManager.AppSettings["auth0:Domain"]);
-
-}
-```
-
-It is important that you register all 3 these pieces of middleware as all of them are required for the authentication to work. The Auth0 middleware  will handle the OAuth 2.0 authentication with Auth0. Once the user has authenticated, their identity will be temporarily stored in the external cookie. The Auth0 middleware will redirect the user back to `/Auth0Account/ExternalLoginCallback` action which will, in turn, [retrieve the user's identity from the external cookie](https://github.com/auth0-samples/auth0-aspnet-owin-mvc-sample/blob/master/01-Login/MvcApplication/MvcApplication/Controllers/Auth0AccountController.cs#L30) and [sign the user into the cookie middleware](https://github.com/auth0-samples/auth0-aspnet-owin-mvc-sample/blob/master/01-Login/MvcApplication/MvcApplication/Controllers/Auth0AccountController.cs#L38).
-
-All of this will be handled automatically for you by the Auth0 middleware and `Auth0AccountController` class which was added to your project when you installed the `Auth0-ASPNET-Owin` NuGet package, but it is important that you register all 3 pieces of middleware correctly as per the code sample above.
-
-## Add Login and Logout Methods
-
-Next, you will need to add `Login` and `Logout` actions to the `AccountController`.
-
-For the `Login` action, you can simply return the Login view which we will create in the next step. For the `Logout` action you will need to sign the user out of the Authentication Manager and then redirect them back to the home page:
-
-```cs
-public class AccountController : Controller
-{
-    public ActionResult Login()
-    {
-        return View();
-    }
-
-    [Authorize]
-    public ActionResult Logout()
-    {
-        HttpContext.GetOwinContext().Authentication.SignOut();
-
-        return RedirectToAction("Index", "Home");
-    }
-}
-```
-
-## Add the Login View
-
-For the Login view, you can embed the [Auth0 Lock component](/libraries/lock). You can use the sample code below which adds a `
        ` to your view and then initializes the Lock component to display inside the view.
-
-``` html
-@using System.Configuration
-@{
-    ViewBag.Title = "Login";
-}
-
-
-
        
-
        
-
-
-
-```
-
-## 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/server-platforms/aspnet-owin/_includes/_setup.md b/articles/server-platforms/aspnet-owin/_includes/_setup.md
deleted file mode 100644
index 3d8035adb1..0000000000
--- a/articles/server-platforms/aspnet-owin/_includes/_setup.md
+++ /dev/null
@@ -1,11 +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 Auth0 OAuth2 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.
-
-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`  
-
-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/server-platforms/aspnet-owin/dashboard-default.md b/articles/server-platforms/aspnet-owin/dashboard-default.md
deleted file mode 100644
index 0cd409bd3d..0000000000
--- a/articles/server-platforms/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-sample',
-  path: '01-Login'
-}) %>
-
-<%= include('_includes/_setup') %>
-
-<%= include('_includes/_login') %>
\ No newline at end of file
diff --git a/articles/server-platforms/aspnet-owin/index.yml b/articles/server-platforms/aspnet-owin/index.yml
deleted file mode 100644
index f0c55178a3..0000000000
--- a/articles/server-platforms/aspnet-owin/index.yml
+++ /dev/null
@@ -1,21 +0,0 @@
-title: ASP.NET (OWIN)
-image: /media/platforms/asp.png
-tags:
-  - 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: dashboard-default
-articles:
-  - 00-intro
-  - 01-login
-  - 02-login-custom
-  - 03-storing-tokens
-  - 04-user-profile
-  - 05-rules
-  - 06-authorization
\ No newline at end of file
diff --git a/articles/server-platforms/aspnet/01-login.md b/articles/server-platforms/aspnet/01-login.md
deleted file mode 100644
index 0d37ce4d2f..0000000000
--- a/articles/server-platforms/aspnet/01-login.md
+++ /dev/null
@@ -1,131 +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',
-  repo: 'auth0-aspnet',
-  path: 'examples/auth0-aspnet-mvc4-sample/',
-  requirements: [
-    'Microsoft Visual Studio 2015',
-    'Auth0-ASPNET v1.4.0'
-  ]
-}) %>
-
-## 1. Install Auth0-ASPNET NuGet Package
-
-Use the NuGet Package Manager (Tools -> Library Package Manager -> Package Manager Console) to install the **Auth0-ASPNET** package, running the command:
-
-${snippet(meta.snippets.dependencies)}
-
-> This package will add a `LoginCallback.ashx` to your project, which will process the login.
-
-## 2. Configure Callback URLs
-
-After authenticating the user on Auth0, we will do a POST to the `/LoginCallback.ashx` URL on your website, e.g. `http://localhost:PORT/LoginCallback.ashx`. For security purposes, you have to register this URL in the [Client Settings](${manage_url}/#/applications/${account.clientId}/settings) section on Auth0 Admin app.
-
-![Callback URLs](/media/articles/server-platforms/aspnet/callback_url.png)
-
-## 3. Fill Web.Config with your Auth0 Settings
-
-The NuGet package also created three settings on ``. Replace those with the following settings:
-
-${snippet(meta.snippets.setup)}
-
-## 4.Trigger Login Manually or Integrating Lock
-
-<%= include('../../_includes/_lock-sdk') %>
-
-## 5. Access User Information
-
-Once the user successfully authenticated to the application, a `ClaimsPrincipal` will be generated which can be accessed through the `Current` property:
-
-```cs
-public ActionResult Index()
-{
-  string email = ClaimsPrincipal.Current.FindFirst("email").Value;
-}
-```
-
-The user profile is normalized regardless of where the user came from. We will always include these: `user_id`, `name`, `email`, `nickname` and `picture`. For more information about the user profile [read this](/user-profile).
-
-## 6. Further Reading
-
-### Authorization
-
-You can use the usual authorization techniques since the `LoginCallback.ashx` handler and the Http Module will generate an `IPrincipal` on each request. This means you can use the declarative `[Authorize]` or `` protection or code-based checks like `User.Identity.IsAuthenticated`
-
-### Redirect to a Login Page
-
-An `[Authorize]` attribute will generate a `401 - Unauthorized` error if the request is not authenticated. If you want to redirect to a login page automatically in these cases, you can leverage the **Forms Authentication** module by configuring this in `web.config`:
-
-```xml
-
-  
-    
-  
-
-```
-
-In the above example, we are redirecting to a `Login` action in an `Account` controller. The `Login` action can return a view that integrates Lock or shows a custom UI, or directly redirect to Auth0 for authentication, as described in [#4](#4-triggering-login-manually-or-integrating-the-auth0lock).
-
-```cs
-public ActionResult Login(string returnUrl)
-{
-  if (string.IsNullOrEmpty(returnUrl) || !this.Url.IsLocalUrl(returnUrl))
-  {
-    returnUrl = "/";
-  }
-
-  // you can use this for the 'authParams.state' parameter
-  // in Lock, to provide a return URL after the authentication flow.
-  ViewBag.State = "ru="+ HttpUtility.UrlEncode(returnUrl);
-
-  return this.View();
-}
-```
-
-### Logout
-
-To clear the cookie generated on login, use the `FederatedAuthentication.SessionAuthenticationModule.SignOut()` method on the `AccountController\Logout` method.
-
-A typical logout action on ASP.Net MVC would look like this:
-
-```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)));
-}
-```
-
-Note that the final destination URL (the `returnTo` value) needs to be in the list of `Allowed Logout URLs`. [Read more about this](/logout#redirecting-users-after-logout).
-
-### Link Accounts
-
-To allow users to link accounts from different providers, read [Link Accounts](/link-accounts).
-
-You will need the `access_token` of the logged in user. You can get it from:
-
-```
-${'<%= ClaimsPrincipal.Current.FindFirst("access_token").Value %>'}
-```
-
-### Flow the Identity to a WCF Service
-
-If you want to flow the identity of the user logged in a website, to a WCF service or an API, you have to use the `responseType: 'token'` parameter on the login widget constructor. When sending that paramter, Auth0 will generate an `id_token` which is a [JsonWebToken](http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06) that can be either send straight to your service or it can be exchanged to generate an `ActAs` token. [Read more about this](/server-apis/wcf-service).
-
-### Manage Environments: Dev, Test, Production
-
-We recommend creating one application per environment in Auth0 and have different client ids and secret per environment. [Read more about this](/azure-tutorial).
diff --git a/articles/server-platforms/aspnet/index.yml b/articles/server-platforms/aspnet/index.yml
deleted file mode 100644
index e00494e70f..0000000000
--- a/articles/server-platforms/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/server-platforms/golang/01-login.md b/articles/server-platforms/golang/01-login.md
deleted file mode 100644
index 38740f590f..0000000000
--- a/articles/server-platforms/golang/01-login.md
+++ /dev/null
@@ -1,197 +0,0 @@
----
-title: Login
-description: This tutorial will demonstrates how to use the Auth0 Go SDK to add authentication and authorization to your web app
-budicon: 448
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-golang-web-app',
-  path: '01-Login',
-	requirements: [
-		'Go 1.5.3 and up'
-	]
-}) %>
-
-## Add Dependencies
-
-Install the following dependencies using `go get`
-
-${snippet(meta.snippets.dependencies)}
-
-> This example uses `mux` 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:
-
-```go
-package callback
-
-import (
-	_ "crypto/sha512"
-	"encoding/json"
-	"github.com/auth0-samples/auth0-golang-web-app/01-Login/app"
-	"golang.org/x/oauth2"
-	"io/ioutil"
-	"net/http"
-	"os"
-)
-
-func CallbackHandler(w http.ResponseWriter, r *http.Request) {
-
-	domain := os.Getenv("AUTH0_DOMAIN")
-
-	conf := &oauth2.Config{
-		ClientID:     os.Getenv("AUTH0_CLIENT_ID"),
-		ClientSecret: os.Getenv("AUTH0_CLIENT_SECRET"),
-		RedirectURL:  os.Getenv("AUTH0_CALLBACK_URL"),
-		Scopes:       []string{"openid", "profile"},
-		Endpoint: oauth2.Endpoint{
-			AuthURL:  "https://" + domain + "/authorize",
-			TokenURL: "https://" + domain + "/oauth/token",
-		},
-	}
-
-	code := r.URL.Query().Get("code")
-
-	token, err := conf.Exchange(oauth2.NoContext, code)
-	if err != nil {
-		http.Error(w, err.Error(), http.StatusInternalServerError)
-		return
-	}
-
-	// Getting now the userInfo
-	client := conf.Client(oauth2.NoContext, token)
-	resp, err := client.Get("https://" + domain + "/userinfo")
-	if err != nil {
-		http.Error(w, err.Error(), http.StatusInternalServerError)
-		return
-	}
-
-	raw, err := ioutil.ReadAll(resp.Body)
-	defer resp.Body.Close()
-	if err != nil {
-		http.Error(w, err.Error(), http.StatusInternalServerError)
-		return
-	}
-
-	var profile map[string]interface{}
-	if err = json.Unmarshal(raw, &profile); err != nil {
-		http.Error(w, err.Error(), http.StatusInternalServerError)
-		return
-	}
-
-	session, err := app.Store.Get(r, "auth-session")
-	if err != nil {
-		http.Error(w, err.Error(), http.StatusInternalServerError)
-		return
-	}
-
-	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
-	}
-
-	// Redirect to logged in page
-	http.Redirect(w, r, "/user", http.StatusSeeOther)
-
-}
-```
-
-Remember to set this handler to the `/callback` path:
-
-${snippet(meta.snippets.setup)}
-
-## Set the Callback URL
-
-${include('../\_callbackRegularWebApp')}
-
-In this case, the redirectUrl should look something like:
-
-```
-http://yourUrl/callback
-```
-
-## Triggering Login Manually or Using Lock
-
-<%= include('../../_includes/_lock-sdk') %>
-
-> **Note:** Please note that the `redirectUrl` specified in the `Auth0Lock` constructor **must match** the one specified in the previous step
-
-## Accessing User Information
-
-You can access the user information via the `profile` you stored in the session on step 2
-
-```go
-func UserHandler(w http.ResponseWriter, r *http.Request) {
-
-	session, err := app.Store.Get(r, "auth-session")
-	if err != nil {
-		http.Error(w, err.Error(), http.StatusInternalServerError)
-		return
-	}
-
-	templates.RenderTemplate(w, "user", session.Values["profile"])
-}
-
-```
-
-```html
-
        
-  
-  
        Welcome {{.nickname}}
        
-
        
-```
-
-[Click here](/user-profile) to check all the information that the userinfo hash has.
-
-## Optional Steps
-
-### Checking if the User is Authenticated
-
-We can use [Negroni](https://github.com/codegangsta/negroni) to create a Middleware that will check if the user is Authenticated or not.
-
-First, we need to install it via `go get`:
-
-```bash
-go get github.com/codegangsta/negroni
-```
-
-Then, we should create a middleware that will check if the `profile` is in the session:
-
-```go
-package middlewares
-
-import (
-  "net/http"
-)
-
-func IsAuthenticated(w http.ResponseWriter, r *http.Request, next http.HandlerFunc) {
-
-	session, err := app.Store.Get(r, "auth-session")
-	if err != nil {
-		http.Error(w, err.Error(), http.StatusInternalServerError)
-		return
-	}
-
-	if _, ok := session.Values["profile"]; !ok {
-		http.Redirect(w, r, "/", http.StatusSeeOther)
-	} else {
-		next(w, r)
-	}
-}
-```
-
-Finally, we can use Negroni to set up this middleware for any route that needs authentication:
-
-```go
-r.Handle("/user", negroni.New(
-  negroni.HandlerFunc(middlewares.IsAuthenticated),
-  negroni.Wrap(http.HandlerFunc(user.UserHandler)),
-))
-```
diff --git a/articles/server-platforms/golang/index.yml b/articles/server-platforms/golang/index.yml
deleted file mode 100644
index 550d44d004..0000000000
--- a/articles/server-platforms/golang/index.yml
+++ /dev/null
@@ -1,12 +0,0 @@
-title: Go
-image: /media/platforms/golang.png
-tags:
-  - quickstart
-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
diff --git a/articles/server-platforms/java-spring-mvc/00-intro.md b/articles/server-platforms/java-spring-mvc/00-intro.md
deleted file mode 100644
index 1880efa2ac..0000000000
--- a/articles/server-platforms/java-spring-mvc/00-intro.md
+++ /dev/null
@@ -1,77 +0,0 @@
----
-title: Introduction
-description: This tutorial demonstrates how to use the Auth0 Java Spring MVC SDK to add authentication and authorization to your web app.
-budicon: 715
----
-
-
-
-This multi-step quickstart will guide you through the process of managing authentication in your Java Spring Web Application with Auth0.
-
-::: panel-info System Requirements
-These tutorials and seed projects have been tested with the following:
-- Java 7 or above
-- Maven 3.0.x or above
-:::
-
-Auth0 provides and manages a [Spring MVC SDK](https://github.com/auth0/auth0-spring-mvc). This SDK allows you to use Auth0 with Java for server-side Spring web apps.
-
-__NOTE:__ You can find a listing of all our Java offerings and several sample projects in [Java technologies and Auth0 libraries](/java-overview).
-
-
-## Samples Projects
-
-<%= include('_includes/_prerequisite') %>
-
-There are two options for following along this quickstart. You can either download the [seed project](https://github.com/auth0-samples/auth0-spring-mvc-sample/tree/master/00-Starter-Seed) or the samples provided at each page of this quickstart.
-
-The seed is a Java Spring Boot app, with all the Auth0 dependencies set, but nothing more. It's an empty canvas meant to be filled as you follow the steps of this quickstart. If you prefer this option download the seed from our [GitHub repository](https://github.com/auth0-samples/auth0-spring-mvc-sample/tree/master/00-Starter-Seed) and follow along.
-
-Instead, you can choose to follow the samples that are included in each step. Each sample uses the [seed project](https://github.com/auth0-samples/auth0-spring-mvc-sample/tree/master/00-Starter-Seed) as a starting point and applies to it the configuration of each step, so, for example, the Login sample would be the [seed project](https://github.com/auth0-samples/auth0-spring-mvc-sample/tree/master/00-Starter-Seed) plus the configuration required to implement login functionality. If you choose to follow this approach continue reading, the rest of this document will guide you through setting up the required prerequisites.
-
-
-### Seed Project Structure
-
-Let's take some time and explain how our [seed project](https://github.com/auth0-samples/auth0-spring-mvc-sample/tree/master/00-Starter-Seed) is structured.
-
-
-```text
-- src
--- main
----- java
------- com
--------- auth0
----------- example
------------- App.java
------------- CallbackController.java
------------- ErrorController.java
------------- HomeController.java
------------- LoginController.java
------------- LogoutController.java
----- resources
------- application.properties
------- auth0.properties
----- webapp
------- WEB-INF
--------- jsp
----------- home.jsp
----------- login.jsp
--------- web.xml
-- pom.xml
-```
-
-The project contains two JSP: the `login.jsp` that will handle the user login, and the `home.jsp` which will display user information after a successful login and provide the option to log out.
-
-The project contains also the following files:
-- `application.properties`: The configuration file that holds information such as the port your app will use, the logging level, etc.
-- `auth0.properties`: The configuration file that holds Auth0 related information, like the client id, client secret, etc. You can find more detailed information in the [Configure your Java Spring app](#configure-your-java-spring-app) section of this document.
-- `App.java`: A Java class that uses Spring Boot’s `SpringApplication.run()` method to launch the application.
-- `CallbackController.java`: The controller that handles the callback.
-- `ErrorController.java`: The controller that handles the errors.
-- `HomeController.java`: The controller that handles landing page requests.
-- `LoginController.java`: The controller that handles the login.
-- `LogoutController.java`: The controller that handles the logouts.
-
-<%= include('_includes/_setup') %>
-
-You are now ready to continue with [login](/quickstart/webapp/java-spring-mvc/01-login) tutorial in order to implement basic login using [Lock](/libraries/lock).
diff --git a/articles/server-platforms/java-spring-mvc/01-login.md b/articles/server-platforms/java-spring-mvc/01-login.md
deleted file mode 100644
index b13fb33731..0000000000
--- a/articles/server-platforms/java-spring-mvc/01-login.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Login
-description: This tutorial demonstrates how to use the Auth0 Java Spring MVC SDK to add authentication and authorization to your web app
-budicon: 448
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-spring-mvc-sample',
-  path: '01-Login',
-  requirements: [
-    'Java 7 or above',
-    'Maven 3.0.x or above'
-  ]
-}) %>
-
-In this step, we will enable login with the [Lock widget](/libraries/lock).
-
-<%= include('_includes/_login') %>
diff --git a/articles/server-platforms/java-spring-mvc/09-mfa.md b/articles/server-platforms/java-spring-mvc/09-mfa.md
deleted file mode 100644
index 9a66c6818c..0000000000
--- a/articles/server-platforms/java-spring-mvc/09-mfa.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: Multifactor Authentication
-description: This tutorial demonstrates how to add Multifactor Authentication to your Java Spring web app with Auth0.
-budicon: 243
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-spring-mvc-sample',
-  path: '09-MFA',
-  requirements: [
-    'Java 7 or above',
-    'Maven 3.0.x or above'
-  ]
-}) %>
-
-<%= include('../_includes/_mfa-introduction') %>
-
-In this tutorial, you will learn how to enable MFA in the Java Spring application you created in the previous steps.
-
-## Enable Multifactor Authentication in Your Account
-
-<%= include('../_includes/_mfa-enable') %>
-
-## Login
-
-<%= include('../_includes/_mfa-login', { loginlink: '/quickstart/webapp/java-spring-mvc/01-login' }) %>
diff --git a/articles/server-platforms/java-spring-mvc/_includes/_login.md b/articles/server-platforms/java-spring-mvc/_includes/_login.md
deleted file mode 100644
index b4e27229f3..0000000000
--- a/articles/server-platforms/java-spring-mvc/_includes/_login.md
+++ /dev/null
@@ -1,194 +0,0 @@
-## Authenticate the User
-
-You need to add the handler for the Auth0 callback so that you can authenticate the user and get their information. For that, we will use the `Auth0CallbackHandler` provided by the SDK.
-
-Define a new Controller, configure it to use the `auth0.loginCallback` endpoint, and inherit from `Auth0CallbackHandler`.
-
-Create a new `CallbackController.java` file and set the following contents:
-
-${snippet(meta.snippets.use)}
-
-
-## Display Lock Widget
-
-In order to setup [Lock](/libraries/lock) update the `login.jsp` as follows:
-
-```html
-${'<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %>'}
-
-
-
-    
-    Login
-    
-    
-    
-    
-    
-
-
-
        
-    
-
        
-
-
-```
-
-__NOTE__: The sample also includes several css, js, and font files, which are not listed in this document for brevity. These files can be found under the `auth0-spring-mvc-sample/src/main/resources/static/` directory and you don't need to include them if you don't want to.
-
-First, we initialize `Auth0Lock` with a `clientID` and the account's `domain`.
-
-```
-var lock = new Auth0Lock('${account.clientId}', '${account.namespace}');
-```
-
-We set several parameters as input, like `redirectUrl` and `responseType`. For details on what each parameter does, refer to [Lock: User configurable options](/libraries/lock/customization).
-
-Once the `Auth0Lock` is initialized we display the widget using `lock.show()`.
-
-
-## Display User Information
-
-Depending on what `scopes` you specified upon login, some user information may be available in the [id_token](/tokens#auth0-id_token-jwt-) received.
-
-The full user profile information is available as a session object keyed on `Auth0User`, you can call `SessionUtils.getAuth0User()` to retrieve the information. However, because the authenticated user is also a `java.security.Principal` object we can inject it into the Controller automatically for secured endpoints.
-
-Add the following to your `HomeController.java` file:
-
-```java
-@RequestMapping(value="/portal/home", method = RequestMethod.GET)
-protected String home(final Map model, final Principal principal) {
-  logger.info("Home page");
-  final Auth0User user = (Auth0User) principal;
-  logger.info("Principal name: "  user.getName());
-  model.put("user", user);
-  return "home";
-}
-```
-
-__NOTE__: The value `/portal/home` should be replaced with the valid one for your implementation.
-
-Once the user has successfully authenticated, the application displays the `home.jsp`. In order to display some user information, as retrieved from Auth0, update the `home.jsp` as follows:
-
-```html
-${'<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %>'}
-${'<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>'}
-
-
-    
-    
-    
-    Home Page
-    
-    
-    
-    
-    
-    
-
-
-
-
-    
        
-        
        
-            
-            
        App.com
        
-        
        
-
-        
        
-            
        Hello <%= "${user.name}" %>!
        
-            
        Your nickname is: <%= "${user.nickname}" %>
        
-            
        Your user id is: <%= "${user.userId}" %>
        
-            
        "/>
        
-        
        
-
-        
        
-            
        
-                
        Subheading
        
-                
        Donec id elit non mi porta gravida at eget metus. Maecenas faucibus mollis interdum.
        
-                
        Subheading
        
-                
        Morbi leo risus, porta ac consectetur ac, vestibulum at eros. Cras mattis consectetur purus sit amet fermentum.
        
-            
        
-
-            
        
-                
        Subheading
        
-                
        Donec id elit non mi porta gravida at eget metus. Maecenas faucibus mollis interdum.
        
-
-                
        Subheading
        
-                
        Morbi leo risus, porta ac consectetur ac, vestibulum at eros. Cras mattis consectetur purus sit amet fermentum.
        
-            
        
-        
        
-
-        
        
-            
         © 2016 Company Inc
        
-        
        
-
-    
        
-
-    
-
-
-
-```
-
-## Run the App
-
-In order to build and run the app using Maven, execute the following:
-
-```bash
-mvn spring-boot:run
-```
-
-Then open your browser and go to [http://localhost:3099/login](http://localhost:3099/login). You can see the Lock widget.
-
-![Login using Lock](/media/articles/java/login-with-lock.png)
-
-The widget displays all the social and database connections that you have defined for this application in the [dashboard](${manage_url}/#/).
-
-Once you login you are redirected to the home page that displays your profile picture, user id, and nickname.
-
-![Display user information](/media/articles/java/display-user-info.png)
-
-Log out by clicking the **Logout** button at the top right of the home page.
diff --git a/articles/server-platforms/java-spring-mvc/_includes/_prerequisite.md b/articles/server-platforms/java-spring-mvc/_includes/_prerequisite.md
deleted file mode 100644
index 47e0301eac..0000000000
--- a/articles/server-platforms/java-spring-mvc/_includes/_prerequisite.md
+++ /dev/null
@@ -1,7 +0,0 @@
-::: panel-info System Requirements
-These tutorials and seed projects have been tested with the following:
-
-* Java 1.7
-* Maven 3.3
-* Spring 4.2.6
-:::
diff --git a/articles/server-platforms/java-spring-mvc/_includes/_setup.md b/articles/server-platforms/java-spring-mvc/_includes/_setup.md
deleted file mode 100644
index 1525b6b00a..0000000000
--- a/articles/server-platforms/java-spring-mvc/_includes/_setup.md
+++ /dev/null
@@ -1,56 +0,0 @@
-## Create an Application
-
-<%= include('../../../_includes/_java_new_app') %>
-
-![App Dashboard](/media/articles/java/app_dashboard.png)
-
-
-## Configure Callback URLs
-
-Callback URLs are 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. Callback URLs can be manipulated on the fly and that could be harmful. For security reasons, you will need to add your application's URL in the app's `Allowed Callback URLs`. This will enable Auth0 to recognize the URLs as valid. If omitted, authentication will not be successful for the app instance.
-
-![Callback error](/media/articles/java/callback_error.png)
-
-If you follow our seed project or the samples based on it, the values you must configure are:
-- Allowed Callback URL: `http://localhost:3099/callback`
-- Allowed Logout URLs: `http://localhost:3099/logout`
-
-
-## Setup Dependencies
-
-To integrate your Java Spring application with Auth0 you need to have the following dependencies set:
-
-- [auth0-spring-mvc](https://github.com/auth0/auth0-spring-mvc): is the Java library that allows you to use Auth0 with Java for Spring MVC web apps. It validates the [JWT](/jwt) from Auth0 in every API call to assert authentication according to configuration.
-
-If you are using maven, add the dependency to your `pom.xml`:
-
-${snippet(meta.snippets.dependencies)}
-
-If you are using Gradle, add it to the dependencies block:
-
-${snippet(meta.snippets.dependenciesGradle)}
-
-
-## Configure your Java Spring App
-
-Your Java Spring app needs some information in order to authenticate against your Auth0 account. Create a file called `auth0.properties` and place it under `src/main/resources`. Set the following settings:
-
-${snippet(meta.snippets.setup)}
-
-Let's see what each attribute means.
-
-| Attribute | Description|
-| --- | --- |
-| `auth0.domain` | Your auth0 domain. You can find the correct value on the Settings tab of your client on the [dashboard](${manage_url}/#/applications). * |
-| `auth0.issuer` | The issuer of the JWT Token. This is typically your auth0 domain with a `https://` prefix and a `/` suffix. For example, if your `auth0.domain` is `example.auth0.com` then the `auth0.issuer` should be set to `https://example.auth0.com/` (the trailing slash is important). |
-| `auth0.clientId` | The unique identifier for your client. You can find the correct value on the Settings tab of your client on the [dashboard](${manage_url}/#/applications). * |
-| `auth0.clientSecret` | The secret used to sign and validate the tokens that will be used in the different authentication flows. You can find the correct value on the Settings tab of your client on the [dashboard](${manage_url}/#/applications). * |
-| `auth0.onLogoutRedirectTo` | The page that users of your site are redirected to on logout. Should start with `/`. |
-| `auth0.securedRoute` | The URL pattern that should map to the URL endpoint you wish to secure. You should replace its value with the correct value for your implementation. It should start with `/`. * |
-| `auth0.loginCallback` | The URL context path for the login callback endpoint. Should start with `/`. |
-| `auth0.loginRedirectOnSuccess` | The landing page URL context path for a successful authentication. Should start with `/`. |
-| `auth0.loginRedirectOnFail` | The URL context path for the page to redirect to upon failure. Should start with `/`. |
-| `auth0.signingAlgorithm` | This is signing algorithm to verify signed JWT token. Use HS256 or RS256. |
-| `auth0.publicKeyPath` | Path location to the public key. Should always be set when using RS256 and is ignored for HS256. |
-
-**NOTE**: If you download the seed using our **Download Sample** button then the `domain`, `issuer`, `clientId` and `clientSecret` attributes will be populated for you, unless you are not logged in or you do not have at least one registered client. In any case, you should verify that the values are correct if you have multiple clients in your account and you might want to use another than the one we set the information for. Do not forget to manually set the `issuer` attribute!
diff --git a/articles/server-platforms/java-spring-mvc/dashboard-default.md b/articles/server-platforms/java-spring-mvc/dashboard-default.md
deleted file mode 100644
index c8f2801f96..0000000000
--- a/articles/server-platforms/java-spring-mvc/dashboard-default.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to use the Auth0 Java Spring MVC SDK to add authentication and authorization to your web app
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-spring-mvc-sample',
-  path: '01-Login',
-  requirements: [
-    'Java 7 or above',
-    'Maven 3.0.x or above'
-  ]
-}) %>
-
-<%= include('_includes/_setup') %>
-
-<%= include('_includes/_login') %>
diff --git a/articles/server-platforms/java-spring-mvc/index.yml b/articles/server-platforms/java-spring-mvc/index.yml
deleted file mode 100644
index c69b506feb..0000000000
--- a/articles/server-platforms/java-spring-mvc/index.yml
+++ /dev/null
@@ -1,19 +0,0 @@
-title: Java Spring MVC
-image: /media/platforms/spring.png
-logo_name: java
-tags:
-  - quickstart
-alias:
-  - spring
-  - spring-security
-seo_alias: java spring
-snippets:
-  dependencies: server-platforms/java-spring/dependencies
-  dependenciesGradle: server-platforms/java-spring/dependencies-gradle
-  setup: server-platforms/java-spring/setup
-  use: server-platforms/java-spring/use
-default_article: dashboard-default
-articles:
-  - 00-intro
-  - 01-login
-  - 09-mfa
diff --git a/articles/server-platforms/java-spring-security-mvc/00-intro.md b/articles/server-platforms/java-spring-security-mvc/00-intro.md
deleted file mode 100644
index 11a1e0e97c..0000000000
--- a/articles/server-platforms/java-spring-security-mvc/00-intro.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-title: Introduction
-description: This tutorial demonstrates how to use the Auth0 Java Spring Security MVC SDK to add authentication and authorization to your web app, using Spring Boot
-budicon: 715
----
-
-
-
-This multistep quickstart guide will walk you through the process of managing authentication in your Java Spring Security Web Application with Auth0.
-
-::: panel-info System Requirements
-These tutorials and seed projects have been tested with the following:
-- Java 7 or above
-- Maven 3.0.x or above
-:::
-
-Auth0 provides and manages a [Spring Security MVC SDK](https://github.com/auth0/auth0-spring-security-mvc). This SDK allows you to use Auth0 with Java for server-side Spring Security web apps, leveraging Spring Boot dependencies.
-
-__NOTE:__ You can find a listing of all our Java offerings and several sample projects in [Java technologies and Auth0 libraries](/java-overview).
-
-
-## Sample Projects
-
-There are two options to follow along with this quickstart. You can either download the [seed project](https://github.com/auth0-samples/auth0-spring-security-mvc-sample/tree/master/00-Starter-Seed) or the samples provided at each page of this quickstart.
-
-The seed project is a regular Java Spring Security app, with all the Auth0 dependencies set, but nothing more. It's an empty canvas meant to be filled as you follow the steps of this quickstart. If you prefer this option download the seed from our [GitHub repository](https://github.com/auth0-samples/auth0-spring-security-mvc-sample/tree/master/00-Starter-Seed) and follow along.
-
-Instead, you can choose to follow the samples that are included in each step. Each sample uses the [seed project](https://github.com/auth0-samples/auth0-spring-security-mvc-sample/tree/master/00-Starter-Seed) as a starting point and builds on it, according to the configuration of each step. For example, the Login sample would be the [seed project](https://github.com/auth0-samples/auth0-spring-security-mvc-sample/tree/master/00-Starter-Seed) plus the configuration required to implement login functionality. If you choose to follow this approach continue reading, the rest of this document will guide you through setting up the required prerequisites.
-
-
-### Seed project Structure
-
-Let's take some time and explain how our [seed project](https://github.com/auth0-samples/auth0-spring-security-mvc-sample/tree/master/00-Starter-Seed) is structured.
-
-
-```text
-- src
--- main
----- java
------- com
--------- auth0
----------- example
------------- App.java
------------- AppConfig.java
------------- ErrorController.java
------------- HomeController.java
------------- LoginController.java
------------- LogoutController.java
----- resources
------- application.properties
------- auth0.properties
----- webapp
------- WEB-INF
--------- jsp
----------- home.jsp
----------- login.jsp
--------- web.xml
-- pom.xml
-```
-
-The project contains two JSP: the `login.jsp` that will handle the user login, and the `home.jsp` which will display user information after a successful login and provide the option to log out.
-
-The project contains also the following files:
-- `application.properties`: The configuration file that holds information such as the port your app will use, the logging level, etc.
-- `auth0.properties`: The configuration file that holds Auth0 related information, like the client id, client secret, etc. You can find more detailed information in the [Configure your Java Spring app](#configure-your-java-spring-app) section of this document.
-- `App.java`: A Java class that uses Spring Boot’s `SpringApplication.run()` method to launch the application.
-- `AppConfig.java`: The security configuration class. By subclassing, and overriding `authorizeRequests` method, you can define the endpoint security configuration (authentication and authorization) suitable for your own needs.
-- `ErrorController.java`: The controller that handles the errors.
-- `HomeController.java`: The controller that handles landing page requests.
-- `LoginController.java`: The controller that handles the login.
-- `LogoutController.java`: The controller that handles the logouts.
-
-<%= include('_includes/_setup') %>
-
-You are now ready to continue with the next tutorial in order to implement basic login using [Lock](/libraries/lock)!
diff --git a/articles/server-platforms/java-spring-security-mvc/01-login.md b/articles/server-platforms/java-spring-security-mvc/01-login.md
deleted file mode 100644
index af0e8594aa..0000000000
--- a/articles/server-platforms/java-spring-security-mvc/01-login.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Login
-description: This tutorial demonstrates how to use the Auth0 Java Spring Security MVC SDK to add authentication and authorization to your web app
-budicon: 448
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-spring-security-mvc-sample',
-  path: '01-Login',
-  requirements: [
-    'Java 7 or above',
-    'Maven 3.0.x or above'
-  ]
-}) %>
-
-
-
-In this step we will implement login functionality using Lock. Lock is an embeddable login form for desktop, tablet and mobile devices.
-
-<%= include('_includes/_login') %>
diff --git a/articles/server-platforms/java-spring-security-mvc/02-custom-login.md b/articles/server-platforms/java-spring-security-mvc/02-custom-login.md
deleted file mode 100644
index c9fdc38f55..0000000000
--- a/articles/server-platforms/java-spring-security-mvc/02-custom-login.md
+++ /dev/null
@@ -1,92 +0,0 @@
----
-title: Custom Login
-description: This tutorial demonstrates how to use the Auth0 library to add custom authentication and authorization to your web app
-budicon: 448
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-spring-security-mvc-sample',
-  path: '02-Custom-Login',
-  requirements: [
-    'Java 7 or above',
-    'Maven 3.0.x or above'
-  ]
-}) %>
-
-
-
-The previous step explains how to log in but with the [Lock](/libraries/lock) widget. Lock is completely optional so you can build an application with Auth0 using your custom design without having to include it. You just need to use the [Auth0.js library](https://github.com/auth0/auth0.js). Let's see how.
-
-In our example, we will configure a custom database connection to use with our custom login. We will also keep on building on our previous example, the one using Lock. We will add a flag that will be used when the custom login is set, while when unset Lock will be used. This is completely optional of course, you can configure your own web app to use only custom login if this is what you want.
-
-## Create a Database Connection
-
-First, we will create a new database connection and we will name it `custom-login-DB`. We will use Auth0 database infrastructure to store our users.
-
-**NOTE:** If you have an existing user store, or wish to store user credentials on your own server, see the custom database connection tutorial at [Authenticate Users with Username and Password using a Custom Database](/connections/database/mysql) for detailed steps on how to setup and configure it.
-
-Log into Auth0, and select the [Connections > Database](${manage_url}/#/connections/database) menu option.
-
-Click the **Create DB Connection** button and provide a name for the database.
-
-You will be navigated to the connection's settings.
-
-At the **Clients Using This Connection** section, enable the connection for your app.
-
-Now let's create a user.
-
-Select the [Users](${manage_url}/#/users) menu option.
-
-Click the **Create User** button and fill in the email, password, and the database at which the user will be created. Use an email address you have access to since creating the user will trigger a verification email to be sent.
-
-Click **Save**.
-
-Head back to [Connections > Database](${manage_url}/#/connections/database) and select the **Try** button on your new database so we can verify that our user can log in.
-
-**NOTE:** You can add also social connections. To do so you need to create the relevant button in your login form and the javascript to specify which connection to use, for example `google-oauth2`, `github`, etc. You can find details and some sample code on the [auth0.js](/libraries/auth0js#login) document.
-
-
-## Create Custom Login
-
-Since we decided to keep Lock as well, we will leave `login.jsp` as is and we will create a new file named `loginCustom.jsp`. Here is the code:
-
-${snippet(meta.snippets.customLoginJsp)}
-
-Notice the differences compared to `login.jsp`:
-
-- The code uses the `auth0-6.8.js` library, instead of `lock.min.js`.
-- We have added html to display a form for email and password input (div `form-signin`).
-- The javascript code uses the `Auth0` class, instead of `Auth0Lock`.
-
-**NOTE**: Login is probably not enough for your app, users need to be able to sign up. To do so you have to call the `signup` method on the `auth0` instance. You can find details on how to do that in the [Custom Signup](/custom-signup) document.
-
-Now let's go and add this flag we were talking about earlier. Remember that this step is optional.
-
-Edit the `auth0.properties` file:
-- Add the line `auth0.customLogin: true`. If you need to disable it, so you can use Lock again, set the value to `false`.
-- Set the value of `auth0.connection` to the name of the database connection you created earlier. If you follow our example, the value is `custom-login-DB`.
-
-The next step is to read these attributes from our code. Edit the `/src/main/java/com/auth0/example/AppConfig.java` file by adding the following code inside the `AppConfig` class:
-
-${snippet(meta.snippets.customLoginGetValues)}
-
-The final step is to edit the `LoginController.java` class. Edit the `login` method as follows:
-
-${snippet(meta.snippets.customLoginEditController)}
-
-Notice the last line. It checks the value of the `auth0.customLogin` and returns either `loginCustom` or `login`.
-
-We have also added code to retrieve the connection name, the value of the `auth0.connection` property: `model.put("connection", appConfig.getConnection());`. This is the method we added in the previous step in the `AppConfig` class.
-
-## Test the App
-
-We are now ready to test the application!
-
-Build and run the project using `mvn spring-boot:run`. Then, go to [http://localhost:3099/login](http://localhost:3099/login).
-
-You should see the custom login page, instead of Lock.
-
-![Custom Login](/media/articles/java/custom_login_form.png)
-
-Enter the credentials of the user you created earlier to test the login.
diff --git a/articles/server-platforms/java-spring-security-mvc/06-rules.md b/articles/server-platforms/java-spring-security-mvc/06-rules.md
deleted file mode 100644
index 53c52cdbd5..0000000000
--- a/articles/server-platforms/java-spring-security-mvc/06-rules.md
+++ /dev/null
@@ -1,88 +0,0 @@
----
-title: Rules
-description: This tutorial demonstrates how to use Auth0 rules to extend what Auth0 has to offer
-budicon: 173
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-spring-security-mvc-sample',
-  path: '06-Rules',
-  requirements: [
-    'Java 7 or above',
-    'Maven 3.0.x or above'
-  ]
-}) %>
-
-
-
-Rules are one of the cool features of Auth0. The reason is their flexibility, which gives you the ability to extend what Auth0 has to offer. They are just JavaScript functions which work like middlewares. To see a detailed description, please refer to [the Rules documentation](/rules).
-
-## Create a Rule
-
-To create a rule go to the [Create Rule page](${manage_url}/#/rules/new). You can create it from scratch or use an existing template. These templates are written by Auth0 team to assist you complete common tasks.
-
-Let's create a rule to implement some basic role-based authorization. If the user logs in using a `@gmail.com` or a `@auth0.com` email, the user will be assigned the `ROLE_ADMIN` role, otherwise, the user will be assigned the `ROLE_USER` role. We will print some text on the screen to see how this works.
-
-The template you can use for this example is called `Set roles to a user`.
-
-In our example we use this script:
-
-${snippet(meta.snippets.rulesSetRoles)}
-
-Once you are done, save the rule.
-
-**NOTE**: Keep in mind that this is just a starting template, you can edit it to meet your business needs.
-
-## Retrieve the Role
-
-The web app will read this information from the `UserProfile` and apply the granted authorities when checking authorization access to secured endpoints configured with Role based permissions.
-
-To do this, edit the `/src/main/java/com/auth0/example/AppConfig.java` by replacing this:
-
-```java
-.antMatchers("/portal/**").hasAuthority("ROLE_ADMIN")
-```
-
-with this:
-
-```java
-.antMatchers("/portal/**").hasAnyAuthority("ROLE_USER", "ROLE_ADMIN")
-```
-
-
-## Display Result
-
-Let's display some info to see that our rule actually works.
-
-Add the following code at the `src/main/webapp/WEB-INF/jsp/home.jsp`, inside your `jumbotron` div:
-
-${snippet(meta.snippets.rulesHomeJsp)}
-
-That's all the changes we need. Let's test this!
-
-
-## Test the Rule
-
-Once you log in, depending on the email you used, you should see one of the two texts we configured.
-
-![Role rule sample](/media/articles/java/rule-role.png)
-
-
-## Optional: Create a Demo Resource
-
-In order to demonstrate the Role based authorization, let's create a resource which only an authenticated and authorized User with Admin rights can access.
-
-**NOTE:** This is an optional step, used for demonstration purposes, you can skip it.
-
-Create a new `AdminService.java` under `/src/main/java/com/auth0/example`. Paste the following code:
-
-${snippet(meta.snippets.rulesAdminService)}
-
-Let's edit our `HomeController.java` to use this AdminService resource. We will autowire the AdminService resource, create a new `adminChecks` method and invoke it from the `HomeController`.
-
-Paste the following code:
-
-${snippet(meta.snippets.rulesHomeController)}
-
-Run the app and check that the logger displays the *Current user accessed Admin secured resource* message.
diff --git a/articles/server-platforms/java-spring-security-mvc/09-mfa.md b/articles/server-platforms/java-spring-security-mvc/09-mfa.md
deleted file mode 100644
index add95b6c1c..0000000000
--- a/articles/server-platforms/java-spring-security-mvc/09-mfa.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-title: Multifactor Authentication
-description: This tutorial demonstrates how to add Multifactor Authentication to your Java Spring Security web app with Auth0.
-budicon: 243
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-spring-security-mvc-sample',
-  path: '09-MFA',
-  requirements: [
-    'Java 7 or above',
-    'Maven 3.0.x or above'
-  ]
-}) %>
-
-
-
-<%= include('../_includes/_mfa-introduction') %>
-
-In this tutorial, you will learn how to enable MFA in the Spring Security application you created in the previous steps.
-
-## Enable Multifactor Authentication in Your Account
-
-<%= include('../_includes/_mfa-enable') %>
-
-## Login
-
-<%= include('../_includes/_mfa-login', { loginlink: '/quickstart/webapp/java-spring-security-mvc/01-login' }) %>
diff --git a/articles/server-platforms/java-spring-security-mvc/_includes/_login.md b/articles/server-platforms/java-spring-security-mvc/_includes/_login.md
deleted file mode 100644
index 09e06b5579..0000000000
--- a/articles/server-platforms/java-spring-security-mvc/_includes/_login.md
+++ /dev/null
@@ -1,72 +0,0 @@
-## Add the Auth0 Callback Handler
-
-First, we need to add the handler for the Auth0 callback so that we can authenticate the user and get their information. For that, we'll use the `Auth0CallbackHandler` provided by the SDK.
-
-We have to define a new Controller, configure it to use the `auth0.loginCallback` endpoint, and inherit from `Auth0CallbackHandler`.
-
-Create a new `CallbackController.java` file and set the following contents:
-
-${snippet(meta.snippets.use)}
-
-## Define Endpoint Security Configuration
-
-The [Auth0 Spring Security MVC library](https://github.com/auth0/auth0-spring-security-mvc) contains a security configuration class, called `Auth0SecurityConfig`. This class handles all the library Application Context wiring configuration, and a default `HttpSecurity` endpoint configuration that secures the URL Context path defined with `auth0.securedRoute` property.
-
-This is defined in a method called `authorizeRequests(final HttpSecurity http)` which should be overridden by you.
-
-${snippet(meta.snippets.LoginAuthRequestsMethod)}
-
-By subclassing, and overriding `authorizeRequests` you can define whatever endpoint security configuration (authentication and authorization) is suitable for your own needs.
-
-For example, this is the declared subclass together with overridden method from our sample application.
-
-${snippet(meta.snippets.LoginAuthRequestsSubclass)}
-
-
-## Display Lock Widget
-
-In order to setup [Lock](/libraries/lock) update the `login.jsp` as follows:
-
-${snippet(meta.snippets.LoginJsp)}
-
-__NOTE__: The sample also includes several css, js, and font files, which are not listed in this document for brevity. These files can be found under the `auth0-spring-mvc-sample/src/main/resources/static/` directory and you don't need to include them if you don't want to.
-
-First, we initialize `Auth0Lock` with a `clientID` and the account's `domain`.
-
-```js
-var lock = new Auth0Lock('${account.clientId}', '${account.namespace}');
-```
-
-We set several parameters as input, like `redirectUrl` and `responseType`. For details on what each parameter does, refer to [Lock: User configurable options](/libraries/lock/customization).
-
-Once the `Auth0Lock` is initialized we display the widget using `lock.show()`.
-
-## Display User Information
-
-Depending on what `scopes` you specified upon login, some user information may be available in the [id_token](/tokens#auth0-id_token-jwt-) received.
-
-The full user profile information is available as a session object keyed on `Auth0User`, you can call `SessionUtils.getAuth0User()` to retrieve the information. However, because the authenticated user is also a `java.security.Principal` object we can inject it into the Controller automatically for secured endpoints.
-
-Add the following to your `HomeController.java` file:
-
-${snippet(meta.snippets.LoginHomeController)}
-
-The value `/portal/home` should be replaced with the valid one for your implementation.
-
-Once the user has successfully authenticated, the application displays the `home.jsp`. In order to display some user information, as retrieved from Auth0, update the `home.jsp` as follows:
-
-${snippet(meta.snippets.LoginHomeJsp)}
-
-## Test the App
-
-We are now ready to test the application!
-
-Build and run the project using `mvn spring-boot:run`. Then, go to [http://localhost:3099/login](http://localhost:3099/login).
-
-You should see the custom login page, instead of Lock.
-
-![Lock Login](/media/articles/java/lock_login_form.png)
-
-Enter the credentials of the user you created earlier to test the login. You should see the following screen.
-
-![Lock Login](/media/articles/java/lock_user_info.png)
diff --git a/articles/server-platforms/java-spring-security-mvc/_includes/_prerequisite.md b/articles/server-platforms/java-spring-security-mvc/_includes/_prerequisite.md
deleted file mode 100644
index 0809ee40d2..0000000000
--- a/articles/server-platforms/java-spring-security-mvc/_includes/_prerequisite.md
+++ /dev/null
@@ -1,6 +0,0 @@
-::: panel-info System Requirements
-This tutorial and seed project have been tested with the following:
-
-* Java 1.8
-* Maven 3.3
-:::
\ No newline at end of file
diff --git a/articles/server-platforms/java-spring-security-mvc/_includes/_setup.md b/articles/server-platforms/java-spring-security-mvc/_includes/_setup.md
deleted file mode 100644
index 2247a0bbe7..0000000000
--- a/articles/server-platforms/java-spring-security-mvc/_includes/_setup.md
+++ /dev/null
@@ -1,63 +0,0 @@
-## Create a Client
-
-<%= include('../../../_includes/_java_new_app') %>
-
-![Client Dashboard](/media/articles/java/app_dashboard.png)
-
-
-## Configure Callback URLs
-
-Callback URLs are 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. Callback URLs can be manipulated on the fly and that could be harmful. For security reasons, you will need to add your application's URL in the client's `Allowed Callback URLs`. This will enable Auth0 to recognize the URLs as valid. If omitted, authentication will not be successful for the app instance.
-
-![Callback error](/media/articles/java/callback_error.png)
-
-If you follow our seed project or the samples based on it, the values you must configure are:
-- Allowed Callback URL: `http://localhost:3099/callback`
-- Allowed Logout URLs: `http://localhost:3099/logout`
-
-
-## Setup Dependencies
-
-To integrate your Spring Security application with Auth0 you need to have the following dependencies set:
-
-- [auth0-spring-security-mvc](https://github.com/auth0/auth0-spring-security-mvc): is the Java library that allows you to use Auth0 with Spring Security for server-side MVC web apps. It validates the [JWT](/jwt) from Auth0 in every API call to assert authentication according to configuration.
-
-If you are using maven, add the dependency to your `pom.xml`:
-
-${snippet(meta.snippets.dependencies)}
-
-If you are using Gradle, add it to the dependencies block:
-
-${snippet(meta.snippets.dependenciesGradle)}
-
-
-## Configure your Spring Security App
-
-Your Spring Security app needs some information in order to authenticate against your Auth0 account. We have created a file for you but you need to update some of the entries with the valid values for your Client. The file is `/src/main/resources/auth0.properties` and it contains the following:
-
-${snippet(meta.snippets.setup)}
-
-Let's see what each attribute means.
-
-| Attribute | Description|
-| --- | --- |
-| `auth0.domain` | Your auth0 domain. You can find the correct value on the Settings tab of your client on the [dashboard](${manage_url}/#/applications). * |
-| `auth0.issuer` | The issuer of the JWT Token. This is typically your auth0 domain with a `https://` prefix and a `/` suffix. For example, if your `auth0.domain` is `example.auth0.com` then the `auth0.issuer` should be set to `https://example.auth0.com/` (the trailing slash is important). |
-| `auth0.clientId` | The unique identifier for your client. You can find the correct value on the Settings tab of your client on the [dashboard](${manage_url}/#/applications). * |
-| `auth0.clientSecret` | The secret used to sign and validate the tokens that will be used in the different authentication flows. You can find the correct value on the Settings tab of your client on the [dashboard](${manage_url}/#/applications). * |
-| `auth0.onLogoutRedirectTo` | The page that users of your site are redirected to on logout. Should start with `/`. |
-| `auth0.securedRoute` | The URL pattern that should map to the URL endpoint you wish to secure. You should replace its value with the correct value for your implementation. It should start with `/`. * |
-| `auth0.loginCallback` | The URL context path for the login callback endpoint. Should start with `/`. |
-| `auth0.loginRedirectOnSuccess` | The landing page URL context path for a successful authentication. Should start with `/`. |
-| `auth0.loginRedirectOnFail` | The URL context path for the page to redirect to upon failure. Should start with `/`. |
-| `auth0.base64EncodedSecret` | A boolean value indicating whether the Secret used to verify the JWT is `base64` encoded. The default is `false`. |
-| `auth0.authorityStrategy` | Indicates whether authorization claims against the Principal shall be `GROUPS`, `ROLES` or `SCOPE` based. The default is `ROLES`. |
-| `auth0.defaultAuth0ApiSecurityEnabled` | A boolean value that switches having the default config enabled. It should be set to `false`. |
-| `auth0.signingAlgorithm` | This is signing algorithm to verify signed JWT token. Use HS256 or RS256. |
-| `auth0.publicKeyPath` | Path location to the public key. Should always be set when using RS256 and is ignored for HS256. |
-
-**NOTE**: If you download the seed using our **Download Sample** button then the `domain`, `issuer`, `clientId` and `clientSecret` attributes will be populated for you, unless you are not logged in or you do not have at least one registered client. In any case, you should verify that the values are correct if you have multiple clients in your account and you might want to use another than the one we set the information for. Do not forget to manually set the `issuer` attribute!
-
-**NOTE**: If you are using the default library configuration (not overriding with your own) which just secures a single, specific context path then the `auth0.securedRoute` value is important. However, if you are building an application which may have several different secured endpoints, or you don't want to specify an explicit configuration value in this `.properties` file then just set `auth0.securedRoute` to something that signifies this. Perhaps `auth0.securedRoute: UNUSED`. Then just ignore the `securedRoute` entirely when you specify your own configuration. See the section [Extending Auth0SecurityConfig](https://github.com/auth0/auth0-spring-security-api#extending-auth0securityconfig) for further info. This property value is a convenience for the developer to configure an endpoint by context path (.eg all URLS with `/api/v1/` in their context path), but there is no obligation to actually reference this property in your own `HttpSecurity` configuration.
-
-**NOTE**: 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. The [sample application](https://github.com/auth0-samples/auth0-spring-security-mvc-sso-sample) contains  two demo websites that have been developed to demonstrate the Auth0 SSO capabilities between a main "portal" website and a Partner website that depends on the main "portal" site for SSO authentication. Fell free to check this out.
diff --git a/articles/server-platforms/java-spring-security-mvc/dashboard-default.md b/articles/server-platforms/java-spring-security-mvc/dashboard-default.md
deleted file mode 100644
index 3898b6bb18..0000000000
--- a/articles/server-platforms/java-spring-security-mvc/dashboard-default.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to use the Auth0 Java Spring Security MVC SDK to add authentication and authorization to your web app
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-spring-security-mvc-sample',
-  path: '01-Login',
-  requirements: [
-    'Java 7 or above',
-    'Maven 3.0.x or above'
-  ]
-}) %>
-
-<%= include('_includes/_setup') %>
-
-<%= include('_includes/_login') %>
diff --git a/articles/server-platforms/java-spring-security-mvc/index.yml b/articles/server-platforms/java-spring-security-mvc/index.yml
deleted file mode 100644
index 2828413e59..0000000000
--- a/articles/server-platforms/java-spring-security-mvc/index.yml
+++ /dev/null
@@ -1,33 +0,0 @@
-title: Java Spring Security
-image: /media/platforms/spring.png
-logo_name: java
-tags:
-  - quickstart
-alias:
-  - spring
-  - spring-security
-seo_alias: java spring
-snippets:
-  dependencies: server-platforms/java-spring-security/dependencies
-  dependenciesGradle: server-platforms/java-spring-security/dependencies-gradle
-  setup: server-platforms/java-spring-security/setup
-  use: server-platforms/java-spring-security/use
-  LoginAuthRequestsMethod: server-platforms/java-spring-security/LoginAuthRequestsMethod
-  LoginAuthRequestsSubclass: server-platforms/java-spring-security/LoginAuthRequestsSubclass
-  LoginJsp: server-platforms/java-spring-security/LoginJsp
-  LoginHomeController: server-platforms/java-spring-security/LoginHomeController
-  LoginHomeJsp: server-platforms/java-spring-security/LoginHomeJsp
-  customLoginJsp: server-platforms/java-spring-security/customLoginJsp
-  customLoginGetValues: server-platforms/java-spring-security/customLoginGetValues
-  customLoginEditController: server-platforms/java-spring-security/customLoginEditController
-  rulesSetRoles: server-platforms/java-spring-security/rulesSetRoles
-  rulesAdminService: server-platforms/java-spring-security/rulesAdminService
-  rulesHomeController: server-platforms/java-spring-security/rulesHomeController
-  rulesHomeJsp: server-platforms/java-spring-security/rulesHomeJsp
-default_article: dashboard-default
-articles:
-  - 00-intro
-  - 01-login
-  - 02-custom-login
-  - 06-rules
-  - 09-mfa
diff --git a/articles/server-platforms/java/00-intro.md b/articles/server-platforms/java/00-intro.md
deleted file mode 100644
index 85f5e18be2..0000000000
--- a/articles/server-platforms/java/00-intro.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: Introduction
-description: This tutorial demonstrates how to use the Auth0 Java SDK to add authentication and authorization to your web app
-budicon: 715
----
-
-
-This multi-step quickstart will guide you through the process of managing authentication in your Java Servlet Web Application with Auth0.
-
-::: panel-info System Requirements
-These tutorials and seed projects have been tested with the following:
-- Java 7 or above
-- Maven 3.0.x or above
-:::
-
-Auth0 provides and manages a [Servlet SDK](https://github.com/auth0/auth0-servlet). This SDK allows you to use Auth0 with Java for server-side MVC web apps. It presents a simple servlet based solution without introducing specific frameworks or libraries such as Spring.
-
-__NOTE:__ You can find a listing of all our Java offerings and several sample projects in [Java technologies and Auth0 libraries](/java-overview).
-
-
-## Sample Projects
-
-There are two options to follow this quickstart. You can either download the [seed project](https://github.com/auth0-samples/auth0-servlet-sample/tree/master/00-Starter-Seed) or the samples provided at each page of this quickstart.
-
-The seed is a regular java app, with all the Auth0 dependencies set, but nothing more. It's an empty canvas meant to be filled as you follow the steps of this quickstart. If you prefer this option download the seed from our [GitHub repository](https://github.com/auth0-samples/auth0-servlet-sample/tree/master/00-Starter-Seed) and follow along.
-
-Instead, you can choose to follow the samples that are included in each step. Each sample uses the [seed project](https://github.com/auth0-samples/auth0-servlet-sample/tree/master/00-Starter-Seed) as a starting point and applies to it the configuration of each step. So, for example, the Login sample would be the [seed project](https://github.com/auth0-samples/auth0-servlet-sample/tree/master/00-Starter-Seed) plus the configuration required to implement login functionality. If you choose to follow this approach continue reading, the rest of this document will guide you through setting up the required prerequisites.
-
-### Seed Project Structure
-
-Let's take some time and explain how our [seed project](https://github.com/auth0-samples/auth0-servlet-sample/tree/master/00-Starter-Seed) is structured.
-
-
-```text
-- src
--- main
----- java
------- com
--------- auth0
----------- example
------------- HomeServlet.java
------------- LoginServlet.java
------------- LogoutServlet.java
----- webapp
------- WEB-INF
--------- jsp
----------- home.jsp
----------- login.jsp
--------- web.xml
-- pom.xml
-```
-
-The project contains two JSP: the `login.jsp` that will handle the user login, and the `home.jsp` which will display user information after a successful login and provide the option to logout.
-
-The project contains also three servlets:
-- `HomeServlet.java`: The servlet retrieves the `AUTH0_USER` attribute, using `getAuth0User()`, appends the value at the request, and forwards the request to the `home.jsp` resource.
-- `LoginServlet.java`: Invoked when the user attempts to login. The servlet retrieves the `auth0.client_id` and `auth0.domain` parameters, appends the values at the request, and forwards the request to the `login.jsp` resource.
-- `LogoutServlet.java`: Invoked when the user clicks the logout link. The servlet invalidates the user session and redirects the user to the URL specified by the parameter `auth0.onLogoutRedirectTo`. We will cover what this parameter is and how it is set later on in this document.
-
-
-## Create an Application
-
-<%= include('../../_includes/_java_new_app') %>
-
-![App Dashboard](/media/articles/java/app_dashboard.png)
-
-<%= include('_includes/_setup') %>
-
-You are now ready to continue with [login](/quickstart/webapp/java/01-login) tutorial in order to implement basic login using [Lock](/libraries/lock).
diff --git a/articles/server-platforms/java/01-login.md b/articles/server-platforms/java/01-login.md
deleted file mode 100644
index 153812954b..0000000000
--- a/articles/server-platforms/java/01-login.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Login
-description: This tutorial demonstrates how to use the Auth0 Java SDK to add authentication and authorization to your web app
-budicon: 448
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-servlet-sample',
-  path: '01-Login',
-  requirements: [
-    'Java 7 or above',
-    'Maven 3.0.x or above'
-  ]
-}) %>
-
-In this step, we will enable login with the [Lock widget](/libraries/lock).
-
-<%= include('_includes/_login') %>
diff --git a/articles/server-platforms/java/09-mfa.md b/articles/server-platforms/java/09-mfa.md
deleted file mode 100644
index 2d1ef76499..0000000000
--- a/articles/server-platforms/java/09-mfa.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: Multifactor Authentication
-description: This tutorial demonstrates how to add Multifactor Authentication to your Java web app with Auth0
-budicon: 243
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-servlet-sample',
-  path: '09-MFA',
-  requirements: [
-    'Java 7 or above',
-    'Maven 3.0.x or above'
-  ]
-}) %>
-
-<%= include('../_includes/_mfa-introduction') %>
-
-In this tutorial, you will learn how to enable MFA in the Java application you created in the previous steps.
-
-## Enable Multifactor Authentication in Your Account
-
-<%= include('../_includes/_mfa-enable') %>
-
-## Login
-
-<%= include('../_includes/_mfa-login', { loginlink: '/quickstart/webapp/java/01-login' }) %>
diff --git a/articles/server-platforms/java/_includes/_login.md b/articles/server-platforms/java/_includes/_login.md
deleted file mode 100644
index 9e010864fd..0000000000
--- a/articles/server-platforms/java/_includes/_login.md
+++ /dev/null
@@ -1,167 +0,0 @@
-## Authenticate the User
-
-You can use the `Auth0CallbackHandler` provided by the SDK to authenticate the user. This should work as-is based on the configuration you set up in `web.xml`.
-
-For more fine-grained control, you can inherit the library version of `Auth0CallbackHandler` to override methods for tailored behavior. See the [Auth0 Servlet ReadMe](https://github.com/auth0/auth0-servlet) on GitHub for details.
-
-
-## Display Lock Widget
-
-In order to setup [Lock](/libraries/lock) update the `login.jsp` as follows:
-
-```html
-${'<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %>'}
-
-
-
-  
-  Login
-  
-  
-  
-  
-  
-
-
-  
        
-    
-  
        
-
-
-```
-
-__NOTE__: The sample also includes several css, js, and font files, which are not listed in this document for brevity. These files can be found under the `webapp` directory and you don't need to include them if you don't want to. The only necessary file is the `${lock_url}`.
-
-First, we initialize `Auth0Lock` with a `clientID` and the account's `domain`.
-
-```js
-var lock = new Auth0Lock('${account.clientId}', '${account.namespace}');
-```
-
-Afterwards, we use the `showSignin` method to open the widget on signin mode. We set several parameters as input, like `authParams` and `responseType`. For details on what each parameter does, refer to [Lock: User configurable options](/libraries/lock/customization).
-
-
-## Display User Information
-
-Depending on which `scopes` you specified upon login, some user information may be available in the [id_token](/tokens#auth0-id_token-jwt-) received.
-
-The full user profile information is available as a session object keyed on `Auth0User`, you can call `SessionUtils.getAuth0User()` to retrieve it.
-
-However, because the authenticated user is also a `java.security.Principal` object we can inject it into the Controller automatically for secured endpoints.
-
-Once the user has successfully authenticated, the application displays the `home.jsp`. In order to display some user information, as retrieved from Auth0, update the `home.jsp` as follows:
-
-```html
-${'<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %>'}
-${'<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>'}
-
-
-    
-    
-    
-    Home Page
-    
-    
-    
-    
-    
-    
-
-
-
-
-
        
-    
        
-        
-        
        App.com
        
-    
        
-    
        
-        
        Hello <%= "${user.name}" %>!
        
-        
        Your nickname is: <%= "${user.nickname}" %>
        
-        
        Your user id is: <%= "${user.userId}" %>
        
-        
        "/>
        
-    
        
-    
        
-        
        
-            
        Subheading
        
-            
        Donec id elit non mi porta gravida at eget metus. Maecenas faucibus mollis interdum.
        
-            
        Subheading
        
-            
        Morbi leo risus, porta ac consectetur ac, vestibulum at eros. Cras mattis consectetur purus sit amet fermentum.
        
-        
        
-
-        
        
-            
        Subheading
        
-            
        Donec id elit non mi porta gravida at eget metus. Maecenas faucibus mollis interdum.
        
-            
        Subheading
        
-            
        Morbi leo risus, porta ac consectetur ac, vestibulum at eros. Cras mattis consectetur purus sit amet fermentum.
        
-        
        
-    
        
-
-    
        
-        
         © 2016 Company Inc
        
-    
        
-
-
        
-
-
-
-
-
-```
-
-### Run the App
-
-To build and run the app using Maven, execute the following:
-
-```bash
-mvn clean install tomcat7:run
-```
-
-Then open your browser and go to [http://localhost:3099/login](http://localhost:3099/login). You can see the Lock widget.
-
-![Login using Lock](/media/articles/java/login-with-lock.png)
-
-The widget displays all the social and database connections that you have defined for this application in the [dashboard](${manage_url}/#/).
-
-Once you login you are redirected to the home page that displays your profile picture, user id, and nickname.
-
-![Display user information](/media/articles/java/display-user-info.png)
-
-Log out by clicking the **Logout** button at the top right of the home page.
diff --git a/articles/server-platforms/java/_includes/_setup.md b/articles/server-platforms/java/_includes/_setup.md
deleted file mode 100644
index d24d8d33d7..0000000000
--- a/articles/server-platforms/java/_includes/_setup.md
+++ /dev/null
@@ -1,49 +0,0 @@
-## Configure Callback URLs
-
-Callback URLs are 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. Callback URLs can be manipulated on the fly and that could be harmful. For security reasons, you will need to add your application's URL in the app's `Allowed Callback URLs`. This will enable Auth0 to recognize the URLs as valid. If omitted, authentication will not be successful for the app instance.
-
-![Callback error](/media/articles/java/callback_error.png)
-
-If you follow our seed project or the samples based on it, the values you must configure are:
-- Allowed Callback URL: `http://localhost:3099/callback`
-- Allowed Logout URLs: `http://localhost:3099/logout`
-
-
-## Setup Dependencies
-
-To integrate your Java application with Auth0 you need to add the following dependencies:
-
-- [auth0-servlet](https://github.com/auth0/auth0-servlet): is the Java library that allows you to use Auth0 with Java for server-side MVC web apps. It validates the [JWT](/jwt) from Auth0 in every API call to assert authentication according to the configuration.
-
-If you are using maven, add the dependency to your `pom.xml`:
-
-${snippet(meta.snippets.dependencies)}
-
-If you are using Gradle, add it to the dependencies block:
-
-${snippet(meta.snippets.dependenciesGradle)}
-
-
-## Configure your Java App
-
-Your java app needs some information in order to authenticate against your Auth0 account. You need to set this information at the deployment descriptor file `src/main/webapp/WEB-INF/web.xml`. The required information is:
-
-${snippet(meta.snippets.setup)}
-
-As you can see in the seed project, there are many customizable attributes in the `web.xml`.
-
-| Attribute | Description|
-| --- | --- |
-| `auth0.domain` | Your auth0 domain. You can find the correct value on the Settings tab of your client on the [dashboard](${manage_url}/#/applications). * |
-| `auth0.issuer` | The issuer of the JWT Token. This is typically your auth0 domain with a `https://` prefix and a `/` suffix. For example, if your `auth0.domain` is `example.auth0.com` then the `auth0.issuer` should be set to `https://example.auth0.com/` (the trailing slash is important). |
-| `auth0.clientId` | The unique identifier for your client. You can find the correct value on the Settings tab of your client on the [dashboard](${manage_url}/#/applications). * |
-| `auth0.clientSecret` | The secret used to sign and validate the tokens that will be used in the different authentication flows. You can find the correct value on the Settings tab of your client on the [dashboard](${manage_url}/#/applications). * |
-| `auth0.onLogoutRedirectTo` | The page that users of your site are redirected to on logout. Should start with `/`. |
-| `auth0.redirect_on_success` | The landing page URL context path for a successful authentication. Should start with `/`. |
-| `auth0.redirect_on_error` | The URL context path for the page to redirect to upon failure. Should start with `/`. |
-| `auth0.redirect_on_authentication_error` | The URL context path for the page to redirect to upon authentication failure. Should start with `/`. |
-| `auth0.signing_algorithm` | This is signing algorithm to verify signed JWT token. Use HS256 or RS256. |
-| `auth0.public_key_path` | Path location to the public key. Should always be set when using RS256 and is ignored for HS256. |
-
-
-**NOTE**: If you download the seed using our **Download Sample** button then the `domain`, `issuer`, `clientId` and `clientSecret` attributes will be populated for you, unless you are not logged in or you do not have at least one registered client. In any case, you should verify that the values are correct if you have multiple clients in your account and you might want to use another than the one we set the information for. Do not forget to manually set the `issuer` attribute!
diff --git a/articles/server-platforms/java/dashboard-default.md b/articles/server-platforms/java/dashboard-default.md
deleted file mode 100644
index 6fd92d08bf..0000000000
--- a/articles/server-platforms/java/dashboard-default.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to use the Auth0 Java SDK to add authentication and authorization to your web app
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-servlet-sample',
-  path: '01-Login',
-  requirements: [
-    'Java 1.7',
-    'Maven 3.3'
-  ]
-}) %>
-
-<%= include('_includes/_setup') %>
-
-<%= include('_includes/_login') %>
diff --git a/articles/server-platforms/java/index.yml b/articles/server-platforms/java/index.yml
deleted file mode 100644
index 41fa60d8af..0000000000
--- a/articles/server-platforms/java/index.yml
+++ /dev/null
@@ -1,17 +0,0 @@
-title: Java
-image: /media/platforms/java.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-platforms/java/dependencies
-  dependenciesGradle: server-platforms/java/dependencies-gradle
-  setup: server-platforms/java/setup
-  use: server-platforms/java/use
-alias:
-  - java
-seo_alias: java
-default_article: dashboard-default
-articles:
-  - 00-intro
-  - 01-login
-  - 09-mfa
diff --git a/articles/server-platforms/laravel/01-login.md b/articles/server-platforms/laravel/01-login.md
deleted file mode 100644
index a5ef2c9c54..0000000000
--- a/articles/server-platforms/laravel/01-login.md
+++ /dev/null
@@ -1,202 +0,0 @@
----
-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
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-laravel-php-web-app',
-  path: '00-Starter-Seed',
-  requirements: [
-    'Composer 1.0-dev',
-    'PHP 5.6.4',
-    'Laravel 5.2.15'
-  ]
-}) %>
-
-## Laravel Compatibility
-
-The latest version (4.x) targets Laravel 5.3 compatibility.
-
-If you are working with an older version (Laravel 4.x) you need to point to composer.json to the version 1.0.*
-
-## Install the Plugin and its Dependencies
-
-${snippet(meta.snippets.dependencies)}
-
-> 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 and it will install them in your project for you.
-
-## Enable it in Laravel
-
-Add the following to the list of service providers, located in `config/app.php`
-
-${snippet(meta.snippets.setup)}
-
-Optionally, if you want to use the [facade](http://laravel.com/docs/facades) called `Auth0` you should also add an alias in the same file
-
-```php
-'aliases' => array(
-    // ...
-    'Auth0' => Auth0\Login\Facade\Auth0::class
-);
-```
-
-Finally, you will need to bind a class that provides the users (your app model user) 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 (which should implement the `\Auth0\Login\Contract\Auth0UserRepository` interface, this is covered later).
-For this you need to add to your `AppServiceProvider` the following line:
-
-```php
-...
-
-public function register()
-{
-
-    $this->app->bind(
-        '\Auth0\Login\Contract\Auth0UserRepository',
-        '\Auth0\Login\Repository\Auth0UserRepository');
-
-}
-
-...
-```
-
-## Configure It
-
-To configure the plugin, you need to publish the plugin configuration and complete the file `config/laravel-auth0.php` using the information of your Auth0 account.
-
-To publish the example configuration file use this command
-
-```bash
-php artisan vendor:publish
-```
-
-## Setup the Callback Action
-
-The plugin works with the [Laravel authentication system](https://laravel.com/docs/5.3/authentication), but instead of using the `Auth::attempt` in a controller that handles a login form submit, you have to hook up the callback uri.
-
-In other words, you need to select a uri (for example `/auth0/callback`) and configure it in your [Auth0 admin page](${manage_url}/#/applications) and also, add it as a route in `routes/web.php` in Laravel
-
-```php
-Route::get('/auth0/callback', '\Auth0\Login\Auth0Controller@callback');
-```
-
-## Triggering Login Manually or Integrating the Auth0 Widget
-
-You can trigger the login in different ways, like redirecting to a login link or you can use [Lock](/lock), by adding the following javascript into a Laravel view or layout (e.g. in `resources/views/welcome.blade.php`)
-
-<%= include('../../_includes/_lock-sdk') %>
-
-Now, after user has logged in, you will be able to access to the logged user info with `Auth::user()`.
-
-## Defining a User and a User Provider
-
-The [Laravel authentication system](https://laravel.com/docs/5.3/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.
-
-The plugin comes with an authentication driver called auth0. This driver defines a user structure that wraps the [Normalized User Profile](/user-profile) defined by Auth0, and it doesn't actually persist the object, it just stores it in the session for future calls.
-
-This works fine for basic testing or if you don't really need to persist the user. 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.
-
-To enable this driver, you need to change the following line in `/config/auth.php`:
-
-```php
-...
-    'providers' => [
-        'users' => [
-            'driver' => 'auth0'
-        ],
-    ],
-...
-```
-
-If you need a more advanced custom solution, you can extend the `Auth0UserRepository` class.
-
-For example, you may want to expose CRUD operations on the application `User` model. In the following
-example, custom `read` methods are added and user profile data is stored locally.
-
-```php
-user_id = $jwt->sub;
-
-      return $this->upsertUser($jwt);
-    }
-
-    public function getUserByUserInfo($userInfo) {
-      return $this->upsertUser($userInfo['profile']);
-    }
-
-    protected function upsertUser($profile) {
-
-      $user = User::where("auth0id", $profile->user_id)->first();
-
-      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();
-      }
-
-      return $user;
-    }
-
-    public function getUserByIdentifier($identifier) {
-        //Get the user info of the user logged in (probably in session)
-        $user = \App::make('auth0')->getUser();
-
-        if ($user===null) return null;
-
-        // build the user
-        $user = $this->getUserByUserInfo($user);
-
-        // it is not the same user as logged in, it is not valid
-        if ($user && $user->auth0id == $identifier) {
-            return $auth0User;
-        }
-    }
-
-}
-```
-
-And change the binding in the second step in your `AppServiceProvider`:
-
-```php
-...
-
-public function register()
-{
-
-    $this->app->bind(
-        '\Auth0\Login\Contract\Auth0UserRepository',
-        \App\Repository\MyCustomUserRepository::class);
-
-}
-
-...
-```
-
-## Use It
-
-Now all your web routes will be secured by auth0.
-
-For loging out your users, you can set up a route like this:
-
-```php
-Route::get('/logout', function() {
-    Auth::logout();
-    return Redirect::home();
-});
-```
diff --git a/articles/server-platforms/laravel/index.yml b/articles/server-platforms/laravel/index.yml
deleted file mode 100644
index a32e188f8a..0000000000
--- a/articles/server-platforms/laravel/index.yml
+++ /dev/null
@@ -1,12 +0,0 @@
-title: PHP (Laravel)
-image: /media/platforms/php.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-platforms/laravel/dependencies
-  setup: server-platforms/laravel/setup
-  use: server-platforms/laravel/use
-seo_alias: laravel
-default_article: 01-login
-articles:
-  - 01-login
diff --git a/articles/server-platforms/nancyfx/01-login.md b/articles/server-platforms/nancyfx/01-login.md
deleted file mode 100644
index 5fd040267f..0000000000
--- a/articles/server-platforms/nancyfx/01-login.md
+++ /dev/null
@@ -1,105 +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-samples',
-  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`
-
-> **Important Hint:** 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");
-
-            return View["login"];
-        };
-
-        Get["/login-callback"] = o => this
-            .AuthenticateThisSession()
-            .ThenRedirectTo("securepage");
-
-        Get["/logout"] = o => this
-            .RemoveAuthenticationFromThisSession()
-            .ThenRedirectTo("index");
-    }
-}
-```
-
-## Triggering Login Manually or Integrating Lock
-
-<%= include('../../_includes/_lock-sdk') %>
-
-> **Note:** Please note that the `redirectUrl` specified in the `Auth0Lock` constructor **must match** the one specified in the previous step
-
diff --git a/articles/server-platforms/nancyfx/index.yml b/articles/server-platforms/nancyfx/index.yml
deleted file mode 100644
index a9d329b4c0..0000000000
--- a/articles/server-platforms/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/server-platforms/nodejs/00-intro.md b/articles/server-platforms/nodejs/00-intro.md
deleted file mode 100644
index 3dec301863..0000000000
--- a/articles/server-platforms/nodejs/00-intro.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Introduction
-description: This tutorial demonstrates how to setup and run the nodejs webapp sample project provided by Auth0
-budicon: 715
----
-
-This multistep quickstart guide will walk you through setting up and managing authentication in your Node.js web apps using Auth0. Each step demonstrates how to implement a specific feature of Auth0 and is accompanied by a downloadable sample project showing the complete solution.
-
-<%= include('../../_includes/_new_app') %>
-
-<%= include('_includes/_setup') %>
-
-## Running the Sample Applications
-
-After installing the dependencies for each of the samples, start the application:
-
-```bash
-npm start
-```
-
-With everything set, the app will be available at `localhost:3000`.
diff --git a/articles/server-platforms/nodejs/01-login.md b/articles/server-platforms/nodejs/01-login.md
deleted file mode 100644
index 2ec459bfe4..0000000000
--- a/articles/server-platforms/nodejs/01-login.md
+++ /dev/null
@@ -1,17 +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 superior',
-    'Express 4.11'
-  ]
-}) %>
-
-<%= include('_includes/_login') %>
diff --git a/articles/server-platforms/nodejs/02-login-custom.md b/articles/server-platforms/nodejs/02-login-custom.md
deleted file mode 100644
index ff88e7c0a4..0000000000
--- a/articles/server-platforms/nodejs/02-login-custom.md
+++ /dev/null
@@ -1,137 +0,0 @@
----
-title: Custom Login
-description: This tutorial demonstrates how to create a custom login page for your web application by using the auth0.js library
-budicon: 448
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-nodejs-webapp-sample',
-  path: '02-Custom-Login',
-  requirements: [
-    'NodeJS 4.3 or superior',
-    'Express 4.11'
-  ]
-}) %>
-
-## auth0.js
-
-The previous step explained how to provide a login screen with Auth0's [Lock widget](/libraries/lock). In this tutorial (based on the previous tutorial's source code) we are going to learn how to create a custom login page by using the [auth0.js library](/libraries/auth0js).
-
-## Add the auth0.js Dependency
-
-To begin, we need to add the `auth0.js` library in our `layout` template. The library can be retrieved from Auth0's CDN.
-
-```jade
-// views/layout.jade
-
-doctype html
-html
-  head
-    title= title
-    link(rel='stylesheet', href='/stylesheets/style.css')
-    // auth0.js
-    script(src="")
-  body
-    block content
-```
-
-## Login with Auth0.js
-
-To log in with `auth0.js` we first need to create an Auth0 instance which will
-then be used to initiate the login process.
-
-```jade
-// views/index.jade
-
-script.
-  var auth0 = new Auth0({
-    domain:      '#{env.AUTH0_DOMAIN}',
-    clientID:    '#{env.AUTH0_CLIENT_ID}',
-    callbackURL: '#{env.AUTH0_CALLBACK_URL}',
-  });
-```
-
-Initiating the login process is done by calling the `.signin()` method of `auth0`
-passing the connection to use.
-
-Here is an example of how to use `.signin()` to log in with Google.
-
-```jade
-// views/index.jade
-
-script.
-
-  ...
-
-  function signinGoogle() {
-    auth0.signin({
-      connection: 'google-oauth2',
-    });
-  }
-```
-
-## Username and Password Login
-
-Logging in with a username and password is very similar to the previous case, but we need to pass the user's credentials to the `.signin()` method.
-
-```jade
-// views/index.jade
-
-script.
-
-  ...
-
-  function signinDb() {
-    auth0.signin({
-      connection: 'Username-Password-Authentication',
-      username: document.getElementById('username').value,
-      password: document.getElementById('password').value,
-    });
-  }
-```
-
-## Putting it all together
-
-We can now add some input fields and buttons to make a complete custom login page.
-
-```jade
-extends layout
-
-block content
-
-  h1= title
-  p Welcome to #{title}
-  br
-  button(onclick="signinGoogle()") Log In with Google
-  br
-  br
-  label Username
-  input(id='username')
-  br
-  label Password
-  input(id='password', type='password')
-  br
-  button(onclick="signinDb()") Log In
-
-  script.
-    var auth0 = new Auth0({
-        domain:      '#{env.AUTH0_DOMAIN}',
-        clientID:    '#{env.AUTH0_CLIENT_ID}',
-        callbackURL: '#{env.AUTH0_CALLBACK_URL}',
-      });
-
-    function signinGoogle() {
-      auth0.signin({
-        connection: 'google-oauth2',
-      });
-    }
-
-    function signinDb() {
-      auth0.signin({
-        connection: 'Username-Password-Authentication',
-        username: document.getElementById('username').value,
-        password: document.getElementById('password').value,
-      });
-    }
-```
diff --git a/articles/server-platforms/nodejs/04-user-profile.md b/articles/server-platforms/nodejs/04-user-profile.md
deleted file mode 100644
index 622e737a25..0000000000
--- a/articles/server-platforms/nodejs/04-user-profile.md
+++ /dev/null
@@ -1,50 +0,0 @@
----
-title: User Profile
-description: This tutorial demonstrates how to fetch user profile information
-budicon: 292
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-nodejs-webapp-sample',
-  path: '04-User-Profile',
-  requirements: [
-    'NodeJS 4.3 or superior',
-    'Express 4.11'
-  ]
-}) %>
-
-## User Profile
-
-Getting the user's profile information is very simple with Auth0. After the user has authenticated, a `user` object
-with the entire profile is attached to every express request.
-
-## Showing the User Profile
-
-We can modify the `/user` endpoint to display the user object. Add the following to the `views/user.jade` template:
-
-```jade
-extends layout
-
-block content
-  img(src="#{user.picture}")
-  h2 Welcome #{user.nickname}!
-  br
-  a(href='/logout') Logout
-  h2 User Profile
-  pre #{userProfile}
-```
-
-To have full access to the user profile on  `userProfile`, we need to stringify the `user` object. Modify the `/` endpoint in `views/user.js` to include `userProfile`.
-
-```js
-// views/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, '  ')
-  });
-});
-```
diff --git a/articles/server-platforms/nodejs/05-linking-accounts.md b/articles/server-platforms/nodejs/05-linking-accounts.md
deleted file mode 100644
index a1e12e9dd1..0000000000
--- a/articles/server-platforms/nodejs/05-linking-accounts.md
+++ /dev/null
@@ -1,178 +0,0 @@
----
-title: Linking Accounts
-description: This tutorial demonstrates how to integrate Auth0 with NodeJS to link accounts
-budicon: 345
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-nodejs-webapp-sample',
-  path: '05-Linking-Accounts',
-  requirements: [
-    'NodeJS 4.3 or superior',
-    'Express 4.11'
-  ]
-}) %>
-
-There may be situations where 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 email and password (which provides very little information about the user), you can ask the user to link their account to an OAuth provider like Facebook or Google to gain access to their social profile.
-
-In this step, we'll modify the application we created in the [Login](/quickstart/server-platforms/nodejs/01-login) step to allow users to link or unlink other OAuth providers to their account.
-
-## Show Linked Accounts Information
-
-The user profile contains an array of identities which consists of profile information from all linked providers. You can verify this by accessing the Auth0 [Users page](${manage_url}/#/users), selecting a user and scrolling down to `identities` under **Identity Provider Attributes**.
-
-This is how a profile looks after linking to Gmail:
-
-![User identities](/media/articles/users/user-identities-linked.png)
-
-If you fetch a profile containing linked accounts, you will have all this information available.
-
-## Linking Accounts
-
-To link accounts, call the [Link a user account](/api/management/v2#!/Users/post_identities) Auth0 API endpoint. To complete the request, you must provide the primary account Auth0 JWT (the token provided when the user logged in), the user id (from the JWT or the profile API) and the JWT of the account you want to link (secondary account).
-
-In order to get the user tokens, we must make a small modification to the `Auth0Strategy` configuration so that
-the user tokens are stored in the user object.
-
-```js
-// app.js
-
-// This will configure Passport to use Auth0
-var strategy = new Auth0Strategy({
-    domain:       process.env.AUTH0_DOMAIN,
-    clientID:     process.env.AUTH0_CLIENT_ID,
-    clientSecret: process.env.AUTH0_CLIENT_SECRET,
-    callbackURL:  process.env.AUTH0_CALLBACK_URL || 'http://localhost:3000/callback'
-  }, function(accessToken, refreshToken, extraParams, profile, done) {
-    // Store the profile and tokens in the user object.
-    return done(null, {
-      profile: profile,
-      extraParams: extraParams,
-    });
-  });
-```
-
-We need a new view called `callback.jade` that will help us store the primary user's JWT after a successful login in the client's `localStorage`.
-
-```jade
-extends layout
-
-block content
-
-  script.
-    // Use local storage to keep track of the user's token and id.
-    localStorage.setItem('idToken', '#{user.extraParams.id_token}')
-    localStorage.setItem('userId', '#{user.profile.id}')
-
-    window.location.href = '/user/';
-```
-
-Modify `routes/index.js` so that the `/callback` route renders the new template.
-
-```js
-// routes/index.js
-
-router.get('/callback',
-  passport.authenticate('auth0', {
-    failureRedirect: '/url-if-something-fails',
-  }),
-  function(req, res) {
-    res.render('callback', {
-      env: env,
-      user: req.user,
-    });
-  });
-```
-
-We now need to provide a means for the user to link another account. Let's add a `Link Account` button to `views/user.jade`
-that uses `Auth0Lock` to perform the secondary login.
-
-```jade
-// views/user.jade
-
-extends layout
-
-block content
-  img(src="#{user.profile.picture}")
-  h2 Welcome #{user.profile.nickname}!
-  br
-  a(href='/logout') Logout
-  br
-  button(onclick="signin()") Link Account
-
-  script.
-    var lock = new Auth0Lock(
-      '#{env.AUTH0_CLIENT_ID}',
-      '#{env.AUTH0_DOMAIN}', {
-        auth: {
-          redirectUrl: 'http://localhost:3000/link',
-          responseType: 'token',
-        }
-      }
-    );
-
-    function signin() {
-      lock.show();
-    }
-```
-
-Let's now add a `/link` endpoint and create the template to be rendered when `/link` is reached.
-
-```jade
-// views/link.jade
-
-extends layout
-
-block content
-  // We're using jQuery to do the POST request
-  script(src="https://code.jquery.com/jquery-3.1.0.min.js")
-
-  script.
-    var lock = new Auth0Lock(
-      '#{env.AUTH0_CLIENT_ID}',
-      '#{env.AUTH0_DOMAIN}'
-    );
-
-    lock.on("authenticated", function(authResult) {
-      linkAccount(authResult.idToken);
-    });
-
-    function linkAccount(secondaryJWT){
-      // At this point you can fetch the secondary user_metadata for merging
-      // with the primary account. Otherwise it will be lost after linking the accounts
-      var primaryJWT = localStorage.getItem('idToken');
-      var primaryUserId = localStorage.getItem('userId');
-      $.ajax({
-        type: 'POST',
-        url: 'https://' + '#{env.AUTH0_DOMAIN}' + '/api/v2/users/' + primaryUserId + '/identities',
-        data: {
-          link_with: secondaryJWT
-        },
-        headers: {
-          'Authorization': 'Bearer ' + primaryJWT
-        }
-      }).then(function(identities){
-        alert('linked!');
-        window.location.href = '/user/';
-      }).fail(function(jqXHR){
-        alert('Error linking Accounts: ' + jqXHR.status + " " + jqXHR.responseText);
-      });
-    }
-```
-
-The `linkAccount()` function is in charge of sending a `POST` request to the [Link a user account](/api/management/v2#!/Users/post_identities) endpoint with both user tokens.
-
-The `/link` endpoint simply renders the template. Add the following route to `routes/index.js`
-
-```js
-// routes/index.js
-
-...
-
-router.get('/link',
-  ensureLoggedIn,
-  function(req, res) {
-    res.render('link', {env: env});
-  });
-```
diff --git a/articles/server-platforms/nodejs/06-rules.md b/articles/server-platforms/nodejs/06-rules.md
deleted file mode 100644
index 0c3519a47b..0000000000
--- a/articles/server-platforms/nodejs/06-rules.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title: Rules
-description: This tutorial demonstrates how to use Auth0 rules
-budicon: 173
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-nodejs-webapp-sample',
-  path: '06-Rules',
-  requirements: [
-    'NodeJS 4.3 or superior',
-    'Express 4.11'
-  ]
-}) %>
-
-## Create a Rule
-
-<%= include('../_includes/_rules-create-section') %>
-
-## Test the Rule Result
-
-The following sample is based on the `01-Login` source code. Add the following to the `views/user.jade` template to display the new `country` field:
-
-```jade
-extends layout
-
-block content
-  img(src="#{user.picture}")
-  h2 Welcome #{user.nickname}!
-  br
-  p Country (Provided by Rule): #{user._json.country}
-  br
-  a(href='/logout') Logout
-```
diff --git a/articles/server-platforms/nodejs/07-authorization.md b/articles/server-platforms/nodejs/07-authorization.md
deleted file mode 100644
index ec4b6ba28d..0000000000
--- a/articles/server-platforms/nodejs/07-authorization.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-title: Authorization
-description: This tutorial demonstrates how assign roles to your users and how to 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-nodejs-webapp-sample',
-  path: '07-Authorization',
-  requirements: [
-    'NodeJS 4.3 or superior',
-    'Express 4.11'
-  ]
-}) %>
-
-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.
-
-## Create a Rule to Assign Roles
-
-First, create a rule that assigns users to either an `admin` role or a single `user` role. Go to the [New Rule](https://manage.auth0.com/#/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 the user’s email contains `@example.com`. Otherwise, the user will be assigned a regular `user` role.
-
-> **NOTE:** The authorization rule can be customized as needed and is not limited to setting roles of `admin` and `user`.
-
-## Check if a User's Role is Present
-
-Create a new file called `requireRole.js`. This file will contain a middleware that will be used to check for the existence of a role in a user's `app_metadata`. Since `app_metadata` is readonly for users, they are not able to manipulate their own authorization level.
-
-```js
-// requireRole.js
-
-module.exports = function requireRole(role) {
-  return function(req, res, next) {
-    var appMetadata = req.user.profile._json.app_metadata || {};
-    var roles = appMetadata.roles || [];
-
-    if (roles.indexOf(role) != -1) {
-      next();
-    } else {
-      res.redirect('/unauthorized');
-    }
-  }
-}
-```
-
-## Restrict Routes Based on the User's Roles
-
-To demonstrate how to restrict access to certain routes based on a user's roles, you can update the `routes/index.js` to include an `/admin` route and use the `requireRole` middleware on it.
-
-```js
-// routes/index.js
-
-...
-
-var requireRole = require('../requireRole');
-
-...
-
-router.get('/admin',
-  requireRole('admin'),
-  function(req, res) {
-    res.render('admin');
-  });
-
-router.get('/unauthorized', function(req, res) {
-  res.render('unauthorized', {env: env});
-});
-
-...
-```
-
-Next, add the required template for the `/admin` and `/unauthorized` routes.
-
-```jade
-// views/admin.jade
-
-extends layout
-
-block content
-  h1 You are seeing this because you have the 'admin' role
-```
-
-```jade
-// views/unauthorized.jade
-
-extends layout
-
-block content
-  h1 Permission denied
-  p Set "roles": ["admin"] in the user's app_metadata section.
-```
-
-The new `/admin` route requires the user to have a role of `admin` in their `app_metadata` and redirects to `/unauthorized` if the role is not present.
diff --git a/articles/server-platforms/nodejs/09-mfa.md b/articles/server-platforms/nodejs/09-mfa.md
deleted file mode 100644
index 15fd20ee24..0000000000
--- a/articles/server-platforms/nodejs/09-mfa.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-title: Multifactor Authentication
-description: This tutorial will show you how to add Multifactor Authentication to your NodeJS WebApp with auth0.
-budicon: 243
----
-
-<%= include('../_includes/_mfa-introduction') %>
-
-## Enable Multifactor Authentication in Your Account
-
-<%= include('../_includes/_mfa-enable') %>
-
-## Login
-
-<%= include('../_includes/_mfa-login', { loginlink: '/quickstart/webapp/nodejs/01-login' }) %>
-
diff --git a/articles/server-platforms/nodejs/10-customizing-lock.md b/articles/server-platforms/nodejs/10-customizing-lock.md
deleted file mode 100644
index c9bb01e402..0000000000
--- a/articles/server-platforms/nodejs/10-customizing-lock.md
+++ /dev/null
@@ -1,56 +0,0 @@
----
-title: Customizing Lock
-description: This tutorial will show you how to customize lock widget.
-budicon: 285
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-nodejs-webapp-sample',
-  path: '10-Customizing-Lock',
-  requirements: [
-    'NodeJS 4.3 or superior',
-    'Express 4.11'
-  ]
-}) %>
-
-Using the Lock widget is easy, but it might be necessary to customize the UI for it. There are several options available to do so.
-
-## Lock Options
-
-Some UI customization can be done via the `options` parameter when creating a `Lock` instance. These options can be found in the [full documentation](/libraries/lock/v10/customization).
-
-## Theme options
-
-Theme properties, such as a different logo or primary color, can be set by adding a `theme` property with custom values when initializing the Lock widget. For more information, see: [Theming Options](/libraries/lock/v10/customization#theming-options).
-
-```js
-var lock = new Auth0Lock(clientId, domain, {
-  theme: {
-    logo: 'https://example.com/assets/logo.png',
-    primaryColor: 'green'
-  }
-});
-```
-
-### Language Dictionary Specification
-
-You can also customize the text that `Lock` will display with the `languageDictionary` option parameter. For more information, see: [Language Dictionary Specification](/libraries/lock/v10/customization#languagedictionary-object-).
-
-```js
-var lock = new Auth0Lock(clientId, domain, {
-  languageDictionary: {
-    title: "My Company"
-  }
-});
-```
-
-### Results
-
-This is how Lock will appear using a custom logo, color, and title:
-
-![Custom lock](/media/articles/reactjs/widget-custom-logo-color.png)
-
-## Further Reading
-
-For more information, read the [full documentation](/libraries/lock/v10/customization) on Lock customization options.
diff --git a/articles/server-platforms/nodejs/11-api-authorization.md b/articles/server-platforms/nodejs/11-api-authorization.md
deleted file mode 100644
index 60392c0a29..0000000000
--- a/articles/server-platforms/nodejs/11-api-authorization.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-title: OAuth 2.0 API Authorization
-description: This tutorial demonstrates how to use Auth0 to make authorized API calls from your web app.
----
-
-At some point, your APIs may need to allow limited access to users, servers, or servers on behalf of users. This tutorial demonstrates how to use the [Authorization Code Flow](https://auth0.com/docs/api-auth/tutorials/authorization-code-grant) to give your applications (or third-party applications) limited access to your APIs on behalf of users. For more information, check out [our documentation](https://auth0.com/docs/api-auth).
-
-<%= include('../../_includes/_compat_warning') %>
-
-### Before Starting
-
-## 1. Enable OAuth 2.0 API Authorization
-
-<%= include('../../_includes/_configure_oauth2aas') %>
-
-## 2. Create an Application
-
-<%= include('_includes/_new_regular_webapp_client') %>
-
-![App Dashboard](/media/articles/server-platforms/reg_web_app_client.png)
-
-Be sure to register the URL of your app in the Allowed Callback URLs in your Client Settings.
-
-## 3. Create a Resource Server (API)
-
-<%= include('../../_includes/_new_api') %>
-
-![Create API](/media/articles/api-auth/api-5.png)
-![Update Scopes](/media/articles/api-auth/api-6.png)
-
-Take note of the API Identifier and Scopes you defined in the Dashboard, as they will be used later.
-
-<%= include('./_includes/_api_authz') %>
diff --git a/articles/server-platforms/nodejs/12-api-refresh-token.md b/articles/server-platforms/nodejs/12-api-refresh-token.md
deleted file mode 100644
index 035758551e..0000000000
--- a/articles/server-platforms/nodejs/12-api-refresh-token.md
+++ /dev/null
@@ -1,63 +0,0 @@
----
-title: OAuth 2.0 Refresh Tokens
-description: This tutorial demonstrates how to use Auth0 to renew Access Tokens using Refresh Tokens.
----
-
-A Refresh Token is a special kind of token that can be used to obtain a renewed access token at any time. You can request new access tokens. Remember, Refresh Tokens must be stored securely by an application because they essentially allow a user to remain authenticated forever. For more information, check out [our documentation](https://auth0.com/docs/api-auth).
-
-<%= include('../../_includes/_compat_warning') %>
-
-## Obtaining a Refresh Token
-
-To obtain a Refresh Token, you should include the `offline_access` scope in `auth0.login` `scope` parameter.
-
-```js
-
-...
-
-// this function will be called when a user clicks the login button
-function signIn() {
-  auth0.login({
-    responseType: 'id_token token',
-    scope: 'openid profile offline_access {API SCOPES}',
-    audience: '{API IDENTIFIER}'
-  });
-}
-
-...
-```
-
-The Refesh Token will be available in `req.user.extraParams.refresh_token`.
-
-## Using a Refresh Token
-
-If you invoke your API and you get a `401` response, this tells you that you might need to refresh your Access Token since it is expired.
-
-In order to renew your Access Token, you must send a request to the `/oauth/token` endpoint to obtain a renewed access token. Note that this quickstart assumes that the *Token Endpoint Authentication Method* setting for your Client is set to `POST`.
-
-```js
-
-// get refresh token
-
-var options = { method: 'POST',
-  url: `https://${process.env.AUTH0_DOMAIN}/oauth/token`,
-  headers: { 'content-type': 'application/json' },
-  body: {
-    grant_type: 'refresh_token',
-    client_id: '{env.AUTH0_CLIENT_ID}',
-    client_secret: '{env.AUTH0_CLIENT_SECRET}',
-    refresh_token: req.user.extraParams.refresh_token
-  },
-  json: true
-};
-
-request(options, function (error, response, body) {
-  // body.access_token is the renewed access token
-  // use this renewed access token to invoke your API
-});
-
-```
-
-You can optionally include the `scope` parameter, including any or all of the scopes that were originally requested. If you ask for scopes for which the user did not already provide consent, the returned `access_token` will not include them. If you specified the `openid` scope, you will also get back an `id_token`.
-
-The renewed Access Token has an expiration time equal to the `Token Expiration (Seconds)` setting for your API.
diff --git a/articles/server-platforms/nodejs/_includes/_api_authz.md b/articles/server-platforms/nodejs/_includes/_api_authz.md
deleted file mode 100644
index d26469b129..0000000000
--- a/articles/server-platforms/nodejs/_includes/_api_authz.md
+++ /dev/null
@@ -1,235 +0,0 @@
-### Configuring Your Application
-
-## Add New Dependencies
-
-For this quickstart tutorial, our examples will use the Jade templating engine, although this is not a requirement. It is assumed that your NodeJS project has dependencies such as Jade, Express, etc. already installed, so we won't cover those. We will focus on the steps necessary to take your existing NodeJS Express app and enable Auth0's API Authorization features with it using the [auth0.js library](/libraries/auth0js).
-
-Run the following commands to install the required dependencies:
-
-```bash
-# Authentication middleware
-npm install passport --save
-
-# Auth0 strategy for Passport.js
-npm install passport-auth0 --save
-
-# Simple helper middleware to ensure the user is authenticated
-npm install connect-ensure-login --save
-
-# Session middleware for Express
-npm install express-session --save
-
-```
-
-## Passport Configuration
-
-First we need to require `express-session`, `passport` and `passport-auth0` in `app.js`.
-
-```js
-// app.js
-
-...
-
-var session = require('express-session');
-var passport = require('passport');
-var Auth0Strategy = require('passport-auth0');
-
-...
-```
-
-Next we need to setup and configure Passport to use the Auth0 strategy.
-
-```js
-// app.js
-
-// Configure Passport to use Auth0
-var strategy = new Auth0Strategy({
-    domain:       process.env.AUTH0_DOMAIN,
-    clientID:     process.env.AUTH0_CLIENT_ID,
-    clientSecret: process.env.AUTH0_CLIENT_SECRET,
-    callbackURL:  process.env.AUTH0_CALLBACK_URL
-  }, function(accessToken, refreshToken, extraParams, profile, done) {
-    // accessToken is the token to call Auth0 API (not needed in the most cases)
-    // extraParams.id_token has the JSON Web Token
-    // profile has all the information from the user
-    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);
-});
-```
-
-## Configure the Middlewares
-
-Add the following middlewares to your app:
-
-```js
-// app.js
-
-...
-
-app.use(session({
-  secret: 'yourSessionSecret',
-  resave: true,
-  saveUninitialized: true
-}));
-app.use(passport.initialize());
-app.use(passport.session());
-
-...
-```
-
-Passport will automatically persist the session after the Auth0 authentication and authorization process is complete.
-
-## Add Route Handlers
-
-The route handlers will be created in the next step. In preparation for that, require `./routes/user` and `./routes/index` in `app.js`.
-
-```js
-// app.js
-
-...
-
-var routes = require('./routes/index');
-var user = require('./routes/user');
-
-...
-```
-
-## Authentication
-
-Using the [auth0.js library](/libraries/auth0js), you can initiate the login process and once the user is authenticated with the chosen provider, the useragent will perform a redirect to the URL specified in `AUTH0_CALLBACK_URL`. This URL will be picked up by Passport.js.
-
-We will need to add a few routes for the application, including: `/` `/logout'` `/callback` and `/user`. We will also need template files for `index` and `user`.
-
-```js
-// routes/index.js
-
-router.get('/', function(req, res, next) {
-  res.render('index', { title: 'NodeJS Quickstart Demo' });
-});
-
-// Perform session logout and redirect to homepage
-router.get('/logout', function(req, res){
-  req.logout();
-  res.redirect('/');
-});
-
-// Perform the final stage of authentication and redirect to '/user'
-router.get('/callback',
-  passport.authenticate('auth0', { failureRedirect: '/url-if-something-fails' }),
-  function(req, res) {
-    res.redirect(req.session.returnTo || '/user');
-  });
-```
-
-After the authetication is complete, the `user` page should be displayed. Add a new file called `routes/user.js`.
-
-```js
-// routes/user.js
-
-var express = require('express');
-var passport = require('passport');
-var ensureLoggedIn = require('connect-ensure-login').ensureLoggedIn();
-var router = express.Router();
-
-// Get the user profile
-router.get('/', ensureLoggedIn, function(req, res, next) {
-  res.render('user', { user: req.user });
-});
-
-module.exports = router;
-```
-
-We can now add some template files for these pages. Start with a base template called `layout.jade`. The CDN link to Auth0's JavaScript library can be placed here. Alternatively, may prefer to place this `script` tag in another layout which places it after the `head` of the page.
-
-```jade
-// views/layout.jade
-
-doctype html
-html
-  head
-    title= title
-    link(rel='stylesheet', href='/stylesheets/style.css')
-    script(src="https://cdn.auth0.com/w2/auth0-7.2.js")
-  body
-    block content
-```
-
-Next, create the `index` view. It is here where you will instantiate the Auth0 client and create a function that will initiate the authentication process when the Login button is clicked by the user.
-
-```jade
-// views/index.jade
-
-extends layout
-
-block content
-
-  h1= Welcome to my application
-  br
-  button(onclick="signIn()") Login
-
-  script.
-    // Construct an instance of the auth0 client
-    var auth0 = new Auth0({
-      domain:       '#{env.AUTH0_DOMAIN}',
-      clientID:    '#{env.AUTH0_CLIENT_ID}',
-      callbackURL: '#{env.AUTH0_CALLBACK_URL}',
-    });
-
-    // this function will be called when a user clicks the login button
-    function signIn() {
-      auth0.login({
-      responseType: 'id_token token',
-      scope: 'openid profile {API SCOPES}',
-      audience: '{API IDENTIFIER}'
-      });
-    }
-
-```
-
-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 may include one or more scopes (separated by a space) you defined in the Dashboard for your API, in addition to any of the standard [openid scopes](https://auth0.com/docs/scopes).
-
-In `views/user.jade` we simply display the user's nickname and profile picture.
-
-```jade
-extends layout
-
-block content
-  img(src="#{user.picture}")
-  h2 Welcome #{user.nickname}!
-  br
-  a(href='/logout') Logout
-```
-
-## Making an Authenticated API Call
-
-Use the `access_token` to invoke the Resource Server (API):
-
-```js
-// invoke API endpoint with authn header
-var options = {
-  url: 'https://my.api/todo',
-  headers: {
-    'Authorization': 'Bearer ' + req.user.extraParams.access_token
-  }
-};
-
-request(options, function(error, response, body) {
-  var info = JSON.parse(body);
-  res.json({jwt: info.jwt});
-});
-
-```
-
-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 Backend/API Quickstart documentation](https://auth0.com/quickstart/backend).
-.
-
diff --git a/articles/server-platforms/nodejs/_includes/_login.md b/articles/server-platforms/nodejs/_includes/_login.md
deleted file mode 100644
index 4e9200d318..0000000000
--- a/articles/server-platforms/nodejs/_includes/_login.md
+++ /dev/null
@@ -1,189 +0,0 @@
-## Add New Dependencies
-
-Run the following commands to install the required dependencies:
-
-```bash
-# Authentication middleware
-npm install passport --save
-
-# Auth0 strategy for Passport.js
-npm install passport-auth0 --save
-
-# Simple helper middleware to ensure the user is authenticated
-npm install connect-ensure-login --save
-```
-
-## Add Requires and Initialize Passport Configuration
-
-First, we need to require `passport` and `passport-auth0` in `app.js`.
-
-```js
-// app.js
-
-...
-
-var passport = require('passport');
-var Auth0Strategy = require('passport-auth0');
-
-...
-```
-
-Next, we need to set up and configure Passport to use the Auth0 strategy.
-
-```js
-// app.js
-
-// Configure Passport to use Auth0
-var strategy = new Auth0Strategy({
-    domain:       process.env.AUTH0_DOMAIN,
-    clientID:     process.env.AUTH0_CLIENT_ID,
-    clientSecret: process.env.AUTH0_CLIENT_SECRET,
-    callbackURL:  process.env.AUTH0_CALLBACK_URL || 'http://localhost:3000/callback'
-  }, function(accessToken, refreshToken, extraParams, profile, done) {
-    // accessToken is the token to call Auth0 API (not needed in the most cases)
-    // extraParams.id_token has the JSON Web Token
-    // profile has all the information from the user
-    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);
-});
-```
-
-## Configure the Middlewares
-
-Add the following middlewares to your app:
-
-```js
-// app.js
-
-...
-
-app.use(passport.initialize());
-app.use(passport.session());
-
-...
-```
-
-## Add Route Handlers
-
-The route handlers will be created in the next step. In preparation for that, require `./routes/user` in `app.js`.
-
-```js
-// app.js
-
-...
-
-var user = require('./routes/user');
-
-...
-```
-
-## Authenticate Using Lock
-
-Using Auth0's Lock widget is the simplest and most robust way of handling user logins. Client side, the `Auth0Lock` library will initiate the login process and once the user is authenticated with the chosen provider, the useragent will perform a redirect to the URL specified in `AUTH0_CALLBACK_URL`. This URL will be picked up by Passport.js.
-
-We will need to add a few routes for the application, including: `/login` `/logout'` `/callback` and `/user`. We will also need template files for `login` and `user`.
-
-```js
-// routes/index.js
-
-// Render the login template
-router.get('/login',
-  function(req, res){
-    res.render('login', { env: process.env });
-  });
-
-// Perform session logout and redirect to homepage
-router.get('/logout', function(req, res){
-  req.logout();
-  res.redirect('/');
-});
-
-// Perform the final stage of authentication and redirect to '/user'
-router.get('/callback',
-  passport.authenticate('auth0', { failureRedirect: '/url-if-something-fails' }),
-  function(req, res) {
-    res.redirect(req.session.returnTo || '/user');
-  });
-```
-
-After the authetication is complete, the `user` page should be displayed. Add a new file called `routes/user.js`.
-
-```js
-// routes/user.js
-
-var express = require('express');
-var passport = require('passport');
-var ensureLoggedIn = require('connect-ensure-login').ensureLoggedIn();
-var router = express.Router();
-
-// Get the user profile
-router.get('/', ensureLoggedIn, function(req, res, next) {
-  res.render('user', { user: req.user });
-});
-
-module.exports = router;
-```
-
-We can now add some template files for these pages. Start with a base template called `layout.jade`. The CDN link to Auth0's Lock widget can be placed here. Alternatively, may prefer to place this `script` tag in another layout which places it after the `head` of the page.
-
-```jade
-// views/layout.jade
-
-doctype html
-html
-  head
-    title= title
-    link(rel='stylesheet', href='/stylesheets/style.css')
-    script(src="${lock_url}")
-  body
-    block content
-```
-
-Next, create the `login` view.
-
-```jade
-// views/login.jade
-
-extends layout
-
-block content
-
-  div(id="root" style="width: 280px; margin: 40px auto; padding: 10px;")
-
-  script.
-    // Construct an instance of Auth0Lock with your clientId and aut0 domain name
-    var lock = new Auth0Lock('#{env.AUTH0_CLIENT_ID}', '#{env.AUTH0_DOMAIN}',{ auth: {
-          redirectUrl: '#{env.AUTH0_CALLBACK_URL}'
-        , responseType: 'code'
-        , params: {
-          scope: 'openid name email picture'
-        }
-      }});
-
-    // Show lock's login widget
-    lock.show();
-```
-
-**Note:** Please note that the `redirectUrl` specified in the `Auth0Lock` constructor **must match** the URL for the callback route.
-
-In `views/user.jade` we simply display the user's nickname and profile picture.
-
-```jade
-extends layout
-
-block content
-  img(src="#{user.picture}")
-  h2 Welcome #{user.nickname}!
-  br
-  a(href='/logout') Logout
-```
diff --git a/articles/server-platforms/nodejs/_includes/_new_regular_webapp_client.html b/articles/server-platforms/nodejs/_includes/_new_regular_webapp_client.html
deleted file mode 100644
index 59e03f1ef2..0000000000
--- a/articles/server-platforms/nodejs/_includes/_new_regular_webapp_client.html
+++ /dev/null
@@ -1,5 +0,0 @@
-<% if (account.userName) { %>
-  
        Get your credentials (Domain, Client ID, and Client Secret) from the dashboard. Be sure to select Regular Web Application as the Client Type.
-<% } else { %>
-  
        Create an Auth0 account (or login) and add an authentication client instance from the dashboard. Once you create your client, 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 Regular Web Application as the Client Type.
-<% } %>
diff --git a/articles/server-platforms/nodejs/_includes/_setup.md b/articles/server-platforms/nodejs/_includes/_setup.md
deleted file mode 100644
index 881c1d09b0..0000000000
--- a/articles/server-platforms/nodejs/_includes/_setup.md
+++ /dev/null
@@ -1,40 +0,0 @@
-<%= include('../../../_includes/_callback_url') %>
-
-## Structure
-
-The sample projects which accompany each of these steps will have the following directory structure:
-
-```bash
-├── app.js
-├── bin
-│   └── www
-├── package.json
-├── public
-│   └── stylesheets
-│       └── style.css
-├── README.md
-├── routes
-│   ├── index.js
-│   └── ...
-└── views
-    ├── index.jade
-    └── ...
-```
-
-## Dependencies
-
-All the project dependencies are managed by `npm` and listed in the `package.json` file for each of the samples.
-
-Run the following command to install the required packages.
-
-```bash
-npm install
-```
-
-Auth0's Lock widget and `auth0.js` library are used throughout these quickstarts. These scripts can be obtained from the following CDN links:
-
-**Lock**
-``
-
-**auth0.js**
-``
diff --git a/articles/server-platforms/nodejs/dashboard-default.md b/articles/server-platforms/nodejs/dashboard-default.md
deleted file mode 100644
index 9cb2abbf78..0000000000
--- a/articles/server-platforms/nodejs/dashboard-default.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to add authentication to a Node.js and Express web app
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-nodejs-webapp-sample',
-  path: '01-Login',
-  requirements: [
-    'NodeJS 4.3 or superior',
-    'Express 4.11'
-  ]
-}) %>
-
-<%= include('_includes/_setup') %>
-
-<%= include('_includes/_login') %>
\ No newline at end of file
diff --git a/articles/server-platforms/nodejs/index.yml b/articles/server-platforms/nodejs/index.yml
deleted file mode 100644
index 85baa7d216..0000000000
--- a/articles/server-platforms/nodejs/index.yml
+++ /dev/null
@@ -1,25 +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: dashboard-default
-articles:
-  - 00-intro
-  - 01-login
-  - 02-login-custom
-  - 04-user-profile
-  - 05-linking-accounts
-  - 06-rules
-  - 07-authorization
-  - 09-mfa
-  - 10-customizing-lock
\ No newline at end of file
diff --git a/articles/server-platforms/php/01-login.md b/articles/server-platforms/php/01-login.md
deleted file mode 100644
index 74ec3a23e3..0000000000
--- a/articles/server-platforms/php/01-login.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to use the Auth0 PHP SDK to add authentication and authorization to your web app
-budicon: 448
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-php-web-app',
-  path: '00-Starter-Seed/basic-webapp',
-  requirements: [
-    'Apache 2.4.4',
-    'PHP 5.6.14 and up'
-  ]
-}) %>
-
-## Add the Dependencies
-
-${snippet(meta.snippets.dependencies)}
-
-> 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 and it will install them in your project for you.
-
-## Configure Auth0 PHP Plugin
-
-```php
-use Auth0\SDK\Auth0;
-
-$auth0 = new Auth0(array(
-    'domain'        => '${account.namespace}',
-    'client_id'     => '${account.clientId}',
-    'client_secret' => '${account.clientSecret}',
-    'redirect_uri'  => '${account.callback}'
-));
-```
-
-## Add Auth0 Callback Handler
-
-Now, we can call `$auth0->getUser()` to retrieve the user information. If we call it from the page that will handle the callback, then it'll use the `code` provided by Auth0 to get the information after the successful login.
-
-```php
-// callback.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
-}
-```
-
-Once the user info is fetched, it'll be stored in the session. Therefore, from this moment on, each time you call `getUser()` it will retrieve the information from the Session.
-
-${include('../_callbackRegularWebApp')}
-
-In this case, the redirectUrl should look something like:
-
-```
-http://yourUrl/callback.php
-```
-
-## Triggering Login Manually or Integrating Lock
-
-<%= include('../../_includes/_lock-sdk') %>
-
-> **Note:** Please note that the `redirectUrl` specified in the `Auth0Lock` constructor **must match** the one specified in the previous step
-
-## Accessing User Information
-
-You can access the user information via the `getUser` method from Auth0
-
-```php
-getUser();
-?>
-
-  
-    
        
-  
-
-```
-
-You can [click here](/user-profile) to find out all of the available properties from the user's profile. Please note that some of these depend on the social provider being used.
-
-### Optional steps
-
-#### Configure session data
-
-By default, the SDK will store the user information in the PHP Session and it will discard the access token and the id token. If you like to persist them as well, you can pass `'persist_access_token' => true` and `'persist_id_token' => true` to the SDK configuration in step 2. You can also disable session altogether by passing `'store' => false`.
-
-If you want to change PHP Session and use Laravel, Zend, Symfony or other abstraction to the session, you can create a class that implements get, set, delete and pass it to the SDK as following.
-
-```php
-$laravelStore = new MyLaravelStore();
-$auth0 = new Auth0(array(
-    // ...
-    'store' => $laravelStore,
-    // ...
-));
-```
diff --git a/articles/server-platforms/php/index.yml b/articles/server-platforms/php/index.yml
deleted file mode 100644
index d3477da97b..0000000000
--- a/articles/server-platforms/php/index.yml
+++ /dev/null
@@ -1,12 +0,0 @@
-title: PHP
-image: /media/platforms/php.png
-tags:
-  - quickstart
-snippets:
-  dependencies: server-platforms/php/dependencies
-  setup: server-platforms/php/setup
-  use: server-platforms/php/use
-seo_alias: php
-default_article: 01-login
-articles:
-  - 01-login
diff --git a/articles/server-platforms/python/01-login.md b/articles/server-platforms/python/01-login.md
deleted file mode 100644
index 9a770a41a7..0000000000
--- a/articles/server-platforms/python/01-login.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: Login
-default: true
-description: This tutorial demonstrates how to use the Auth0 Python SDK to add authentication and authorization to your web app
-budicon: 448
----
-
-You can get started by either downloading the seed project or if you would like to add Auth0 to an existing application you can follow the tutorial steps.
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-python-web-app',
-  path: '00-Starter-Seed',
-  requirements: [
-    'Python 2.7, 3.5.1',
-    'Flask 0.10.1 and up',
-    'Requests 2.3.0 and up'
-  ]
-}) %>
-
-## 1. Add the Dependencies
-
-${snippet(meta.snippets.dependencies)}
-
-This example uses `flask` but it could work with any server
-
-## 2. 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:
-
-${snippet(meta.snippets.setup)}
-
-## 3. Specify the Callback URLs
-
-${include('../_callbackRegularWebApp')}
-
-In this case, the callbackURL should look something like:
-
-```
-http://yourUrl/callback
-```
-
-## 4. Trigger Login Manually or Integrate Lock
-
-<%= include('../../_includes/_lock-sdk') %>
-
-> **Note:** Please note that the `redirectUrl` specified in the `Auth0Lock` constructor **must match** the URL specified in the previous step
-
-## 5. Access User Information
-
-You can access the user information via the `profile` you stored in the session on step 2
-
-```python
-@app.route("/dashboard")
-@requires_auth
-def dashboard():
-    return render_template('dashboard.html', user=session['profile'])
-
-```
-
-```html
-
        
-  
-  
        Welcome {{user['nickname']}}
        
-
        
-```
-
-[Click here](/user-profile) to check all the information that the userinfo hash has.
-
-### 6. Optional steps
-
-#### Check if the user is authenticated
-
-You can add the following annotation to your `Flask` app to check if the user is authenticated. Note that you should import `wraps` first, adding the following line to your file `from functools import wraps`.
-
-```python
-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
-```
diff --git a/articles/server-platforms/python/index.yml b/articles/server-platforms/python/index.yml
deleted file mode 100644
index a6392a6958..0000000000
--- a/articles/server-platforms/python/index.yml
+++ /dev/null
@@ -1,12 +0,0 @@
-title: Python
-image: /media/platforms/python.png
-tags:
-  - 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
diff --git a/articles/server-platforms/rails/00-introduction.md b/articles/server-platforms/rails/00-introduction.md
deleted file mode 100644
index 1086d80b21..0000000000
--- a/articles/server-platforms/rails/00-introduction.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: Introduction
-description: This tutorial demonstrates how to integrate Auth0 in a Ruby on Rails app to add authentication and authorization
-budicon: 448
----
-
-This multistep quickstart guide will walk you through managing authentication in your Ruby on Rails apps with Auth0.
-
-## Seed and Samples
-
-To follow along with this quickstart you can either download the [seed project](https://github.com/auth0-samples/auth0-rubyonrails-sample/tree/master/00-Starter-Seed) or the [samples](https://github.com/auth0-samples/auth0-rubyonrails-sample) provided at each page of this quickstart.
-
-The seed is a regular RoR app, with all the Auth0 dependencies set, but nothing more. It's an empty canvas meant to be filled as you follow the steps of this quickstart. If you prefer this option download the seed from our [GitHub repository](https://github.com/auth0-samples/auth0-rubyonrails-sample/tree/master/00-Starter-Seed) and follow along.
-
-You can also follow the samples that are included in each step. Each sample uses the seed project as a starting point and applies each step configuration to it, so, for example, the Login sample would be the seed project plus the login configuration. If you choose to follow this approach continue reading, the rest of this document will guide you through setting up the required prerequisites.
-
-## Create a Client
-
-Create a new client 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 your default app credentials.
-
-![App Dashboard](/media/articles/server-platforms/rails/app_dashboard.png)
-
-<%= include('../../_includes/_callback_url') %>
-
-${include('../_callbackRegularWebApp')}
-
-In this case, the callbackURL should look something like:
-
-```bash
-https://example.com/auth/oauth2/callback
-```
-
-### 3. Structure
-The project structure follows the regular Ruby on Rails application structure. The tree below displays the location of the most referred files in the quickstart.
-
-```bash
-├── app
-│   ├── assets
-│   │   └── javascripts
-│   │       └──home.js.erb
-│   ├── controllers
-│   │   └── concerns
-│   │   |   └── secured.rb
-│   │   └── home_controller.rb
-│   │   └── dashboard_controller.rb
-│   │   └── auth0_controller.rb
-│   └── views
-│       └── auth0
-│       │   └── failure.html.rb
-│       └── dashboard
-│       │   └── show.html.rb
-│       └── home
-│           └── show.html.rb
-└── config
-│    └── initializers
-│    │   └── auth0.rb
-│    └── routes.rb
-│    └── secrets.yml
-└── .env
-```
-
-## Dependencies
-
-To follow along with the integration steps, add the following dependencies to your `Gemfile` and run `bundle install`
-
-${snippet(meta.snippets.dependencies)}
diff --git a/articles/server-platforms/rails/01-login.md b/articles/server-platforms/rails/01-login.md
deleted file mode 100644
index 9df94e6c63..0000000000
--- a/articles/server-platforms/rails/01-login.md
+++ /dev/null
@@ -1,182 +0,0 @@
----
-title: Login
-description: Learn how to login using the Auth0 Lock widget and OmniAuth.
-budicon: 448
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-rubyonrails-sample',
-  path: '01-Login',
-  requirements: [
-    'Ruby 2.3.1',
-    'Rails 5.0.0'
-  ]
-}) %>
-
-The easiest way to add authentication to your Rails application is to use Auth0's [Lock widget](/lock) and OmniAuth authentication [strategy](https://github.com/auth0/omniauth-auth0).
-
-## Initialize Omniauth Auth0
-
-Create a file named `auth0.rb` under `config/initializers` with the following content:
-
-${snippet(meta.snippets.setup)}
-
-> **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
-
-Use the following command to create the controller that will handle the Auth0 callback:
-
-```bash
-rails generate controller auth0 callback failure --skip-template-engine --skip-assets
-```
-
-In the newly created controller, add a callback success and failure handler.
-
-```ruby
-class Auth0Controller < ApplicationController
-  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
-
-  def failure
-    # show a failure page or redirect to an error page
-    @error_msg = request.params['message']
-  end
-end
-```
-
-Replace the generated routes on `routes.rb` with the following:
-
-```ruby
-get "/auth/oauth2/callback" => "auth0#callback"
-get "/auth/failure" => "auth0#failure"
-```
-
-## Trigger Login with Lock
-
-<%= include('../../_includes/_lock-sdk') %>
-
-> **NOTE:** The `callbackURL` specified in the `Auth0Lock` constructor **must match** the one specified in the **Allowed Callback URLs** area in your Auth0 dashboard. Follow the [introduction](/quickstart/webapp/rails/00-introduction) step for further detail.
-
-If you wish to force an identity provider, you may redirect the user and specify the connection name in the query string.
-
-```ruby
-redirect_to '/auth/oauth2?connection=CONNECTION_NAME'
-```
-
-> [Click here](https://github.com/intridea/omniauth/wiki/Auth-Hash-Schema) to check all the information that the userinfo hash has.
-
-## Check the User's Authentication Status 
-
-You can use a controller concern to control access to routes that require the user to be authenticated.
-
-```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
-```
-
-Include the concern in the corresponding controller to prevent unauthenticated users from accessing its routes:
-
-```ruby
-class DashboardController < ApplicationController
- include Secured
-
-  def show
-  end
-end
-```
-
-## Display Error Descriptions
-
-Configuration the application to display erros 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/enviroments/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:
-
-```
-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.
\ No newline at end of file
diff --git a/articles/server-platforms/rails/02-custom-login.md b/articles/server-platforms/rails/02-custom-login.md
deleted file mode 100644
index 34d845bd9e..0000000000
--- a/articles/server-platforms/rails/02-custom-login.md
+++ /dev/null
@@ -1,223 +0,0 @@
----
-title: Custom Login
-description: Learn how to login using the Authentication API SDK instead of OmniAuth.
-budicon: 448
----
-
-The [login](/quickstart/webapp/rails/01-login) step explains how to log a user in using Lock and OmniAuth. You may also want to design your own custom user interface for authentication. In this step, you'll learn how to create a custom login form using the Auth0 Ruby SDK.
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-rubyonrails-sample',
-  path: '02-Custom-Login',
-  requirements: [
-    'Ruby 2.3.1',
-    'Rails 5.0.0'
-  ]
-}) %>
-
-## Add the Dependencies
-
-Add the following dependencies to your `Gemfile` and run `bundle install`:
-
-${snippet(meta.snippets.dependencies)}
-
-## Create a Login Form
-
-**NOTE**: `home` is not a mandatory name for the view / controller.
-
-```ruby
-
        
-  ${ '<%= form_tag do %>' }
-      ${ '<%= text_field_tag :user, "", class:"form-control" %>' }
-      
        
-      ${ '<%= password_field_tag :password, "", class:"form-control"%>' }
        
-      
        
-      ${ '<%= submit_tag("Login", class: "btn btn-success btn-lg") %>' }
-      ${ '<%= submit_tag("Sign up", name: "signup", class:"btn btn-success btn-lg") %>' }
-  ${' <% end %> '}
-  ${ '<%= link_to "Login with Google" , controller: :auth0, action: :google_authorize %>' }
-
        
-```
-
-Add the following to your `config/routes.rb` file in order for the form to post its contents to the auth action of the home controller:
-
-```ruby
-post "/" => "auth0#callback"
-```
-
-## Create an Auth Action
-
-Add the following actions in the `auth0` controller:
-
-```ruby
-def callback
-  if params[:user]
-    signup if params[:signup]
-    session[:token_id] = login
-  else
-    session[:token_id] = google_login
-  end
-  redirect_to '/dashboard'
-  rescue Auth0::Unauthorized
-    redirect_to '/', notice: 'Invalid email or password'
-  rescue => ex
-    redirect_to '/', notice: ex.message
-end
-```
-The `callback` controller action calls the `signup` or `login` actions based on the `params` hash. Upon successful execution, it redirects to `/dashboard`. In case of an exception, it redirects to `/` and flashes the exception message.
-
-Next, add the definitions for the `login` and `signup` actions under `private`:
-
-```ruby
-def login
-  auth0_client.login(
-    params[:user],
-    params[:password],
-    authParams: {
-      scope: 'openid name email'
-    },
-    connection: 'Username-Password-Authentication'
-  )
-end
-
-def signup
-  auth0_client.signup(
-    params[:user],
-    params[:password]
-  )
-end
-```
-
-## Add an SDK Client Instance in the Application Controller
-
-To call the API methods using the Auth0 Ruby SDK, you need to initialize an auth0 client instance. Add the following code in your Application Controller (`controllers/application_controller.rb`):
-
-```ruby
-def auth0_client
-  creds = { client_id: Rails.application.secrets.auth0_client_id,
-            client_secret: Rails.application.secrets.auth0_client_secret,
-            api_version: 1,
-            domain: Rails.application.secrets.auth0_domain }
-  @auth0_client ||= Auth0Client.new(creds)
-end
-```
-
-## Checking if the User is Authenticated
-
-In [Login](/quickstart/webapp/rails/01-login) describes how to prevent users from executing restricted actions with a `before_action` concern. You will use the same strategy now, but the code will change slightly.
-
-Create a `Secured` controller concern with the code below:
-
-```ruby
-module Secured
-  extend ActiveSupport::Concern
-
-  included do
-    before_action :logged_in?
-  end
-
-  def logged_in?
-    redirect_to '/' unless session[:token_id].present?
-  end
-end
-```
-
-Then, update the `DashboardController` so that it includes this concern:
-
-```ruby
-class DashboardController < ApplicationController
-  include Secured
-  def show
-  end
-end
-```
-
-This way, if a user attempts to access the routes governed by the `DashboardController` actions, it will be redirected to `/`.
-
-## Login with Google
-
-For your users to login using a Social Connection without using neither Lock nor OmniAuth, follow these steps:
-
-**NOTE**: Social connections support only browser based (passive) authentication. This is because most of these providers don't allow entering the user/password in applications that don't belong to them, so the user gets redirected to the provider (e.g. Google sign in page). Three steps take place in this process: initiation, authentication, and getting the access token. You'll begin the authentication flow, Auth0 will take care of the Authentication, and then you'll obtain the access and id token for the user (*to learn more about this process go to: [Authentication API](/api/authentication#!%23get--authorize_social) and [OAuth Server Side](/protocols#oauth-server-side) documents*).
-
-For this particular example, you'll configure Google as your social provider. The API methods called by the API also support Facebook, Twitter and Weibo.
-
-**Prerequisite**: configure your Google Social Connection by following [this tutorial](/connections/social/google).
-
-To begin the authentication flow, you'll need to generate a redirect to the social provider. To do so, create the `google_authorize method` in the `Auth0Controller`:
-
-```ruby
-def google_authorize
-  redirect_to client.authorization_url(
-    Rails.application.secrets.auth0_callback_url,
-    connection: 'google-oauth2',
-    scope: 'openid'
-  ).to_s
-end
-```
-
-Next, add the actual link to the controller action in the home view:
-
-```ruby
-${ '<%= link_to "Login with Google" , controller: :auth0, action: :google_authorize %>' }
-```
-And the corresponding route in the `routes` file:
-
-```ruby
-get 'auth0/google_authorize' => 'auth0#google_authorize'
-```
-
-The authentication will be handled by Auth0. The user is redirected to the identity provider site. When this process finishes, a request is made to the callback URL and handled by the application. You'll need to extract the access_code and get the access and id tokens posting a request to the Auth0 token endpoint using the SDK.
-
-Add the following method to the `Auth0Controller`:
-
-```ruby
-def google_login
-  client.obtain_user_tokens(params['code'], Rails.application.secrets.auth0_callback_url, 'google-oauth2', 'openid')['id_token']
-end
-```
-
-And call this method from the controller `callback` action.
-
-**NOTE**: this logic is only necessary if you're mixing the login form from the first section of the tutorial and social authentication. Otherwise, you can call `google_login` straight from the `callback` action.
-
-```ruby
-def callback
-  begin
-    if params[:user]
-      if params[:signup]
-        signup
-      end
-      session[:token_id] = login
-    else
-      session[:token_id] = google_login
-    end
-    redirect_to '/dashboard'
-  rescue Auth0::Unauthorized
-    redirect_to '/', notice: 'Invalid email or password'
-  rescue => ex
-    redirect_to '/', notice: ex.message
-  end
-end
-```
-
-## Additional Considerations
-
-For the sake of simplicity, this sample does not go into details such as creating a user model and combining a custom login and the Lock widget. [OmniAuth documentation](https://github.com/intridea/omniauth#integrating-omniauth-into-your-application) suggests using a `SessionsController`, such as the one displayed below. Combining authentication mechanisms could be achieved by having several User model creation methods.
-
-```ruby
-class SessionsController < ApplicationController
-  def create
-    @user = User.find_or_create_from_auth_hash(auth_hash)
-    self.current_user = @user
-    redirect_to '/'
-  end
-
-  protected
-
-  def auth_hash
-    request.env['omniauth.auth']
-  end
-end
-```
diff --git a/articles/server-platforms/rails/03-session-handling.md b/articles/server-platforms/rails/03-session-handling.md
deleted file mode 100644
index 796f79c46a..0000000000
--- a/articles/server-platforms/rails/03-session-handling.md
+++ /dev/null
@@ -1,69 +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: '03-Session-Handling',
-  requirements: [
-    'Ruby 2.3.1',
-    'Rails 5.0.0'
-  ]
-}) %>
-
-## Store Session Data on Login
-
-Upon successful authentication, OmniAuth-Auth0 sets a special hash called 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"
-```
-
-And store the user information in the session adding the following code to the `auth0_controller\callback` method:
-
-```ruby
-  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
-
-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).
-
-A typical logout action would look like this:
-
-```ruby
-class LogoutController < ApplicationController
-  include LogoutHelper
-  def logout
-    reset_session
-    redirect_to logout_url.to_s
-  end
-end
-```
-
-You can take advantage of the SDK for generating the logout URL.
-
-```ruby
-module LogoutHelper
-  def logout_url
-    creds = { client_id: ENV['AUTH0_CLIENT_ID'],
-    client_secret: ENV['AUTH0_CLIENT_SECRET'],
-    api_version: 1,
-    domain: ENV['AUTH0_DOMAIN'] }
-    auth0_client = Auth0Client.new(creds)
-    auth0_client.logout_url(root_url)
-  end
-end
-```
-
-**NOTE**: The final destination URL (the `returnTo` value) needs to be in the list of `Allowed Logout URLs`. [Read more about this](/logout#redirecting-users-after-logout).
diff --git a/articles/server-platforms/rails/04-user-profile.md b/articles/server-platforms/rails/04-user-profile.md
deleted file mode 100644
index b4954c984c..0000000000
--- a/articles/server-platforms/rails/04-user-profile.md
+++ /dev/null
@@ -1,87 +0,0 @@
----
-title: User Profile
-description: Access the user profile information using OmniAuth-Auth0 strategy.
-budicon: 448
----
-
-The [login](/quickstart/webapp/rails/01-login) step explains how to log users in using the Lock widget and a gem called [OmniAuth](https://github.com/intridea/omniauth) (and a specific Auth0 strategy for OmniAuth). In this step, you'll learn how to access the user profile data once the user has logged into the application.
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-rubyonrails-sample',
-  path: '04-User-Profile',
-  requirements: [
-    'Ruby 2.3.1',
-    'Rails 5.0.0'
-  ]
-}) %>
-
-## The OmniAuth Auth Hash
-
-Using Auth0's OmniAuth strategy, you only need to redirect users to `/auth/oauth2` (which you did in [Login](/quickstart/webapp/rails/01-login)). From there, OmniAuth will take over and take the user through the necessary steps to authenticate them with the Auth0 strategy.
-
-After receiving a successful callback at /auth/oauth2/callback, OmniAuth provides the 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).
-
-## Add the Dependencies
-
-Add the following dependencies to your `Gemfile` and run `bundle install`:
-
-${snippet(meta.snippets.dependencies)}
-
-## Retrieve the Auth Hash
-
-In the [login](/quickstart/webapp/rails/01-login) step, you configured the application for Lock to start the OmniAuth 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
-session[:userinfo] = request.env['omniauth.auth']
-
-redirect_to '/dashboard'
-```
-
-## 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 as the full user profile data may vary depending on several factors, such as the user's identity provider and its linked profile, among others.
-
-Add the following lines in the dashboard view in order to retrieve the user profile data:
-
-```ruby
-
        
-  
        
-  
        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
-class DashboardController < ApplicationController
-  include Secured
-  def show
-    @user = session[:userinfo]
-  end
-end
-```
diff --git a/articles/server-platforms/rails/05-linking-accounts.md b/articles/server-platforms/rails/05-linking-accounts.md
deleted file mode 100644
index c5f7f710e2..0000000000
--- a/articles/server-platforms/rails/05-linking-accounts.md
+++ /dev/null
@@ -1,213 +0,0 @@
----
-title: Linking Accounts
-description: Link and Unlink accounts from other identity providers using the Rails SDK.
-budicon: 448
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-rubyonrails-sample',
-  path: '05-Linking-Accounts',
-  requirements: [
-    'Ruby 2.3.1',
-    'Rails 5.0.0'
-  ]
-}) %>
-
-In this tutorial you'll learn how to use the Auth0 Rails SDK to link user accounts from different identity providers, allowing a user to authenticate from any of their accounts and still be recognized by your app and associated with the same user profile.
-
-The sample application allows the users to log in with an initial provider, and provides a form that enables them to link another account using Auth0 Lock. Click [here](/link-accounts) to learn more about account linking.
-
-## Add Dependencies
-
-Add the following dependencies to your `Gemfile` and run `bundle install`
-
-${snippet(meta.snippets.dependencies)}
-
-## Handling the Second Authentication with Lock
-
-In the [login](/quickstart/webapp/rails/01-login) step, you created a JavaScript function to handle authentication with Lock. The same pattern can be used to trigger the second authentication.
-
-Add the following method to `/app/assets/javascripts/home.js.rb`:
-
-```js
-function linkPasswordAccount() {
-  connection = $("#link_provider").val();
-  var linkOptions = {
-    auth: {
-      redirectUrl: '${ "<%= Rails.application.secrets.auth0_callback_url %>" }',
-      allowLogin: true
-    },
-    languageDictionary: {
-      title: 'Link another account'
-    }
-  }
-
-  if (connection) {
-    linkOptions.allowedConnections = [connection];
-  }
-  
-  var linkLock = new Auth0Lock('${ "<%= Rails.application.secrets.auth0_client_id %>" }', '${ "<%= Rails.application.secrets.auth0_domain %>" }', linkOptions);
-  
-  //open lock in signin mode, with the customized options for linking
-  linkLock.show();
-}
-```
-
-## Create the Settings View
-
-This view will contain two forms for linking and unlinking accounts, respectively.
-- The first form will show a submit button that, when clicked, will launch Lock allowing the user to login to a second account. Upon successful authentication, the `Auth0Controller` `callback` action will process the account linking using the SDK.
-- The second form will have a dropdown listing the user providers, and a submit button. Upon clicking the button, the `SettingsController` `unlink_provider` action will use the SDK to unlink the selected account.
-
-To create the linking form, add the following markup to the settings view:
-
-```ruby
-<%= "\<%= form_tag({ action: 'link_provider' },{ class: 'form-horizontal col-xs-10 col-xs-offset-1' }) do %\>" %>
-  
        
-    
-    
        
-      ${" <%= select_tag(:link_provider, options_for_select(@providers), class: 'form-control') %> "}
-    
        
-  
        
-  
        
-    
        
-      Link Accounts
-    
        
-  
        
-${ "<% end %>" }
-```
-
-To create the second form, add the following code to the settings view:
-
-```ruby
-<%= "\<%= form_tag({ action: 'unlink_provider', method: 'post' },{ class: 'form-horizontal col-xs-10 col-xs-offset-1' }) do %\>" %>
-  
        
-    
-    
        
-      ${" <%= select_tag(:unlink_provider, options_for_select(@unlink_providers), class: 'form-control') %> "}
-    
        
-  
        
-  
        
-    
        
-      ${" <%= button_tag(type: 'submit', class: 'btn btn-danger btn-lg') do %> "}
-        Unlink Accounts
-      ${" <% end %> "}
-    
        
-  
        
-${" <% end %> "}
-```
-
-## Create the Settings Controller
-
-Create the `show` action that will continue to retrieve the user information as in the previous steps, but additionally it will collect the list of the current user's identity providers into the `providers` hash:
-
-```ruby
-def show
-  @user = session[:userinfo]
-  @unlink_providers = unlink_providers.keys - [user[:provider]]
-  @providers = link_providers - @unlink_providers - [user[:provider]]
-end
-```
-
-Next, create the `link_provider` and `unlink_provider` actions
-- `link_provider` will obtain the second identity from the `linkuserinfo` session hash and call the `link_user_account` method of the ruby SDK. Upon successful linkage, it will redirect the user back to the settings page, flashing a success notice.
-
-```ruby
-    @user = session[:userinfo]
-    link_user = session[:linkuserinfo]
-    ClientHelper.auth0_client(user).link_user_account(user['uid'], link_with: link_user[:credentials][:id_token])
-    redirect_to '/settings', notice: 'Provider succesfully linked.'
-  end
-```
-
-- `unlink_provider` will obtain the main identity from the `userinfo` session hash and call the `unlink_users_account` method of the ruby SDK, passing the selected provider as a parameter. Then, it will redirect the user back to the settings page, flashing the corresponding notice.
-
-```ruby
-def unlink_provider
-  @user = session[:userinfo]
-  unlink_user_id = unlink_providers[params['unlink_provider']]
-  ClientHelper.auth0_client(user).unlink_users_account(user['uid'], params['unlink_provider'], unlink_user_id)
-  redirect_to '/settings', notice: 'Provider succesfully unlinked.'
-end
-```
-Add the `unlink_providers` private method, which will build a hash of the user identities in the different providers.
-
-```ruby
-def unlink_providers
-  user_info = ClientHelper.auth0_client_user(user).user_info
-  Hash[user_info['identities'].collect { |identity| [identity['provider'], identity['user_id']] }]
-end
-```
-
-And finally, create the private `link_providers` method, which retrieves the providers enabled for the client.
-
-```ruby
-def link_providers
-  connections = ClientHelper.auth0_client_admin.connections
-  connections.map do |connection|
-    connection['strategy'] if connection['enabled_clients'].include?(ENV['AUTH0_CLIENT_ID'])
-  end.compact
-end
-```
-> You can read more about the OmniAuth Auth0 custom strategy and the authentication hash [here](https://github.com/auth0/omniauth-auth0#auth-hash).
-
-## Update the Auth0Controller
-
-You need to update the `callback` action in this controller to handle the second authentication / account linking.
-
-```ruby
-class Auth0Controller < ApplicationController
-  def callback
-    unless session[:userinfo].present?
-      session[:userinfo] = request.env['omniauth.auth']
-      redirect_to '/dashboard'
-      return
-    end
-    session[:linkuserinfo] = request.env['omniauth.auth']
-    redirect_to '/settings/link_provider'
-  end
-```
-
-## Update the DashboardController to Reflect Profile Updates
-
-Since linking and unlinking accounts will change the user profile, you will need to change the `DashboardController` slightly so that it retrieves the user profile using the SDK upon page refresh:
-
-```ruby
-include ClientHelper
-def show
-  @user = ClientHelper.auth0_client_user(session[:userinfo]).user_info
-end
-```
-
-## Update the ClientHelper
-
-Last, but not least, add the following methods to `helpers\client_helper`. It will allow you to call the Authentication SDK with different credentials:
-
-```ruby
-def self.auth0_client_user(user)
-  creds = { client_id: Rails.application.secrets.auth0_client_id,
-            token: user[:credentials][:token],
-            api_version: 2,
-            domain: Rails.application.secrets.auth0_domain }
-
-  Auth0Client.new(creds)
-end
-
-def self.auth0_client(user)
-  creds = { client_id: Rails.application.secrets.auth0_client_id,
-            token: user[:credentials][:id_token],
-            api_version: 2,
-            domain: Rails.application.secrets.auth0_domain }
-
-  Auth0Client.new(creds)
-end
-
-def self.auth0_client_admin
-  creds = { client_id: Rails.application.secrets.auth0_client_id,
-            token: Rails.application.secrets.auth0_master_jwt,
-            api_version: 2,
-            domain: Rails.application.secrets.auth0_domain }
-  Auth0Client.new(creds)
-end
-```
diff --git a/articles/server-platforms/rails/06-rules.md b/articles/server-platforms/rails/06-rules.md
deleted file mode 100644
index 3c705545b0..0000000000
--- a/articles/server-platforms/rails/06-rules.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-title: Rules
-description: This tutorial will show you how to use Auth0 rules to extend what Auth0 has to offer.
-budicon: 448
----
-
-<%= include('../_includes/_rules-introduction') %>
-
-## Create a Rule
-
-<%= include('../_includes/_rules-create-section') %>
-
-## Test Rule Result
-
-![Country rule sample](/media/articles/server-platforms/rails/rule_country_preview.png)
-
-**NOTE**: No additional code is required, as the new property will be included in the full user profile.
-
-After the rule executes, the output that the application will receive for the full user profile is the following user object:
-
-```bash
-{
-  "email": "test@test.com",
-  "nickname": "test",
-  "user_id": "auth0|575acb630e8da29012778689",
-  //...
-  "country": "Argentina"  // NEW PROPERTY ADDED BY THE RULE
-}
-```
-
-This is just one of the tons of cool things we can do with rules. Go ahead and create any rule that fits your needs.
diff --git a/articles/server-platforms/rails/07-authorization.md b/articles/server-platforms/rails/07-authorization.md
deleted file mode 100644
index 5903bc344d..0000000000
--- a/articles/server-platforms/rails/07-authorization.md
+++ /dev/null
@@ -1,77 +0,0 @@
----
-title: Authorization
-description: Learn how to assign roles to your users, and use those claims to authorize or deny a user to access certain portions of the app.
-budicon: 448
----
-
-Authentication tells your application to trust a user, granting him or her access to it. But that might not be enough. Most times, you will need to grant or restrict users from accessing specific parts of your application based on a number of attributes (commonly named "claims", being their "role", "department", or "country" a few examples). In this section, you'll learn how to assign a "role" claim to your users, and use those claims to authorize them to access an "admin" page.
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-rubyonrails-sample',
-  path: '07-Authorization',
-  requirements: [
-    'Ruby 2.3.1',
-    'Rails 5.0.0'
-  ]
-}) %>
-
-## Create a Rule to Assign Roles
-
-<%= include('../_includes/_authorization-introduction', { ruleslink: '/quickstart/webapp/rails/06-rules' }) %>
-
-## Add Dependencies
-
-Add the following dependencies to your `Gemfile` and run `bundle install`:
-
-${snippet(meta.snippets.dependencies)}
-
-## Create the Admin and Unauthorized Views
-
-Add a placeholder text to indicate the user has accessed the admin area in the Admin View (```app/views/admin/show.html.erb```):
-
-```ruby
-
-${' <%= link_to "Back to Home", dashboard_path %> '}
-```
-
-And a placeholder to indicate the user cannot access the requested content in the Unauthorized View (```app/views/unauthorized/show.html.erb```):
-
-```ruby
-
-${' <%= link_to "Back to Home", dashboard_path %> '}
-```
-
-## Create the Admin Controller
-
-In the Admin Controller, add a ```before_action``` to check if the user has the admin role. If not, redirect the user to the unauthorized page:
-
-```ruby
-class AdminController < ApplicationController
-  include Secured
-  before_action :admin?
-
-  def show
-  end
-
-  private
-
-  def admin?
-    redirect_to unauthorized_show_path unless roles.include?('admin')
-  end
-
-  def roles
-    app_metadata ? app_metadata[:roles] : []
-  end
-
-  def app_metadata
-    session[:userinfo][:extra][:raw_info][:app_metadata]
-  end
-end
-```
-
-That's it. Now you can verify that only users logged in with an email that contains `@example` (or following the rule you've introduced) will be able to access the admin page.
diff --git a/articles/server-platforms/rails/08-mfa.md b/articles/server-platforms/rails/08-mfa.md
deleted file mode 100644
index d7f064dd44..0000000000
--- a/articles/server-platforms/rails/08-mfa.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: Multifactor Authentication
-description: This tutorial will show you how to add Multifactor Authentication to your Rails app with Auth0.
-budicon: 448
----
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-rubyonrails-sample',
-  path: '08-MFA',
-  requirements: [
-    'Ruby 2.3.1',
-    'Rails 5.0.0'
-  ]
-}) %>
-
-<%= include('../_includes/_mfa-introduction') %>
-
-On this tutorial, you'll learn how to enable MFA in the Rails application created in the [Login](/quickstart/webapp/rails/01-login) step.
-
-## Enable Multifactor Authentication in Your Account
-
-<%= include('../_includes/_mfa-enable') %>
-
-## Login
-
-<%= include('../_includes/_mfa-login', { loginlink: '/quickstart/webapp/rails/01-login' }) %>
diff --git a/articles/server-platforms/rails/09-customizing-lock.md b/articles/server-platforms/rails/09-customizing-lock.md
deleted file mode 100644
index f3283ed205..0000000000
--- a/articles/server-platforms/rails/09-customizing-lock.md
+++ /dev/null
@@ -1,80 +0,0 @@
----
-title: Customizing Lock
-description: This tutorial will show you how to customize lock widget.
-budicon: 448
----
-
-In addition to a carefully-considered default user interface, Lock offers UI customization functionality.
-
-<%= include('../../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-rubyonrails-sample',
-  path: '09-Customizing-Lock',
-  requirements: [
-    'Ruby 2.3.1',
-    'Rails 5.0.0'
-  ]
-}) %>
-
-## Lock Options
-
-Some UI customization can be done via the `options` parameter when creating a `Lock` instance. You can edit the Lock options in the corresponding javascript initialization code. In this tutorial, it is located in ```app/assets/javascripts/home.js.erb```.
-
-> **NOTE:** If you're setting up your rails application from scratch, refer to [Introduction](/quickstart/webapp/rails/00-introduction).
-
-
-### Theme options
-
-You can set custom theme properties like using a different logo, or changing the primary color. Just add a `theme` property with custom values when initializing the auth0 Lock widget. See full details [here](/libraries/lock/v10/customization#theming-options).
-
-```ruby
-#app/assets/javascripts/home.js.erb
-var options = {
-   auth: {
-		redirectUrl: '${" <%= Rails.application.secrets.auth0_callback_url %> "}',
-		params: {
-			scope: 'openid name email picture'
-		}
-        },
-   theme: {
-          logo: '${" <%= image_url('test-icon.png')%> "}',
-          primaryColor: '#b81b1c'
-        }
- };
-var lock = new Auth0Lock('${" <%= Rails.application.secrets.auth0_client_id %> "}', '${" <%= Rails.application.secrets.auth0_domain %> "}', options);
-
-function signin() {
-	lock.show();
-}
-```
-
-### Language Dictionary Specification
-
-You can also customize every piece of text `Lock` needs to display. The option parameter to do this is `languageDictionary`.
-See full details [here](/libraries/lock/v10/customization#languagedictionary-object-)
-
-```ruby
-#app/assets/javascripts/home.js.erb
-var options = {
-  auth: {
-    redirectUrl: '${" <%= Rails.application.secrets.auth0_callback_url %> "}',
-    params: {
-	scope: 'openid name email picture'
-    }
-  },
- languageDictionary: {
-        title: 'My Company'
- }
-};
-var lock = new Auth0Lock('${" <%= Rails.application.secrets.auth0_client_id %> "}', '${" <%= Rails.application.secrets.auth0_domain %> "}', options);
-
-function signin() {
-  lock.show();
-}
-```
-
-### Results
-
-This is how it looks like using custom logo, color, and title:
-
-![Custom lock](/media/articles/server-platforms/rails/widget-custom-logo-color.png)
diff --git a/articles/server-platforms/rails/index.yml b/articles/server-platforms/rails/index.yml
deleted file mode 100644
index ea9d0d8072..0000000000
--- a/articles/server-platforms/rails/index.yml
+++ /dev/null
@@ -1,28 +0,0 @@
-title: Ruby On Rails
-image: /media/platforms/rails.png
-tags:
-  - quickstart
-  - ruby
-  - rails
-  - ruby on rails
-snippets:
-  dependencies: server-platforms/rails/dependencies
-  setup: server-platforms/rails/setup
-  use: server-platforms/rails/use
-alias:
-  - ruby-rails
-  - sinatra
-  - omniauth
-seo_alias: rails
-default_article: 01-login
-articles:
-  - 00-introduction
-  - 01-login
-  - 02-custom-login
-  - 03-session-handling
-  - 04-user-profile
-  - 05-linking-accounts
-  - 06-rules
-  - 07-authorization
-  - 08-mfa
-  - 09-customizing-lock
diff --git a/articles/server-platforms/scala/01-login.md b/articles/server-platforms/scala/01-login.md
deleted file mode 100644
index 6154e7cbe3..0000000000
--- a/articles/server-platforms/scala/01-login.md
+++ /dev/null
@@ -1,191 +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-samples',
-  repo: 'auth0-scala-samples',
-  path: '00-Starter-Seed',
-  requirements: [
-    'Scala 2.11.7',
-    'Typesafe Activator 1.3.7',
-    'Play framework 2.4.6'
-  ]
-}) %>
-
-## Add your Auth0 Configuration Keys
-
-${snippet(meta.snippets.dependencies)}
-
-## Add Your Auth0 Callback Handler
-
-Add the handler for the Auth0 callback so you can authenticate the user and retrieve their information:
-
-```scala
-// controllers/Callback.scala
-package controllers
-
-import scala.concurrent.ExecutionContext.Implicits.global
-import scala.concurrent.Future
-
-import play.api.Play
-import play.api.Play.current
-import play.api.cache.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.WS
-import play.api.mvc.Action
-import play.api.mvc.Controller
-
-class Callback extends Controller {
-
-  // callback route
-  def callback(codeOpt: Option[String] = None) = Action.async {
-    (for {
-      code <- codeOpt
-    } yield {
-      // Get the token
-      getToken(code).flatMap { case (idToken, accessToken) =>
-       // Get the user
-       getUser(accessToken).map { user =>
-          // Cache the user and tokens into cache and session respectively
-          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")))
-  }
-
-  def getToken(code: String): Future[(String, String)] = {
-    val tokenResponse = WS.url(String.format("https://%s/oauth/token", "${account.namespace}"))(Play.current).
-      withHeaders(HeaderNames.ACCEPT -> MimeTypes.JSON).
-      post(
-        Json.obj(
-          "client_id" -> "${account.clientId}",
-          "client_secret" -> "${account.clientSecret}",
-          "redirect_uri" -> "http://localhost:9000/callback",
-          "code" -> code,
-          "grant_type"-> "authorization_code"
-        )
-      )
-
-    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 userResponse = WS.url(String.format("https://%s/userinfo", "${account.namespace}"))(Play.current)
-      .withQueryString("access_token" -> accessToken)
-      .get()
-
-    userResponse.flatMap(response => Future.successful(response.json))
-  }
-}
-```
-
-${include('../_callbackRegularWebApp')}
-
-Your callback URL should look something like:
-
-`https://yourapp.com/callback`
-
-## Trigger Login Manually or Integrate Lock
-
-<%= include('../../_includes/_lock-sdk') %>
-
-**Note:** The `redirectUrl` specified in the `Auth0Lock` constructor must match the callback URL specified in the previous step.
-
-## Access User Information
-
-You can access the user information from the `cache`
-
-```scala
-// controllers/User.scala
-package controllers
-
-import play.api._
-import play.api.mvc._
-import scala.concurrent.Future
-import scala.concurrent.ExecutionContext.Implicits.global
-import play.api.http.{MimeTypes, HeaderNames}
-import play.api.libs.ws.WS
-import play.api.mvc.{Results, Action, Controller}
-import play.api.libs.json._
-import play.api.cache.Cache
-import play.api.Play.current
-import play.mvc.Results.Redirect
-
-class User extends Controller {
-    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(controllers.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))
-    }
-}
-```
-
-```scala
-// views/user.html.scala
-@(profile: JsValue)
-
-@main("Auth0 Play2 Scala Sample","home") {
-  
-  
        Welcome @((profile \ "name").as[String])
        
-}
-```
-
-## Optional Steps
-
-You can add the following `Action` to check if the user is authenticated. If not, redirect them to the login page:
-
-```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/server-platforms/scala/index.yml b/articles/server-platforms/scala/index.yml
deleted file mode 100644
index c2d9c2a3e7..0000000000
--- a/articles/server-platforms/scala/index.yml
+++ /dev/null
@@ -1,12 +0,0 @@
-title: Play 2 Scala
-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/server-platforms/servicestack/01-login.md b/articles/server-platforms/servicestack/01-login.md
deleted file mode 100644
index f19ed9625b..0000000000
--- a/articles/server-platforms/servicestack/01-login.md
+++ /dev/null
@@ -1,164 +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)
-
-Add the following line to your `App_Start/Route_Config.cs` file to the beginning of the `RegisterRoutes` function (this is required for ServiceStack):
-
-```
-routes.IgnoreRoute("api/{*pathInfo}");
-```
-
-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__:
-
-  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:
-
-```
-ConfigureAuth(container);
-```
-
-And then uncomment (if it is commented out) and edit the `ConfigureAuth` method to look like this:
-
-${snippet(meta.snippets.setup)}
-
-> 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 Client 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 ``:
-
-```
-
-
-
-```
-
-## 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 };
-  }
-}
-```
-> Notice we are not doing anything useful with these properties. You can place a breakpoint here and explore the session object.
-
-## Triggering Login Manually or Integrating Lock
-
-<%= include('../../_includes/_lock-sdk') %>
-
-## Add UI Code to Login and Invoke the `HelloService`
-
-Open `default.htm` and add the following statement in the `jQuery.ready` body:
-
-```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
-
-After successful authentication, the `UserProfile` will be displayed on the page.
diff --git a/articles/server-platforms/servicestack/index.yml b/articles/server-platforms/servicestack/index.yml
deleted file mode 100644
index a385ce7ba2..0000000000
--- a/articles/server-platforms/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/server-platforms/symfony/01-login.md b/articles/server-platforms/symfony/01-login.md
deleted file mode 100644
index f6e2d5738d..0000000000
--- a/articles/server-platforms/symfony/01-login.md
+++ /dev/null
@@ -1,123 +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-samples',
-  repo: 'auth0-symfony-php-web-app',
-  path: '00-Starter-Seed',
-  requirements: [
-    'PHP 5.3.9',
-    'Symfony 2.8'
-  ]
-}) %>
-
-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 a 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`
-
-> 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 and it will install them in your project for you.
-
-## 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:
-    pattern: /auth0/callback
-```
-
-## Configure Auth0
-
-${include('../_callbackRegularWebApp')}
-
-In this case, the callbackURL should look something like:
-
-```
-http://yourUrl/auth0/callback
-```
-
-## Configure the Resource Owner
-
-Add this to your `app/config/config.yml`
-
-```yml
-hwi_oauth:
-    firewall_name: secured_area
-    resource_owners:
-        auth0:
-            type:                auth0
-            base_url:            https://${account.namespace}
-            client_id:           ${account.clientId}
-            client_secret:       ${account.clientSecret}
-```
-
-## 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 are protected (aka, needs login). 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 `/demo/hello/` 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
-
-    access_control:
-        - { path: ^/login, roles: IS_AUTHENTICATED_ANONYMOUSLY }
-        - { path: ^/demo/hello, 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 Manually or Integrating Lock
-
-Set the following in `app/resources/views/base.html.twig`
-
-<%= include('../../_includes/_lock-sdk') %>
-
-### Troubleshooting
-
-#### SSL certificate problem: self signed certificate in certificate chain
-
-If there is an issue with CAs database on your computer, you may need to download this [CAs database](https://curl.haxx.se/ca/cacert.pem). To use it on Windows for example, place it in `c:\cacert.pem` and point to it in `php.ini` with `openssl.cafile=c:/cacert.pem`.
diff --git a/articles/server-platforms/symfony/index.yml b/articles/server-platforms/symfony/index.yml
deleted file mode 100644
index 25d4dc8b4c..0000000000
--- a/articles/server-platforms/symfony/index.yml
+++ /dev/null
@@ -1,12 +0,0 @@
-title: PHP (Symfony)
-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/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 8e6a14f6f5..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
@@ -8,15 +16,13 @@ This is a fixed scope project designed to establish a foundational set up of Aut
 
 ## Estimated effort
 
-Between 40 - 120 hours.
-
-> Auth0 Professional Services are delivered in 40 hs. "blocks".
+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 customers Auth0 subscription model. Provide knowledge transfer to customer staff to prepare them to operate the Solution and to expand Auth0 usage into other scenarios.
+* **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 development team during initial phases of development, under a pair-programming model, taking responsibilities for Auth0-related code.
+* **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
 
diff --git a/articles/services/auth0-advanced.md b/articles/services/auth0-advanced.md
deleted file mode 100644
index 8acbe62e5d..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
-
-8 hours.
-
-
-## 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 5fca2869a9..0000000000
--- a/articles/services/auth0-introduction.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-description: Training covering fundamentals of the Auth0 service.
----
-
-# Training: Auth0 Introduction
-
-A training covering fundamentals of the Auth0 service. Audience is Developers, Solutions Architects, Security and Infrastructure engineers.
-
-## Duration
-
-8 hours.
-
-
-## Level
-
-**Level 200** 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 422a267def..03287053c2 100644
--- a/articles/services/code-review.md
+++ b/articles/services/code-review.md
@@ -1,16 +1,21 @@
 ---
 description: Project to help customers analyze common design patterns.
+topics:
+  - professional services
+  - code-review
+contentType:
+  - reference
+useCase:
+  - development
 ---
 
-# Advisory Hours: Code Review
+# 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
 
-40 hours.
-
-> Auth0 Professional Services are delivered in 40 hs. "blocks".
+Time-boxed working sessions based on customer requirements with an Auth0 Solutions Architect and the customer's development team.
 
 ## Typical work-streams
 
diff --git a/articles/services/custom-extensions.md b/articles/services/custom-extensions.md
deleted file mode 100644
index bec2a35078..0000000000
--- a/articles/services/custom-extensions.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-description: A project to develop or customize components that extend Auth0's out-of-the-box functionality.
----
-
-# Advisory Hours: Custom Extensions
-
-A project to develop or customize components that extend Auth0's out-of-the-box functionality. Typical assets include: Auth0 Extensions, custom db connection scripts, rules, and Webtasks.
-
-## Estimated effort
-
-40 hours.
-
-> Auth0 Professional Services are delivered in 40 hs. "blocks".
-
-## Typical work-streams
-
-* **Design:** define requirements and scope of the customizations required.
-* **Develop:** build and document
-1 month after delivery or 8 support hours (whatever occurs first) that can be used to ask questions, have us make small changes
-
-## Deliverables
-
-* Code one Custom Extension artifact, how-to deploy document, session explaining the code and the features.
-
-<%= include('../_includes/_contact-sales') %>
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/geo-ha.md b/articles/services/geo-ha.md
deleted file mode 100644
index 8dcfdf7119..0000000000
--- a/articles/services/geo-ha.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-description: Project to assist customers with Geo distributed High Availability.
----
-
-# Geo High Availability
-
-An offering to assist customers with design and deployment for Geo-distributed High Availability. The focus is on infrastructure design, reducing risks during deployment, and preparing Operations for a successful on going management.
-
-## Estimated effort
-
-40 hours.
-
-> Auth0 Professional Services are delivered in 40 hs. "blocks".
-
-## Typical work-streams
-
-* **Planning:** analysis of alternative design templates, requirements gathering for disaster recovery scenarios,  infrastructure architecture and design sessions to meet those requirements.
-* **Disaster Recovery simulation:** collaborate with customers' teams to test DR plan, validating processes, tools and people readiness.
-* **Deployment:** participate on the deployment of the actual solution.
-
-## Deliverables
-
-* Technical document: infrastructure decisions, requirements, setup details, processes, simulation details.
-
-<%= include('../_includes/_contact-sales') %>
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 61a03cf4ea..4fbecde974 100644
--- a/articles/services/index.md
+++ b/articles/services/index.md
@@ -3,46 +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
+
+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. 
 
-<%= include('../_includes/_topic-links', { links: [
-  'services/architectural-design',
-  'services/performance-scalability',
-  'services/geo-ha',
-  'services/scenario-guidance',
-  'services/code-review'
-] }) %>
+
        
 
-## Maintain & Improve
+
          
+  
        • 
+    Services
 
-<%= include('../_includes/_topic-links', { links: [
-  'services/pair-programming',
-  'services/private-saas-configuration',
-  'services/code-review',
-  'services/custom-extensions'
-] }) %>
+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:
+    
+  
          • 
+
        
 
-## Educate
+
          
+  
        • 
+    Packages
 
-<%= include('../_includes/_topic-links', { links: [
-  'services/auth0-introduction',
-  'services/auth0-advanced',
-  'services/private-saas-introduction',
-  'services/private-saas-management'
-] }) %>
+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.
+  
          • 
+
        
 
-## Jumpstart
+## Keep reading
 
-<%= include('../_includes/_topic-links', { links: [
-  'services/jumpstart'
-] }) %>
+* [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 181cc70980..0000000000
--- a/articles/services/jumpstart.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-description: Focused project to help customers get started with Auth0 during their first year.
----
-
-# Jumpstart
-
-This offering consists of 3 blocks of 4 hours, each covering the following.
-
-## Scenario Guidance
-
-A lighter weight version of [full Scenario Guidance offering](/services/scenario-guidance), this activity is designed to help you assess your requirements, and jointly draft a solution to address these.
-
-We recommend completing this activity during the first 60 days of your subscription.
-
-## Code Review / Programming Advisory
-
-A quick review of your implementation, including integration with your applications, general Auth0 configuration, rules, custom db connections, and so forth. The goal is to make sure you are optimally using Auth0's capabilities.
-
-We recommend completing this activity no later than your subscription mid-term.
-
-## Architectural Review
-
-This activity is designed to perform an evaluation of the Auth0 installation to ensure optimal use. It's an opportunity to update any documentation available, and includes an overview of different environments, applications, connections, and overall configuration. It also includes a walk-through of Auth0's roadmap, features to come, and an open discussion about other usage of Auth0 inside the company in the near future.
- 
-
-<%= 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 7c5fec84d4..a2aff15193 100644
--- a/articles/services/pair-programming.md
+++ b/articles/services/pair-programming.md
@@ -1,14 +1,21 @@
 ---
 description: Project to co-develop integration points with Auth0.
+topics:
+  - professional services
+  - pair-programming
+contentType:
+  - reference
+useCase:
+  - development
 ---
 
-# Advisory Hours: Pair Programming
+# 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
 
-40 hours.
+Time-boxed working sessions based on customer requirements with an Auth0 Solutions Architect and customer's development team.
 
 ## Typical work-streams
 
diff --git a/articles/services/performance-scalability.md b/articles/services/performance-scalability.md
index 53e1d70ca0..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
@@ -8,15 +16,13 @@ An offering to assist customers with common performance testing needs, including
 
 ## Estimated effort
 
-80 hours.
-
-> Auth0 Professional Services are delivered in 40 hs. "blocks".
+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 tunning iterations.
+* **Test runs:** work with the customer on 3 testing and tuning iterations.
 * **Results Analysis:** documenting findings and recommendations.
 
 ## Deliverables
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 9a4bd9b748..0000000000
--- a/articles/services/private-saas-configuration.md
+++ /dev/null
@@ -1,26 +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
-
-40 hours.
-
-> Auth0 Professional Services are delivered in 40 hs. "blocks".
-
-## 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-introduction.md b/articles/services/private-saas-introduction.md
deleted file mode 100644
index c537dc65d2..0000000000
--- a/articles/services/private-saas-introduction.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-description: A hands-on training to learn fundamentals of the Auth0 Private SaaS offering.
----
-
-# Training: Private SaaS Introduction
-
-Training to learn fundamentals of the Auth0 Private SaaS offering, including pre-requisites, installation, deployment options, and on going operations such as updates, monitoring and troubleshooting.
-
-## Duration
-
-4 hours.
-
-## Level
-
-**Level 200**, assumes basic knowledge and complete understanding of Auth0 core features.
-
-## Topics covered
-
-Overall functionality, comparison with Public SaaS version, features, overview of deployment options, configuration, telemetry, updates and configuration management. It includes and Hands-on-Lab.
-
-<%= 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 9b0166d232..0000000000
--- a/articles/services/private-saas-management.md
+++ /dev/null
@@ -1,23 +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
-
-8 hours.
-
-> Auth0 Professional Services are delivered in 40 hs. "blocks".
-
-## 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 a75dfba8d8..fc211feb9e 100644
--- a/articles/services/scenario-guidance.md
+++ b/articles/services/scenario-guidance.md
@@ -1,14 +1,26 @@
 ---
 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 Hours: Scenario guidance
+# 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 (e.g. technology briefings, Q&A sessions, etc).
+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
 
-20 hours.
+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
 
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
new file mode 100644
index 0000000000..5ca58fe4e8
--- /dev/null
+++ b/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/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/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/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/index.md b/articles/sso/index.md
deleted file mode 100644
index 403f73ea72..0000000000
--- a/articles/sso/index.md
+++ /dev/null
@@ -1,96 +0,0 @@
----
-url: /sso
-description: Introduction to Single Sign On (SSO) with Auth0.
----
-
-# What is SSO (Single Sign On)?
-
-SSO (Single Sign On) occurs when a user logs in to one Client and is then signed in to other Clients automatically, regardless of the platform, technology, or domain the user is using.
-
-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 clients. 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, 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)
-
-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, i.e. 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
-
-::: panel-info Enabling Identity Providers
-Prior to enabling SSO for a given Client, you must first [configure the Identity Provider(s)](/identityproviders) you want to use.
-:::
-
-To enable SSO for one of your Clients (recall that each Client is independent of one another), navigate to the [Clients section of the Auth0 Management Dashboard](${manage_url}/#/clients). Click on **Settings** (represented by the gear icon) for the Client 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 Client'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 Client 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/single-page-apps-sso)
-* [Server-Side SSO (Regular Web Apps)](/sso/regular-web-apps-sso)
-
-> 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 a Client, Auth0 will maintain an SSO session for any user authenticating via that Client. 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 Client that created the session within the given timeframe.
-
-## 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, etc.
-
-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
-
-Single Sign On 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 Client
-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).
\ No newline at end of file
diff --git a/articles/sso/index.yml b/articles/sso/index.yml
new file mode 100644
index 0000000000..3fc1f73b02
--- /dev/null
+++ b/articles/sso/index.yml
@@ -0,0 +1,9 @@
+versioning:
+  baseUrl: sso
+  current: current
+  versions:
+    - legacy
+    - current
+  defaultArticles:
+    legacy: index
+    current: index
diff --git a/articles/sso/legacy/index.md b/articles/sso/legacy/index.md
new file mode 100644
index 0000000000..8283021d59
--- /dev/null
+++ b/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/articles/sso/legacy/regular-web-apps-sso.md b/articles/sso/legacy/regular-web-apps-sso.md
new file mode 100644
index 0000000000..3f8fc043fc
--- /dev/null
+++ b/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/articles/sso/legacy/single-page-apps.md b/articles/sso/legacy/single-page-apps.md
new file mode 100644
index 0000000000..e726c4d78a
--- /dev/null
+++ b/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/articles/sso/regular-web-apps-sso.md b/articles/sso/regular-web-apps-sso.md
deleted file mode 100644
index f7b21a2ebd..0000000000
--- a/articles/sso/regular-web-apps-sso.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-description: Server-side SSO with regular web applications.
----
-
-# Server-side SSO (Regular Web Apps)
-
-To log a user in silently (i.e. without displaying the Lock screen) the following conditions need to be met:
-
-1. The Client needs to be configured to **Use Auth0 instead of the IdP to do Single Sign On** in the [Clients section of the Auth0 Management Dashboard](${manage_url}/#/clients)
-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.
-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.
-
-```
-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:
-
-```
-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:
-
-```
-https://${account.namespace}/authorize?client_id=${account.clientId}&response_type=code&redirect_uri=${account.callback}
-```
diff --git a/articles/sso/single-page-apps-sso.md b/articles/sso/single-page-apps-sso.md
deleted file mode 100644
index 52d4312cc3..0000000000
--- a/articles/sso/single-page-apps-sso.md
+++ /dev/null
@@ -1,177 +0,0 @@
----
-description: Client-side SSO with single page applications.
----
-
-# Client-side SSO (Single Page Apps)
-
-To log a user in silently (i.e. without displaying the Lock screen) the following conditions need to be met:
-
-1. The Client needs to be configured to **Use Auth0 instead of the IdP to do Single Sign On** in the [Clients section of the Auth0 Management Dashboard](${manage_url}/#/clients)
-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.
-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, e.g. 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 Log Out](/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 (i.e. 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/articles/sso/sso-username-password.md b/articles/sso/sso-username-password.md
deleted file mode 100644
index a75340e15d..0000000000
--- a/articles/sso/sso-username-password.md
+++ /dev/null
@@ -1,96 +0,0 @@
----
-description: Overview of single sign on with username and password logins.
----
-
-# Single Sign On with username/password logins
-
-To initiate SSO for a username/password connection (e.g. database connections, AD/LDAP, etc.) you can use this endpoint:
-
-```
-POST
-https://${account.namespace}/usernamepassword/login
-```
-
-This endpoint accepts the following parameters:
-
-```
-{
-  scope:'openid',
-  response_type:'code',
-  connection:'YOUR CONNECTION',
-  username: username,
-  password: password,
-  sso: true|false,
-  client_id:'${account.clientId}',
-  redirect_uri:'${account.callback}',
-  tenant:'${account.tenant}'
-}
-```
-
-The response from this is an HTML form that can be injected on your web page DOM. The form is then submitted to complete the authentication. Through this process, a session cookie (that is, an auth0 cookie) is set on the users' browser that can then be used for SSO.
-
-## Sample
-
-```html
-
-  
-    Username Password SSO
-  
-  
-    
-    
        Username Password SSO
        
-    
        Welcome to Username Password SSO
        
-    
        
-    Username:
        Password:
        
-    
-    
-  
-
-```
-
-This endpoint is conceptually similar to `/ro` (Resource Owner), the difference is that while `/ro` returns a JSON object with the result of the authentication (containing an `access_token` and optionally an `id_token`), `/usernamepassword/login` returns HTML of the form:
-
-```html
-
-    
-    
-    
-    
-
-```
-
-Submitting this form to Auth0 will result in the completion of the authentication request (a final redirect to your application callback URL). Notice this works for both `response_types=code|token`. (See [Protocols](/protocols) for details on both).
-
-A complete sample is available [here](https://github.com/auth0-samples/auth0-database-connection-custom-sso).
diff --git a/articles/support/_delete-tenant.md b/articles/support/_delete-tenant.md
new file mode 100644
index 0000000000..339c60adc2
--- /dev/null
+++ b/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/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
new file mode 100644
index 0000000000..df35bb82d8
--- /dev/null
+++ b/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/articles/support/delete-reset-tenant.md b/articles/support/delete-reset-tenant.md
new file mode 100644
index 0000000000..5b89c4de31
--- /dev/null
+++ b/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/articles/support/how-auth0-versions-software.md b/articles/support/how-auth0-versions-software.md
new file mode 100644
index 0000000000..0d3109b493
--- /dev/null
+++ b/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/articles/support/index.md b/articles/support/index.md
index acb4ded1d2..d579b97fee 100644
--- a/articles/support/index.md
+++ b/articles/support/index.md
@@ -1,145 +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
 
-## 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.
+The following page contains information about the Auth0 support program.
 
-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.
+## Support Options Overview
 
-## Public Forum
+Auth0 offers the following support plans:
 
-Auth0's public [discussion forum](https://ask.auth0.com) offers support for __all__ subscribers. All customers, even on free accounts, can use our public [discussion forum](https://ask.auth0.com) to search existing questions and receive support from our engineers if their question has not already been asked.
+
+  
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+    
+      
+      
+    
+  
+
        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.
        
 
-## Support Center
+### Community Support
 
-:::panel-info Pricing
-For pricing information on the various subscription plans, please see your [Account Settings](${manage_url}/#/account/billing/subscription).
+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/).
 :::
 
-Additionally, paid subscribers can create a private ticket via [Support Center](${env.DOMAIN_URL_SUPPORT}). All account 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}).
+### 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](${env.DOMAIN_URL_SUPPORT}) for fastest response.
+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)
 
-### Ticket Response Times
+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.
 
-Ticket response times will vary based on your support plan (shown below).  Note that customers on non-paying trial or free subscriptions are not eligible for a support plan and should utilize the discussion forum. Non-paying customers may still raise a private ticket via the Support Center. However, there is no support response SLA for these users, and tickets will be answered on a best effort basis after prioritization of paying subscribers' tickets. 
+![](/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:
 
 
-      
-      
-      
-      
-      
+      
+      
-     
-      
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-      
-    
-      
-      
-      
-      
-      
+      
+      
-      
-      
-      
-      
-      
+      
+      
-      
-      
-      
-      
-      
+      
+      
-      
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-      
-    
-    
-      
-      
-      
-      
-      
+      
+      
        
   
     
         Free (No Plan)   Standard Support  Enterprise Support  Preferred Support Severity LevelDescription
     
        
           
   
        Subscription PlanFreeDeveloper, Developer Pro. Legacy plans: Gold, Silver and Home GrownEnterpriseAddon to Enterprise
        Ticket PrioritizationLowestNormalHighPrioritized
         Support Hours Standard: M-F 7am-7pm (local timezone) / Critical Outage: M-F 7am-pm (PST) Standard: M-F 7am-7pm (local timezone) / Critical Outage: M-F 7am-pm (local timezone) Standard: M-F 7am-7pm (local timezone) / Critical Outage: 24x7x365  Standard: M-F 7am-7pm (local timezone) / Critical Outage: 24x7x365 
        
     
        First Response Time Target2-5+ Business Days2 Business DaysStandard: 3 business hours / Critical Outage: 1 hourStandard: 1 business hour / Critical Outage: 1 hour1 (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.
     
        
     
        Subsequent Response Time TargetBest Effort after paid subscriptionsStandard: 16 business hours / Critical Outage: ongoing within support hoursStandard: 8 business hours / Critical Outage: ongoing within support hoursStandard: 4 business hours / Critical Outage: ongoing within support hours2 (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.
     
        
     
        Public ForumYesYesYesYes3 (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
     
        
     
        Support CenterLimited - Best effortYesYesYes
        Ticket Response ChannelsSupport forum, Support CenterSupport forum, Support CenterSupport forum, Support Center, chat, web conferenceSupport forum, Support Center, chat, web conference
        Onboarding ExperienceSelf-service in app and emailSelf-service in app and emailSprint Sprint Preferred 
        Ongoing Customer Success Engagement none none Customer Success Team Allocated Success Manager 4 (Low)Minor Problem / Enhancement Request. Information requested on Auth0 Platform capabilities, navigation, installation, or configuration; enhancement request.
     
        
           
 
        
 
-### Ticket Severity
+### 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
 
-Standard: Defined as an Auth0 issue impacting your live or in-production systems or your ability to progress to production where:
+Auth0 will provide support for Severity Level 1 Defects on a 24x7x365 basis.
 
-- Business processes and functions are degraded;
-- A group or groups of users are impacted;
-- There is a reasonable workaround;
-- Application is not yet in live, production status.
+For all other defects, Auth0 will provide support during the hours specified below:
 
-Critical: Defined as an Auth0 issue severely impacting your live or in-production systems where:
+| 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 |
 
-- Major business processes and functions are stopped for all or most users;
-- Majority of users are significantly impacted, for example: unable to log in;
-- There is no workaround;
-- Application is in live, production status.
+## Support Languages
 
-Critical Production issues should always be reported via the [Support Center](${env.DOMAIN_URL_SUPPORT}) for fastest response.
+We provide all technical support in English, but we will make an effort to accommodate other languages if possible.
 
-- Subscriptions previously known as "Free" map to the current "Free" support classification
-- Subscriptions previously known as "Gold/Silver/Home Grown"  map to the current "Standard" support plan.
-- Customers that have Developer or Developer Pro subscriptions map to the current "Standard" support plan.
-- Support plans previously known as "Enterprise" and "Premium" support map to the current "Enterprise" support plan.
-- The "Preferred" support plan is a new plan available for purchase as of October 2016.
+## 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
 
-Every effort will be made to respond sooner than the times listed above. However, some types of problems such as development issues that require us to install software to duplicate a problem, may take time due to the research and work required.  Response times may also be delayed during periods of heavy ticket volume.
+All customers, even those with free subscription plans, may report security concerns via [Auth0 Whitehat](https://auth0.com/whitehat).
 
-If you have specific support requirements or are interested in the __Enterprise Support__ or __Preferred Support__ option, please [contact sales](https://auth0.com/?contact=true).
+[Additional Details](https://auth0.com/legal)
diff --git a/articles/support/matrix.md b/articles/support/matrix.md
new file mode 100644
index 0000000000..1d8783c5bc
--- /dev/null
+++ b/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/articles/support/removing-auth0-exporting-data.md b/articles/support/removing-auth0-exporting-data.md
new file mode 100644
index 0000000000..c9cc3013e5
--- /dev/null
+++ b/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/articles/support/reset-account-password.md b/articles/support/reset-account-password.md
new file mode 100644
index 0000000000..05c72bd204
--- /dev/null
+++ b/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/articles/support/sla.md b/articles/support/sla.md
deleted file mode 100644
index 9f8630f932..0000000000
--- a/articles/support/sla.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-description: Details on SLA for enabled subscribers.
----
-
-# SLA
-
-At an additional cost, Auth0 offers a __99.9%__ uptime service level agreement guarantee to subscribers enabling it in their subscription. Details on SLA below:
-
-
-#### I. 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. 
-
-#### II.  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).
-
-#### III. 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.
-
-#### IV.  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
new file mode 100644
index 0000000000..bda497694e
--- /dev/null
+++ b/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/articles/support/testing.md b/articles/support/testing.md
new file mode 100644
index 0000000000..cf2c67b86a
--- /dev/null
+++ b/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/articles/support/tickets.md b/articles/support/tickets.md
index c2b2c7e8ad..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
 ---
 
-# Opening and Managing Tickets in Support Center
+# Open and Manage Support Tickets
 
-With [Support Center](${env.DOMAIN_URL_SUPPORT}), you can create tickets for questions or issues you are experiencing. You need to be a full administrator of an Auth0 account to access Support Center.
+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 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 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.
 
-## Opening a New Ticket
+## Open a new ticket
 
-1. From [Support Center](${env.DOMAIN_URL_SUPPORT}), click on the **OPEN TICKET** button.
-![](/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.
-![](/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
+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
-        *  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?
@@ -39,10 +53,14 @@ If you are an existing Appliance customer, you will need to create an Auth0 clou
     * What troubleshooting steps have you tried?
 1. When you have completed all the fields, click on the **SUBMIT** button.
 
-## Updating an Existing Ticket
+## 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.
-![](/media/articles/support/select-ticket.png)
+![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.
-![](/media/articles/support/update-ticket.png)
+![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/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 bf9b5bbd06..0000000000
--- a/articles/tokens/access-token.md
+++ /dev/null
@@ -1,153 +0,0 @@
----
-title: Access Token
-description: This page explains an overview about Auth0 access tokens.
----
-
-# Access Token
-
-## Overview
-
-The Access Token, commonly referred to as `access_token` in code samples, is a credential that can be used by a client to access an API. The `access_token` should be used as a `Bearer` credential and transmitted in an HTTP `Authorization` header to the API. Auth0 uses access tokens to protect access to the Auth0 Management API.
-
-Auth0 generates access tokens in [JSON Web Token (JWT)](/jwt) format, an industry standard. 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.
-
-::: panel-info Opaque token format
-The [Auth0 Management API v1](/api/management/v1) (which has been deprecated) uses an opaque token format in which claims are referenced in a separate database, rather than directly in the token.
-:::
-
-## 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.
-
-* Calls to the Lock widget will return an `access_token` as shown in the [Lock documentation](/libraries/lock).
-* [Examples using auth0.js](https://github.com/auth0/auth0.js).
-* Check the [List of tutorials](/tutorials) to see how to make calls to libraries for other languages/SDKs.
-
-## How to use an access token
-
-Access tokens are typically obtained in order to access user-owned resources. For example, a Calendar client 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 client 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 client, which the client 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 clients. 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 client 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\": \"${account.clientSecret}\",\"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.
-
-```
-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 client 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).
-
-
-## Authorize access tokens
-
-Once a client has obtained an access token, it will include that token as a credential when making API requests.
-
-```
-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 do the following:
-
-1. Ensure that the token is intended to be used at the API by checking that the value of `aud` is identical to the API's identifier.
-1. Ensure that the token has not expired by comparing the value of `exp` to the current time.
-1. Ensure that the token was issued by a trusted authorization server. In this case, Auth0 is the trusted authorization server and a secret, `keyboardcat`, is known only to Auth0 and the API. The signature of the token is validated using this secret.
-1. Ensure that the token has the correct scopes to perform the requested operation.
-
-If any of these check 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 and write his or her calendar.
-
-The API can now process the request, allowing the application to read and write to user `usr_123`'s calendar.
-
-## 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 [APIs dashboard](${manage_url}/#/apis). The default value is `24` hours (`86400` seconds).
-
-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. 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 the access token grants access to. 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.
-
-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 faster than one that accesses a ToDo API.
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 3867e71ffe..0000000000
--- a/articles/tokens/delegation.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-description: This page explains an overview about Auth0 delegation tokens.
----
-
-# Delegation Tokens
-
-## Overview
-
-Delegation tokens are tokens used to call another API.
-
-The Auth0 `id_token` can be exchanged for another token, called a Delegation token, that can be used to call either other application APIs registered as clients in the same Auth0 tenant or APIs represented by some types of application Addons registered in the same Auth0 tenant.
-
-The type of the delegation token will vary depending on the target API with which it will be used.  For example, if it will be used for an application/API registered in Auth0, it will be a JWT token.  If the delegation token is for an application AddOn, it will vary by provider.  For example, if issued for Azure blob storage, it will be a SAS (Shared Access Signature).  If the delegation token is for the Firebase add on , it will be a JWT.
-
-Further information available at: [Delegation token request](https://github.com/auth0/auth0.js#delegation-token-request).
-
-## How to get a delegation token
-
-The `id_token` for an authenticated user can be used with the `/delegation` endpoint to request a delegation token for a particular target.  The target can be either another application/API registered in Auth0 or 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.
-
-Further information available at:  [Delegation endpoint](/api/authentication#delegation).
-
-## Control the contents of a delegation 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) in the [Authentication API](/api/authentication) for more information.
-
-## Token Validity
-
-For customer application APIs registered in Auth0, the validity of a delegation token issued for that target is governed by the _JWT Expiration (seconds)_ value. This is set for each application in _[Applications](${manage_url}/#/applications) > Settings_.
-
-For APIs registered as Addons in Auth0, the validity period of the token will vary by individual Addon.  The documentation available from the provider of any Addon API should be consulted for further information on tokens and expirations.
-
-## Renew a delegation token
-
-When a delegation token expires, the [Delegation endpoint](/api/authentication#delegation) can be used to obtain a token.
-
-## Termination of tokens
-
-The ability to revoke a delegation token will vary by individual Addon.  The documentation available from the provider of any Addon API should be consulted for further information on whether a token can be revoked and if so, how to do it.
-
-The delegation tokens for customer APIs registered in Auth0 cannot be revoked.  A best practice, therefore, is to set the JWT expiration duration to a relatively short value.
-
-## Example
-
-Consider the following scenario. You have two web applications: _appA_ and _appB_. They both need to talk to the same backend API, _apiC_. The steps you should follow for this configuration would be:
-
-1. Register _appA_ and _appB_ in Auth0. Now each app has its own client secret.
-2. Register your backend API _apiC_ in Auth0. Now the API has its own client secret as well.
-3. Navigate to the [Applications](${manage_url}/#/applications), select _apiC_ and click on _Settings > Show Advanced Settings > OAuth_. In the _Allowed APPs / APIs_ field set the applications _appA_ and _appB_. This will set these two apps as clients that are allowed to make delegation requests to _apiC_. You have to set the client ID of your two apps in this field, separated by comma or newline.
-4. In your implementation, the applications _appA_ and _appB_ would invoke an Auth0 method (lock or SDK call) to authenticate a user and request an `id_token` be returned.
-5. The applications _appA_ and _appB_ would then use the [delegation endpoint](/api/authentication#delegation) to exchange the original `id_token` for a new token with which to call _apiC_.
-6. The generated delegation token will be signed with the target API's (_apiC_) client secret. The target API should validate that signature.
-
-## Uses
-
-A delegation token should be obtained and used when a client program needs to call the API of either a) another application/API registered in Auth0 or b) the API for an Application Addon, such as Firebase or SAP, registered and configured in Auth0, in the same tenant as the calling program.
-
-* [Delegation token request example](https://github.com/auth0/auth0.js#delegation-token-request)
-
-* [Auth0.js example](/libraries/auth0js#12)
-
-## Best Practices
-
-For granularity of access control, it is good to set up different applications/APIs with different secrets, so that a delegation token can be issued uniquely for each application/API.
-
-Tokens should be issued with a short timeframe for expiration, where configurable.
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 c534867902..0000000000
--- a/articles/tokens/id-token.md
+++ /dev/null
@@ -1,116 +0,0 @@
----
-title: ID token
-description: How to obtain, use and renew an id_token.
----
-
-# ID Token
-
-## Overview
-
-The ID token, usually referred to as `id_token` in code samples, is a [JSON Web Token (JWT)](/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 client uses `RS256` encryption then the `id_token` will be signed with a private key and verified with a public key.
-
-The `id_token` is consumed by the client and used to get user information like the user's name, email, and so forth, typically used for UI display. It was added to the OIDC specification as an optimization so the client can know the identity of the user, without having to make an additional network requests.
-
-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.
-
-## How to 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, 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.
-
-## How to validate an ID token
-
-The way to validate an ID token depends on the hash algorithm used by your Client:
-- If you used `HS256` then the token is signed with the Client Secret, using the HMAC algorithm. You can verify the signature using the Client Secret value, which you can find at the _[Client Settings](${manage_url}/#/clients/${account.clientId}/settings)_ page.
-- If you used `RS256` then the token is signed with a public/private key pair, using RSA. You can verify the signature using the Public Key or Certificate, which you can find at the _[Client Settings](${manage_url}/#/clients/${account.clientId}/settings) > Show Advanced Settings > Certificates_ page.
-
-To check or update the algorithm your Client uses go to _[Client Settings](${manage_url}/#/clients/${account.clientId}/settings) > Show Advanced Settings > OAuth > JsonWebToken Signature Algorithm_. The most secure practice, and our recommendation, is to use `RS256`.
-
-## How to control the contents of an ID token
-
-In order to retrieve an `id_token` the `responseType` should be set to `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/v10/customization#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.
-
-::: panel-warning Add claims using Rules
-If you are using [OAuth 2.0 API Authorization](/api-auth/tutorials/configuring-tenant-for-api-auth), you can add claims to the `id_token` using [Rules](/rules), with the following format: `context.idToken['http://my-custom/claim'] = 'some-value'`.
-:::
-
-## 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 > Clients > Settings](${manage_url}/#/clients/${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 `renewAuth()` method.
-
-```js
-auth0.renewAuth({
-  audience: 'https://mystore.com/api/v2',
-  scope: 'read:order write:order',
-  redirectUri: 'https://example.com/auth/silent-callback',
-
-  // this will use postMessage to comunicate between the silent callback
-  // and the SPA. When false the SDK will attempt to parse the url hash
-  // should ignore the url hash and no extra behaviour is needed.
-  usePostMessage: true
-  }, 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.
-
-## More Information
-
-* [Overview of JSON Web Tokens](/jwt)
-* [Silent Authentication for Single Page Apps](/api-auth/tutorials/silent-authentication)
-* [How to get, use and revoke a Refresh Token](/tokens/refresh-token)
-* [A writeup on the contents of a JSON Web Token](https://scotch.io/tutorials/the-anatomy-of-a-json-web-token)
-* [Wikipedia page on JSON Web Tokens](https://en.wikipedia.org/wiki/JSON_Web_Token)
-* [IETF RFC for JWT](https://tools.ietf.org/html/rfc7519)
-* [Debugger for viewing JSON Web Tokens](http://jwt.io/)
-* [Using JWTs as API keys](https://auth0.com/blog/2014/12/02/using-json-web-tokens-as-api-keys/)
-* [Blacklisting JWTs](https://auth0.com/blog/2015/03/10/blacklist-json-web-token-api-keys/)
-* [Vulnerabilities in use of JWT’s by libraries](https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/)
-* [Cookies vs Tokens](https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/)
-* [Ten things about tokens](https://auth0.com/blog/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/)
-* [Description of the JWT expiration](/applications)
-* [Discussion of web apps vs apis, cookies vs tokens](/apps-apis)
-* [What happens if the ID token is too large?](https://auth0.com/forum/t/id-token-is-too-large/3116)
-* [Why JWT is getting more popular](https://auth0.com/blog/2015/07/21/jwt-json-webtoken-logo/)
-* [Sample for altering scopes in a Rule](https://github.com/auth0/rules/blob/dff2a3e72f01d33af3086414be7cf115b19eea0c/rules/custom-scopes.md)
diff --git a/articles/tokens/idp.md b/articles/tokens/idp.md
deleted file mode 100644
index e50a481862..0000000000
--- a/articles/tokens/idp.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-description: How to obtain Identity Provider access tokens.
----
-
-# Identity Provider Access Tokens
-
-## Overview
-
-Third-party access tokens are issued by Identity Providers (including Social providers like Facebook and Google) 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.
-
-## How to obtain Identity Provider access tokens
-
-Identity Provider (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 containing an Auth0 API token generated with  `read:user_idp_tokens` scope. 
-
-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).
-
-## How to control contents of IdP access tokens
-
-The contents of third-party access tokens will vary by the issuing IdP.
-
-## Validity
-
-The validity period for third-party access tokens will vary by the issuing IdP.
-
-## Renewing 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.
-
-## Termination of tokens
-
-The ability to terminate IdP access tokens is up to each provider.
-
-## Uses
-
-The IdP access token is used to call the API offered by the provider that issued the token. For example, an access token issued after authentication to Facebook could be used to call the Facebook Graph API.
-
-For more information see:
-
-* [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)
-
-## Best practices
-
-### Validation
-
-In general, IdP access tokens are passed to the issuing provider, and the issuing provider is responsible for validation of the token.
diff --git a/articles/tokens/index.html b/articles/tokens/index.html
deleted file mode 100644
index e104458e6b..0000000000
--- a/articles/tokens/index.html
+++ /dev/null
@@ -1,149 +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 six 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/jwt.md b/articles/tokens/jwt.md
deleted file mode 100644
index d9dfad2170..0000000000
--- a/articles/tokens/jwt.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-url: /jwt
-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.
----
-# JSON Web Tokens (JWT) in Auth0
-
-> For more information on all the types of access tokens used by Auth0, see [Tokens](/tokens).
-
-<%= include('../videos/_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 an 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.
-
-## When should you use JSON Web Tokens?
-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.
-There are three types of claims: *reserved*, *public*, and *private* claims.
-
-- **Reserved claims**: These is a set of predefined claims which are not mandatory but recommended, to provide a set of useful, interoperable claims. Some of them are: **iss** (issuer), **exp** (expiration time), **sub** (subject), **aud** (audience), and others.
-
-  > Notice that the claim names are only three characters long as JWT is meant to be compact.
-
-- **Public claims**: These can be defined at will by those using JWTs. But to avoid collisions they should be defined in the IANA JSON Web Token Registry or be defined as a URI that contains a collision resistant namespace.
-
-- **Private claims**: These are the custom claims created to share information between parties that agree on using them.
-
-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.
-
-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:
-
-```
-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)
-
-## Why should we use JSON Web Tokens?
-
-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_
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.md b/articles/tokens/refresh-token.md
deleted file mode 100644
index 55245f4153..0000000000
--- a/articles/tokens/refresh-token.md
+++ /dev/null
@@ -1,159 +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 Tokens
-
-A **refresh token** is a special kind of [JWT](/jwt) 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.  
-
-For more information on the types of access tokens used by Auth0, see [Tokens](/tokens).
-
-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/).
-
-## Introduction
-
-The response of an [authentication request](/protocols) can result in an `id_token` (JWT) being issued by Auth0. This token is used to make authenticated calls to a secured API. JWTs have an expiration date indicated by the `exp` claim (among other security measures, like signing). Applications that are installed locally on a device (such as a desktop or smartphone) may want to avoid asking the user to enter their credentials each time this token expires.
-
-A refresh token allows the application to request Auth0 to issue a new `id_token` directly, without needing to re-authenticate the user. This will work as long as the refresh token has not been revoked.
-
-Refresh tokens can be issued for each combination of __app__, __user__ and __device__. Once the Auth0 refresh token is issued, the values of the client, user, and device set during its creation cannot be changed.
-
-::: panel-warning Secure Storage
-Refresh tokens must be stored securely by an application since they allow a user to remain authenticated essentially forever.
-:::
-
-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).
-
-## 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-client) 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.
-
-**NOTE**: In this case, the token was returned to the client directly in the URL because the [implicit flow](/protocols#oauth2-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-info Rate limits
-Obtaining new tokens using the `refresh_token` should occur only if the `id_token` has expired. For example, it is a bad practice to call the endpoint to get a new 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.
-
-### 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:
-
-```json
-[
-  {
-    "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.
-
-![](/media/articles/tokens/dashboard-revoke-refresh-token.png)
-
-Click **UNLINK** to confirm.
-
-## SDK Support
-
-The [Lock](/libraries/lock), [auth0.js](/libraries/auth0js), and [auth0-angular.js](https://github.com/auth0/auth0-angular) libraries include support to obtain and use refresh tokens.
-
-For more information about using refresh tokens with these libraries, see:
-
-* [Lock Android: Refreshing JWT Tokens](/libraries/lock-android/refresh-jwt-tokens)
-
-* [Lock iOS: Saving and Refreshing JWT Tokens](/libraries/lock-ios/save-and-refresh-jwt-tokens)
-
-* [Get a refresh token with Auth0.js](https://github.com/auth0/auth0.js#login) and [Use a refresh token to get new id_token](https://github.com/auth0/auth0.js#refresh-token)
-
-* [Using Refresh Tokens in Mobile Applications](https://github.com/auth0/auth0-angular/blob/master/docs/refresh-token.md)
diff --git a/articles/tokens/refresh_token.md b/articles/tokens/refresh_token.md
deleted file mode 100644
index 35245c748c..0000000000
--- a/articles/tokens/refresh_token.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: Auth0 refresh_token
-description: A refresh token allows an application to request Auth0 to issue a new id_token directly, without needing to re-authenticate the user.
----
-
-# Auth0 `refresh_token`
-
-Refresh tokens contain the information required to obtain a new access token. This access token can then be used to authenticate the user without them having 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. 
-
-Refresh tokens are subject to strict storage requirements to ensure that they are not leaked. Refresh tokens can also be blacklisted by the authorization server. 
-
-See the [Refresh Token](/refresh-token) page for information on how to obtain, view and revoke refresh tokens.
-
-### Additional information
-
-* [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/)
-
-* [Lock Android: Refreshing JWT Tokens](/libraries/lock-android/refresh-jwt-tokens)
-
-* [Lock iOS: Saving and Refreshing JWT Tokens](/libraries/lock-ios/save-and-refresh-jwt-tokens)
-
-* [Using Refresh Tokens in Mobile Applications](https://github.com/auth0/auth0-angular/blob/master/docs/refresh-token.md)
-
-* [Get a refresh token with Auth0.js](https://github.com/auth0/auth0.js#login)
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 d077ec086e..0000000000
--- a/articles/topics/extensibility.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Auth0 Extensibility
-articles:
-  - rules
-  - extensions
----
-
-# Extensibility
-
-<%= include('./_topic') %>
diff --git a/articles/topics/getting-started.md b/articles/topics/getting-started.md
deleted file mode 100644
index 12de8303ec..0000000000
--- a/articles/topics/getting-started.md
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Getting Started with Auth0
-articles:
-  - overview
-  - videos
-  - architecture-scenarios
----
-
-# Getting Started
-
-<%= include('./_topic') %>
diff --git a/articles/topics/guides.md b/articles/topics/guides.md
deleted file mode 100644
index 9c912d37df..0000000000
--- a/articles/topics/guides.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Guides
-articles:
-  - rules
-  - email
----
-
-# Guides
-
-<%= include('./_topic') %>
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 191c7bd55f..0000000000
--- a/articles/topics/identity-glossary.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: Identity Glossary
-articles:
-  - protocols
-  - tokens
-  - tokens/jwt
----
-
-::: panel-info Auth0 Identity Glossary
-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/tutorials/adding-generic-oauth1-connection.md b/articles/tutorials/adding-generic-oauth1-connection.md
deleted file mode 100644
index 1ff4daeec2..0000000000
--- a/articles/tutorials/adding-generic-oauth1-connection.md
+++ /dev/null
@@ -1,87 +0,0 @@
----
-description: How to add a generic Oauth1 Authorization Server to Auth0.
----
-
-# Adding a generic OAuth1 Authorization Server to Auth0
-
-The most common [identity providers](/identityproviders) are available on Auth0's [dashboard](${manage_url}). However, you can add any __OAuth1 Authorization Server__ to Auth0 as an identity provider.
-
-To create an arbitrary __OAuth1__ connection, you use __[Auth0's Connections API](/api/v2#!/Connections/post_connections)__. 
-
-This example would create a custom Twitter connection:
-
-```
-curl -H "Content-Type: application/json" -H 'Authorization: Bearer YOUR_GLOBAL_CLIENT_ACCESS_TOKEN' -d @twitter.json https://${account.namespace}/api/connections
-```
-
-```
-{
-  "name": "custom-twitter",
-  "strategy": "oauth1",
-  "options": {
-    "client_id": "YOUR_TWITTER_CLIENT_ID",
-    "client_secret": "YOUR_TWITTER_CLIENT_SECRET",
-    "requestTokenURL": 'https://api.twitter.com/oauth/request_token',
-    "accessTokenURL": 'https://api.twitter.com/oauth/access_token',
-    "userAuthorizationURL": 'https://api.twitter.com/oauth/authenticate',
-    "scripts": {
-      "fetchUserProfile": "function (token, tokenSecret, ctx, cb) {var OAuth = new require('oauth').OAuth;var oauth = new OAuth(ctx.requestTokenURL,ctx.accessTokenURL,ctx.client_id,ctx.client_secret,'1.0',null,'HMAC-SHA1');oauth.get('https://api.twitter.com/1.1/users/show.json?user_id=' + ctx.user_id,token,tokenSecret,function(e, b, r) {if (e) return cb(e);if (r.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode));cb(null, JSON.parse(b));});}"
-    }
-  }
-}
-```
-
-The key parameters for a connection are:
-
-* **name**: this is how the connection can be referenced later on in Auth0 or in your app.
-* **strategy**: this must be __oauth1__. It defines the protocol implemented by the provider.
-
-The __options__ object:
-
-* **client_id** and **client_secret** must be obtained from your provider.
-* **requestTokenURL**: `https://api.twitter.com/oauth/request_token`
-* **accessTokenURL**: `https://api.twitter.com/oauth/access_token`
-* **userAuthorizationURL**: `https://api.twitter.com/oauth/authenticate`
-* **fetchUserProfile**: Auth0 allows you to define a custom script that returns a JSON object with user info. What you do in the script is up to you. For convenience, the __[OAuth](https://www.npmjs.com/package/oauth)__ module is included to simplify OAuth1 calls.
-
-The script will have the following signature:
-
-```
-function(token, tokenSecret, ctx, callback){
-  
-  var profile = {
-    user_id: '123',
-    given_name: 'Eugenio',
-    family_name: 'Pace',
-    email: 'eugenio@mail.com'
-  };
-
-  callback(null, profile);
-}
-```
-
-The `token` and `tokenSecret` parameters will often be used for authenticating requests to the provider's API. 
-
-> We recommend using the field names in the [normalized profile](/user-profile).
-
-Notice that you can manipulate the profile returned from the provider to filter/remove/add anything in it. However, we recommend you keep this script as simple as possible. More sophisticated manipulation of the user information can be achieved through [Rules](/rules). 
-
-> One advantage of using Rules is that they apply to __any__ connection.
-
-## Using your new connection
-
-You can use any of the Auth0 standard mechanisms to login a user with the new connection (e.g. direct links, [Auth0 Lock](lock), [auth0.js](auth0js), etc.). 
-
-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=THE_NAME_OF_THE_CONNECTION
-```
-
-
-## Other resources
-
-* [Custom OAuth2/OAuth1 Connections samples](oauth2-examples)
-* [Identity Providers in Auth0](identityproviders)
-* [Protocols](protocols)
-* [Custom OAuth2 Connections](oauth2)
diff --git a/articles/tutorials/adding-scopes-for-an-external-idp.md b/articles/tutorials/adding-scopes-for-an-external-idp.md
deleted file mode 100644
index 399d365ea8..0000000000
--- a/articles/tutorials/adding-scopes-for-an-external-idp.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-description: How to add scopes to your IdP connection.
----
-
-# Add scopes/permissions to call  Identity Provider's APIs
-
-Once user is logged in, you can get the user profile and then the associated `accessToken` to call the Identity Provider APIs as described in: [Call an Identity Provider API](/what-to-do-once-the-user-is-logged-in/calling-an-external-idp-api)
-
-However, if you are receiving `Access Denied` when calling the IdP API, you probably have not requested the correct permissions for the user during login.
-
-To configure the scopes/permissions needed from the user, go to the [Connections > Social](${manage_url}/#/connections/social) section of Auth0 Dashboard. There, you can click on an IdP to select the particular scopes required. 
-
-For example, if you click the Facebook connection, you can select the required scopes listed in the configuration pop-up:
-
-![Scopes for Facebook](/media/articles/what-to-do-once-the-user-is-logged-in/adding-scopes-for-an-external-idp/scopes.png)
diff --git a/articles/tutorials/authenticating-a-tessel-device.md b/articles/tutorials/authenticating-a-tessel-device.md
deleted file mode 100644
index 94e500c36c..0000000000
--- a/articles/tutorials/authenticating-a-tessel-device.md
+++ /dev/null
@@ -1,129 +0,0 @@
----
-description: How to authenticate and authorize a Tessel device with Auth0.
----
-
-# Authenticating & Authorizing a Tessel device with Auth0
-
-[Tessel](https://tessel.io) is an amazing board. Not only it has a great hardware spec and a great extensibility story, you can program it in Javascript! When it was announced on Kickstarter we immediately supported it and waited long weeks to get hold of one.
-
-![](/media/articles/scenarios/tessel/TM-00-04-ports.png)
-
-It finally arrived and were able to write our first program: get a token from Auth0 and call an API.
-
-> Tessel aims for full compatibility with Javascript. Most of core node modules also work, but not all of them. See [the docs for full details](https://github.com/tessel/docs/blob/master/compatibility.md).
-
-## The sample
-
-This example is straight-forward:
-
-1. We call the `Resource Owner` endpoint on Auth0 with device credentials
-2. Get a token back
-3. We use the token to call an API
-
-![](/media/articles/scenarios/tessel/tessel-flow.png)
-
-
-```
-var http = require('https');
-var tessel = require('tessel');
-
-tessel.syncClock(function () {
-
-  var device_id = 'tessel-01';
-  var password = 'THE TESSEL PASSWORD';
-
-  authenticate(device_id, password, function(e,token){
-
-    if(e) return console.log("Error:" + e);
-
-    getDeviceProfile(token.access_token, function(e, profile){
-      console.log("Device profile:");
-      console.log(profile);
-    });
-  });
-
-  function getDeviceProfile(token, done){
-    request('${account.namespace}',
-          '/userinfo',
-          'GET',
-          {
-          "Content-type": "application/json",
-          "Authorization": "Bearer " + token
-        },
-        null,
-        function(e,response){
-          if(e) return done(e);
-          done(null, JSON.parse(response));
-        });
-  }
-
-  function authenticate(device_id, password, done)
-  {
-    request('${account.namespace}',
-          '/oauth/ro',
-          'POST',
-          {
-          "Content-type": "application/json",
-        },
-        JSON.stringify({
-            client_id:   '${account.clientId}',
-            username:    device_id,
-            password:    password,
-            connection:  'devices',
-            grant_type:  "password",
-            scope: 'openid'
-          }),
-          function(e,response){
-            if(e) return done(e);
-            done(null, JSON.parse(response));
-        });
-  }
-
-  function request(host, path, method, headers, body, done){
-    var options = {
-      hostname: host,
-      path: path,
-      method: method,
-      headers: headers
-    };
-
-    var req = http.request(options, function(res) {
-      res.setEncoding('utf8');
-
-      var response = "";
-
-      res.on('data', function (chunk) {
-        response += chunk;
-      });
-
-      res.on('end', function(){
-        done(null, response);
-        });
-    });
-
-    req.on('error', function(e) {
-      done(e);
-    });
-
-    if( body ) req.write(body);
-    req.end();
-  }
-});
-```
-
-Noteworthy highlights of the code:
-
-1. This is 99% compatible with node (the only device specific module.is `tessel` that we only use to make sure all SSL calls happen with adequate time references.
-2. The `request` function, is a simple wrapper on `http` module functions. The `request` module doesn't currently work in Tessel.
-
-The `Resource Owner` endpoint requires credentials (e.g. username/password), so the backend user store connected to Auth0 needs to support this (like a Database connection or Active Directory).
-
-## Tessel Setup
-
-* Run `tessel update` to make sure you install the latest firmware with SSL support.
-* You will obviously need connection to the web. You can setup WiFi with the `tessel wifi` command.
-
-## Summary
-Tessel is awesome. We see a lot of potential. This sample shows how easy it is to connect it with Auth0.
-
-> Always send credentials (e.g. `username`/`password`) over secured networks.
diff --git a/articles/tutorials/authenticating-devices-using-mqtt.md b/articles/tutorials/authenticating-devices-using-mqtt.md
deleted file mode 100644
index a3f100826e..0000000000
--- a/articles/tutorials/authenticating-devices-using-mqtt.md
+++ /dev/null
@@ -1,251 +0,0 @@
----
-description: How to authenticate and authorize devices using MQTT with Auth0.
----
-
-# Authenticating & Authorizing Devices using MQTT with Auth0
-
-[MQTT](http://en.wikipedia.org/wiki/MQ_Telemetry_Transport) is a lightweight protocol often used for devices to communicate with other systems. It is designed for the __publish/subscribe__ messaging pattern.
-
-Generally speaking there are 3 components:
-
-1. A `publisher` of messages.
-2. A `subscriber` to messages.
-3. A `broker` that connects one and the other.
-
-There's a notion of `topics` (a.k.a. as `channels` or `subjects`) which messages are associated with. Topics are used to route messages between publishers and subscribers.
-
-The MQTT protocol supports a basic authentication mechanism based on `usernames` & `passwords`. These credentials are sent with the `CONNECT` message.
-
-This article shows an integration between nodejs based MQTT broker: [mosca](https://github.com/mcollina/mosca) and [Auth0](http://auth0.com). In this example, Auth0 is used to __authenticate__ `publishers` and `subscribers` to the broker, and then __authorize__ routing of messages.
-
-> mosca is a nodejs based messaging broker that implements other protocols besides MQTT. It offers great extensibility features. It is surprisingly simple to integrate with Auth0.
-
-![](/media/articles/scenarios/mqtt/mqtt-dataflow.png)
-
-## Components of the solution
-
-### The Broker
-
-__mosca__ is straightforward to host and can be embedded in other servers. For the purpose of this sample, we simply self-host a __mosca__ server:
-
-
-```
-var mosca = require('mosca')
-var Auth0Mosca = require('auth0mosca');
-
-var settings = {
-  port: 9999,
-};
-
-//'Thermostats' is a Database connection where all devices are registered.
-var auth0 = new Auth0Mosca('https://eugeniop.auth0.com', '{Your Auth0 ClientID}', '{Your Auth0 Client Secret}','Thermostats');
-
-//Setup the Mosca server
-var server = new mosca.Server(settings);
-
-//Wire up authentication & authorization to mosca
-server.authenticate = auth0.authenticateWithCredentials();
-server.authorizePublish = auth0.authorizePublish();
-server.authorizeSubscribe = auth0.authorizeSubscribe();
-
-server.on('ready', setup);
-
-// Fired when the mqtt server is ready
-function setup() {
-    console.log('Mosca server is up and running');
-}
-
-server.on('clientConnected', function(client) {
-  console.log('New connection: ', client.id );
-});
-```
-
-This creates a server listening for MQTT messages on port 9999. __mosca__ allows you to override the 3 functions used to authenticate and authorize operations.
-
-In this sample, we are using a very simple module `auth0mosca` to perform these functions. Auth0 is wired up to __mosca__.
-
-### The Auth0Mosca module
-
-This little [module](https://www.npmjs.org/package/auth0mosca) provides the 4 functions used by __mosca__, `authenticateWithCredentials`, `authenticateWithJWT`, `authorizePublish` and `authorizeSubscribe`:
-
-```
-var request = require('request');
-var jwt = require('jsonwebtoken');
-
-function Auth0Mosca(auth0Namespace, clientId, clientSecret, connection)
-{
-  this.auth0Namespace = auth0Namespace;
-  this.connection = connection;
-  this.clientId = clientId;
-  this.clientSecret = clientSecret;
-}
-
-Auth0Mosca.prototype.authenticateWithJWT = function(){
-
-  var self = this;
-
-  return function(client, username, password, callback) {
-
-    if( username !== 'JWT' ) { return callback("Invalid Credentials", false); }
-
-    // console.log('Passsord:'+password);
-
-    jwt.verify(password, self.clientSecret, function(err,profile){
-          if( err ) { return callback("Error getting UserInfo", false); }
-          console.log("Authenticated client " + profile.user_id);
-          console.log(profile.topics);
-          client.deviceProfile = profile;
-          return callback(null, true);
-        });
-  }
-}
-
-Auth0Mosca.prototype.authenticateWithCredentials = function(){
-
-  var self = this;
-
-  return function(client, username, password, callback) {
-
-     var data = {
-        client_id:   self.clientId, // {client-name}
-        username:    username.toString(),
-        password:    password.toString(),
-        connection:  self.connection,
-        grant_type:  "password",
-        scope: 'openid name email' //Details: https:///scopes
-    };
-
-    request.post({
-        headers: {
-                "Content-type": "application/json"
-            },
-        url: self.auth0Namespace + '/oauth/ro',
-        body: JSON.stringify(data)
-      }, function(e,r,b){
-        if(e){
-          console.log('Error in Authentication');
-          return callback(e,false);
-        }
-        var r = JSON.parse(b);
-
-        if( r.error ) { return callback( r, false); }
-
-        jwt.verify(r.id_token, self.clientSecret, function(err,profile){
-          if( err ) { return callback("Error getting UserInfo", false); }
-          client.deviceProfile = profile;
-          return callback(null, true);
-        });
-    });
-  }
-}
-
-Auth0Mosca.prototype.authorizePublish = function() {
-  return function (client, topic, payload, callback) {
-   callback(null, client.deviceProfile && client.deviceProfile.topics && client.deviceProfile.topics.indexOf(topic) > -1);
-  }
-}
-
-Auth0Mosca.prototype.authorizeSubscribe = function() {
-  return function(client, topic, callback) {
-  callback(null, client.deviceProfile && client.deviceProfile.topics && client.deviceProfile.topics.indexOf(topic) > -1);
-}
-
-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.
-
-By convention, all devices connected to the broker have an account in Auth0:
-
-![](/media/articles/scenarios/mqtt/7JNZP.png)
-
-Notice that the Device Profile also has a property `topics`. This is an array with all topics this particular device is allowed to. In the screenshot above, `thermostat-1a` will be allowed publishing (or subscribing) to topics `temperature` and `config`.
-
-The `authorizePublish` and `authorizeSubscribe` functions simply check that a particular requested topic is present in this list.
-
-The `authenticateWithJWT` expects a JWT in the `password` field. The flow in this case is slightly different:
-
-1. The publisher & subscriber will obtain a token
-2. They connect to `mosca` submitting the JWT
-3. `mosca` validates the JWT
-4. Messages are sent and re-transmitted to subscribers
-
-![](/media/articles/scenarios/mqtt/mqtt-dataflow2.png)
-
-Publishers and subscribers will obtain the JWT through some means. Notice that the broker doesn't need to communicate with Auth0 anymore. JWTs are self-contained artifacts that can be validated with the secret used to sign them.
-
-### The Publisher
-
-For this sample, the publisher is a simple nodejs program that uses the `mqtt` module, and adds the right credentials:
-
-```
-var mqtt = require('mqtt')
-  , host = 'localhost'
-  , port = '9999';
-
-var settings = {
-  keepalive: 1000,
-  protocolId: 'MQIsdp',
-  protocolVersion: 3,
-  clientId: 'Thermostat 1a',
-  username:'thermostat-1a',
-  password:'the password'
-}
-
-// client connection
-var client = mqtt.createClient(port, host, settings);
-
-setInterval(sendTemperature, 2000, client);
-
-function sendTemperature(client){
-  var t = {
-    T: Math.random() * 100,
-    Units: "C"
-  };
-
-  client.publish('temperature', JSON.stringify(t));
-}
-```
-
-Of course `username` & `password` here will have to match whatever is stored in Auth0.
-
-### The subscriber
-The subscriber is very similar to the publisher:
-
-```
-var mqtt = require('mqtt')
-  , host = 'localhost'
-  , port = '9999';
-
-var settings = {
-  keepalive: 1000,
-  protocolId: 'MQIsdp',
-  protocolVersion: 3,
-  clientId: 'Reader-X1',
-  username:'reader-X1',
-  password:'the password'
-}
-
-// client connection
-var client = mqtt.createClient(port, host, settings);
-
-
-client.subscribe('temperature');
-
-client.on('message', function(topic, message) {
-
-  if(topic ==='temperature')
-  {
-    console.log('New reading', message);
-  }
-});
-```
-
-## Summary
-This shows how easy it is to use Auth0 in various scenarios. Auth0's user store is being used to manage devices. Of course much more sophisticated authorization rules could be written based on other conditions: time, location, device_id, etc. All these would be very simple to implement, either through additional profile attributes or through [Auth0 Rules](/rules). This also shows how the flexible Auth0 Profile can be extended to support arbitrary artifacts (e.g. `topics` in the example).
-
-> Caveats: it is never a good idea to send credentials (`username`/`password`) over unsecured networks. There are other implementations that provide transport level security that would prevent message contents to be revealed. __mosca__ supports TLS as an example. Likely a production deployment would favor this, unless all traffic happens in a closed network.
-
-### Acknowledgements
-Many thanks to [Matteo Collina](http://www.matteocollina.com/) for the review of this article, and for building the awesome __mosca__.
diff --git a/articles/tutorials/aws-api-setup.md b/articles/tutorials/aws-api-setup.md
deleted file mode 100644
index e051d8afe1..0000000000
--- a/articles/tutorials/aws-api-setup.md
+++ /dev/null
@@ -1,108 +0,0 @@
----
-description: How to enable delegated authentication with AWS APIs.
-url: /aws-api-setup
----
-# Setup AWS for Delegated Authentication with APIs
-
-To enable delegated authentication with AWS APIs, you must create a **SAML Provider** and one or more **Roles**.
-
-## Create a SAML Provider
-
-To create a SAML provider, follow these steps:
-
-1. Go to the [AWS IAM Console](https://console.aws.amazon.com/iam/home#home). Click on **Identity Providers** in the left menu and then click **Create Provider**:
-
-  ![](/media/articles/aws-api-setup/aws-api-setup-1.png)
-
-2. Select **SAML** as the **Provider Type** and enter a name for your provider:
-
-  ![](/media/articles/aws-api-setup/aws-api-setup-2.png)
-
-3. Download your metadata document from <% if (account.userName) { %><% } else { %>`https://${account.namespace}/samlp/metadata/${account.clientId}`<% } %>.
-
-  Click **Choose File** and browse to the metadata document you just downloaded. Click **Next Step**:
-
-  ![](/media/articles/aws-api-setup/aws-api-setup-3.png)
-
-4. Verify your provider information and click **Create**:
-
-  ![](/media/articles/aws-api-setup/aws-api-setup-4.png)
-
-## Create a Role
-
-Now create a role with one or more associated policies. (You can create as many roles as required.)
-
-1. On the AWS IAM Console, click on **Roles** in the left menu and then click **Create New Role**:
-
-  ![](/media/articles/aws-api-setup/aws-api-setup-5.png)
-
-2. Provide a name for your new role and click **Next Step**:
-
-  ![](/media/articles/aws-api-setup/aws-api-setup-6.png)
-
-3. Select **Role for Identity Provider Access**. Then select **Grant API access to SAML providers** and click **Next Step**:
-
-  ![](/media/articles/aws-api-setup/aws-api-setup-7.png)
-
-4. Select or enter the following values:
-
-  * **SAML Provider**: the provider you just created
-  * **Attribute**: `SAML:iss`
-  * **Value**: `urn:${account.namespace}`
-
-  and click **Next Step**:
-
-  ![](/media/articles/aws-api-setup/aws-api-setup-8.png)
-
-5. On the Verify Role Trust page, accept the Policy Document as provided. Click **Next Step**:
-
-  ![](/media/articles/aws-api-setup/aws-api-setup-9.png)
-
-6.  At **Attach Policy**, either select a pre-defined policy to attach or define a custom policy as defined in the [next section](#create-a-custom-policy). Click **Next Step**
-
-7. Review the information and click **Create Role**:
-
-  ![](/media/articles/aws-api-setup/aws-api-setup-10.png)
-
-## Create a Custom Policy
-
-In this example, you will create a policy that grants full access to the S3 resource: `YOUR_BUCKET/<%= '${saml:sub}' %>`. This will be evaluated at run-time and replaced with the `user_id` of the logged-in user.
-
-1. On the **Roles** page, select the role you just created.
-
-  On the **Permissions** tab under **Inline Policies**, click the link to create an inline policy:
-
-  ![](/media/articles/aws-api-setup/aws-api-setup-11.png)
-
-2. Name your policy and enter the following code in the **Policy Document** field:
-
-  ```
-  {
-    "Version": "2012-10-17",
-    "Statement": [{
-        "Effect": "Allow",
-        "Action": [
-          "*"
-        ],
-        "Resource": [
-        "arn:aws:s3:::YOUR_BUCKET/<%= '${saml:sub}' %>",
-        "arn:aws:s3:::YOUR_BUCKET/<%= '${saml:sub}' %>/*"]
-    }]
-  }
-  ```
-
-3. Click **Validate Policy** to check your syntax, then click **Apply Policy**.
-
-  ![](/media/articles/aws-api-setup/aws-api-setup-12.png)
-
-## Copy the ARN values
-
-1. From the summary page of the role you just created, copy the **Role ARN** value. You will use this value later when calling the `/delegation` endpoint in Auth0.
-
-  ![](/media/articles/aws-api-setup/aws-api-setup-13.png)
-
-2. From the summary page of the identity provider you created previously, copy the **Provider ARN** value. You will use this value as the **Principal ARN** in the [Rule you will build to be used in conjunction with the call to Auth0's `/delegation` endpoint](/integrations/aws#get-the-aws-token-for-an-authenticated-user).
-
-  ![](/media/articles/aws-api-setup/aws-api-setup-14.png)
-
-**NOTE:** For more information on supported AWS APIs, see: [AWS Services That Work with IAM](http://docs.aws.amazon.com/IAM/latest/UserGuide/Using_SpecificProducts.html).
diff --git a/articles/tutorials/azure-tutorial.md b/articles/tutorials/azure-tutorial.md
deleted file mode 100644
index 833c506be0..0000000000
--- a/articles/tutorials/azure-tutorial.md
+++ /dev/null
@@ -1,63 +0,0 @@
----
-description: How to use Auth0 with Microsoft Azure.
-url: /azure-tutorial
----
-# 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.
-
-To integrate applications supported by the Microsoft Azure platform, consider these tutorials:
-
-* [ASP.NET application](/server-platforms/aspnet) 
        
-Simple non-intrusive integration with any version of ASP.NET.
-
-* [Node.js application](/server-platforms/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).
-
-We recommend creating one application per environment in Auth0 (e.g. "Dev", "Test", "QA", etc).
-
-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
-
-`Web.config`
-```
-
-
-
-```
-
-`Web.Release.config`
-```
-
-  
-    
-    
-    
-  
-
-```
-
-Then, whenever you have to reference the ClientID, Secret or callback, you use this syntax:
-
-```
-
-
-```
-
-Whether you deploy to Microsoft Azure Web Sites or a Cloud Service the Web.config transformation will run.
-
-> **TIP**: to test your web.config transforms you can use this [awesome tool](http://webconfigtransformationtester.apphb.com/)
diff --git a/articles/tutorials/blacklisting-attributes.md b/articles/tutorials/blacklisting-attributes.md
deleted file mode 100644
index 022f9b75fa..0000000000
--- a/articles/tutorials/blacklisting-attributes.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-description: How to blacklist user attributes that you do not want persisting in Auth0 databases.
----
-
-# Blacklisting Attributes
-
-In the event that 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.
-
-## Blacklisting Attributes via the Management API
-
-You may blacklist selected attributes by making a `PATCH /api/v2/connections/{id}` call to the Management API.
-
-To assist you in creating the appropriate request, you may use the [Update a Connection](/api/v2#!/Connections/patch_connections_by_id) section of the [APIv2 Explorer Page](/api/v2).
-
-Prior to beginning, please ensure that you are logged in to an account that is permitted to make changes to your Auth0 configuration. This will allow the API Explorer to dynamically generate the required API token with the necessary API Key and Secret.
-
-### Making a Test Call or Generating the cURL Command via the API Explorer Page
-
-1.  Under Scopes, click on "update:connections" to add the scope required for this particular endpoint to the [API token](/api/v2/tokens).
-2. Populate the `id` field with ID of the connection you would like to update.
-3. Populate the `body` field with the JSON snippet that contains the information that will be used to update your configuration.
-4.  Click on "TRY" to get a test response to your input.
-5.  If you are satisfied with the results of your test call to the API, click "get curl command" to get the constructed call.
-
-Sample cURL command:
-
-```text
-curl -H "Authorization: Bearer YOUR_TOKEN" -X PATCH  -H "Content-Type: application/json" -d '{REQUEST BODY}' https://${account.namespace}/api/v2/tenants/settings
-```
-
-When updating the JSON that will be included in the `body`, please note that the fields you would like to blacklist are included in `options`:
-
-```text
-{
-  "options": {
-    "non_persistent_attrs": ["", ""]
-  },
-  "enabled_clients": [
-    ""
-  ]
-}
-```
-
-HTTP Request:
-
-```har
-{
-  "method": "PATCH",
-  "url": "https://${account.namespace}/api/v2/tenants/settings",
-  "httpVersion": "HTTP/1.1",
-  "cookies": [],
-  "headers": [
-    { "name": "Authorization", "value": "Bearer YOUR_TOKEN" }
-  ],
-  "queryString" : [],
-  "postData": {
-    "mimeType": "application/json",
-    "text": "{\"options\": {\"non_persistent_attrs\": [\"\", \"\"]}\", \"enabled_clients\": [\"\"]}"
-  },
-  "headersSize" : -1,
-  "bodySize" : -1,
-  "comment" : ""
-}
-```
-
-## Limitations
-
-Only root fields (e.g. `user.name` or `user.email`) may be blacklisted.
-
-When you blacklist attributes, they will be still be available via:
-
-- rules;
-- 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 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.
-
-### Working with the Limitations
-
-If any of the above limitations regarding blacklisted attributes are unacceptable, you may write a [rule](/rules) to encrypt the data and have the data persist the `user.app_metadata` object.
diff --git a/articles/tutorials/building-multi-tenant-saas-applications-with-azure-active-directory.md b/articles/tutorials/building-multi-tenant-saas-applications-with-azure-active-directory.md
deleted file mode 100644
index 789a655e83..0000000000
--- a/articles/tutorials/building-multi-tenant-saas-applications-with-azure-active-directory.md
+++ /dev/null
@@ -1,249 +0,0 @@
----
-description: How to build a multi-tenant SaaS application with Azure AD and Auth0.
----
-
-# Building multi-tenant, SaaS applications with Azure AD and Auth0
-
-Azure AD is often used as a user directory for Office 365, Intune, Dynamics CRM and applications you're building for the users in your organization.
-
-![](/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-ad-mt-single-tenant-example.png)
-
-In that case the users in your organization's directory (contoso.onmicrosoft.com) will be able to access the applications you registered in your directory (Contoso Intranet and Office 365). This is how the [standard integration with Auth0 works](/waad-clientid), you'll create an application in Azure AD that points to Auth0 after which you can create it as an Azure AD Connection in the dashboard.
-
-A more advanced concept in Azure AD is the support for multi-tenant applications. This is where your directory can define an application (typically a SaaS application) which can be used by other directories (your customers).
-
-![](/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-ad-multi-tenant-example.png)
-
-In this example Fabrikam Corporation is an ISV hosting a Timesheet SaaS applications. They have been using Auth0 to make sure customers can login with their Facebook, Google, LinkedIn, ... accounts. But now they want to extend this support and provide SSO to organizations which are using Azure AD (or Office 365). For Fabrikam Corporation this can be a great way to attract new customers because they can offer SSO to thousands of companies already using Azure AD/Office 365 in just a few clicks.
-
-Contoso is one of their new customers which have signed up with their Azure AD. Users in this directory will now have SSO to Fabrikam's Timesheet SaaS and will be able to use their existing Contoso credentials after going through a simple consent flow.
-
-This document will cover how Fabrikam can create a multi-tenant Azure AD application, how it will integrate with Auth0 and how the end user experience will be when signing up for the application.
-
-## Prerequisites
-
-Before you can create a multi-tenant application in Azure AD you'll need a Microsoft Azure subscription and a domain name (like fabrikamcorp.com). This domain name is a requirement for adding multi-tenant applications to Azure AD.
-
-## Creating an application in Auth0
-
-We'll start by creating an application in Auth0 in which we define the Allowed Callback URLs for our application. In this example we're building an ASP.NET MVC application which runs locally and in Azure Web Sites, but keep in mind that this scenario works with any technology and any hosting platform.
-
-![](/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-new-a0-app.png)
-
-## Creating an application in Azure AD
-
-The first thing Fabrikam will do is create a new directory in Azure AD if they haven't got one already.
-
-![](/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-create-directory.png)
-
-The final application will be running on https://timesheets.fabrikamcorp.com so we'll need to register `fabrikamcorp.com` as a domain first before we can create the multi-tenant application.
-
-On the Domains tab you can create a new domain:
-
-![](/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-domain-name.png)
-
-This domain will also require verification and you'll need to add a TXT/MX record as described in the verification page.
-
-![](/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-domain-verified.png)
-
-The DNS propagation can take some minutes so if you see the "Could not verify domain" error that's normal. You can use sites like [What's My DNS](http://www.whatsmydns.net) to follow up on the DNS propagation of your domain.
-
-The next step will be to create a new Application in your Directory.
-
-![](/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-new-app.png)
-
-![](/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-new-app-name.png)
-
-The SIGN-ON URL is the url of your application that users will see when adding the application to their directory (in the consent flow).
-
-The APP ID URI is the unique identifier for your application (next to the Client ID) and must match a domain you registered under domains.
-
-![](/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-new-app-prop.png)
-
-Once the application has been created we'll need to enable it for multi-tenancy, generate a key and configure the callback urls. You'll have 2 types of callback urls: the callback url for Auth0's login endpoint and the callback url for the consent flow.
-
-When new customers sign up with their Azure AD directory the consent flow will redirect back to your application after approval/denial. In this example the page is available from different urls (http://localhost:55000/registration/complete, ...) which is why we're adding this page multiple times.
-
-![](/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-app-config.png)
-
-The final step is to configure the permissions for the application and this is where it gets interesting. 
-
-The first option is to ask for the 'Read directory data' and 'Enable SSO' permissions. Enabling these options will allow you to get more information about the user and the directory using the [Azure AD Graph API](https://msdn.microsoft.com/en-us/library/azure/hh974476.aspx). This is really useful if you want to access additional information about the user like the groups the user belongs to etc... The only downside is that you'll need to be an administrator to give this type of consent.
-
-The other option is to only ask for the 'Enable SSO' permission, which we'll be using in this example. The interesting part here is that regular users will also be able to go through the consent flow. This will allow you to reach even more users:
-
-- Organization administrators will be able to give consent for the whole directory (all users in the directory will be able to access the application)
-- Regular users will be able to give consent just for their own. The reason why this is even more interesting is because this enables single users to sign up for your application and have SSO, even if this user is the only person in the organization using your application (no administrator permissions are required here)
-
-![](/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-app-perm.png)
-
-## Creating a connection in Auth0
-
-After configuring our application in Azure AD we can add it as a connection in the Auth0 dashboard. Here we'll need to enter the Client ID and Client Secret of the application:
-
-![](/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-new-conn.png)
-
-And when creating the connection we'll need to enter the name of the directory (`fabrikamcorporation.onmicrosoft.com`) and enable the Common Endpoint. This is required if you're building multi tenant applications.
-
-![](/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-conn-comm-endpoint.png)
-
-## Creating the application
-
-Azure AD, the Auth0 connection and the Auth0 application have been configured, now it's time to create the actual application.
-
-![](/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-app-homepage.png)
-
-### Registration
-
-Before users from an other directory (your customers) are able to authenticate they'll need to go through a consent flow. The homepage allows users to sign up with a social account or with their organization. And the `Register` button will start the consent flow for a single user. Checking the option **Enable for my organization** will require an administrator, to give consent for the whole organization.
-
-The following code will store a "registration request" with a unique ID (the SignupToken) after which it will redirect to the consent page. The SignupToken is added as the state of the request, and we'll be able to use this value once the user went through the flow to correlate this back to the original request.
-
-```cs
-private const string OnboardingUrl =
-    "https://login.windows.net/common/oauth2/authorize?response_type=code
-        &client_id={0}&resource={1}&redirect_uri={2}&state={3}";
-
-[HttpPost]
-[Route("")]
-public async Task Start(RegistrationModel model)
-{
-    using (var db = new TimesheetContext())
-    {
-        // Store thre registration request.
-        var registration = db.RegistrationRequests.Add(new RegistrationRequest
-        {
-            Id = Guid.NewGuid(),
-            CreatedOn = DateTime.UtcNow,
-            SignupToken = Guid.NewGuid().ToString(),
-            AdminConsented = model.EnableForMyOrganization,
-            OrganizationName = model.OrganizationName
-        });
-        await db.SaveChangesAsync();
-
-        // Build the redirect to the consent page.
-        var authorizationRequest = String.Format(OnboardingUrl,
-            Uri.EscapeDataString(
-                ConfigurationManager.AppSettings["AzureAD:ClientID"]),
-            Uri.EscapeDataString("https://graph.windows.net"),
-            Uri.EscapeDataString(Request.Url.GetLeftPart(UriPartial.Authority) 
-                + "/registration/complete"),
-            Uri.EscapeDataString(registration.SignupToken));
-        if (model.EnableForMyOrganization)
-            authorizationRequest += String.Format("&prompt={0}", 
-                Uri.EscapeDataString("admin_consent"));
-        return Redirect(authorizationRequest);
-    }
-}
-```
-
-This will redirect the user to the consent page and in case we've enabled this for the whole organization this will trigger an admin consent which requires an administrator give consent.
-
-![](/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-consent-page.png)
-
-After accepting the user is redirected back to the application where the registration request is being processed. If everything went well the application will receive a code which can be used to receive an authorization code, the `result` variable.
-
-```cs
-[HttpGet]
-[Route("complete")]
-public async Task Complete(string code, string error, string error_description, string resource, string state)
-{
-    using (var db = new TimesheetContext())
-    {
-        if (!String.IsNullOrEmpty(error) 
-             || !String.IsNullOrEmpty(error_description))
-        {
-            return View("RegistrationError", new RegistrationErrorModel() { Error = error, ErrorDescription = error_description });
-        }
-
-        var registrationRequest = await 
-            db.RegistrationRequests.FirstOrDefaultAsync(r => 
-                r.SignupToken == state);
-        if (registrationRequest == null)
-        {
-            return View("RegistrationRequestUnknown");
-        }
-                
-        // Get the user's profile from Azure AD.
-        var credential = new ClientCredential(
-            ConfigurationManager.AppSettings["AzureAD:ClientID"], 
-            ConfigurationManager.AppSettings["AzureAD:Key"]);
-        var authContext = new AuthenticationContext(
-            "https://login.windows.net/common/");
-        var result = authContext.AcquireTokenByAuthorizationCode(code, 
-            new Uri(Request.Url.GetLeftPart(UriPartial.Path)), credential);
-
-        // Clean up the registration request.
-        db.RegistrationRequests.Remove(registrationRequest);
-
-        // Persist the user.
-
-        // Consent happend by administrator for the whole organization..
-        if (registrationRequest.AdminConsented)
-        {
-            // Persist the tenant.
-
-            // Save.
-            await db.SaveChangesAsync();
-
-            // Show confirmation page.
-            return View("TenantRegistrationSuccess");
-        }
-                
-        // Save.
-        await db.SaveChangesAsync();
-
-        // Show user confirmation page.
-        return View("UserRegistrationSuccess");
-    }
-}
-```
-
-The `result` variable contains information about the user and the tenant and can be used to persist the user and the tenant in the database.
-
-Note that the code will first validate if the state matches and existing SignupToken in the database to make sure this request was initiated from the application (eg: after a payment was made).
-
-### Signin
-
-We're using the Lock for signing in users, but for enterprise connections like Azure AD it only supports HRD (home realm discovery) based on the email address. But since we don't know all email domains that customers will use when logging in with Azure AD we'll modify the Lock a little.
-
-Before showing the Lock we're adding a button to allow login with Azure AD connection.
-
-> Note: Lock v10 does not support adding custom buttons yet, so this must be done using [Lock v9](https://auth0.com/docs/libraries/lock/v9). 
-
-```js
-lock.once('signin ready', function () {
-    var link = $(''
-        + 'Login with Azure AD');
-    link.on('click', function () {
-        lock.getClient().login({ 
-            connection: 'fabrikamcorporation.onmicrosoft.com'
-            // repeat any needed custom auth params here, such as 
-            // state, responseType and callbackURL.
-            // Only domain and clientID are carried over from
-            // Lock instance.
-            // , responseType: 'code'
-            // , callbackURL: ...
-            // , ...
-        });
-    });
-
-    var iconList = $(this.$container).find('.a0-iconlist');
-    iconList.append(link);
-});
-lock.show({
-    connections: ['google-oauth2', 'facebook', 'windowslive'],
-    socialBigButtons: true,
-    callbackURL: window.location.origin + '/signin-auth0'
-});
-```
-
-After registering the user can now login by clicking the "Login with Azure AD" button.
-
-![](/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-login-popup.png)
-
-And finally the user is signed in and the profile page shows the user's information. From now on these users will be able to use the same credentials they use for Office 365, Intune, ... to access Fabrikam's Timesheet SaaS.
-
-![](/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-profile.png)
-
-The sample application is available on [GitHub](https://github.com/auth0/auth0-azuread-multi-tenant-apps-sample).
diff --git a/articles/tutorials/bulk-importing-users-into-auth0.md b/articles/tutorials/bulk-importing-users-into-auth0.md
deleted file mode 100644
index 50bd3829cc..0000000000
--- a/articles/tutorials/bulk-importing-users-into-auth0.md
+++ /dev/null
@@ -1,128 +0,0 @@
----
-description: How to bulk import users using the Management API endpoint.
----
-
-# Bulk Import Users to Auth0 Using a Job
-
-Our focus has always been not only greenfield projects but also existing applications that want to extend their authentication capabilities.
-
-With this in mind, our [Management API has an endpoint](/api/management/v2#!/Jobs/post_users_imports) that allows consumers to populate a database connection with users obtained from a file. Each of those users will have to reset their password when they log in for the first time.
-
-## Pre-requisites
-
-Before you launch the import users job, a database (to which the users will be imported) must already exist.
-
-### Users 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
-
-### 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"
-    }
-  }
-]
-```
-
-> The file size limit for a bulk import is 10MB. 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, receive a response, check on a job's status, and check for details on any failed entries in your job.
-
-### Requesting 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:
-* **users** (the file, detailed above, that you are uploading, which contains JSON data for your users)
-* **connection_id** (a string, the connection id of the connection to which the above users will be inserted)
-* **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)
-* **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.)
-
-If it works, you will get a response similar to the following one:
-
-```
-{
-    "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 account that the job is being run on will get an e-mail notifying them about the result.
-
-For example, 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.
-
-If the job was successful, owner(s) would get an e-mail notification that contains similar information to the summary returned when checking the status of a completed job, containing such data as the amount of successfully inserted and failed entries.
-
-### Querying 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 a 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](https://manage.auth0.com/#/logs), which allows for a custom WebHook to be triggered using the [WebHook Logs Extension](/extensions/management-api-webhooks).
-
-### Retrieving 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/tutorials/calling-an-external-idp-api.md b/articles/tutorials/calling-an-external-idp-api.md
deleted file mode 100644
index c659fe03cc..0000000000
--- a/articles/tutorials/calling-an-external-idp-api.md
+++ /dev/null
@@ -1,94 +0,0 @@
----
-description: How to call an Identity Provider API.
----
-
-# Call an Identity Provider API
-
-Upon successfully authenticating a user with an external Identity Provider such as Facebook or GitHub, the IdP often includes an access token in the user's profile. This token can be used to call the IdP's API.
-
-If you need access to the user's IdP access token, you'll need to call the [Get Users by ID](/api/management/v2#!/Users/get_users_by_id) endpoint of the [Auth0 Management API](/api/management/v2) with the `read:user_idp_tokens` scope. This document details the recommended two-step method for doing so.
-
-## Step 1: Create a Client
-
-You will need to create an Auth0 client that calls the Auth0 Management API on behalf of your app to obtain an access token.
-
-1. Go to the [Clients page of the Auth0 Management Dashboard](${manage_url}/#/clients) and click **Create Client**.
-
-  ![Management Dashboard Clients Page](/media/articles/tutorials/calling-an-external-idp-api/create-client.png)
-
-2. Select **Non Interactive Clients** and click **Create**.
-
-  ![Management Dashboard Clients Type Selection](/media/articles/tutorials/calling-an-external-idp-api/select-ni-client.png)
-
-3. Once you have created the Client, copy the `Client ID` and `Client Secret` from the **Settings** page.
-
-  ![Management Dashboard Client Setting Page](/media/articles/tutorials/calling-an-external-idp-api/client-id-secret.png)
-
-4. Next, go to the [APIs](${manage_url}/#/apis) section of the Auth0 dashboard and select the **Auth0 Management API**.
-
-  ![Management Dashboard API Page](/media/articles/tutorials/calling-an-external-idp-api/api.png)
-
-  **NOTE:** If you do not see the **APIs** option in the left menu, you must enable it. Go to [Account Settings > Advanced](${manage_url}/#/account/advanced) and select **Enable APIs Section**.
-
-5. Select the **Non Interactive Clients** tab and authorize the app you just created. You will then be able to choose the required `read:user_idp_tokens` scope. Click **Update**.
-
-![Management Dashboard API Authorization](/media/articles/tutorials/calling-an-external-idp-api/authorize-client.png)
-
-For more information on creating a Client to access the Auth0 API, see [Set up a Client Credentials Grant using the Dashboard](/api-auth/config/using-the-auth0-dashboard).
-
-## Step 2: Configure the Backend Service
-
-You will need to create a service to execute the following three steps:
-
-1. [Obtain an Auth0 access token](#obtain-an-auth0-access-token)
-2. [Obtain the User Profile](#obtain-the-user-profile)
-3. [Extract the IdP Token](#extract-the-idp-access-token)
-
-### 1. Obtain an Auth0 Access Token
-
-The following code executes a client credentials exchange so that you receive an access token allowing access to the [Auth0 Management API](/api/management/v2#!).
-
-```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\": \"${account.clientSecret}\", \"audience\": \"https://${account.namespace}/api/v2/\", \"grant_type\": \"client_credentials\" }"
-  }
-}
-```
-
-### 2. Obtain the User Profile
-
-Using the Auth0 access token, call the [Get a User](/api/management/v2#!/Users/get_users_by_id) endpoint to get the user profile:
-
-```har
-{
-  "method": "GET",
-  "url": "https://${account.namespace}/api/v2/Users/get_users_by_id",
-  "headers": [
-    { "name": "Content-Type", "value": "application/json" }
-  ]
-}
-```
-
-**Notes**:
-
-* For Native and Single-Page Applications, you'll need to send the `id_token` to your backend and verify it using the Client Secret. For Web Applications, you can use the `user_id` field from the user profile's `user` property.
-* The request must include an `Authorization` header with `Bearer` token, which is the Auth0 access token you obtained in the previous step.
-
-### 3. Extract the IdP Access Token
-
-Within the user's `identities` array, there will be an `access_token` that you can extract and use to make calls to the IdP's API:
-
-  `user.identities[0].access_token`
-
-In most cases, the user will only have one identity, but if you have used the [account linking feature](/link-accounts), there may be more.
-
-:::panel-warning Exposing Your Token
-For security reasons, be sure that you don't expose the IdP access token to your client-side application.
-:::
diff --git a/articles/tutorials/cancel-paid-subscriptions.md b/articles/tutorials/cancel-paid-subscriptions.md
deleted file mode 100644
index db51b3221f..0000000000
--- a/articles/tutorials/cancel-paid-subscriptions.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-description: To cancel your Auth0 subscription, you can downgrade to a free subscription or close your account.
----
-
-# Cancelling Your Auth0 Subscription
-
-If you wish to cancel your Auth0 subscription, you have two options:
-
-1. [Downgrade](#downgrade-a-paid-subscription-to-a-free-subscription) a paid subscription to a free subscription;
-2. [Close](#close-your-auth0-account) your Auth0 account.
-
-## Downgrade a Paid Subscription to a Free Subscription
-
-1. Log in to the Auth0 [Management 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)
-
-3. Select **Account Settings**.
-4. On the **Account 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**. 
-
-## Close Your Auth0 Account
-
-::: warning-banner
-This action cannot be undone.
-:::
-
-1. Log in to the Auth0 [Management 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)
-
-3. Select **Account Settings**.
-4. On the **Account Settings** page is open, click on the **Advanced** tab.
-
-![](/media/articles/subscriptions/advanced.png)
-
-5. Scroll down to the **Danger Zone** at the bottom of the page, and click **Delete**.
-
-![](/media/articles/subscriptions/danger-zone.png)
diff --git a/articles/tutorials/configuration-to-query-users-from-google-apps.md b/articles/tutorials/configuration-to-query-users-from-google-apps.md
deleted file mode 100644
index 62c3cce747..0000000000
--- a/articles/tutorials/configuration-to-query-users-from-google-apps.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-description: How to setup the configuration needed to query users from a Google Apps domain.
----
-
-# Configuration to Query Users from a Google Apps domain
-
-In order to be able to query **Google Apps** domain users, you must enable API access:
-
-1. An administrator of a Google Apps domain needs to login to the Google Apps Admin console, then 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)
-
-**Additional Resources:**
-[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)
diff --git a/articles/tutorials/configure-wsfed-application.md b/articles/tutorials/configure-wsfed-application.md
deleted file mode 100644
index 2f7a22eb4b..0000000000
--- a/articles/tutorials/configure-wsfed-application.md
+++ /dev/null
@@ -1,16 +0,0 @@
----
-description: How to configure a WS-Fed application to use Auth0 as an identity provider.
----
-
-# 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 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.
diff --git a/articles/tutorials/creating-invite-only-applications.md b/articles/tutorials/creating-invite-only-applications.md
deleted file mode 100644
index b333a0bb44..0000000000
--- a/articles/tutorials/creating-invite-only-applications.md
+++ /dev/null
@@ -1,322 +0,0 @@
----
-description: This scenario demonstrates an invite-only sign-up implementation using the Auth0 Management API to customize the process and the email flow.
----
-
-# Invite-only Applications
-
-Self-service provisioning is a common concept for SaaS applications. Users can register and pay and then begin using the application. 
-
-Other types of applications (such as Google Apps and Office 365) may not allow single users to register for an application. Instead, customers may be organizations that pay upfront for a number of users and only want to allow those users access to your application. In these cases, an invite-only workflow can be used. 
-
-## Analystick scenario
-
-Analystick is a multi-tenant SaaS solution offering analytics in the cloud. Their customers send them a list of users (with their given name, family name and email address) that can access the application.
-
-This functionality can be achieved using an Enterprise Connection where you federate with your customer using ADFS/SAML-P/…. This will allow your customer to authenticate users with their own Active Directory which specifies who is to be given access to the application.
-
-The invite-only flow will be setup as follows: 
-
-1. The tenant admnistrator will create new users in their subscription from within the application. 
-2. The application will call the Auth0 Management API to create these new users in a database connection. 
-3. The application will send out activation emails to these users. 
-4. When users click the activation link, they will be redirected to Auth0 where their email address will be set to validated. 
-5. After validation, Auth0 will redirect users to the application where they will be presented with a password reset form. 
-6. The application will update each user's password in Auth0, after which they will be able to authenticate.
-
-![](/media/articles/invite-only/invite-only-overview.png)
-
-### Setup
-
-Users can be stored in a single database because Analystick will be signing up users from Contoso, Fabrikam and other companies with their corporate email addresses, making users unique for each customer.
-
-![](/media/articles/invite-only/invite-only-connections.png)
-
-To prevent users from signing up, select the **Disable Sign Ups** option on the connection to make sure users can only be created on the backend.
-
-The Analystick application is an ASP.NET MVC web application hosted on `http://localhost:45000/`. You will need to create an application in the dashboard with the correct parameters:
-
- - **Name**: give your application a clear name as this will be used in the emails being sent out during the invite-only workflow
- - **Allowed Callback URLs**: this should be the url of your application followed with `/signin-auth0` (a requirement of the Auth0.Owin NuGet package for .NET)
-
-![](/media/articles/invite-only/invite-only-app.png)
-
-### User Management
-
-Analystick has built a simple user interface in their admin backend to allow the import of up to 5 users.
-
-![](/media/articles/invite-only/invite-only-new.png)
-
-This admin interface uses the Auth0 SDK for .NET to communicate with the Auth0 Management API:
-
-```
-public class UsersController : Controller
-{
-    private readonly Client _client;
-
-    public UsersController()
-    {
-        _client = new Client(
-            ConfigurationManager.AppSettings["auth0:ClientId"],
-            ConfigurationManager.AppSettings["auth0:ClientSecret"],
-            ConfigurationManager.AppSettings["auth0:Domain"]);
-    }
-
-    public ActionResult Index()
-    {
-        var users = _client.GetUsersByConnection(ConfigurationManager.AppSettings["auth0:Connection"]);
-        return View(users.Select(u => new UserModel
-        {
-            UserId = u.UserId,
-            GivenName = u.GivenName,
-            FamilyName = u.FamilyName,
-            Email = u.Email
-        }).ToList());
-    }
-
-    ...
-
-    [HttpPost]
-    public ActionResult New(IEnumerable users)
-    {
-      if (users != null)
-      {
-          foreach (var user in users.Where(u => !String.IsNullOrEmpty(u.Email)))
-          {
-              var randomPassword = Guid.NewGuid().ToString();
-              var metadata = new
-              {
-                  user.GivenName,
-                  user.FamilyName,
-                  activation_pending = true
-              };
-
-              var profile = _client.CreateUser(user.Email, randomPassword,
-                ConfigurationManager.AppSettings["auth0:Connection"], false, metadata);
-
-              var userToken = JWT.JsonWebToken.Encode(
-                new { id = profile.UserId, email = profile.Email },
-                  ConfigurationManager.AppSettings["analystick:signingKey"],
-                    JwtHashAlgorithm.HS256);
-
-              var verificationUrl = _client.GenerateVerificationTicket(profile.UserId,
-                  Url.Action("Activate", "Account", new { area = "", userToken }, Request.Url.Scheme));
-
-              var body = "Hello {0}, " +
-                "Great that you're using our application. " +
-                "Please click ACTIVATE to activate your account." +
-                "The Analystick team!";
-
-              var fullName = String.Format("{0} {1}", user.GivenName, user.FamilyName).Trim();
-              var mail = new MailMessage("app@auth0.com", user.Email, "Hello there!",
-                  String.Format(body, fullName, verificationUrl));
-              mail.IsBodyHtml = true;
-
-              var mailClient = new SmtpClient();
-              mailClient.Send(mail);
-          }
-      }
-
-      return RedirectToAction("Index");
-    }
-
-    [HttpPost]
-    public ActionResult Delete(string id)
-    {
-        if (!String.IsNullOrEmpty(id))
-            _client.DeleteUser(id);
-        return RedirectToAction("Index");
-    }
-}
-```
-
-The `CreateUser` method is called to create the user in the database connection. This method is called with 5 parameters:
-
- 1. The user’s email address
- 2. The user’s password (a new Guid is assigned as a random password to the user)
- 3. The name of the connection in which to create the user
- 4. The email verified parameter (set to false prior to the user clicking the activation link).
- 5. A metadata object containing the given name and family name of the user, and an activation pending setting (used later to validate the user).
-
-### Emails
-
-Once the user is created, you will need to send the verification email. The email will contain a link to the account activation URL of the application (/activate/account) that contains the password reset form. To securely identify the user, a JWT token is appended to the URL. 
-
-To generate the `verificationUrl`, call the `GenerateVerificationTicket` method on the SDK, set the return URL to that of the password reset form, and append the token.
-
-**NOTE:** Since you do not want the default emails to be sent, you must disable the **Verification Email** and **Welcome Email** in the Auth0 dashboard.
-
-![](/media/articles/invite-only/invite-only-disable-email.png)
-
-The backend will be sending out the email, so you will need to access an SMTP server. This example uses Mailtrap, but any SMTP server will do. 
-
-After signing up with an email server, add these SMTP settings to the `web.config`:
-
-```xml
-  
-    
-      
-        
-      
-    
-  
-```
-
-That is all that is required for user provisioning. 
-
-Now go back to the user overview to start importing users.
-
-![](/media/articles/invite-only/invite-only-users.png)
-
-Each user will receive a welcome email containing a link to activate their account.
-
-![](/media/articles/invite-only/invite-only-activation-mail.png)
-
-### User Activation
-
-The link in the email template redirects to Auth0 for email verification. 
-
-After successful verification, Auth0 will redirect the user to the password reset form of the application with the user token included in the URL.
-
-![](/media/articles/invite-only/invite-only-activation.png)
-
-Once the user has entered their password, you should verify that the account has not been updated yet, update the user's password, and mark the user as active (`activation_pending = false`).
-
-```cs
-/// 
-/// GET Account/Activate?userToken=xxx
-/// 
-/// 
-/// 
-public ActionResult Activate(string userToken)
-{
-    dynamic metadata = JWT.JsonWebToken.DecodeToObject(userToken,
-        ConfigurationManager.AppSettings["analystick:signingKey"]);
-    var user = GetUserProfile(metadata["id"]);
-    if (user != null)
-        return View(new UserActivationModel { Email = user.Email, UserToken = userToken });
-    return View("ActivationError",
-        new UserActivationErrorModel("Error activating user, could not find an exact match for this email address."));
-}
-
-/// 
-/// POST Account/Activate
-/// 
-/// 
-/// 
-[HttpPost]
-public ActionResult Activate(UserActivationModel model)
-{
-    dynamic metadata = JWT.JsonWebToken.DecodeToObject(model.UserToken,
-        ConfigurationManager.AppSettings["analystick:signingKey"], true);
-    if (metadata == null)
-    {
-        return View("ActivationError",
-            new UserActivationErrorModel("Unable to find the token."));
-    }
-
-    if (!ModelState.IsValid)
-    {
-        return View(model);
-    }
-
-    UserProfile user = GetUserProfile(metadata["id"]);
-    if (user != null)
-    {
-        if (user.ExtraProperties.ContainsKey("activation_pending")
-              && !((bool)user.ExtraProperties["activation_pending"]))
-            return View("ActivationError",
-              new UserActivationErrorModel("Error activating user, the user is already active."));
-
-        _client.ChangePassword(user.UserId, model.Password, false);
-        _client.UpdateUserMetadata(user.UserId, new { activation_pending = false });
-
-        return View("Activated");
-    }
-
-    return View("ActivationError",
-        new UserActivationErrorModel("Error activating user, could not find an exact match for this email address."));
-}
-```
-
-**NOTE:** Always validate the token first to be sure you are updating the correct user.
-
-Next, display a confirmation page where the user can click a link to sign in. 
-
-You can customize the rendering of Lock. Since you don’t want users to sign up, hide the Sign Up button which is visible by default:
-
-```javascript
-var lock = new Auth0Lock('@System.Configuration.ConfigurationManager.AppSettings["auth0:ClientId"]', '@System.Configuration.ConfigurationManager.AppSettings["auth0:Domain"]');
-
-function showLock() {
-    lock.show({
-        callbackURL: window.location.origin + '/signin-auth0',
-        disableSignupAction: true
-    });
-}
-```
-
-![](/media/articles/invite-only/invite-only-login.png)
-
-As a final step, you can enforce user activation by configuring Auth0 at application startup to intercept every login. This allows you to modify a user’s identity before handing it over to the OWIN pipeline.
-
-This example checks if a user is active, and if so, adds the **Member** role to the user:
-
-```cs
-public partial class Startup
-{
-   public void ConfigureAuth(IAppBuilder app)
-   {
-      ...
-
-      var provider = new Auth0AuthenticationProvider
-      {
-         OnReturnEndpoint = context =>
-         {
-             ..
-         },
-         OnAuthenticated = context =>
-         {
-             if (context.User["activation_pending"] != null)
-             {
-                 var pending = context.User.Value("activation_pending");
-                 if (!pending)
-                 {
-                     context.Identity.AddClaim(new Claim(ClaimTypes.Role, "Member"));
-                 }
-             }
-
-            ...
-
-             return Task.FromResult(0);
-         }
-      };
-
-      app.UseAuth0Authentication(ConfigurationManager.AppSettings["auth0:ClientId"],
-        ConfigurationManager.AppSettings["auth0:ClientSecret"], ConfigurationManager.AppSettings["auth0:Domain"],
-         provider: provider);
-   }
-}
-```
-
-Now you can ensure that these pages will only be accessible to users by enforcing the presence of a **Member** claim:
-
-```cs
-[Authorize(Roles = "Member")]
-public class ProfileController : Controller
-{
-    public ActionResult Index()
-    {
-        ...
-    }
-}
-```
-
-Once users have completed the entire flow, they will be able to access the member-only pages.
-
-![](/media/articles/invite-only/invite-only-profile.png)
-
-### Summary
-
-This scenario has demonstrated an invite-only sign-up implementation using the Auth0 Management API to customize the sign-up process and the email flow. 
-
-For more information about the Management API, see the [Management API Explorer](/api/v2) to try the various endpoints.
diff --git a/articles/tutorials/creating-users-in-the-management-portal.md b/articles/tutorials/creating-users-in-the-management-portal.md
deleted file mode 100644
index 5a623a8c8f..0000000000
--- a/articles/tutorials/creating-users-in-the-management-portal.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-description: How to create users in the Auth0 Management Dashboard.
----
-
-# Creating Users via the Management Dashboard
-
-You can manually create users via the [Auth0 Management Dashboard](${manage_url}).
-
-Log in and open up the Management Dashboard. Navigate to the Users tab.
-
-![](/media/articles/users/dashboard.png)
-
-Click on the "Create User" button near the top right-hand side of the screen.
-
-![](/media/articles/users/users-tab.png)
-
-4. Provide the following pieces of information for the new user:
-    * Email;
-    * Password;
-    * Repeat Password (for confirmation);
-    * Connection.
-
-  When finished, click "Save".
-
-> The connection you use must be associated with a Client, otherwise you will receive an error message that says, "The connection is disabled."
-
-![](/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)
diff --git a/articles/tutorials/custom-mfa-rules.md b/articles/tutorials/custom-mfa-rules.md
deleted file mode 100644
index c6d1ceca9b..0000000000
--- a/articles/tutorials/custom-mfa-rules.md
+++ /dev/null
@@ -1,119 +0,0 @@
----
-description: You can add step-up authentication to your app with Auth0's extensible multifactor authentication support.
----
-
-# Step-Up Authentication with Custom Multifactor Authentication Rules
-
-::: panel-info Notice
-Auth0 now supports `amr` and `acr` claims with `acr_values` for step-up authentication. This approach allows for more control with MFA.
-
-[Click here for details.](/tutorials/step-up-authentication) 
-:::
-
-## What is 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* can require 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) can trigger 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 and, if not, require the user to step-up to access certain resources.
-
-![](/media/articles/step-up-authentication/flow.png)
-
-## Custom Multifactor Authentication Rule
-
-The following [rule](/rules) modifies the outgoing token by adding an `authentication_level` parameter. A regular login will be marked as `normal`.
-
-This rule also inspects the `scope`. If the login request is made with `step_up` scope, the application is requesting step-up authentication. In this case, this rule forces the user to additionally authenticate with multifactor authentication and sets the `authentication_level` to `mfa`.
-
-```js
-function (user, context, callback) {
-
-  user.authentication_level = 'normal';
-
-  if (isStepUpRequested()) {
-    triggerStepUp(user, context);
-    user.authentication_level = 'mfa';
-  }
-
-  callback(null, user, context);
-
-  function isStepUpRequested() {
-    // If "step_up" is part of the incoming scope, we will force step up authn.
-    return (context.request.query.scope || context.request.body.scope || '')
-      .split(' ')
-      .indexOf('step_up') >= 0;
-  }
-
-  function triggerStepUp(user, ctx) {
-    // Force step up with Google authenticator.
-    ctx.multifactor = {
-      provider: 'google-authenticator',
-      issuer: "Step Up Authentication",
-      ignoreCookie: true
-    };
-  }
-}
-```
-
-**NOTE:** In addition to the [Auth0 supported mutlifactor authentication providers](/multifactor-authentication#using-auth0s-built-in-support) (Google Authenticator and Duo Security) you can plug in your own [custom provider](/multifactor-authentication#use-a-custom-mfa-service).
-
-## Application Logic
-
-You will need to add logic to your app to check the user's login authentication level when they request access to sensitive resources.
-
-First, write some middleware (or something similar, depending on your platform) in your web app to enforce step-up authentication.
-
-```js
-var requireMultiFactor = function(req, res, next) {
-  if (!req.isAuthenticated() || req.user._json.authentication_level != 'mfa') {
-    logger.warn('User did not sign in with MFA. Step up required.');
-    return res.redirect('/login/mfa');
-  }
-
-  next();
-};
-```
-
-If the user has not yet authenticated or did not authenticate with multifactor authentication, this code will redirect the user to `/login/mfa` within your app. This route requires the user to authenticate (or re-authenticate) and specifies the `step_up` scope which will trigger the custom logic in the rule you created above:
-
-```js
-router.get('/login/mfa',
-  passport.authenticate('auth0', { scope: 'openid step_up' }));
-```
-
-Next, add code to ensure that the multifactor authentication requirement is applied to all routes that expose sensitive data, like the employee directory:
-
-```js
-router.get('/employees', requireMultiFactor, function(req, res) {
-  res.render('employees');
-});
-```
-
-**NOTE:** Enable the **Use Auth0 instead of the IdP to do Single Sign On** option in the settings page of your app in Auth0 or specify a connection name when triggering step-up authentication to make sure users are not forced to authenticate when already logged in. By enabling the SSO setting or specifying a connection name, your app will trigger an SSO login which will only prompt the user for multifactor authentication.
-
-## Sample Application
-
-The *Fabrikam Intranet* sample is [available on GitHub](https://github.com/auth0/step-up-authentication-sample). In this sample, a user that tries to access the Customers section will be required to authenticate:
-
-![](/media/articles/step-up-authentication/login-page.png)
-
-After they have authenticated, the user will be allowed access to the customer data:
-
-![](/media/articles/step-up-authentication/customers-page.png)
-
-In this case, the token will indicate that the user logged in at the `normal` authentication level (no multifactor authentication).
-
-![](/media/articles/step-up-authentication/normal-authentication-level.png)
-
-When the user tries to access the Employees directory, they will be forced to authenticate using a higher authentication level (multifactor authentication).
-
-![](/media/articles/step-up-authentication/mfa.png)
-
-After this step, the user's token will indicate that the authentication level is `mfa`.
-
-![](/media/articles/step-up-authentication/mfa-authentication-level.png)
-
-As a result, the app will now allow the user to access more sensitive resources:
-
-![](/media/articles/step-up-authentication/employees-page.png)
\ No newline at end of file
diff --git a/articles/tutorials/generic-oauth2-connection-examples.md b/articles/tutorials/generic-oauth2-connection-examples.md
deleted file mode 100644
index 45fcb4cd1a..0000000000
--- a/articles/tutorials/generic-oauth2-connection-examples.md
+++ /dev/null
@@ -1,289 +0,0 @@
----
-description: This document covers generic OAuth 1.0/2.0 examples.
-toc: true
----
-
-# Generic OAuth 1.0 and 2.0 Examples
-
-Adding [OAuth 1.0](/oauth1) and [OAuth 2.0](/oauth2) providers as Connections allow you to support providers that are not currently built-in to the [Auth0 Management Dashboard](${manage_url}), like [DigitalOcean](#digitalocean), [Tumblr](#tumblr), and more.
-
-This document covers examples of OAuth 1.0/2.0 Connections that you can create by making the appropriate `POST` call to the [Auth0 APIv2's Connections endpoint](/api/v2#!/Connections/post_connections). Please note that doing so requires an [APIv2 token](/api/v2/tokens) with `create:connections` scope.
-
-## DigitalOcean
-
-1. Navigate to [Digital Ocean](https://cloud.digitalocean.com/login).
-2. If you have not already registered a Digital Ocean application, you will need to do so prior to continuing.
-3. Once available, copy the `Client ID` and `Client Secret` for use with your cURL `POST`.
-
-```har
-{
-	"method": "POST",
-	"url": "https://YOURACCOUNT.auth0.com/api/v2/connections",
-	"httpVersion": "HTTP/1.1",
-	"cookies": [],
-	"headers": [{
-		"name": "Authorization",
-		"value": "Bearer ABCD"
-	}],
-	"queryString": [],
-	"postData": {
-		"mimeType": "application/json",
-		"text": "{ \"name\": \"digitalocean\", \"strategy\": \"oauth2\", \"options\": { \"client_id\", \"YOUR-DIGITAL-OCEAN-CLIENT-ID\", \"client_secret\": \"YOUR-DIGITAL-OCEAN-CLIENT-SECRET\", \"authorizationURL\": \"https://cloud.digitalocean.com/v1/oauth/authorize\", \"tokenURL\": \"https://cloud.digitalocean.com/v1/oauth/token\", \"scope\": [\"read\"], \"scripts\": { \"fetchUserProfile\": \"function(accessToken, ctx, cb) { request.get('https://api.digitalocean.com/v2/account', { headers: { 'Authorization': 'Bearer ' + accessToken } }, function(e, r, b) { if (e) return cb(e); if (r.statusCode !== 200 ) return cb(new Error('StatusCode: ' + r.statusCode)); var profile = JSON.parse(b).account; profile.user_id = profile.uuid; cb(null, profile); });}"
-	},
-	"headersSize": -1,
-	"bodySize": -1,
-	"comment": ""
-}
-```
-
-## Dribbble
-
-1. Navigate to [Dribble](https://dribbble.com/account/applications/new).
-2. If you have not already registered a new Dribble consumer, you will need to do so prior to continuing. If you have, set the `Redirect URI` of your application to `https://${account.namespace}/login/callback`.
-3. Copy the `Client ID` and `Client Secret` for use with your cURL `POST`.
-
-```har
-{
-	"method": "POST",
-	"url": "https://YOURACCOUNT.auth0.com/api/v2/connections",
-	"httpVersion": "HTTP/1.1",
-	"cookies": [],
-	"headers": [{
-		"name": "Authorization",
-		"value": "Bearer ABCD"
-	}],
-	"queryString": [],
-	"postData": {
-		"mimeType": "application/json",
-		"text": "{ \"name\": \"dribbble\", \"strategy\": \"oauth2\", \"options\": { \"client_id\", \"YOUR_DRIBBLE_CLIENT_ID\", \"client_secret\": \"YOUR_DRIBBLE_CLIENT_SECRET\", \"authorizationURL\": \"https://dribbble.com/oauth/authorize\", \"tokenURL\": \"https://dribbble.com/oauth/token\", \"scope\": [\"public\"], \"scripts\": { \"fetchUserProfile\": \"function(accessToken, ctx, cb) { request.get('https://api.dribbble.com/v1/user', { headers: { 'Authorization': 'Bearer ' + accessToken } }, function(e, r, b) { if (e) return cb(e); if (r.statusCode !== 200 ) return cb(new Error('StatusCode: ' + r.statusCode)); var profile = JSON.parse(b); profile.user_id = profile.id; profile.picture = profile.avatar_url; cb(null, profile); });}"
-	},
-	"headersSize": -1,
-	"bodySize": -1,
-	"comment": ""
-}
-```
-
-## Imgur
-
-1. Navigate to [Imgur](https://api.imgur.com/oauth2/addclient).
-2. If you have not already registered an Imgur application, you will need to do so prior to continuing.
-3. Once available, copy the `Client ID` and `Client Secret` for use with your cURL `POST`.
-
-```har
-{
-	"method": "POST",
-	"url": "https://YOURACCOUNT.auth0.com/api/v2/connections",
-	"httpVersion": "HTTP/1.1",
-	"cookies": [],
-	"headers": [{
-		"name": "Authorization",
-		"value": "Bearer ABCD"
-	}],
-	"queryString": [],
-	"postData": {
-		"mimeType": "application/json",
-		"text": "{ \"name\": \"imgur\", \"strategy\": \"oauth2\", \"options\": { \"client_id\", \"YOUR-IMGUR-CLIENT-ID\", \"client_secret\": \"YOUR-IMGUR-CLIENT-SECRET\", \"authorizationURL\": \"https://api.imgur.com/oauth2/authorize\", \"tokenURL\": \"https://api.imgur.com/oauth2/token\", \"scripts\": { \"fetchUserProfile\": \"function(accessToken, ctx, cb) { request.get('https://api.imgur.com/3/account/me', { headers: { 'Authorization': 'Bearer ' + accessToken } }, function(e, r, b) { if (e) return cb(e); if (r.statusCode !== 200 ) return cb(new Error('StatusCode: ' + r.statusCode)); var profile = JSON.parse(b).data; profile.user_id = profile.id; cb(null, profile); });}"
-	},
-	"headersSize": -1,
-	"bodySize": -1,
-	"comment": ""
-}
-```
-
-## JIRA
-
-### Step 1: Generate an RSA Keypair
-
-Generate an RSA keypair with the following command (or any equivalent method):
-
-```bash
-$ openssl genrsa -out EXAMPLE.key 2048 && openssl rsa -pubout -in EXAMPLE.key -out EXAMPLE.pub
-```
-
-### Step 2: Create a JIRA Application Link
-
-
-From JIRA, go to **Administration** > **Application** > **Application Links**, and [create an Application Link](https://confluence.atlassian.com/display/APPLINKS-050/Application+Links+Documentation) with the following settings:
-
-* **Application URL**: Any arbitrary URL (you can ignore the `No response was received from the URL` warnings);
-* **Application Name**: Any arbitrary name;
-* **Application Type**: Generic Application;
-* **Create incoming link**: *checked*.
-
-Leave all other options left blank.
-
-To create the incoming link, use the following settings:
-
-  * **Consumer Key**: Any arbitrary URL-friendly name (for example, `auth0-jira`)
-  * **Consumer Name**: Any arbitrary name
-  * **Public Key**: The RSA keypair previously generated in step 1 (copy and paste the entire `.pub` file)
-  * **Consumer Callback URL**: `https://${account.namespace}/login/callback`
-
-:::panel-info Updating Settings
-If you need to modify these settings after you've created the application link, you can do so via the **Incoming Authentication** section of the link's settings.
-:::
-
-In the JSON below, replace all instances of the following placeholders:
-  * `JIRA_URL`: The root URL of your JIRA instance (for example, `https://foo.atlassian.net`)
-  * `CONSUMER_KEY`: The chosen Consumer Key for your application link
-  * `CONSUMER_SECRET`: The previously generated private key (as a JSON string). You can convert `EXAMPLE.key` to a valid JSON string using the following command:
-
-```bash
-node -p -e 'JSON.stringify(require("fs").readFileSync("EXAMPLE.key").toString("ascii"));'
-```
-
-```har
-{
-	"method": "POST",
-	"url": "https://YOURACCOUNT.auth0.com/api/v2/connections",
-	"httpVersion": "HTTP/1.1",
-	"cookies": [],
-	"headers": [{
-		"name": "Authorization",
-		"value": "Bearer ABCD"
-	}],
-	"queryString": [],
-	"postData": {
-		"mimeType": "application/json",
-		"text": "{ \"name\": \"jira\", \"strategy\": \"oauth1\", \"options\": { \"consumerKey\", \"CONSUMER_KEY\", \"consumerSecret\": \"CONSUMER_SECRET\", \"requestTokenURL\": \"JIRA_URL/plugins/servlet/oauth/request-token\", \"accessTokenURL\": \"JIRA_URL/plugins/servlet/oauth/access-token\", \"userAuthorizationURL\": \"JIRA_URL/plugins/servlet/oauth/authorize\", \"signatureMethod\": \"RSA-SHA1\", \"scripts\": { \"fetchUserProfile\": \"function(token, tokenSecret, ctx, cb) {\n  // Based on passport-atlassian-oauth\n  // https://github.com/tjsail33/passport-atlassian-oauth/blob/a2e444b0c3969dfd7caf4524ce4a4c379656ba2e/lib/passport-atlassian-oauth/strategy.js\n  var jiraUrl = 'JIRA_URL';\n  var OAuth = new require('oauth').OAuth;\n  var oauth = new OAuth(ctx.requestTokenURL, ctx.accessTokenURL, ctx.client_id, ctx.client_secret, '1.0', null, 'RSA-SHA1');\n  function oauthRequest(url, cb) {\n    return oauth._performSecureRequest(token, tokenSecret, 'GET', url, null, '', 'application/json', cb);\n  }\n  oauthRequest(jiraUrl + '/rest/auth/1/session', function(err, body, res) {\n    if (err) return cb(err);\n    if (res.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode));\n    var json;\n    try {\n      json = JSON.parse(body);\n    } catch(ex) {\n      return cb(new Error('Invalid JSON returned from JIRA', ex));\n    }\n    var profileUrl = jiraUrl + '/rest/api/2/user?expand=groups&username=' + encodeURIComponent(json.name);\n    oauthRequest(profileUrl, function(err, body, res) {\n      if (err) return cb(err);\n      if (res.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode));\n      try {\n        json = JSON.parse(body);\n      } catch(ex) {\n        return cb(new Error('Invalid JSON returned from JIRA', ex));\n      }\n      // Auth0-specific mappings, customize as n:qeeded\n      // https:///user-profile/normalized\n      return cb(null, {\n        user_id: json.name,\n        username: json.name,\n        email: json.emailAddress,\n        name: json.displayName,\n        groups: json.groups,\n        picture: json.avatarUrls['48x48'],\n        active: json.active,\n        self: json.self,\n        timezone: json.timeZone,\n        locale: json.locale\n      });\n    });\n  });\n}\n"
-	},
-	"headersSize": -1,
-	"bodySize": -1,
-	"comment": ""
-}
-```
-
-## Tumblr
-
-1. Navigate to [Tumblr](https://www.tumblr.com/oauth/apps).
-2. If you have not already registered a new Tumblr application, you will need to do so prior to continuing.
-3. Copy the `OAuth Consumer Key` and `Secret Key` for use with your cURL `POST`.
-
-```har
-{
-	"method": "POST",
-	"url": "https://YOURACCOUNT.auth0.com/api/v2/connections",
-	"httpVersion": "HTTP/1.1",
-	"cookies": [],
-	"headers": [{
-		"name": "Authorization",
-		"value": "Bearer ABCD"
-	}],
-	"queryString": [],
-	"postData": {
-		"mimeType": "application/json",
-		"text": "{ \"name\": \"tumblr\", \"strategy\": \"oauth1\", \"options\": { \"client_id\", \"YOUR-TUMBLR-CONSUMER-KEY\", \"client_secret\": \"YOUR-TUMBLR-SECRET-KEY\", \"requestTokenURL\": \"https://www.tumblr.com/oauth/request_token\", \"accessTokenURL\": \"https://www.tumblr.com/oauth/access_token\", \"userAuthorizationURL\": \"https://www.tumblr.com/oauth/authorize\", \"scripts\": { \"fetchUserProfile\": \"function (token, tokenSecret, ctx, cb) {var OAuth = new require('oauth').OAuth;var oauth = new OAuth(ctx.requestTokenURL,ctx.accessTokenURL,ctx.client_id,ctx.client_secret,'1.0',null,'HMAC-SHA1');oauth.get('https://api.tumblr.com/v2/user/info',token,tokenSecret,function(e, b, r) {if (e) return cb(e);if (r.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode));var user = JSON.parse(b).response.user; user.user_id = user.name; cb(null, user);});}"
-	},
-	"headersSize": -1,
-	"bodySize": -1,
-	"comment": ""
-}
-```
-
-## Twitch
-
-1. Navigate to [Twitch](http://www.twitch.tv/kraken/oauth2/clients/new).
-2. If you have not already registered a Twitch application, you will need to do so prior to continuing.
-3. Once available, copy the `Client ID` and `Client Secret` for use with your cURL `POST`.
-
-```har
-{
-	"method": "POST",
-	"url": "https://YOURACCOUNT.auth0.com/api/v2/connections",
-	"httpVersion": "HTTP/1.1",
-	"cookies": [],
-	"headers": [{
-		"name": "Authorization",
-		"value": "Bearer ABCD"
-	}],
-	"queryString": [],
-	"postData": {
-		"mimeType": "application/json",
-		"text": "{ \"name\": \"twitch\", \"strategy\": \"oauth2\", \"options\": { \"client_id\", \"YOUR-TWITCH-CLIENT-ID\", \"client_secret\": \"YOUR-TWITCH-CLIENT-SECRET\", \"authorizationURL\": \"https://api.twitch.tv/kraken/oauth2/authorize\", \"tokenURL\": \"https://api.twitch.tv/kraken/oauth2/token\", \"scope\": [\"user_read\"], \"scripts\": { \"fetchUserProfile\": \"function(accessToken, ctx, cb){ request.get('https://api.twitch.tv/kraken/user', { headers: { 'Authorization': 'OAuth ' + accessToken, 'Accept': 'application/vnd.twitchtv.v3+json' } }, function(e, r, b) { if (e) return cb(e); if (r.statusCode !== 200 ) return cb(new Error('StatusCode: ' + r.statusCode)); var profile = JSON.parse(b); profile.id = profile._id; delete profile._id; profile.links=profile._links; delete profile._links; return cb(null, profile);});}"
-	},
-	"headersSize": -1,
-	"bodySize": -1,
-	"comment": ""
-}
-```
-
-## Uber
-
-1. Navigate to [Uber Developers](https://developer.uber.com/).
-2. If you have not already [registered an Uber application](https://developer.uber.com/dashboard/create), you will need to do so prior to continuing. If you have, set the `Redirect URI` of your application to 'https://${account.namespace}/login/callback'.
-3. Copy the `Client ID` and `Client Secret` for use with your cURL `POST`.
-
-```har
-{
-	"method": "POST",
-	"url": "https://YOURACCOUNT.auth0.com/api/v2/connections",
-	"httpVersion": "HTTP/1.1",
-	"cookies": [],
-	"headers": [{
-		"name": "Authorization",
-		"value": "Bearer ABCD"
-	}],
-	"queryString": [],
-	"postData": {
-		"mimeType": "application/json",
-		"text": "{ \"name\": \"uber\", \"strategy\": \"oauth2\", \"options\": { \"client_id\", \"YOUR_UBER_APP_KEY\", \"client_secret\": \"YOUR_UBER_APP_SECRET\", \"authorizationURL\": \"https://login.uber.com/oauth/authorize\", \"tokenURL\": \"https://login.uber.com/oauth/token\", \"scope\": [\"profile\"], \"scripts\": { \"fetchUserProfile\": \"function(accessToken, ctx, cb) { request.get('https://api.uber.com/v1/me', { headers: { 'Authorization': 'Bearer ' + accessToken } }, function(e, r, b) { if (e) return cb(e); if (r.statusCode !== 200 ) return cb(new Error('StatusCode: ' + r.statusCode)); var profile = JSON.parse(b); profile.user_id = profile.uuid; cb(null, profile); });}\" } }, \"enabled_clients\": [\"\"] }"
-	},
-	"headersSize": -1,
-	"bodySize": -1,
-	"comment": ""
-}
-```
-
-## Vimeo
-
-1. Navigate to [Vimeo](https://dribbble.com/account/applications/new).
-2. If you have not already registered a new Vimeo application, you will need to do so prior to continuing.
-3. Copy the `Client ID` and `Client Secret` for use with your cURL `POST`.
-
-```har
-{
-	"method": "POST",
-	"url": "https://YOURACCOUNT.auth0.com/api/v2/connections",
-	"httpVersion": "HTTP/1.1",
-	"cookies": [],
-	"headers": [{
-		"name": "Authorization",
-		"value": "Bearer ABCD"
-	}],
-	"queryString": [],
-	"postData": {
-		"mimeType": "application/json",
-		"text": "{ \"name\": \"vimeo\", \"strategy\": \"oauth2\", \"options\": { \"client_id\", \"YOUR_VIMEO_CLIENT_ID\", \"client_secret\": \"YOUR_VIMEO_CLIENT_SECRET\", \"authorizationURL\": \"https://api.vimeo.com/oauth/authorize\", \"tokenURL\": \"https://api.vimeo.com/oauth/access_token\", \"scope\": [\"public\"], \"scripts\": { \"fetchUserProfile\": \"function(accessToken, ctx, cb) { request.get('https://api.vimeo.com/me', { headers: { 'Authorization': 'Bearer ' + accessToken } }, function(e, r, b) { if (e) return cb(e); if (r.statusCode !== 200 ) return cb(new Error('StatusCode: ' + r.statusCode)); var profile = JSON.parse(b); profile.user_id = profile.uri; cb(null, profile); });}"
-	},
-	"headersSize": -1,
-	"bodySize": -1,
-	"comment": ""
-}
-```
-
-## Xing
-
-1. Navigate to [Xing](https://developer.xing.com/).
-2. If you have not already registered a Xing application, you will need to do so prior to continuing.
-3. Once available, copy the `Client ID` and `Client Secret` for use with your cURL `POST`.
-
-```har
-{
-	"method": "POST",
-	"url": "https://YOURACCOUNT.auth0.com/api/v2/connections",
-	"httpVersion": "HTTP/1.1",
-	"cookies": [],
-	"headers": [{
-		"name": "Authorization",
-		"value": "Bearer ABCD"
-	}],
-	"queryString": [],
-	"postData": {
-		"mimeType": "application/json",
-		"text": "{ \"name\": \"xing\", \"strategy\": \"oauth1\", \"options\": { \"client_id\", \"YOUR-XING-CLIENT-ID\", \"client_secret\": \"YOUR-XING-CLIENT-SECRET\", \"requestTokenURL\": \"https://api.xing.com/v1/request_token\", \"accessTokenURL\": \"https://api.xing.com/v1/access_token\", \"userAuthorizationURL\": \"https://api.xing.com/v1/authorize\", \"scripts\": { \"fetchUserProfile\": \"function (token, tokenSecret, ctx, cb) {var OAuth = new require('oauth').OAuth;var oauth = new OAuth(ctx.requestTokenURL,ctx.accessTokenURL,ctx.client_id,ctx.client_secret,'1.0',null,'HMAC-SHA1');oauth.get('https://api.xing.com/v1/users/me.json',token,tokenSecret,function(e, b, r) {if (e) return cb(e);if (r.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode)); var p = JSON.parse(b); var profile = p.users[0]; cb(null, profile); });}"
-	},
-	"headersSize": -1,
-	"bodySize": -1,
-	"comment": ""
-}
-```
diff --git a/articles/tutorials/get-user-information-with-unbounce-landing-pages.md b/articles/tutorials/get-user-information-with-unbounce-landing-pages.md
deleted file mode 100644
index 5b8d295338..0000000000
--- a/articles/tutorials/get-user-information-with-unbounce-landing-pages.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-description: How to get user information with one-click social authentication on Unbounce landing pages.
----
-
-# Get User Information with one-click social authentication on Unbounce Landing Pages
-
-### Configuration on Auth0
-
-1. Create an account in [Auth0](https://auth0.com) and navigate to the [dashboard](${manage_url}).
-2. Go to **Clients -> + Create Client**. Create a Single Page Application on the Auth0 dashboard, go to Settings and take note of 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`).
-3. Go to **Connections -> Social** and Turn on the Social Providers you want to support.
-
-**NOTE:** you should configure the Client ID and Secret for each social connection.
-
-![](/media/articles/scenarios/unbounce/social-connections.png)
-
-## Configuration on Unbounce
-
-* 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.
-
-```
-
-
-```
-
-**NOTE:** You should use the clientID and Domain of the client 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 [normalized profile](/user-profile/normalized) fields `name`, `email`, `given_name`, `family_name`, `nickname` and `picture`. You can also include IdPs specific attributes such as `headline` if you are using LinkedIn.
-
-![](/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 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 `#INPUT_1` you should put the ID of the form field (you can see it while editing the form, under `Field Name and ID`).
-
-```
-$('#REPLACE_WITH_BUTTON_ID').bind('click', function() {
-  auth0.login({
-    connection: 'REPLACE_WITH_CONNECTION_NAME',  // you get the connection name from Auth0 dashboard (expand social provider)
-  });
-});
-
-  var result = auth0.parseHash(window.location.hash);
-
-  if (result && result.idToken) {
-    auth0.getProfile(result.idToken, function (err, profile) {
-      // normalized attributes from Auth0
-      $('#INPUT_1').val(profile.name);
-      $('#INPUT_2').val(profile.email);
-      $('#INPUT_3').val(profile.given_name);
-      $('#INPUT_4').val(profile.family_name);
-      $('#INPUT_5').val(profile.nickname);
-      $('#INPUT_6').val(profile.picture);
-
-      // provider-speicifc attributes
-      if (profile.headline) $('#INPUT_7').val(profile.headline);
-    });
-  } else if (result && result.error) {
-    alert('error: ' + result.error);
-  }
- 
-```
-
-That's it! 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/tutorials/how-auth0-versions-software.md b/articles/tutorials/how-auth0-versions-software.md
deleted file mode 100644
index e9eebbdb05..0000000000
--- a/articles/tutorials/how-auth0-versions-software.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-title: How Auth0 versioning works
-description: This page explains how Auth0 versioning works.
----
-
-# 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
-
-> 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.
-
-[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)](http://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:
-
-```js
-
-
-
-
-
-
-
-
-```
-
-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 about git: 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`.
diff --git a/articles/tutorials/how-to-monitor-auth0.md b/articles/tutorials/how-to-monitor-auth0.md
deleted file mode 100644
index 86012e8fdc..0000000000
--- a/articles/tutorials/how-to-monitor-auth0.md
+++ /dev/null
@@ -1,154 +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",
-  "headers": [
-    { "name": "Authorization", "value": "Bearer YOUR_ID_TOKEN_HERE" }
-  ]
-}
-```
-
-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 [Management Dashboard](${manage_url}) and Documentation.
-
-```har
-{
-  "method": "GET",
-  "url": "https://${account.namespace}/testall",
-  "headers": [
-    { "name": "Authorization", "value": "Bearer YOUR_ID_TOKEN_HERE" }
-  ]
-}
-```
-
-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.
-
-```har
-{
-  "method": "POST",
-  "url": "https://${account.namespace}/oauth/ro",
-  "headers": [
-    { "name": "Content-Type", "value": "application/json" }
-  ],
-  "postData": {
-    "mimeType": "application/json",
-    "text": "{\"client_id\": \"An app registered in Auth0 for monitoring\",\"username\": \"A system account for monitoring\", \"password\": \"A password\", \"connection\": \"A user store defined in Auth0\", \"grant_type\": \"password\", \"scope\":\"openid\", \"device\": \"SCOM\"}"
-  }
-}
-```
-
-A successful request would return a `200` HTTP status code and the following information:
-
-```json
-{
-  "id_token": "eyJ0eXAi......3Jia5WgM",
-  "access_token": "F25VQ.....NWpS",
-  "token_type": "bearer"
-}
-```
-
-We recommend using an authentication flow that doesn't require a user interface (such as the `Resource Owner flow`) 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 Associated with Your Auth0 Account
-
-If you are seeing issues with your Auth0 service, but the monitoring endpoints aren't returning information on errors, check the status of any external services that you use via Auth0.
-
-* [Amazon Web Services](https://status.aws.amazon.com/)
-* [Azure Active Directory](https://azure.microsoft.com/en-us/status/)
-* [Facebook](https://developers.facebook.com/status/)
-* [GitHub](https://status.github.com/)
-* [Google's G Suite](https://www.google.com/appsstatus#hl=en&v=status)
-* [Mandrill](http://status.mandrillapp.com/)
-* [SendGrid](http://status.sendgrid.com/)
-* [Twilio](https://status.twilio.com/)
-
-## Monitoring a Dedicated Deployment
-
-Please see the [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/tutorials/how-to-test-partner-connection.md b/articles/tutorials/how-to-test-partner-connection.md
deleted file mode 100644
index 7dabd7ad56..0000000000
--- a/articles/tutorials/how-to-test-partner-connection.md
+++ /dev/null
@@ -1,52 +0,0 @@
----
-description: How to test a partner connection.
----
-
-# Testing a partner connection
-
-Testing a connection in Auth0 is very easy: 
-
-1. Click on the __Try__ button on each connection.
-2. Login with the identity provider.
-3. Wait for the __It Works!__ page that displays the result. 
-
-Auth0 simulates the authentication flow as if it was an application, displaying the __User Profile__ resulting from a successful authentication.
-
-There's a caveat though: for this to work you have to be logged-in in the dashboard.
-
-This is often not possible if you are testing a connection that belongs to someone else, and you don't have test credentials with them. This is common when connecting to __Enterprise connections__ such as __SAML IdPs__ or __Active Directory__. 
-
-Having your partners test the new connection is very easy nevertheless:
-
-## 1. Create a Test app
-
-Register a new application on Auth0: __[Dashboard > Apps/APIs > Create](${manage_url}/#/applications/create)__. You can give it any name: __Test App__
-
-In the settings of the newly created app, configure __Allowed Callback Urls__ to __[http://jwt.io](http://jwt.io)__.
-
-Click on __SAVE CHANGES__.
-
-
-## 2. Send your Partner the link to login
-
-  https://${account.namespace}/authorize?response_type=token&scope=openid%20profile&client_id=${account.clientId}&redirect_uri=http://jwt.io&connection=THE_CONNECTION_YOU_WANT_TO_TEST
-
-Make sure you replace these two parameters:
-
-* __client_id__: the app client_id created in __Step 1__.
-* __connection__: the name of the connection you want to test.
-
-> `scope=openid profile` will instruct Auth0 to return the full profile. If it is too large, you will see an error. You can trim it by specifying only a few properties: `scope=openid name email`. See [scopes](/scopes) for more details.
-
-## 3. Test it!
-
-When your partner follows the link above, they will be redirected to their configured Identity Provider (the __connection__). After successful authentication, they will be sent back to [JWT.io](http://jwt.io) where all user properties will be decoded from the token. 
-
-> Note that the test app is not a _real_ app. [JWT.io](http://jwt.io) is just a testing website that is able to decode tokens sent on a URL fragment.
-
-
-
-
-
-
-
diff --git a/articles/tutorials/how-to-update-applications-client-secret.md b/articles/tutorials/how-to-update-applications-client-secret.md
deleted file mode 100644
index cbbcbf901d..0000000000
--- a/articles/tutorials/how-to-update-applications-client-secret.md
+++ /dev/null
@@ -1,52 +0,0 @@
----
-description: This page lists different ways of how to update your application's client secret.
----
-
-# Changing your application's client_secret
-
-The `client_secret` of an application protects a service by only giving tokens to authorized applications. Client secrets should be protected, and if your `client_secret` has been compromised then you will need to generate a new one. Remember that all authorized apps will need to be updated with the new `client_secret`.
-
-## Changing your client_secret in the dashboard
-
-You can change your `client_secret` under [Clients](${manage_url}/#/clients) in the dashboard. Choose the client you wish to edit by clicking on the **Settings** gear icon or the client name. You can edit the **Client Secret** field, and when you are finished, click the **SAVE CHANGES** button at the bottom of the page.
-
-## Updating authorized clients
-
-Once you have changed your client's `client_secret` you will need to update any authorized clients to have the new value. To make sure the authorized client does not have any downtime with connecting to your client, we suggest you store the new `client_secret` as a fallback to the previous secret. So if the connection does not work with the old secret, use the new secret. The secrets can be stored in a list or similar structure to keep track of keys until they are no longer needed. Once you are sure an old secret is no longer used, it can safely be taken out of the client.
-
-## How to generate a new client_secret
-
-If your `client_secret` needs to be replaced you will need to generate a new one on your own. It should be a cryptographically strong random string. There are many ways to do this such as using a library that creates a GUID, a hashing function, etc.
-
-Here is an example of a command you can use to generate a random string:
-
-`dd if=/dev/random bs=48 count=1`
-
-## Using the Management API to set the new Client Secret
-
-You can change your client's secret by using the [Rotate Secret API endpoint](/api/v2/clients/{id}/rotate-secret). This will rotate your secret with a secret generated by Auth0. This is the recommended approach, since we ensure a safe secret. However the generated secret will **not** be Base64-encoded. You can use this endpoint to start using non encoded secrets.
-
-If you are still using a Base64-encoded client secret and you want to change your client's secret with a new encoded one, you can use the [Update a client API endpoint](/api/v2#!/Clients/patch_clients_by_id).  Set the `id` of the client you are updating, and then in the `body` section enter your new `client_secret` as a JSON field.
-
-**Note:** The `client_secret` can only be updated with the `update:client_keys` scope.
-
-You can get your `client_id` and `client_secret` by choosing your client in the [Clients](${manage_url}/#/clients) section of the dashboard.
-
-Or you can update a `client_secret` by creating your own request to the API:
-
-```har
-{
-  "method": "PATCH",
-  "url": "https://${account.namespace}/api/v2/clients/${account.clientId}",
-  "headers": [{
-    "name": "Content-Type",
-    "value": "application/json"
-  }],
-  "postData": {
-    "mimeType": "application/json",
-    "text": "{\"client_secret\": \"NEW_CLIENT_SECRET\"}"
-  }
-}
-```
-
-Remember that if your client uses a Base64-encoded client secret, and you want to update it using the [Update a client API endpoint](/api/v2#!/Clients/patch_clients_by_id) then the updated one has to be encoded as well. Otherwise, you should use the [Rotate Secret API endpoint](/api/v2/clients/{id}/rotate-secret).
diff --git a/articles/tutorials/index.md b/articles/tutorials/index.md
deleted file mode 100644
index 82427ca1bc..0000000000
--- a/articles/tutorials/index.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-url: /tutorials
----
-
-# Tutorials
-
-
          
-<% cache.find('articles/tutorials', {sort: 'title'}).forEach(article => { %>
-  
        • 
-    <%- article.title %>
-    
          <%- article.description %>
          
-  
          • 
-<% }); %>
-
        
-
----
-
-# Quickstarts
-
-To find quickstarts please go to the [docs home page](/) and browse the tutorial navigator at the top by selecting your platform and language.
diff --git a/articles/tutorials/integrating-auth0-amazon-cognito-mobile-apps.md b/articles/tutorials/integrating-auth0-amazon-cognito-mobile-apps.md
deleted file mode 100644
index 16b0fa6301..0000000000
--- a/articles/tutorials/integrating-auth0-amazon-cognito-mobile-apps.md
+++ /dev/null
@@ -1,130 +0,0 @@
----
-description: How to integrate Auth0 with Amazon Cognito for mobile applications.
----
-
-# Integrating Auth0 with Amazon Cognito for Mobile Apps.
-
-**Amazon Cognito** is a backend as a service that lets you focus on writing a fantastic user experience for your client app (native or web).
-
-In this document, I’ll explain how you can integrate your mobile app with two solutions: Auth0 to get authentication with either [Social Providers](/identityproviders#social) (Facebook, Twitter, etc.), [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
-
-## Configuring 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 (_accountName_.auth0.com) and your _clientId_ and use them to create the Identity Pool in the [IAM Console](https://console.aws.amazon.com/iam/home):
-
-![IDP Creation](/media/articles/scenarios/amazon-cognito/IDPCreation.gif)
-
-> 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.
-
-Please do **not** use the certificate thumbprint shown on the Auth0 Application Dashboard.
-
-### 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.
-
-![Cognito Pool Creation](/media/articles/scenarios/amazon-cognito/IDPCognito.gif)
-
-> Please take a note of the ARN selected in the end of the gif. We’ll use it later on!
-
-### Grab the Role ARN
-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).
-
-![Grab Role ARN](/media/articles/scenarios/amazon-cognito/Roles.gif)
-
-# Configuring Auth0
-### Configure your application
-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.
-
-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, press "Show Advanced Settings" and change the algorithm to RS256:
-
-![](/media/articles/scenarios/amazon-cognito/cdn-amazon-cognito-rs256.png)
-
-## Code time!
-Now it’s time to start coding our app. In this case, we’ll be using Swift, but the same sample applies to Objective-C as well.
-
-### Adding the Needed Dependencies
-
-Add the following dependencies to your `Podfile`
-
-```ruby
-pod "Lock", "~> 2.4"
-pod "JWTDecode"
-pod "SimpleKeychain"
-pod "AWSCore"
-pod "AWSCognito"
-```
-### Logging the User In
-We’ll use [Auth0 Lock for iOS](https://github.com/auth0/lock) to log the user in. You can read detailed instructions on how to implement it in [this documentation page](/native-platforms/ios-swift).
-Once the user is successfully logged in with Auth0, we’ll send their credentials to Amazon Cognito:
-
-```swift
-let authController = A0LockViewController()
-authController.onAuthenticationBlock = {(profile:A0UserProfile!, token:A0Token!) -> () in
-  // Save Tokens and Credentials into the keychain as you'd regularly do
-  // ...
-
-  let provider = AWSCognitoCredentialsProvider.credentialsWithRegionType(
-    AWSRegionType.USEast1,
-    // Your AWS Account ID
-    accountId: Constants.AWSAccountID.value,
-    // This is the ARN from Cognito Identity Pool
-    identityPoolId: Constants.CognitoPoolID.value,
-    unauthRoleArn: '',
-    // This is the ARN from the Role
-    authRoleArn: Constants.CognitoRoleAuth.value);
-
-
-  let configuration = AWSServiceConfiguration(region: AWSRegionType.USEast1, credentialsProvider: self.provider);
-  AWSServiceManager.defaultServiceManager().setDefaultServiceConfiguration(configuration)
-
-  // Set here the Auth0 URL you've set when creating the OpenID Connect Provider
-  provider.logins = ['samples.auth0.com': token.idToken]
-  self.provider.getIdentityId().continueWithBlock { (task: BFTask!) -> AnyObject! in
-      self.provider.refresh()
-      if (task.error != nil) {
-          // Fail
-      } else {
-          // Logged in with Cognito successfully
-      }
-      return nil
-  }
-}
-```
-
-### Using Cognito
-
-Now, the user is logged in to Cognito through Auth0. You can now store information in Cognito that only this user will be able to use.
-
-```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()
-```
-## Let’s see how it works!
-
-![Cognito working](/media/articles/scenarios/amazon-cognito/CognitoSample.gif)
-
-## Final Thoughts
-
-That’s it! Now, your users can login with Github or any other identity provider using a native UI and save their information with Cognito easily.
-
-You can check out a working sample that uses Cognito and Auth0 in [this Github repository](https://github.com/auth0/Lock.iOS-OSX/tree/master/Examples/Cognito.Swift)
-
-Happy coding :).
diff --git a/articles/tutorials/integrating-with-slack.md b/articles/tutorials/integrating-with-slack.md
deleted file mode 100644
index cfbec90c8a..0000000000
--- a/articles/tutorials/integrating-with-slack.md
+++ /dev/null
@@ -1,56 +0,0 @@
----
-description: How to integrate and configure Auth0 with Slack.
----
-
-# Integrate Auth0 with Slack
-
-You can configure Slack to login with Auth0. That way, users would be able to login with any of the [identity providers](/identityproviders) supported by Auth0, such as Active Directory, LDAP, Google Apps, Facebook, Google, Twitter, and so on. It will also provide Single Sign On with other clients configured.
-
-# Configure Your Auth0 Account
-
-Login to the Auth0 [Management Dashboard](${manage_url}).
-
-Select **SSO Integrations**.
-
-![](/media/articles/scenarios/slack/sso-integration.png)
-
-Click the **Slack** box.
-
-![](/media/articles/scenarios/slack/sso-int-options.png)
-
-Set the name for your SSO Integration. Click **Create**.
-
-![](/media/articles/scenarios/slack/sso-int-name.png)
-
-You will be brought to the **Slack Configuration Instructions** page.
-
-![](/media/articles/scenarios/slack/slack-config-instructions.png)
-
-This page contains instructions on how to configure your integration with your Slack account, which you will discover in the next section of this document.
-
-Click on the **Settings** tab.
-
-![](/media/articles/scenarios/slack/slack-settings.png)
-
-Provide the following values:
-* **Name**: the name for your SSO integration (if you would like to change the value you provided when you first set up the integration);
-* **Team Name**: the name of your Slack team.
-* **Use Auth0 instead of the IdP to do single sign on**: if you would like Auth0 to handle Single Sign On instead of Slack, set the appropriate slide to **green** to activate this feature.
-
-Save.
-
-# Configure Your Slack Account
-
-When you configure your Slack Account, please refer to the **Slack Configuration Instructions** page in your Auth0 Management Dashboard for the required parameters.
-
-![](/media/articles/scenarios/slack/slack-config-instructions.png)
-
-1. Login to the [Slack Authentication Settings](https://slack.com/admin/auth) page as an administrator.
-2. Under the **SAML Authentication** tab, click **Configure**.
-3. Choose **Custom SAML 2.0** as the **SAML Provider**.
-4. Populate the **SAML 2.0 Endpoint (HTTP)** with the Auth0-provided URL. Alternatively, you can add a Connection parameter to login with a specific identity provider. Now, Auth0 will redirect users to the specified Connection and not display the Auth0 login widget.
-5. Provide the **Identity Provider Issuer** (optional);
-6. Provide the **Public Certificate** value.
-7. Save.
-
-For additional information, please consult 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).
diff --git a/articles/tutorials/manage-dashboard-admins.md b/articles/tutorials/manage-dashboard-admins.md
deleted file mode 100644
index 92a1e1f306..0000000000
--- a/articles/tutorials/manage-dashboard-admins.md
+++ /dev/null
@@ -1,13 +0,0 @@
----
-description: How to add and remove admin users in the Auth0 dashboard.
----
-
-# Manage Admins in the Dashboard
-
-Admin users can be added and removed from the dashboard, by going to **Account Settings** and choosing the [Dashboard Admins](${manage_url}/#/account/admins) tab.
-
-![Change Dashboard Admins](/media/articles/tutorials/manage-admins.png)
-
-To add an Admin, enter the email of the account and then select the applications you would like this user to have admin access to in the **Application** box. Then click the **ADD** button.
-
-Admins can be removed by clicking the **REMOVE** button after they have been added.
diff --git a/articles/tutorials/office365-connection-deprecation-guide.md b/articles/tutorials/office365-connection-deprecation-guide.md
deleted file mode 100644
index e0d01a1224..0000000000
--- a/articles/tutorials/office365-connection-deprecation-guide.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-description: Details migrating Office365 connections to Windows Azure AD.
----
-
-# Office365 Connections Deprecated - Use Windows Azure AD
-
-## Immediate Action
-
-Migrate your Office365 Connections to Windows Azure AD Connections.
-
-## How
-
-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).
-
-__IMPORTANT:__ If you were using the `user_id` in your application, notice that it will change from `office365|....some-guid....` to `waad|...email....`.
-
-## Why
-
-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.
diff --git a/articles/tutorials/openid-connect-discovery.md b/articles/tutorials/openid-connect-discovery.md
deleted file mode 100644
index 1ecaa9b7ab..0000000000
--- a/articles/tutorials/openid-connect-discovery.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-description: How to use OpenID Connect discovery with Auth0.
----
-
-# OpenID Connect Discovery
-
-Auth0 exposes 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
-  {
-    // 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);
-    }
-  }
-});
-```
-
-## 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:
-
-### 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)
-
-With this setting, Auth0 will issue JWT tokens signed with your private signing key. Your app will verify them with your public signing key.
diff --git a/articles/tutorials/redirecting-users.md b/articles/tutorials/redirecting-users.md
deleted file mode 100644
index 67d1173d18..0000000000
--- a/articles/tutorials/redirecting-users.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-description: How to handle returning users after authentication.
----
-
-# Redirecting Users After Login
-
-In order to give your application's users a good experience, it is necessary to handle how users are redirected back to your application after authentication.
-
-The `redirect_uri` field is meant to be used for a callback url, which is not necesarily they URL you want to bring users to after authentication. Callback URLs are the URLs that Auth0 invokes after the authentication process where your application is then routed. Since callback URLs can be manipulated for security only whitelisted URLs set in `Allowed Callback URLs` will be recognized as valid. 
-
-If you want to redirect your users to another page on your site that is not the callback url, there are a few options on how to do so:
-
-## Using the `state` parameter
-The `state` parameter is one of the supported Auth0 [Authentication Parameters](/libraries/lock/v10/sending-authentication-parameters). You can use this field to hold multiple values such as a JSON object that holds the URL you want to bring the user to. 
-
-For example:
-
-```
-state = {
-   "auth0_authorize": "xyzABC123",
-   "return_url": "https://yoursite.com/home"
-}
-```
-
-When the state value is returned after a successful request, you can use the `return_url` contained in the `state` to redirect the user to the desired URL. [Click here to learn more about using the state parameter.](/protocols/oauth-state)
-
-## Storing the redirect URL
-
-Another option is to store the desired redirect URL in web storage to be used after authentication. This is similar to how you would [store a JWT](/security/store-tokens#where-to-store-your-jwts). Like with the `state` parameter, this will hold the URL you want to bring your users to.
-
-These are just a few suggestions and there are other ways you can configure your application to handle redirecting your users after authentication.
diff --git a/articles/tutorials/removing-auth0-exporting-data.md b/articles/tutorials/removing-auth0-exporting-data.md
deleted file mode 100644
index 983cfcdfa2..0000000000
--- a/articles/tutorials/removing-auth0-exporting-data.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-description: How to export data out of Auth0.
----
-
-# Moving out of Auth0
-
-All data in your Auth0 account 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}).
-
-## Keeping 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
-
-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).
-
-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, etc.) 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.
-
-## Further reading
-
-* [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/articles/tutorials/sending-events-to-keenio.md b/articles/tutorials/sending-events-to-keenio.md
deleted file mode 100644
index 36110a7715..0000000000
--- a/articles/tutorials/sending-events-to-keenio.md
+++ /dev/null
@@ -1,60 +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:
-
-> Anlytics 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.large number of anayltics services with a single, simple to use API. 
-
-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.
-
-![](/media/articles/tutorials/keen-io-dataflow.png)
-
-### 1. 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`. 
-
-
-```
-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);
-       });
-}
-```
-> 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/tutorials/sending-events-to-segmentio.md b/articles/tutorials/sending-events-to-segmentio.md
deleted file mode 100644
index beb5091e76..0000000000
--- a/articles/tutorials/sending-events-to-segmentio.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-description: How to send events to segment.io from Auth0.
----
-
-# Sending events to segment.io from Auth0
-
-[segment.io](http://segment.io/features) provides access to large number of anayltics services with a single, simple to use API. 
-
-This example shows how you can very easily connect Auth0 to __segment.io__ and stream `signup` and `login` events. 
-
-Implementing this with Auth0 is very easy, only taking a few lines of code.
-
-![](/media/articles/tutorials/segment-io-dataflow.png)
-
-### 1. Recording a __SignUp__ or __Login__ event in segment.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 this is a `login` event, otherwise we assume a new `signup`. 
-
-The `sendEvent` function is a simple wrapper around the __segment.io REST API__ which is trivial to call using the provided `request` module. Notice we are also sending some additional contextual information: the __IP address__ and __User Agent__ of the user.
-
-
-```
-function(user, context, callback) {
-
-  if(user.signedUp){
-    sendEvent('login');
-  } else {
-    sendEvent('signup');  
-  }
-  
-  function sendEvent(e)
-  {
-    var sioTrack =  
-    {
-      secret: "YOUR SEGMENTIO SECRET",
-      userId: user.user_id,
-      event: e,
-      properties: {
-        application: context.clientName,
-        ip: context.ip,
-        agent: context.userAgent
-      },
-      context: {
-        "providers" : { "all": false }
-      }
-    };
-
-    request({
-      method: 'POST',
-      url: '  https://api.segment.io/v1/track',
-      headers: {
-        'Content-type': 'application/json',
-      },
-      body: JSON.stringify(sioTrack),
-    }, 
-    function (err, response, body) {
-      if(err) return callback(err, user, context);
-      if(e === 'signup'){ user.persistent.signedUp = true; }
-      callback(null, user, context);
-    });
-  }
-}
-```
-> 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/tutorials/sending-events-to-splunk.md b/articles/tutorials/sending-events-to-splunk.md
deleted file mode 100644
index 265c81d9e2..0000000000
--- a/articles/tutorials/sending-events-to-splunk.md
+++ /dev/null
@@ -1,63 +0,0 @@
----
-description: How to send events to Spunk from Auth0.
----
-
-# Sending events to Splunk from Auth0
-
-[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.
-
-Implementing this with Auth0 is very easy, only taking a few lines of code.
-
-![](/media/articles/tutorials/splunk-dataflow.png)
-
-### 1. Recording a __SignUp__ or __Login__ event in Splunk:
-
-This Auth0 rule 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 `user.signedUp` property. If the property is present then we assume this is a `login` event, otherwise we assume 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, username, etc.
-
-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 dashbaord.
-
-When enabled, this rule will start sending events that will show up on Splunk's dashboard:
-
-![](/media/articles/scenarios/splunk/splunk-dashbaord.png)
-
-```
-function(user, context, callback) {
-
-  var splunkBaseUrl = 'YOUR SPLUNK SERVER, like: https://your server:8089';
-
-  //Add any interesting info to the event
-  var event = {
-    message: user.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?source=auth0&sourcetype=auth0_activity',
-                  auth: {
-                      'user': 'YOUR SPLUNK USER',
-                      'pass': 'YOUR SPLUNK PASSWORD',
-                    },
-                  body: JSON.stringify(event)
-                },
-                function(e,r,b) {
-                    if( e ) { return callback(e) };
-                    if( r.statusCode !== 200 ) return callback('Invalid operation');
-                    if( !user.signedUp ) { persistent.signedUp = true }; //Signal signup for next time
-                    return callback(e,user,context);
-                 });
-}
-```
-> 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/tutorials/single-sign-on-with-zendesk-using-jwt.md b/articles/tutorials/single-sign-on-with-zendesk-using-jwt.md
deleted file mode 100644
index 55d93bd4e8..0000000000
--- a/articles/tutorials/single-sign-on-with-zendesk-using-jwt.md
+++ /dev/null
@@ -1,87 +0,0 @@
----
-description: How to enable SSO with Zendesk using JWT.
----
-
-# Single Sign-On with Zendesk using JWT
-
-This [Zendesk article](https://support.zendesk.com/hc/en-us/articles/203663816-Setting-up-single-sign-on-with-JWT-JSON-Web-Token-) details everything about getting SSO to work with any JWT provider.
-
-> **Note:** If you happen to lock yourself out of your Zendesk account while following this tutorial, you can always log in with your regular Zendesk credentials at https://your_domain.zendesk.com/access/normal
-
-SSO can be enabled for Zendesk administrators/agents, users, or both. In any case, the configuration is the same.
-
-## 1. Enable SSO with JWT
-
-Log in to the Zendesk dashboard, go to **Security** settings and enable **SSO** with **JSON Web Token**:
-
-![](/media/articles/scenarios/zendesk-sso/zendesk-sso-1.png)
-
-**Remote login URL** should point to a webpage where your users will be able to sign in, for example, using [Lock](/lock).
-Take note of the **Shared secret**, which will be used in the following step.
-
-## 2. Implement a rule to create a JWT for Zendesk
-
-We want to create a JWT with a user's information after login that Zendesk can understand.
-This can be achieved by [using a rule](/rules).
-In this example the Zendesk **Shared secret** is being stored as an encrypted key-value pair, which can be accessed with `configuration.ZENDESK_JWT_SECRET` in the rule's code.
-
-```js
-function (user, context, callback) {
-
-  // Assuming your Zendesk URL is https://foo.zendesk.com
-  var ZENDESK_SUBDOMAIN = 'foo';
-
-  // Generate a random UUID: http://en.wikipedia.org/wiki/Universally_unique_identifier
-  // Used in the token's jti claim to protect against replay attacks
-  var uuid = require('uuid');
-
-  // Create the JWT as required by Zendesk
-  var payload = {
-    iat: new Date().getTime() / 1000,
-    jti: uuid.v4(),
-    email: user.email,
-    name: user.name,
-    external_id: user.user_id
-  };
-
-  // Sign the token and add it to the profile
-  var zendesk_token = jwt.sign(payload, configuration.ZENDESK_JWT_SECRET);
-  user.zendesk_jwt_url = 'https://' + ZENDESK_SUBDOMAIN + '.zendesk.com/access/jwt?jwt=' + zendesk_token;
-
-  callback(null, user, context);
-}
-```
-
-## 3. Redirect users to the URL returned by Zendesk
-
-The rule returned in the previous step will return a user property named `zendesk_jwt_url`, which will allow your user to log in.
-If using [Lock](/lock), for example:
-
-```js
-lock.show(function (err, profile, id_token) {
-  if (err) {
-    console.error('Something went wrong!', err);
-  } else if (profile.zendesk_jwt_url) {
-    window.location = profile.zendesk_jwt_url;
-  }
-});
-```
-
-### Optional: Redirecting users to the URL they originally visited
-
-When Zendesk redirects users to your login page, a [`return_to` query parameter](https://support.zendesk.com/hc/en-us/articles/203663816-Setting-up-single-sign-on-with-JWT-JSON-Web-Token-#topic_hkm_kst_kk) is added to your login page URL.
-This parameter contains the Zendesk URL where your users should be redirected after login.
-It should be added to the Zendesk URL returned by the above rule:
-
-```js
-// Using URI.js, see http://medialize.github.io/URI.js/
-return_to = URI(document.URL).query(true).return_to;
-
-lock.show(function (err, profile, id_token) {
-  if (err) {
-    console.error('Something went wrong!', err);
-  } else if (profile.zendesk_jwt_url) {
-    document.getElementById('zendesk_url').href = URI(profile.zendesk_jwt_url).addSearch({return_to: return_to});
-  }
-});
-```
diff --git a/articles/tutorials/step-up-authentication.md b/articles/tutorials/step-up-authentication.md
deleted file mode 100644
index 8b036ac620..0000000000
--- a/articles/tutorials/step-up-authentication.md
+++ /dev/null
@@ -1,80 +0,0 @@
----
-description: You can add step-up authentication to your app with Authentication Context Class Reference
----
-
-# 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* can require 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) can trigger a stronger authentication mechanism like [multifactor authentication](/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 and, if not, require the user to step-up to access certain resources.
-
-![](/media/articles/step-up-authentication/flow.png)
-
-## Step-Up Authentication with ACR
-
-There are three core concepts used when addressing authentication level at Auth0.
-
-* `acr`- Authentication Context Class Reference: is a string used to specify the 'class' of authentication that was performed on the current session. Look to [Authentication Context Class Reference](http://openid.net/specs/openid-connect-core-1_0.html) page for more detail and specific policies. Currently, Auth0 utilizes the 'Multi-Factor Authentication' policy, `http://schemas.openid.net/pape/policies/2007/06/multi-factor`.
-
-* `amr`- Authentication Methods References: is a JSON case senstitive string list of methods that were used to authenticate the current session.  For instance, values might indicate that both password and OTP authentication methods were used.  See the [Authentication Methods References](http://openid.net/specs/openid-connect-core-1_0.html) page for more details.
-
-* `acr_values`: this is a space-separated string that specifies the `acr` values that have been requested to use for processing the request, with the values appearing in order of preference. This can be used to request the class of `acr` above when authentication is to be performed.  See [here](http://openid.net/specs/openid-connect-core-1_0.html) for more details.
-
-`acr` and `amr` are both available on the `id_token` of the current session, when appropriate. Both can signal to use MFA. The `acr_values` field is added to the request for authentication.
-
-## Example
-
-To request that Auth0 require a multifactor authentication, add the field `acr_values` to the authentication along with the `acr` level desired. For example, with [Auth0.js](/libraries/auth0js) it would work like the following code snippet:
-
-```js
-// Use acr_values to indicate this user needs a step-up with MFA
-auth0.signin({
-  connection: 'google-oauth2',
-  acr_values: 'http://schemas.openid.net/pape/policies/2007/06/multi-factor'
-});
-```
-
-With [Lock](/libraries/lock), the following would indicate the need for MFA:
-```js
-// Use acr_values to indicate this user needs a step-up with MFA
-var options = {
-  ...
-  auth: {
-    acr_values: 'http://schemas.openid.net/pape/policies/2007/06/multi-factor'
-  }
-};
-
-lock = new Auth0Lock('clientID', 'account.auth0.com', options);
-```
-
-To confirm that a session has had multifactor authentication, the id_token can be checked for its `acr` and `amr` claims.
-```js
-var decoded = jwt.verify(id_token, AUTH0_CLIENT_SECRET, { algorithms: ['HS256'] });
-
-// Confirm that the acr has the expected value
-if (Array.isArray(decoded.amr) && decoded.amr.indexOf('mfa') >= 0) {
-  throw new Error('Step-up authentication failed');
-}
-
-// We also expect to have the amr claim
-if(decoded.acr !== 'http://schemas.openid.net/pape/policies/2007/06/multi-factor'){
-  throw new Error('Step-up authentication failed');
-}
-```
-
-More example code with the step-up functionality can be found [here](https://github.com/auth0/guardian-example).
-
-## Further Reading
-
-* [Multifactor Authentication in Auth0](/multifactor-authentication)
-* [Auth0 id_token](/tokens/id_token)
-* [Overview of JSON Web Tokens](/jwt)
-* [Reference for acr, amr and acr_values](http://openid.net/specs/openid-connect-core-1_0.html)
-* [Authentication policy definitions](http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html#rfc.section.4)
-* [JSON Web Token Example](https://github.com/auth0/node-jsonwebtoken)
-* [Guardian example (with step-up functionality)](https://github.com/auth0/guardian-example)
-
-
-
diff --git a/articles/tutorials/track-signups-enrich-user-profile-generate-leads.md b/articles/tutorials/track-signups-enrich-user-profile-generate-leads.md
deleted file mode 100644
index 23b17b2432..0000000000
--- a/articles/tutorials/track-signups-enrich-user-profile-generate-leads.md
+++ /dev/null
@@ -1,143 +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 (e.g. IP addresses, agent, etc.).
-
-We also call this event `Sign Up`:
-
-```
-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`).
-
-```
-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.
-
-```
-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/tutorials/tracking-new-leads-in-salesforce-and-raplead.md b/articles/tutorials/tracking-new-leads-in-salesforce-and-raplead.md
deleted file mode 100644
index 66c4c62c86..0000000000
--- a/articles/tutorials/tracking-new-leads-in-salesforce-and-raplead.md
+++ /dev/null
@@ -1,119 +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).
-
-```
-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.
-
-```
-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/tutorials/troubleshooting-with-har-files.md b/articles/tutorials/troubleshooting-with-har-files.md
deleted file mode 100644
index f69b53b136..0000000000
--- a/articles/tutorials/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**: ![docs/img/ss-2015-01-19T11-32-15.png](/media/articles/har/ss-2015-01-19T11-32-15.png)
-1. Before sending the HAR file to us, make sure to obfuscate any sensitive information using a text editor (e.g. remove passwords, client_secrets, etc).
-1. Send the file to support by opening a [support ticket](${env.DOMAIN_URL_SUPPORT})
diff --git a/articles/tutorials/using-auth0-as-an-identity-provider-with-github-enterprise.md b/articles/tutorials/using-auth0-as-an-identity-provider-with-github-enterprise.md
deleted file mode 100644
index 714b1c6cd6..0000000000
--- a/articles/tutorials/using-auth0-as-an-identity-provider-with-github-enterprise.md
+++ /dev/null
@@ -1,64 +0,0 @@
----
-description: How to use Auth0 as an identity provider with GitHub Enterprise.
----
-
-# 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 Client using the [Clients]() page of the Management Dashboard.
-
-On the row associated with your chosen Client, click on the **Addons** button, which is the second button from the right on the appropriate Client 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/tutorials/using-auth0-to-secure-an-api.md b/articles/tutorials/using-auth0-to-secure-an-api.md
deleted file mode 100644
index c2e7092866..0000000000
--- a/articles/tutorials/using-auth0-to-secure-an-api.md
+++ /dev/null
@@ -1,125 +0,0 @@
----
-description: How to use Auth0 to secure a CLI.
----
-
-# Using Auth0 to secure a CLI
-
-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.
-
-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.
-
-## How it works
-
-Traditionally, public clients (e.g. mobile apps, SPAs and CLIs) have used the [implicit flow](/api-auth/grant/implicit) to obtain a token. In this flow, there's no __client authentication__ because there's no easy way of storing a `client_secret`.
-
-The [PKCE flow](/protocols) ('pixy' for friends), increases security by adding a cryptographic challenge in the token exchange. This prevents rogue apps to intercept the response from the authorization server, and get hold of the token.
-
-For this exchange to work without secret, you will have to set the `token_endpoint_auth_method` to `none`.
-
-```bash
-curl -H "Authorization: Bearer API2_TOKEN" -X PATCH  -H "Content-Type: application/json" -d '{"token_endpoint_auth_method":"none"}' https://yours.auth0.com/api/v2/clients/${account.clientId}
-```
-
-A CLI program just needs to:
-
-### 1. Initiate the authorization request:
-
-This is the regular OAuth2 authorization request, with the caveat that now it includes two parameters:
-
-* A `code_challenge` consisting of a randomly generated value (called the `verifier`), hashed (SHA256), and base64Url encoded.
-* A `code_challenge_method: S256`
-
-```
-https://${account.namespace}/authorize?response_type=code&scope=openid&client_id=${account.clientId}&redirect_uri=${account.callback}&code_challenge={Base64UrlEncode(SHA256(THE VERIFIER))}&code_challenge_method=S256
-```
-
-### 2. Get an __authorization code__:
-
-If authentication is successful, then Auth0 will redirect the browser to the callback with a `code` query parameter.
-
-  ${account.callback}/?code=123
-
-### 3. Exchange __code__ for __token__:
-
-With the `code`, the program then uses the `/token` endpoint 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 client.
-
-```
-POST /token HTTP/1.1
-Host: ${account.namespace}
-Content-type: application/json
-{
-  "code": "THE CODE",
-  "code_verifier": "THE VERIFIER",
-  "client_id": "${account.clientId}",
-  "grant_type": "authorization_code",
-  "redirect_uri": "${account.callback}"
-}
-``` 
-
-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, the request will fail.
-
-## Simple CLI example
-
-This simple project shows how the above would work in a nodejs CLI app. It uses the `opn` module to open a browser to perform the authentication. It expects a simple web app running on the ${account.callback} address that can display the `code` so the user can copy, and enter it in the CLI:
-
-```js
-var opn = require('opn');
-var request = require('request');
-var crypto = require('crypto');
-var readline = require('readline');
-var dotenv = require('dotenv');
-
-dotenv.load();
-
-var env = {
-  AUTH0_CLIENT_ID: process.env.${account.clientId},
-  AUTH0_URL: process.env.AUTH0_URL,
-  AUTH0_CALLBACK_URL: process.env.${account.callback} || 'http://localhost:3000',
-  AUTH0_CONNECTION: process.env.AUTH0_CONNECTION || 'Username-Password-Authentication'
-};
-
-var rl = readline.createInterface({
-  input: process.stdin,
-  output: process.stdout
-});
-
-//Generate the verifier, and the corresponding challenge
-var verifier = base64url(crypto.randomBytes(32));
-var verifier_challenge = base64url(crypto.createHash('sha256').update(verifier).digest());
-
-var authorize_url = env.AUTH0_URL + '/authorize?response_type=code&scope=openid%20profile&' + 
-                                    'client_id=' + env.${account.clientId} + 
-                                    '&redirect_uri=' + env.${account.callback} + 
-                                    '&code_challenge=' + verifier_challenge + '&code_challenge_method=S256' +
-                                    '&connection=' + env.AUTH0_CONNECTION;
-
-//Open a browser and initiate the authentication process with Auth0
-//The callback URL is a simple website that simply displays the OAuth2 authz code
-//User will copy the value and then paste it here for the process to complete.
-opn(authorize_url);
-
-rl.question('Please enter the authorization code: ', function(code) {
-  request.post(env.AUTH0_URL + '/oauth/token',{
-    json:{
-      code: code,
-      code_verifier: verifier,
-      client_id: env.${account.clientId},
-      grant_type: 'authorization_code',
-      redirect_uri: env.${account.callback}
-  }},function(err,status,body){
-    //TODO: do something useful with the token (in body)
-    //CLI is ready to call APIs, etc.
-  });
-
-  rl.close();
-});
-
-function base64url(b) {
-  return b.toString('base64')
-          .replace(/\+/g, '-')
-          .replace(/\//g, '_')
-          .replace(/=/g, '');
-}
-```
diff --git a/articles/tutorials/using-auth0-with-multi-tenant-apps.md b/articles/tutorials/using-auth0-with-multi-tenant-apps.md
deleted file mode 100644
index 3815748d51..0000000000
--- a/articles/tutorials/using-auth0-with-multi-tenant-apps.md
+++ /dev/null
@@ -1,184 +0,0 @@
----
-description: This articles lists several existing multi-tenant applications and describes their implementations.
----
-
-# Using Auth0 with Multi-tenant Apps
-
-
-Multi-tenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations (referred to as tenants).
-
-
-Here are some examples of existing multi-tenant applications and descriptions of their implementations.
-
-## Slack
-
-### Authentication:
-
-* Slack implements a login screen that asks for an email.
-* The email is then mapped to a Slack account:  `https://{account}.slack.com`.
-* Slack likely maintains a mapping table between email (or email domain) and the Slack subdomain. Notice that in the example, when entering `matias@auth0.com`, the user is redirected to `https://auth0.slack.com`.
-* Slack only supports email/password authentication. Asking for an email first is a good approach for an enterprise SSO. Each organization will have a configured identity provider (SAML, ADFS, etc.). Slack will redirect to this provider once the user has entered their email, instead of asking them for credentials.
-
-![](/media/articles/saas/saas-01.png)
-
-### Authorization:
-
-* With Slack, a user can belong to multiple teams or organizations. Each team can be considered a __tenant__.
-* You can switch from one team to another through an option in Slack.
-* Users can have either __full__ or __single-channel__ access within a team.
-* A user can have __full access__ on one team but only __single-channel access__ on another.
-
-![](/media/articles/saas/saas-02.png)
-
-### Modeling in Auth0
-
-The `User Profile` below captures the intent of the requirements described above:
-
-```json
-{
-  "email": "matias@auth0.com",
-  "app_metadata": {
-    "permissions": {
-      "auth0": {
-        "role": "admin",
-        "channels": ["*"]
-      },
-      "another-company": {
-        "role": "single-channel",
-        "channels": [ "some-channel" ]
-      }
-    }
-  }
-}
-```
-
-## Dropbox
-
-### Authentication:
-
-* Dropbox asks for an email. If there is an organization with a domain that matches the email suffix, Dropbox will hide the password textbox and display a __Single Sign On Enabled__ message on the login screen.
-* When the user clicks on __Continue__, they will be redirected to the configured identity provider.
-* If there is no SSO configured for that domain, the user will enter their password.
-
-![](/media/articles/saas/saas-03.png)
-
-### Authorization:
-
-* Once a user is authenticated, they are granted access to the files they own and those that were shared with them.
-* Users are granted access to their personal account and to any organizations they belong to.
-
-![](/media/articles/saas/saas-04.png)
-
-### Modeling in Auth0
-
-```json
-{
-  "email": "foo@bar.com",
-  "app_metadata": {
-    "permissions": {
-      "personal": {
-        "role": "full",
-      },
-      "company1": {
-        "role": "user",
-      },
-      "company2": {
-        "role": "admin",
-      }
-    }
-  }
-}
-```
-
-Storing all of the folders that the user has access to as part of the user profile would be unwieldy. The user object would get very large if the user has many folders. A more manageable approach is to store information at the company level role. All other ACLs are handled at the application or database level.
-
-## Auth0
-
-### Authentication:
-
-* Auth0 has a single [Dashboard](${manage_url}) for all tenants.
-* Auth0 supports Google, GitHub, Live and user/password authentication.
-* Auth0 also supports Enterprise connections for Platinum level subscriptions. You can request this by opening a [support ticket](${env.DOMAIN_URL_SUPPORT}).
-* Auth0 uses email domains for home realm discovery (see screen below), making it similar to the Dropbox experience.
-
-![](/media/articles/saas/saas-05.png)
-
-### Authorization:
-
-* A user can belong to multiple tenants and have different permissions on each (__user foo__ can be an __admin__ on __tenant bar__ and a __regular user__ of __tenant xyz__).
-* This is implemented by assigning a `user_id` property to an **account-level** entity if the user has access to everything or an **app-level** entity if the user has only app level permission.
-
-![](/media/articles/saas/saas-06.png)
-
-### Modeling in Auth0
-
-```json
-{
-  "email": "foo@bar.com",
-  "app_metadata": {
-    "permissions": {
-      "company1": {
-        "role": "full",
-        "clients": [ "*" ]
-      },
-      "company2": {
-        "role": "app-owner",
-        "clients": [ "iaeonoemaoiy2ie029je" ]
-      }
-    }
-  }
-}
-```
-
-## How to use Auth0 with a multi-tenant app
-
-A typical modern SaaS multi-tenant app has these features:
-
-* Allows users to signup with a custom __username/password__, especially during trial periods.
-* Allows users to login with their existing __Google__, __LinkedIn__ or __Yahoo!__ credentials.
-* Small businesses with employee directories based on __Office365__ or __Google Apps__ prefer to login using these credentials.
-* Larger companies often have identity systems for employees. Many companies rely on __Active Directory__ or __LDAP__ while some have deployed systems for identity federation based on __ADFS__, __PingFederate__, __Okta__, __OneLogin__, __CA Siteminder__, or even a custom __SAML-P provider__.
-* The app is often a web app built as a __Single Page App__ (SPA) using __AngularJS__ with a backend API built with __nodejs__. A mobile app for __Android__ and __iOS__ with a subset of the web app functionality may also be available.
-
-### One database connection or many
-
-A single database connection is often sufficient. Whether or not a user has access to a certain tenant can be handled with [metadata](/api/v1#!#put--api-users--user_id--metadata) instead of separate database connections.
-
-If you need to isolate a set of users (e.g. staging vs. prod environment), it may make sense to use different database connections. Even then, it would be better to create different accounts in Auth0.
-
-You may require a separate database connection if, for example,  **tenant-A** uses the built-in Auth0 user store but **tenant-B** has a set of users elsewhere that you want to authenticate. In this case, you could create a [custom db connection](/connections/database/mysql) for **tenant-B** and reference that association in your application.
-
-### A single Auth0 account for all tenants
-
-One account for all tenants is simpler and allows you to manage them in one place.
-
-Only if you want to share access to the dashboard with tenants would a separate Auth0 account per tenant be required. But to do so would require you to leverage the restricted API to create each new account. However, you can use the regular API to add applications and connections.
-
-**NOTE:** You can find a sample multi-tenant app where each tenant has its own Auth0 account on [Github](https://github.com/auth0/auth0-multitenant-spa-api-sample).
-
-### Different roles for each tenant
-
-You can use [metadata](/api/v1#!#put--api-users--user_id--metadata) to handle roles per tenant, as mentioned above.
-
-Metadata in Auth0's user profile is a generic way of associating information to any authenticated user. __Permissions__, __Groups__, and __Roles__ are all special cases of these attributes.
-
-Here is an example that would model a simplified chat system like Slack:
-
-```json
-{
-  "email": "matias@auth0.com",
-  "app_metadata": {
-    "permissions": {
-      "auth0": {
-        "role": "admin",
-        "channels": ["*"]
-      },
-      "another-company": {
-        "role": "single-channel",
-        "channels": [ "some-channel" ]
-      }
-    }
-  }
-}
-```
-
diff --git a/articles/tutorials/using-ionic-and-firebase.md b/articles/tutorials/using-ionic-and-firebase.md
deleted file mode 100644
index 3ff701e230..0000000000
--- a/articles/tutorials/using-ionic-and-firebase.md
+++ /dev/null
@@ -1,314 +0,0 @@
----
-description: A tutorial for using Ionic Framework and Firebase.
----
-
-## Ionic Framework + Firebase Tutorial
-
-You can either download the sample project, or follow the instructions below.
-
-<%= include('../_includes/_package', {
-  org: 'auth0-samples',
-  repo: 'auth0-ionic-firebase',
-  path: ''
-}) %>
-
-### 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 values:
        
-
-
        https://${account.namespace}/mobile, file://*, http://localhost:8100
-
        
-
-
        
-
-### 2. Configure Auth0 to work with Firebase
-
-You need to add your Firebase account information to Auth0. Once the user logs in to the App, Auth0 will use this information to issue a Firebase authentication token.
-
-Go to [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) and click on Addons. In there, turn on the __Firebase Addon__.
-
-Under **Settings**, use the **Use SDK v3+ tokens** slider to select the SDK version you are using.
-
-**SDK Version 2:**
-If you are using an older version, you will only need to enter your **Firebase Secret** which you can get from your Firebase dashboard under **Project Settings** then **Service Accounts** then **Database Secrets**.
-
-![Firebase Secret](/media/articles/tutorials/firebase-secret-sdkv2.png)
-
-**SDK Version 3+:**
-For SDKv3 and later, you will need the **Private Key** and **Client Email**. The **Private Key Id** and **Token Expiration** fields are optional.
-
-In your Firebase dashboard, go to **Project Settings** and select the **Service Accounts** tab. Then under Firebase Admin SDK, scroll down and click on **GENERATE NEW PRIVATE KEY**.
-
-![Generate a Firebase Key](/media/articles/tutorials/firebase-generate-key.png)
-
-This will generate a JSON file which will contain the `private_key_id`, `private_key` and `client_email` fields to be entered into the Addon Settings on the Auth0 dashboard. Click **SAVE** when you are finished.
-
-![Enter Fields](/media/articles/tutorials/enter-firebase-settings.png)
-
-### 3. Adding the needed dependencies
-
-Add the following dependencies to the `bower.json` and run `bower install`:
-
-```json
-"dependencies" : {
-  "auth0-angular": "4.*",
-  "a0-angular-storage": ">= 0.0.6",
-  "angular-jwt": ">= 0.0.4",
-  "angularfire": "~0.9.2"
-},
-```
-
-### 4. Add the references to the scripts in the `login.html`
-
-```html
-
-
-
-
-
-
-
-
-
-
-
-```
-
-### 5. Add `InAppBrowser` plugin
-
-You must install the `InAppBrowser` plugin from Cordova to be able to show the Login popup. Run the following command:
-
-```bash
-ionic plugin add org.apache.cordova.inappbrowser
-```
-
-Add the following configuration to the `config.xml` file:
-
-```xml
-
-  
-  
-
-```
-
-### 6. Add the module dependency and configure the service
-
-Add the `auth0`, `angular-storage`, `angular-jwt` and `firebase` module dependencies to your angular app definition and configure `auth0` by calling the `init` method of the `authProvider`
-
-```js
-// app.js
-angular.module('starter', ['ionic',
-  'starter.controllers',
-  'starter.services',
-  'auth0',
-  'angular-storage',
-  'angular-jwt',
-  'firebase'])
-.config(function($stateProvider, $urlRouterProvider, authProvider, $httpProvider,
-  jwtInterceptorProvider) {
-
-
-  $stateProvider
-  // This is the state where you'll show the login
-  .state('login', {
-    url: '/login',
-    templateUrl: 'templates/login.html',
-    controller: 'LoginCtrl',
-  })
-  // Your app states
-  .state('dashboard', {
-    url: '/dashboard',
-    templateUrl: 'templates/dashboard.html',
-    data: {
-      // This tells Auth0 that this state requires the user to be logged in.
-      // If a user isn't logged in and tries to access this state
-      // they will be redirected to the login page
-      requiresLogin: true
-    }
-  })
-
-  ...
-
-  authProvider.init({
-    domain: '<%= account.namespace %>',
-    clientID: '<%= account.clientId %>',
-    loginState: 'login'
-  });
-
-  ...
-
-})
-.run(function(auth) {
-  // This hooks all auth events to check everything as soon as the app starts
-  auth.hookEvents();
-});
-```
-
-
-### 7. Implementing login
-
-Now you're ready to implement the Login. You can inject the `auth` service in any controller and just call `signin` method to show the Login / SignUp popup.
-In this case, add the call in the `login` method of the `LoginCtrl` controller.
-After a successful login, you will:
-
-1. Save the __user profile__.
-2. Save the __token__ and __[refresh token](/refresh-token)__
-3. Call Auth0 to issue a __Firebase token__ and save it as well.
-
-> All these artifacts are persisted into `localStorage` in the browser. The Firebase token is obtained through Auth0's [Delegation endpoint](/api/authentication#delegation).
-
-```js
-// LoginCtrl.js
-function LoginCtrl(store, $scope, $location, auth) {
-  $scope.login = function() {
-    auth.signin({
-      authParams: {
-        scope: 'openid offline_access',
-        device: 'Mobile device'
-      }
-    }, function(profile, token, accessToken, state, refreshToken) {
-      store.set('profile', profile);
-      store.set('token', idToken);
-      store.set('refreshToken', refreshToken);
-      auth.getToken({
-        api: 'firebase'
-      }).then(function(delegation) {
-        store.set('firebaseToken', delegation.id_token);
-        $state.go('dashboard');
-      }, function(error) {
-        // Error getting the firebase token
-      })
-    }, function() {
-      // Error callback
-    });
-  }
-}
-```
-
-```html
-
-
-
-
-```
-
-> Note: there are multiple ways of implementing login. The example above uses the __Auth0 Lock__ a component that implements a ready to use login UI. You can build your own UI changing the `
+```
+
+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/index.md b/articles/user-profile/index.md
deleted file mode 100644
index d7759d3d44..0000000000
--- a/articles/user-profile/index.md
+++ /dev/null
@@ -1,125 +0,0 @@
----
-description: Explains the basics of a User profile, how to create a user and view users and their profile details.
-url: /user-profile
-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. Please see [Structure of the User Profile](/user-profile/user-profile-structure) for more information about the attributes available on the User Profile.
-
-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.
-
-For more information about User Profiles, please see [User Profile: In-Depth Details](/user-profile/user-profile-details).
-
-## Manage User Profiles in the Management Dashboard
-
-Use the Auth0 Management Dashboard ("Dashboard") to manage User Profiles.
-
-Within the Dashboard, you can create, view, modify, or delete users. These options are available via the [Users](${manage_url}/#/users) page.
-
-**Note:** User Management is included as part of the **Developer** subscription plan. You may need to [upgrade your plan](${manage_url}/#/account/billing/subscription) to access these features.
-
-![User Profile Dashboard](/media/articles/user-profile/user-profile-dashboard.png)
-
-### Create a New 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 account. The connection you use must be associated with a Client.
-
-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).
-
-### 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 information available via the `app_metadata` and `user_metadata` attributes. Click the "Edit" button in this section to edit the user's `user_metadata` attributes. Note that all `app_metadata` attributes are read-only.
-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
-
-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/signin-as-user-01.png)
-
-> Can't see the button? The following conditions are required for the button display:
-> - The applications registered in the account 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/signin-as-user-02.png)
-
-::: panel-info 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 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.
-:::
-
-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/block-user.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/unblock-user.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/delete-user.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.
diff --git a/articles/user-profile/normalized.md b/articles/user-profile/normalized.md
deleted file mode 100644
index 4d517f037c..0000000000
--- a/articles/user-profile/normalized.md
+++ /dev/null
@@ -1,173 +0,0 @@
----
-description: Auth0 normalizes common user properties in the User Profile.
----
-
-# Auth0 Normalized User Profile
-
-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`.
-
-## 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. 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.
-
-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.
-
-### 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 (e.g. `{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.
-
-## 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
-
-You can retrieve the user profile using [Lock](/libraries/lock/v10/api#getuserinfo-), [Auth0.js](/libraries/auth0js#user-management), or our [Authentication API /userinfo endpoint](/api/authentication#get-user-info).
-
-We also have a _User Profile_ section on most of our [quickstarts](/quickstarts). Some of the most popular technologies we offer quickstarts and samples for are:
-- [Android](/quickstart/native/android/04-user-profile)
-- [Angular 1.x](/quickstart/spa/angularjs/04-user-profile) and [Angular 2](/quickstart/spa/angular2/04-user-profile)
-- [React](/quickstart/spa/react/04-user-profile)
-- [Node.js](/quickstart/webapp/nodejs/04-user-profile)
-- [ASP .NET Core](/quickstart/webapp/aspnet-core/05-user-profile)
-- [jQuery](/quickstart/spa/jquery/04-user-profile)
-- and [many more](/quickstarts)
diff --git a/articles/user-profile/progressive-profiling.md b/articles/user-profile/progressive-profiling.md
deleted file mode 100644
index 64dfcbb2ee..0000000000
--- a/articles/user-profile/progressive-profiling.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-description: This page details how to implement progressive profiling with Auth0.
----
-
-# Progressive Profiling
-
-Rather than asking your users to fill out extensive registration forms, you can use **progressive profiling**, a technique to collect user information as users interact with your system.
-
-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.
-
-> 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.
-
-## Implementing Progressive Profiling with Auth0
-
-You can very easily implement **progressive profiling** with Auth0. Every user that authenticates through Auth0 gets User Profile, and its contents can come from three different sources:
-
-* Properties supplied by the identity provider properties (e.g. any user property coming from LinkedIn, Facebook, or any [connection](/identityproviders));
-* Attributes that are dynamically created in [Auth0 Rules](/rules), e.g. calling APIs like [FullContact](https://www.fullcontact.com/) or [Clearbit](https://clearbit.com/);
-* Application-specific attributes that developers can collect on their apps. Auth0 calls this `metadata` for users.
-
-![](/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).
-
-> 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.
-
-> Auth0 provides two metadata attributes: `user_metadata` and `app_metadata`. You may update the contents of `user_metadata` with the user token obtained after authentication, but you will need a server-side APIv1 token to modify the contents of `app_metadata`.
-
-This feature makes it very easy to control what information gets collected and when, and then through the [Users API](/api/v2#!/Users/patch_users_by_id), enriches the user profile with all that data:
-
-![](/media/articles/user-profile/progressive-profiling-example.png)
-
-In the example above, we collect `last_name` and `first_name` on signup. We then collect, on a later interaction, the user's `title` and `company`. Finally, in the context of an article that might interest the user, we add a `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 b0f3cc6b5e..0000000000
--- a/articles/user-profile/user-data-storage.md
+++ /dev/null
@@ -1,294 +0,0 @@
----
-title: User Data Storage Guidance
-description: Demonstrating 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 a Client's users. This document covers best practices on how to store your data securely and efficiently. Additionally, this document uses a sample Client (a mobile music application) that reflects the end-to-end user experience of using Auth0 with an external database to illustrate specific topics.
-
-:::panel-info Example: Mobile Music Application
-The sample Client 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). See the [Mobile + API architecture scenario](/architecture-scenarios/application/mobile-api) for a visualization of the Client's overall structure.
-:::
-
-## 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 Client 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.
-
-#### 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 client. 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://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\": {\"displayName\": \"J-vald3z\"}"
-  },
-  "headersSize": -1,
-  "bodySize": -1,
-  "comment": ""
-}
-'''
-
-## Why shouldn't I put all my Client'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 Client'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 Client.
-
-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.
-
->[Learn about token-based authentication and how to implement JWT in your Clients.](/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 Client. 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()
-    }
-```
-
-> 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 Client, 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 Client:
-
-```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 02720d1b20..0000000000
--- a/articles/user-profile/user-impersonation.md
+++ /dev/null
@@ -1,161 +0,0 @@
----
-description: This page explains how to impersonate a user, often used for testing and troubleshooting purposes.
----
-
-# User Impersonation
-
-::: panel-warning Advanced Feature
-Impersonation functionality may be disabled by default for your tenant, but can be enabled by [contacting support](${env.DOMAIN_URL_SUPPORT}).
-:::
-
-Often administrators need to impersonate other users for testing or troubleshooting purposes. Using impersonation the administrators can login to an app as a specific user, see everything exactly as that user sees it, and do everything exactly as that user does it.
-
-Auth0 provides a _Sign in As_ feature for user impersonation, and provides the following:
-- 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.
-
-## Impersonate a User using the Management Dashboard
-
-Navigate to the [Users](${manage_url}/#/users) page in the Management Dashboard and select the user you want to login as. Click on the _Sign in as User_ and select the app you want to log into using the dropdown menu.
-
-![](/media/articles/user-profile/signin-as-user-01.png)
-
-> Can't see the button? Check the following conditions; they should apply for the button to be displayed:
-> - The applications registered in the account 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).
-
-![](/media/articles/user-profile/signin-as-user-02.png)
-
-> Impersonating a user using the Management Dashboard will not return a [JWT](/jwt) to your application by default. You can achieve this by calling the [impersonation endpoint](/api/authentication/reference#impersonation) manually and adding `additionalParameters.scope: "openid"` to the request body.
-
-## Impersonate a User using 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.
-
-## Implement impersonation in your app
-
-Let's assume that you have two apps, `app1` and `app2`, and you want to impersonate the users of `app2`.
-
-Your first step would be to generate a _Bearer_ token to be used with [Impersonation API](/api/authentication/reference#impersonation). You can generate it with the [Authentication API](/api/authentication) `/oauth/token` endpoint using your _Global Client ID_ and _Global Client Secret_. The token will be valid for 24 hours, so you should ask for a token everytime you make a request to the API or handle vigorously `401` responses.
-
-```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\": \"${account.clientSecret}\",\"grant_type\": \"client_credentials\"}"
-  }
-}
-```
-
-> Management APIv2 calls are made with tokens issued by your _Global Client ID_, which is a unique identifier for your Auth0 account. You can retrieve your _Global Client ID_ and _Global Client Secret_ in the [Management APIv2 documentation page](/api/management/v2) (click on API Key/Secret). They are also available at the _Advanced_ section under _Account Settings_ in the Auth0 [Management Dashboard](${manage_url}/#/account/advanced).
-
-Afterwards, you would have to find out the user id of the user that you want to impersonate. That would be the 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 {bearer-token}" }
-  ]
-}
-```
-
-The `{bearer_token}` should be replaced with an Auth0 Management APIv2 token. Details on how to do this can be found [here](/api/management/v2/tokens).
-
-> You can also retrieve the `user_id` information from the Management 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.
-
-You are now ready to call the [Impersonation API](/api/authentication/reference#impersonation). The request should include an `Authorization` header with `Bearer bearer-token`, where `bearer-token` is the token you retrieved at the first step. 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. (e.g. 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](http://en.wikipedia.org/wiki/Cross-site_request_forgery).
-
-The `callback_url` must match what is defined in your [settings](${manage_url}/#/settings) page.
-
-There are various possible values 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](/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` (For example: `scope: 'openid name email picture'`).
-You can get more information about this in the [Scopes documentation](/scopes).
-
-```har
-{
-  "method": "POST",
-  "url": "https://${account.namespace}/users/{user_id}/impersonate",
-  "headers": [
-    { "name": "Content-Type", "value": "application/json" },
-    { "name": "Authorization", "value": "Bearer {bearer-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:
-- The `{user_id}` should be replaced with the `user_id` you retrieved at the second step (the user to impersonate).
-- The `{bearer_token}` should be replaced with the token already retrieved at the first step.
-- The `{protocol-to-use}` should be replaced with the protocol to use against the identity provider, for example `oauth2`.
-- The `{impersonator-id}` should be replaced with the `user_id` of the impersonator.
-
-Upon successful authentication, a URL will be returned as response that will look like the following:
-
-    ${account.callback}/?code=AUTHORIZATION_CODE&state=STATE_VALUE
-
-`${account.callback}` is the URL you specified as `callback_url` (and configured in your [settings](${manage_url}/#/settings) page), `state` should match the `state` value you sent with your request and `code` is the authorization code you need.
-
-> 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-implicit-flow).
-
-Now you should exchange the `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. You will need to send the `code` obtained before along with your `clientId` and `clientSecret`.
-
-```har
-{
-  "method": "POST",
-  "url": "https://${account.namespace}/users/oauth/token",
-  "headers": [
-    { "name": "Content-Type", "value": "application/json" }
-  ],
-  "postData": {
-    "mimeType": "application/json",
-    "text": "{\"client_id\": \"${account.clientId}\",\"client_secret\": \"${account.clientSecret}\",\"code\": \"{AUTHORIZATION_CODE}\",\"grant_type\": \"authorization_code\",\"callback_url\": \"{CALLBACK_URL}\"}"
-  }
-}
-```
-
-Replace the `{AUTHORIZATION_CODE}` with the `code` you received previously. Also, replace `{CALLBACK_URL}` 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.
-
-
-##### Sample Access Token Response:
-
-  {
-       "access_token": ".....Access Token.....",
-       "token_type": "bearer",
-       "id_token": "......The JWT......"
-  }
-
-Congratulations, you are done!
-
-## Further reading
-- [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-profile-details.md b/articles/user-profile/user-profile-details.md
deleted file mode 100644
index bf83d8455a..0000000000
--- a/articles/user-profile/user-profile-details.md
+++ /dev/null
@@ -1,210 +0,0 @@
----
-description: This page details Auth0 User Profiles, such as sources of profile data, normalized user profiles, caching, profile structure and custom profiles.
----
-
-# 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](#sources-of-user-profile-data)
-- [Normalized User Profile](#normalized-user-profile)
-- [Caching of the User Profile in Auth0](#caching-of-the-user-profile-in-auth0)
-- [Structure of User Profile Data](#structure-of-user-profile-data)
-- [Storing Custom Profile Data](#storing-custom-profile-data)
-- [Application Access to User Profile](#application-access-to-user-profile)
-- [Management API Access to User Profiles](#management-api-access-to-user-profiles)
-- [User Profile vs Tokens](#user-profile-vs-tokens)
-- [Modification of User Profiles](#modification-of-user-profiles)
-- [Mapping User Profile Attributes in AD/LDAP Connector](#mapping-user-profile-attributes-in-ad-ldap-connector)
-- [Mapping User Profile Attributes in SAML Assertions](#mapping-user-profile-attributes-in-saml-assertions)
-- [User Profile with Account Linking](#user-profile-with-account-linking)
-- [User Data Storage Guidance](/user-profile/user-data-storage)
-
-## 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 client 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-info 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.
-:::
-
-::: panel-danger Usage of Metadata
-Please note that an authenticated user can modify data in their profile's `user_metadata`, but they can't modify anything in their `app_metadata`.
-:::
-
-
-> 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 (e.g. Facebook, Twitter, Google, SAML, your own provider, etc.). 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 a client 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 client 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 client applications integrated with Auth0. This "SAVE" will not alter information in the core user profile which is provided by the Connection.
-
-### Management API
-
-The Auth0 Management API provides access to read, update, and delete User Profiles stored in the Auth0 database.
-
-> 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.
-
-> 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 a client 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 client 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.
-
-`Apps/APIs -> {name of app} - Addons -> SAML2 Web App -> Settings`
-
-## User Profile with Account Linking
-
-Users may log into an application initially via one Connection (e.g. a database). They may then log in via another Connection (e.g. 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 a3e9ddf4da..0000000000
--- a/articles/user-profile/user-profile-structure.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-description: This page lists the attributes that are available on the User Profile.
----
-
-# Structure of the User Profile
-
-The following attributes are available on the [User Profile](/user-profile):
-
-* `app_metadata`: the custom fields storing information about a user. These attributes contain information that influences the user's access;
-
-* `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`: the user's email address
-
-* `email_verified`: the `yes/no` 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 (e.g. Facebook, Twitter, etc.);
-    * `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;
-
-* `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;
-
-* `updated_at`: the timestamp of when the user's profile was last updated/modified;
-
-* `user_id`: 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 (e.g. work and home addresses);
-
-* `username`: the user's username.
-
-**Note**: Fields indicated with an asterisk (*) are not returned as part of `user_profile/id_token` nor are they included in any response from the `/userinfo` endpoint.
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/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
new file mode 100644
index 0000000000..2b8b93b77d
--- /dev/null
+++ b/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/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/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/index.yml b/articles/users/search/index.yml
new file mode 100644
index 0000000000..1a8c5c46c4
--- /dev/null
+++ b/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/articles/users/search/v2/index.md b/articles/users/search/v2/index.md
new file mode 100644
index 0000000000..df2b8516b9
--- /dev/null
+++ b/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/articles/users/search/v2/query-syntax.md b/articles/users/search/v2/query-syntax.md
new file mode 100644
index 0000000000..69e99dbdf0
--- /dev/null
+++ b/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/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
new file mode 100644
index 0000000000..fe39072f3a
--- /dev/null
+++ b/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/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
new file mode 100644
index 0000000000..ce0d124d4b
--- /dev/null
+++ b/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/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/_video.md b/articles/videos/_video.md
deleted file mode 100644
index 3d65e25515..0000000000
--- a/articles/videos/_video.md
+++ /dev/null
@@ -1,5 +0,0 @@
-
-
diff --git a/articles/videos/_video_inline.md b/articles/videos/_video_inline.md
deleted file mode 100644
index fda5ab0931..0000000000
--- a/articles/videos/_video_inline.md
+++ /dev/null
@@ -1,18 +0,0 @@
-
-
-
        
-  
        Video Content
        
-  <% var article = _.find(cache.get('videos'), { hash: hash }); %>
-  
        
-    
        
-      
        
-         
-        
-      
        
-      
        
-        
        ${article.short_title}
        
-        
        ${article.description}
        
-      
        
-    
        
-  
        
-
        
diff --git a/articles/videos/developer-overview.md b/articles/videos/developer-overview.md
deleted file mode 100644
index 294c0634d9..0000000000
--- a/articles/videos/developer-overview.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: Auth0 Developer Overview Video
-short_title: Developer Overview
-order: 1
-id: s15ysw45uy
-asset_id: 25fa8c921cfed649925ebd725c41dc7b0ec64d4f
-description: This video will show you how easy it is to add Auth0 to your application. You will also see how to customize Auth0 to meet the exact needs of your solution.
----
-# Developer Overview
-
-<%= include('./_video', { id: meta.id }) %>
-
-In this video you will see how Auth0 can help you quickly add identity to your application. You will learn about how to handle various types of authentication, how to customize the login experience, and how Auth0 can be extended to meet the exact needs of your application.
-
-
        
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
index 87858766ff..7d5ef5c972 100644
--- a/articles/videos/index.md
+++ b/articles/videos/index.md
@@ -1,25 +1,32 @@
 ---
-url: /videos
-title: Auth0 Developer Videos
-description: A selection of videos showing developers how to perform common tasks with Auth0.
+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
 
-# Developer Videos
-Below you will find a selection of videos that will introduce you to various topics in the Auth0 platform.
+[Learn about digital identity](/videos/learn-identity) including OAuth2, OpenID Connect, calling APIs, and more! In this video series, we cover:
 
-
        
-<% cache.find('articles/videos', {sort: 'order'}).forEach(article => { %>
-  <% if (article.id) { %>
-  
        
-    
        
-        
-    
        
-    
        
-    
        ${article.short_title}
        
-      
        ${article.description}
        
-    
        
-  
        
-  <% } %>
-<% }); %>
-
        
+* 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/articles/videos/rules.md b/articles/videos/rules.md
deleted file mode 100644
index cfeb98bb58..0000000000
--- a/articles/videos/rules.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: Auth0 Rules Video
-short_title: Rules
-order: 2
-id: g7dy1fpwc3
-asset_id: 27664359f517abb19f8f08b97b363232da66c072
-description: This video will show you to use Rules to customize and extend the Auth0 platform customize user profile, add authorization, and integrate with external services all with a few lines of JavaScript.
----
-# Using Rules
-
-<%= include('./_video', { id: meta.id }) %>
-
-In this video you will learn all about using rules in your application. 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.
-
-
        
diff --git a/articles/videos/session-and-cookies.md b/articles/videos/session-and-cookies.md
deleted file mode 100644
index 4199912e2e..0000000000
--- a/articles/videos/session-and-cookies.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: Auth0 Understanding Sessions & Cookies Video
-short_title: Sessions & Cookies
-order: 3
-id: paxlbixuya
-asset_id: 8713e22d392cbad7798b01a8fec40761450c4d32
-description: This video will help you better understand how Auth0 works with sessions and cookies in a traditional web application.
----
-# Understanding Sessions & Cookies
-
-<%= include('./_video', { id: meta.id }) %>
-
-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.
-
-
        
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 5df8b39d7e..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: client-platforms
+    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
diff --git a/config/cards.yml b/config/cards.yml
index db0843643f..2815aab1aa 100644
--- a/config/cards.yml
+++ b/config/cards.yml
@@ -5,158 +5,113 @@
 ## ------------------------------------------------------------
 
 - id: "getting-started"
-  title: "Getting Started"
-  icon: "icon-budicon-499"
-  color: "orange"
-  description: "Learn the basics of using Auth0."
-  url: "/topics/getting-started"
+  title: "Get Started"
+  icon: "IdenticonGettingStarted"
+  description: "Learn the basics"
+  url: "/get-started"
   articles:
 
-    - title: "Overview"
-      url: "/overview"
-
-    - title: Developer Videos
-      url: /videos
-
-    - title: Architecture Scenarios
-      url: /architecture-scenarios
-
-- 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"
-
-    - title: "Lock for iOS"
-      url: "/libraries/lock-ios"
-
-    - title: "Lock for Android"
-      url: "/libraries/lock-android"
-
-- id: "identity-glossary"
-  title: "Identity Glossary"
-  icon: "icon-budicon-715"
-  color: "oil"
-  description: "Learn the protocols and terminologies for identity."
-  url: "/topics/identity-glossary"
-  articles:
-
-    - title: "Protocols"
-      url: "/protocols"
-
-    - title: "Tokens"
-      url: "/tokens"
-
-    - title: "JWT"
-      url: "/jwt"
-
-
-- 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: "API Auth"
-      url: "/api-auth"
-
-    - title: "Refresh Tokens"
-      url: "/refresh-token"
-
-    - title: "Importing and Migrating"
-      url: "/connections/database/migrating"
-
-- id: "apis"
-  title: "APIs"
-  icon: "icon-budicon-546"
-  color: "blue"
-  description: "Working directly with Auth0 APIs"
-  url: "/api/info"
+  
+    - title: "Universal Login"
+      url: "/authenticate/login/auth0-universal-login"
+
+    - title: "Identity Providers"
+      url: "/authenticate/identity-providers"
+      
+    - 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: "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: "Appliance Planning"
-      url: "/appliance/appliance-overview"
-
-    - title: Administrator's Manual
-      url: /appliance/admin
+    - title: "Universal Login Pages"
+      url: "/customize/login-pages"
 
-    - title: Onboarding Process
-      url: /onboarding/appliance-sprint
-
-- id: "extensibility"
-  title: "Extensibility"
-  icon: "icon-budicon-173"
-  color: "red"
-  description: "Adding to and customizing Auth0's standard feature set."
-  url: "/topics/extensibility"
-  articles:
-
-    - title: "Rules"
-      url: "/rules"
+    - title: "Actions"
+      url: "/customize/actions"
 
     - title: "Extensions"
-      url: "/extensions"
-
-    - title: "Webtasks"
-      url: "https://webtask.io/docs/101"
+      url: "/customize/extensions"
 
-
-- id: "identity-providers"
-  title: "Identity Providers"
-  icon: "icon-budicon-297"
-  color: "yellow"
-  description: "Integrating Auth0 with identity providers."
-  url: "/identityproviders"
+- id: "secure"
+  title: "Secure"
+  icon: "IdenticonSecurity"
+  description: "Compliance, privacy, and threats"
+  url: "/secure"
   articles:
 
-    - title: "Database Connections"
-      url: "/connections/database"
-
-    - title: "Social Connections"
-      url: "/identityproviders#social"
+    - title: "Attack Protection"
+      url: "/secure/attack-protection"
+      
+    - title: "Multi-factor Authentication"
+      url: "/secure/multi-factor-authentication"
 
-    - title: "Passwordless"
-      url: "/connections/passwordless"
+    - title: "Data Privacy"
+      url: "/secure/data-privacy-and-compliance"
 
-- id: "enterprise-identity"
-  title: "Enterprise Identity"
-  icon: "icon-budicon-606"
-  color: "oil"
-  description: "Integrating and integrating enterprise identity solutions."
-  url: "/identityproviders#enterprise"
+- id: "deploy-and-monitor"
+  title: "Deploy and Monitor"
+  icon: "IdenticonMonitoring"
+  description: "Deployment models and logs"
+  url: "/deploy-monitor"
   articles:
 
-    - title: "Active Directory"
-      url: "/connections/enterprise/active-directory"
+    - title: "Deployment Options"
+      url: "/deploy-monitor/deployment-options"
+      
+    - title: "Check Auth0 Status"
+      url: "/deploy-monitor/monitor/check-auth0-status"
+
+    - title: "Logs"
+      url: "/deploy-monitor/logs" 
+      
+- id: "troubleshoot"
+  title: "Troubleshoot"
+  icon: "IdenticonTroubleshoot"
+  description: "Get help and troubleshoot"
+  url: "/troubleshoot"
+  articles:
 
-    - 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/redirect-urls.json b/config/redirect-urls.json
deleted file mode 100644
index 8b0367472d..0000000000
--- a/config/redirect-urls.json
+++ /dev/null
@@ -1,1171 +0,0 @@
-[
-  {
-    "from": "/ionic-tutorial",
-    "to": "/native-platforms/ionic"
-  },
-  {
-    "from": "/javaapi-tutorial",
-    "to": "/server-apis/java"
-  },
-  {
-    "from": "/laravelapi-tutorial",
-    "to": "/server-apis/php-laravel"
-  },
-  {
-    "from": "/nodeapi-tutorial",
-    "to": "/server-apis/nodejs"
-  },
-  {
-    "from": "/nodejs-tutorial",
-    "to": "/quickstart/webapp/nodejs"
-  },
-  {
-    "from": "/server-platforms/nodejs",
-    "to": "/quickstart/webapp/nodejs"
-  },
-  {
-    "from": "/client-platforms/react",
-    "to": "/quickstart/spa/react"
-  },
-  {
-    "from": "/server-platforms/golang",
-    "to": "/quickstart/webapp/golang"
-  },
-  {
-    "from": "/phpapi-tutorial",
-    "to": "/server-apis/php"
-  },
-  {
-    "from": "/pythonapi-tutorial",
-    "to": "/server-apis/python"
-  },
-  {
-    "from": "/rubyapi-tutorial",
-    "to": "/server-apis/rails"
-  },
-  {
-    "from": "/awsapi-tutorial",
-    "to": "/server-apis/aws"
-  },
-  {
-    "from": "/wams",
-    "to": "/server-apis/azure-mobile-services"
-  },
-  {
-    "from": "/firebaseapi-tutorial",
-    "to": "/server-apis/firebase"
-  },
-  {
-    "from": "/salesforcesandboxapi-tutorial",
-    "to": "/server-apis/salesforce-sandbox"
-  },
-  {
-    "from": "/salesforceapi-tutorial",
-    "to": "/server-apis/salesforce"
-  },
-  {
-    "from": "/sapapi-tutorial",
-    "to": "/server-apis/sap-odata"
-  },
-  {
-    "from": "/rails-tutorial",
-    "to": "/server-platforms/rails"
-  },
-  {
-    "from": "/python-tutorial",
-    "to": "/server-platforms/python"
-  },
-  {
-    "from": "/php-tutorial",
-    "to": "/quickstart/webapp/php"
-  },
-  {
-    "from": "/server-platforms/php",
-    "to": "/quickstart/webapp/php"
-  },
-  {
-    "from": "/server-apis/ruby",
-    "to": "/quickstart/backend/ruby"
-  },
-  {
-    "from": "/java-tutorial",
-    "to": "/server-platforms/java"
-  },
-  {
-    "from": "/phonegap-tutorial",
-    "to": "/native-platforms/phonegap"
-  },
-  {
-    "from": "/widget",
-    "to": "/login-widget2"
-  },
-  {
-    "from": "/scenarios-keenio",
-    "to": "/scenarios/keenio"
-  },
-  {
-    "from": "/scenarios-mixpanel-fullcontact-salesforce",
-    "to": "/scenarios/mixpanel-fullcontact-salesforce"
-  },
-  {
-    "from": "/scenarios-mqtt",
-    "to": "/scenarios/mqtt"
-  },
-  {
-    "from": "/scenarios-parse",
-    "to": "/scenarios/parse"
-  },
-  {
-    "from": "/scenarios-rapleaf-salesforce",
-    "to": "/scenarios/rapleaf-salesforce"
-  },
-  {
-    "from": "/scenarios-segmentio",
-    "to": "/scenarios/segmentio"
-  },
-  {
-    "from": "/scenarios-splunk",
-    "to": "/scenarios/splunk"
-  },
-  {
-    "from": "/scenarios-tessel",
-    "to": "/scenarios/tessel"
-  },
-  {
-    "from": "/scenarios-unbounce",
-    "to": "/scenarios/unbounce"
-  },
-  {
-    "from": "/updating-appliance",
-    "to": "/appliance/update"
-  },
-  {
-    "from": "/adldap-auth",
-    "to": "/connector/install"
-  },
-  {
-    "from": "/adldap-x",
-    "to": "/connector/install-other-platforms"
-  },
-  {
-    "from": "/aspnet-tutorial",
-    "to": "/server-platforms/aspnet"
-  },
-  {
-    "from": "/aspnet-owin-tutorial",
-    "to": "/server-platforms/aspnet-owin"
-  },
-  {
-    "from": "/servicestack-tutorial",
-    "to": "/server-platforms/servicestack"
-  },
-  {
-    "from": "/laravel-tutorial",
-    "to": "/server-platforms/laravel"
-  },
-  {
-    "from": "/symfony-tutorial",
-    "to": "/server-platforms/symfony"
-  },
-  {
-    "from": "/sharepoint-apps",
-    "to": "/integrations/sharepoint-apps"
-  },
-  {
-    "from": "/ad",
-    "to": "/connections/enterprise/active-directory"
-  },
-  {
-    "from": "/adfs",
-    "to": "/connections/enterprise/adfs"
-  },
-  {
-    "from": "/37signals-clientid",
-    "to": "/connections/social/37signals"
-  },
-  {
-    "from": "/amazon-clientid",
-    "to": "/connections/social/amazon"
-  },
-  {
-    "from": "/aol-clientid",
-    "to": "/connections/social/aol"
-  },
-  {
-    "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": "/o365-clientid",
-    "to": "/connections/enterprise/o365-deprecated"
-  },
-  {
-    "from": "/paypal-clientid",
-    "to": "/connections/social/paypal"
-  },
-  {
-    "from": "/planningcenter-clientid",
-    "to": "/connections/social/planning-center"
-  },
-  {
-    "from": "/salesforce-clientid",
-    "to": "/connections/social/salesforce"
-  },
-  {
-    "from": "/renren-clientid",
-    "to": "/connections/social/renren"
-  },
-  {
-    "from": "/sharepoint-clientid",
-    "to": "/connections/enterprise/sharepoint-online"
-  },
-  {
-    "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": "/checksum",
-    "to": "/appliance/checksum"
-  },
-  {
-    "from": "/android-tutorial",
-    "to": "/quickstart/native/android"
-  },
-  {
-    "from": "/native-platforms/android",
-    "to": "/quickstart/native/android"
-  },
-  {
-    "from": "/angular-tutorial",
-    "to": "/quickstart/spa/angularjs"
-  },
-  {
-    "from": "/client-platforms/angularjs",
-    "to": "/quickstart/spa/angularjs"
-  },
-  {
-    "from": "/client-platforms/angular2",
-    "to": "/quickstart/spa/angular2"
-  },
-  {
-    "from": "/aspnetwebapi-owin-tutorial",
-    "to": "/server-apis/webapi-owin"
-  },
-  {
-    "from": "/aspnetwebapi-tutorial",
-    "to": "/server-apis/aspnet-webapi"
-  },
-  {
-    "from": "/ember-tutorial",
-    "to": "/quickstart/spa/emberjs"
-  },
-  {
-    "from": "/client-platforms/emberjs",
-    "to": "/quickstart/spa/emberjs"
-  },
-  {
-    "from": "/ios-tutorial",
-    "to": "/quickstart/native/ios-objc"
-  },
-  {
-    "from": "/native-platforms/ios-objc",
-    "to": "/quickstart/native/ios-objc"
-  },
-  {
-    "from": "/java-tutorial",
-    "to": "/server-platforms/java"
-  },
-  {
-    "from": "/mvc3-tutorial",
-    "to": "/server-platforms/aspnet"
-  },
-  {
-    "from": "/mvc-tutorial-enterprise",
-    "to": "/tutorials/aspnet-mvc4-enterprise-providers"
-  },
-  {
-    "from": "/phonegap-plugin-tutorial",
-    "to": "/native-platforms/cordova"
-  },
-  {
-    "from": "/singlepageapp-tutorial",
-    "to": "/quickstart/spa/vanillajs"
-  },
-  {
-    "from": "/client-platforms/vanillajs",
-    "to": "/quickstart/spa/vanillajs"
-  },
-  {
-    "from": "/wcf-tutorial",
-    "to": "/server-apis/wcf-service"
-  },
-  {
-    "from": "/win8-cs-tutorial",
-    "to": "/native-platforms/windows-store-csharp"
-  },
-  {
-    "from": "/windowsstore-auth0-tutorial",
-    "to": "/native-platforms/windows-store-csharp"
-  },
-  {
-    "from": "/windowsstore-js-auth0-tutorial",
-    "to": "/native-platforms/windows-store-javascript"
-  },
-  {
-    "from": "/win8-tutorial",
-    "to": "/native-platforms/windows-store-javascript"
-  },
-  {
-    "from": "/windowsphone-tutorial",
-    "to": "/native-platforms/windowsphone"
-  },
-  {
-    "from": "/wpf-winforms-tutorial",
-    "to": "/native-platforms/wpf-winforms"
-  },
-  {
-    "from": "/xamarin-tutorial",
-    "to": "/native-platforms/xamarin"
-  },
-  {
-    "from": "/auth0js",
-    "to": "/libraries/auth0js"
-  },
-  {
-    "from": "/aws",
-    "to": "/integrations/aws"
-  },
-  {
-    "from": "/lock",
-    "to": "/libraries/lock"
-  },
-  {
-    "from": "/login-widget",
-    "to": "/libraries/login-widget"
-  },
-  {
-    "from": "/login-widget2",
-    "to": "/libraries/login-widget2"
-  },
-  {
-    "from": "/webapi",
-    "to": "/server-apis/aspnet-webapi"
-  },
-  {
-    "from": "/okta",
-    "to": "/protocols/saml/identity-providers/okta"
-  },
-  {
-    "from": "/onelogin",
-    "to": "/protocols/saml/identity-providers/onelogin"
-  },
-  {
-    "from": "/ping7",
-    "to": "/protocols/saml/identity-providers/ping7"
-  },
-  {
-    "from": "/passwordless",
-    "to": "/connections/passwordless"
-  },
-  {
-    "from": "/siteminder",
-    "to": "/protocols/saml/identity-providers/siteminder"
-  },
-  {
-    "from": "/ssocircle",
-    "to": "/protocols/saml/identity-providers/ssocircle"
-  },
-  {
-    "from": "/wsfedwebapp-tutorial",
-    "to": "/tutorials/wsfed-web-app"
-  },
-  {
-    "from": "/apiv2Changes",
-    "to": "/api/management/v2/changes"
-  },
-  {
-    "from": "/apiv2",
-    "to": "/api/management/v2"
-  },
-  {
-    "from": "/tokens/apiv2",
-    "to": "/api/management/v2/tokens"
-  },
-  {
-    "from": "/metadata-in-rules",
-    "to": "/rules/metadata-in-rules"
-  },
-  {
-    "from": "/metadata/rules",
-    "to": "/rules/metadata-in-rules"
-  },
-  {
-    "from": "/api-reference",
-    "to": "/api/management/v1/reference"
-  },
-  {
-    "from": "/api/v1",
-    "to": "/api/management/v1"
-  },
-  {
-    "from": "/api/v1/reference",
-    "to": "/api/management/v1/reference"
-  },
-  {
-    "from": "/api/v1/use-cases",
-    "to": "/api/management/v1/use-cases"
-  },
-  {
-    "from": "/api",
-    "to": "/api/info"
-  },
-  {
-    "from": "/api/v2",
-    "to": "/api/management/v2"
-  },
-  {
-    "from": "/api/v2/tokens",
-    "to": "/api/management/v2/tokens"
-  },
-  {
-    "from": "/api/v2/changes",
-    "to": "/api/management/v2/changes"
-  },
-  {
-    "from": "/auth-api",
-    "to": "/api/authentication"
-  },
-  {
-    "from": "/api/authentication/reference",
-    "to": "/api/authentication"
-  },
-  {
-    "from": "/oauth2",
-    "to": "/connections/social/oauth2"
-  },
-  {
-    "from": "/mysql-connection-tutorial",
-    "to": "/connections/database/mysql"
-  },
-  {
-    "from": "/migrating",
-    "to": "/connections/database/migrating"
-  },
-  {
-    "from": "/quickstart/native-mobile/windows8-cp/:client",
-    "to": "/quickstart/native-mobile/windows-store-csharp/:client"
-  },
-  {
-    "from": "/quickstart/native-mobile/windows8/:client",
-    "to": "/quickstart/native-mobile/windows-store-javascript/:client"
-  },
-  {
-    "from": "/quickstart/spa/angular/:client",
-    "to": "/quickstart/spa/angularjs/:client"
-  },
-  {
-    "from": "/quickstart/spa/javascript/:client",
-    "to": "/quickstart/spa/vanillajs/:client"
-  },
-  {
-    "from": "/quickstart/native-mobile/wpf-winforms/aspnetweb-api",
-    "to": "/quickstart/native-mobile/wpf-winforms/aspnet-webapi"
-  },
-  {
-    "from": "/quickstart/native-mobile/:platform/laravel-api",
-    "to": "/quickstart/native-mobile/:platform/php-laravel"
-  },
-  {
-    "from": "/quickstart/native-mobile/:platform/rails-api",
-    "to": "/quickstart/native-mobile/:platform/rails"
-  },
-  {
-    "from": "/quickstart/native-mobile/:platform/:api",
-    "to": "/quickstart/native-mobile/:platform"
-  },
-  {
-    "from": "/mfa",
-    "to": "/multifactor-authentication"
-  },
-  {
-    "from": "/multi-factor-authentication",
-    "to": "/multifactor-authentication"
-  },
-  {
-    "from": "/multi-factor-authentication/yubikey",
-    "to": "/multifactor-authentication/yubikey"
-  },
-  {
-    "from": "/quickstart",
-    "to": "/"
-  },
-  {
-    "from": "/link-accounts/user-initiated",
-    "to": "/link-accounts/user-initiated-linking"
-  },
-  {
-    "from": "/libraries/lock/using-refresh-tokens",
-    "to": "/libraries/lock/using-a-refresh-token"
-  },
-  {
-    "from": "/quickstart/native-mobile/:client/node-api",
-    "to": "/quickstart/native-mobile/:client/nodejs"
-  },
-  {
-    "from": "/quickstart/webapp/play-2-scala",
-    "to": "/quickstart/webapp/scala"
-  },
-  {
-    "from": "/quickstart/hybrid/:client/python-api",
-    "to": "/quickstart/hybrid/:client/python"
-  },
-  {
-    "from": "/quickstart/native-mobile/:client/ruby-api",
-    "to": "/quickstart/native-mobile/:client/ruby"
-  },
-  {
-    "from": "/quickstart/native-mobile/:client/aspnetweb-owin-api",
-    "to": "/quickstart/native-mobile/:client/webapi-owin"
-  },
-  {
-    "from": "/quickstart/:platform/reactnative-ios",
-    "to": "/quickstart/:platform/react-native-ios"
-  },
-  {
-    "from": "/quickstart/:platform/reactnative-ios/:backend",
-    "to": "/quickstart/:platform/react-native-ios/:backend"
-  },
-  {
-    "from": "/quickstart/:platform/reactnative-android",
-    "to": "/quickstart/:platform/react-native-android"
-  },
-  {
-    "from": "/quickstart/:platform/reactnative-android/:backend",
-    "to": "/quickstart/:platform/react-native-android/:backend"
-  },
-  {
-    "from": "/connections/passwordless/ios-sms",
-    "to": "/connections/passwordless/ios-sms-objc"
-  },
-  {
-    "from": "/premium-support",
-    "to": "/support"
-  },
-  {
-    "from": "/multifactor-authentication/custom-provider",
-    "to": "/multifactor-authentication"
-  },
-  {
-    "from": "/native-platforms/windows-store-javascript",
-    "to": "/native-platforms/windows-uwp-javascript"
-  },
-  {
-    "from": "/native-platforms/windows-store-csharp",
-    "to": "/native-platforms/windows-uwp-csharp"
-  },
-  {
-    "from": "/tutorials/aspnet-mvc4-enterprise-providers",
-    "to": "/server-platforms/aspnet"
-  },
-  {
-    "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": "/appliance/checksum",
-    "to": "/appliance"
-  },
-  {
-    "from": "/appliance/proxy-updater",
-    "to": "/appliance"
-  },
-  {
-    "from": "/appliance/update",
-    "to": "/appliance"
-  },
-  {
-    "from": "/enterprise-support",
-    "to": "/onboarding/enterprise-support"
-  },
-  {
-    "from": "/extensions/azure-blog-storage",
-    "to": "/extensions/azure-blob-storage"
-  },
-  {
-    "from": "/quickstart/hybrid",
-    "to": "/quickstart/native"
-  },
-  {
-    "from": "/quickstart/hybrid/:platform",
-    "to": "/quickstart/native/:platform"
-  },
-  {
-    "from": "/quickstart/hybrid/:platform/:api([^0-9]+)",
-    "to": "/quickstart/native/:platform"
-  },
-  {
-    "from": "/quickstart/spa/:platform/:api([^0-9]+)",
-    "to": "/quickstart/spa/:platform"
-  },
-  {
-    "from": "/quickstart/native/:platform/:api([^0-9]+)",
-    "to": "/quickstart/native/:platform"
-  },
-  {
-    "from": "/quickstart/backend/:platform/:api([^0-9]+)",
-    "to": "/quickstart/backend/:platform"
-  },
-  {
-    "from": "/quickstart/backend/java",
-    "to": "/quickstart/backend/java-spring-security",
-    "status": 302
-  },
-  {
-    "from": "/policies/rate-limit",
-    "to": "/policies/rate-limits"
-  },
-  {
-    "from": "/i18n/password-strength",
-    "to": "/i18n/password-options"
-  },
-  {
-    "from": "/multifactor-authentication2",
-    "to": "/multifactor-authentication"
-  },
-  {
-    "from": "/quickstart/native/ios-reactnative",
-    "to": "/quickstart/native/react-native-ios"
-  },
-  {
-    "from": "/quickstart/native-mobile/:platform",
-    "to": "/quickstart/native/:platform"
-  },
-  {
-    "from": "/quickstart/native-mobile/:platform/no-api",
-    "to": "/quickstart/native/:platform"
-  },
-  {
-    "from": "/quickstart/native-mobile",
-    "to": "/quickstart/native"
-  },
-  {
-    "from": "/sso/single-sign-on",
-    "to": "/sso"
-  },
-  {
-    "from": "/libraries/lock/i18n",
-    "to": "/libraries/lock/v10/i18n",
-    "status": 302
-  },
-  {
-    "from": "/libraries/lock/migration-guide",
-    "to": "/libraries/lock/v10/migration-guide",
-    "status": 302
-  },
-  {
-    "from": "/libraries/lock/sending-authentication-parameters",
-    "to": "/libraries/lock/v10/sending-authentication-parameters",
-    "status": 302
-  },
-  {
-    "from": "/libraries/lock/v10",
-    "to": "/libraries/lock",
-    "status": 302
-  },
-  {
-    "from": "/libraries/lock/v10/installation",
-    "to": "/libraries/lock#lock-10-installation",
-    "status": 302
-  },
-  {
-    "from": "/libraries/lock/customization",
-    "to": "/libraries/lock/v10/customization",
-    "status": 302
-  },
-  {
-    "from": "/libraries/lock/display-modes",
-    "to": "/libraries/lock/v10/customization#container-string-",
-    "status": 302
-  },
-  {
-    "from": "/libraries/lock/ui-customization",
-    "to": "/libraries/lock/v10/ui-customization",
-    "status": 302
-  },
-  {
-    "from": "/quickstart/spa/react/03-user-profile",
-    "to": "/quickstart/spa/react/04-user-profile"
-  },
-  {
-    "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": "/tutorials/step-up-authentication"
-  },
-  {
-    "from": "/refresh-token",
-    "to": "/tokens/refresh-token"
-  },
-  {
-    "from": "/tokens/access_token",
-    "to": "/tokens/access-token"
-  },
-  {
-    "from": "/salesforce-community",
-    "to": "/connections/social/salesforce"
-  },
-  {
-    "from": "/update-client-secret",
-    "to": "/tutorials/how-to-update-applications-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",
-    "to": "/libraries/custom-signup"
-  },
-  {
-    "from": "/custom-error-pages",
-    "to": "/error-pages/custom"
-  },
-  {
-    "from": "/error-pages",
-    "to": "/error-pages/generic"
-  },
-  {
-    "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-an-api"
-  },
-  {
-    "from": "/apps-apis",
-    "to": "/tutorials/web-apps-vs-web-apis-cookies-vs-tokens"
-  },
-  {
-    "from": "/monitoring",
-    "to": "/tutorials/how-to-monitor-auth0"
-  },
-  {
-    "from": "/har",
-    "to": "/tutorials/troubleshooting-with-har-files"
-  },
-  {
-    "from": "/tutorials/troubleshootings-with-har-files",
-    "to": "/tutorials/troubleshooting-with-har-files"
-  },
-  {
-    "from": "/hrd",
-    "to": "/libraries/lock/v10/selecting-the-connection-for-multiple-logins"
-  },
-  {
-    "from": "/blacklist-attributes",
-    "to": "/tutorials/blacklisting-attributes"
-  },
-  {
-    "from": "/brute-force-protection",
-    "to": "/anomaly-detection/brute-force-protection"
-  },
-  {
-    "from": "/breached-password",
-    "to": "/anomaly-detection/breached-passwords"
-  },
-  {
-    "from": "/office365-deprecated",
-    "to": "/tutorials/office365-connection-deprecation-guide"
-  },
-  {
-    "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/ionic-and-firebase",
-    "to": "/tutorials/using-ionic-and-firebase"
-  },
-  {
-    "from": "/scenarios/keenio",
-    "to": "/tutorials/sending-events-to-keenio"
-  },
-  {
-    "from": "/scenarios/mixpanel-fullcontact-salesforce",
-    "to": "/tutorials/track-signups-enrich-user-profile-generate-leads"
-  },
-  {
-    "from": "/scenarios/mqtt",
-    "to": "/tutorials/authenticating-devices-using-mqtt"
-  },
-  {
-    "from": "/scenarios/multi-tenant-saas-azure-ad",
-    "to": "/tutorials/building-multi-tenant-saas-applications-with-azure-active-directory"
-  },
-  {
-    "from": "/scenarios/rapleaf-salesforce",
-    "to": "/tutorials/tracking-new-leads-in-salesforce-and-raplead"
-  },
-  {
-    "from": "/scenarios/segmentio",
-    "to": "/tutorials/sending-events-to-segmentio"
-  },
-  {
-    "from": "/scenarios/slack",
-    "to": "/tutorials/integrating-with-slack"
-  },
-  {
-    "from": "/scenarios/splunk",
-    "to": "/tutorials/sending-events-to-splunk"
-  },
-  {
-    "from": "/scenarios/tessel",
-    "to": "/tutorials/authenticating-a-tessel-device"
-  },
-  {
-    "from": "/scenarios/unbounce",
-    "to": "/tutorials/get-user-information-with-unbounce-landing-pages"
-  },
-  {
-    "from": "/scenarios/zendesk-sso",
-    "to": "/tutorials/single-sign-on-with-zendesk-using-jwt"
-  },
-  {
-    "from": "/scenarios",
-    "to": "/tutorials"
-  },
-  {
-    "from": "/rate-limits",
-    "to": "/policies/rate-limits"
-  },
-  {
-    "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": "/java-overview",
-    "to": "/dev-centers/java"
-  },
-  {
-    "from": "/oauth-web-protocol",
-    "to": "/protocols/oauth2/oauth-web-protocol"
-  },
-  {
-    "from": "/protocols/oauth-web-protocol",
-    "to": "/protocols/oauth2/oauth-web-protocol"
-  },
-  {
-    "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": "/applications",
-    "to": "/clients"
-  },
-  {
-    "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": "/error-pages",
-    "to": "/hosted-pages/error-pages"
-  },
-  {
-    "from": "/error-pages/custom",
-    "to": "/hosted-pages/custom-error-pages"
-  },
-  {
-    "from": "/error-pages/generic",
-    "to": "/hosted-pages/error-pages"
-  },
-  {
-    "from": "/saml/identity-providers/okta",
-    "to": "/protocols/saml/identity-providers/okta"
-  },
-  {
-    "from": "/saml/identity-providers/onelogin",
-    "to": "/protocols/saml/identity-providers/onelogin"
-  },
-  {
-    "from": "/saml/identity-providers/ping7",
-    "to": "/protocols/saml/identity-providers/ping7"
-  },
-  {
-    "from": "/saml/identity-providers/salesforce",
-    "to": "/protocols/saml/identity-providers/salesforce"
-  },
-  {
-    "from": "/saml/identity-providers/siteminder",
-    "to": "/protocols/saml/identity-providers/siteminder"
-  },
-  {
-    "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": "/libraries/lock-android/use-your-own-ui",
-    "to": "/libraries/lock-android/custom-theming"
-  },
-  {
-    "from": "/libraries/lock-android/native-social-authentication",
-    "to": "/libraries/lock-android/custom-authentication-providers"
-  },
-  {
-    "from": "/onboarding/appliance-outage",
-    "to": "/appliance/critical-issue"
-  },
-  {
-    "from": "/libraries/lock/v10/custom-signup",
-    "to": "/libraries/custom-signup"
-  },
-  {
-    "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",
-    "to": "/tokens/id-token"
-  },
-  {
-    "from": "/connections",
-    "to": "/identityproviders"
-  },
-  {
-    "from": "/anomaly-detection/brute-force-protection",
-    "to": "/anomaly-detection#brute-force-protection"
-  }
-]
diff --git a/config/redirects.js b/config/redirects.js
new file mode 100644
index 0000000000..5719f79b0b
--- /dev/null
+++ b/config/redirects.js
@@ -0,0 +1,9107 @@
+//  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('|')})`;
+
+const redirects = [
+  /* MISCELLANEOUS AND OUTDATED  */
+
+  {
+    from: [
+      '/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: '/',
+  },
+  {
+    from: '/topics/guides',
+    to: '/',
+  },
+  {
+    from: ['/design', '/design/web'],
+    to: '/',
+  },
+  {
+    from: ['/contentful-test-1', '/contentful-test-2', '/contentful-test-3', '/contentful-test-4'],
+    to: '/',
+  },
+  {
+    from: [
+      '/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: '/get-started/authentication-and-authorization-flow/device-authorization-flow/mobile-device-login-flow-best-practices',
+  },
+  {
+    from: '/topics/identity-glossary',
+    to: '/glossary',
+  },
+  {
+    from: ['/deploy/checklist', '/deploy/deploy-checklist'],
+    to: '/deploy-monitor/deploy-checklist',
+  },
+
+  /* QUICKSTARTS */
+
+  {
+    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/:platform/reactnative-ios/:backend?', '/quickstart/:platform/reactnative-android/:backend?'],
+    to: '/quickstart/native/react-native',
+  },
+  {
+    from: ['/android-tutorial', '/native-platforms/android', '/quickstart/native/android-vnext'],
+    to: '/quickstart/native/android',
+  },
+  {
+    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: '/quickstarts/spa/vanillajs/01-login',
+    to: '/quickstart/spa/vanillajs/01-login',
+  },
+  {
+    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: ['/aspnet-owin-tutorial', '/aspnetwebapi-owin-tutorial'],
+    to: '/quickstart/webapp/aspnet-owin',
+  },
+  {
+    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: [
+      '/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: [
+      '/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: [
+      '/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: '/server-platforms/golang',
+    to: '/quickstart/webapp/golang',
+  },
+  {
+    from: '/laravel-tutorial',
+    to: '/quickstart/webapp/laravel',
+  },
+  {
+    from: ['/laravelapi-tutorial', '/quickstart/backend/php-laravel', '/quickstart/backend/laravel/00-getting-started'],
+    to: '/quickstart/backend/laravel',
+  },
+  {
+    from: ['/nodeapi-tutorial', '/quickstart/backend/nodejs/00-getting-started'],
+    to: '/quickstart/backend/nodejs',
+  },
+  {
+    from: ['/phpapi-tutorial', '/quickstart/backend/php/00-getting-started'],
+    to: '/quickstart/backend/php',
+  },
+  {
+    from: ['/pythonapi-tutorial', '/quickstart/backend/python/00-getting-started'],
+    to: '/quickstart/backend/python',
+  },
+  {
+    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: [
+      '/quickstart/native/ios-reactnative',
+      '/quickstart/native/react-native-ios',
+      '/quickstart/native/react-native-android',
+    ],
+    to: '/quickstart/native/react-native',
+  },
+  {
+    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: [
+      '/server-apis/ruby',
+      '/quickstart/backend/ruby/00-getting-started',
+      '/quickstart/backend/ruby',
+      '/rubyapi-tutorial',
+      '/quickstart/backend/rails/00-getting-started',
+    ],
+    to: '/quickstart/backend/rails',
+  },
+  {
+    from: '/python-tutorial',
+    to: '/quickstart/webapp/python',
+  },
+  {
+    from: ['/php-tutorial', '/server-platforms/php'],
+    to: '/quickstart/webapp/php',
+  },
+  {
+    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?',
+    ],
+    to: '/quickstart/native/windows-uwp-csharp',
+  },
+  {
+    from: '/wpf-winforms-tutorial',
+    to: '/quickstart/native/wpf-winforms',
+  },
+  {
+    from: '/xamarin-tutorial',
+    to: '/quickstart/native/xamarin',
+  },
+  {
+    from: '/quickstart/native/xamarin',
+    to: '/quickstart/native/net-android-ios',
+  },
+  {
+    from: '/quickstart/native/xamarin/interactive',
+    to: '/quickstart/native/net-android-ios/interactive',
+  },
+  {
+    from: '/quickstart/spa/auth0-react/02',
+    to: '/quickstart/spa/react/02-calling-an-api',
+  },
+  {
+    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',
+  },
+  {
+    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/webapp/aspnet-core-3', '/quickstart/webapp/aspnet-core-2'],
+    to: '/quickstart/webapp/aspnet-core',
+  },
+  {
+    from: [
+      '/quickstart/spa/aurelia',
+      '/ember-tutorial',
+      '/client-platforms/emberjs',
+      '/quickstart/spa/emberjs',
+      '/quickstart/spa/ember',
+      '/quickstart/spa/jquery',
+    ],
+    to: '/quickstart/spa',
+  },
+  {
+    from: ['/quickstart', '/quickstart/'],
+    to: '/quickstarts',
+  },
+  {
+    from: '/quickstart/backend/golang/00-getting-started',
+    to: '/quickstart/backend/golang',
+  },
+  {
+    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/webapp/java/getting-started', '/java-tutorial'],
+    to: '/quickstart/webapp/java',
+  },
+  {
+    from: [
+      '/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/webapp/java-spring-boot',
+  },
+  {
+    from: [
+      '/quickstart/webapp/nodejs',
+      '/nodejs-tutorial',
+      '/server-platforms/nodejs',
+      '/quickstart/webapp/nodejs/02-user-profile',
+      '/quickstart/webapp/nodejs/01-login',
+    ],
+    to: '/quickstart/webapp/express',
+  },
+  {
+    from: ['/quickstart/native/cordova'],
+    to: '/quickstart',
+  },
+
+  /* CONNECTIONS */
+
+  {
+    from: ['/37signals-clientid', '/connections/social/37signals', '/connections/social/basecamp'],
+    to: 'https://marketplace.auth0.com/integrations/37signals-social-connection',
+  },
+  {
+    from: ['/amazon-clientid', '/connections/social/amazon'],
+    to: 'https://marketplace.auth0.com/integrations/amazon-social-connection',
+  },
+  {
+    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/google-apps'],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/google-apps',
+  },
+  {
+    from: [
+      '/connections/enterprise/samlp',
+      '/connections/enterprise/saml',
+      '/connections/enterprise/sharepoint-online',
+      '/connections/enterprise/ws-fed',
+    ],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/saml',
+  },
+  {
+    from: ['/dwolla-clientid', '/connections/social/dwolla'],
+    to: 'https://marketplace.auth0.com/integrations/dwolla-social-connection',
+  },
+  {
+    from: ['/baidu-clientid', '/connections/social/baidu'],
+    to: 'https://marketplace.auth0.com/integrations/baidu-social-connection',
+  },
+  {
+    from: ['/box-clientid', '/connections/social/box'],
+    to: 'https://marketplace.auth0.com/integrations/box-social-connection',
+  },
+  {
+    from: ['/evernote-clientid', '/connections/social/evernote'],
+    to: 'https://marketplace.auth0.com/integrations/evernote-social-connection',
+  },
+  {
+    from: ['/exact-clientid', '/connections/social/exact'],
+    to: 'https://marketplace.auth0.com/integrations/exact-social-connection',
+  },
+  {
+    from: ['/facebook-clientid', '/connections/social/facebook'],
+    to: 'https://marketplace.auth0.com/integrations/facebook-social-connection',
+  },
+  {
+    from: ['/fitbit-clientid', '/connections/social/fitbit'],
+    to: 'https://marketplace.auth0.com/integrations/fitbit-social-connection',
+  },
+  {
+    from: ['/github-clientid', '/connections/social/github'],
+    to: 'https://marketplace.auth0.com/integrations/github-social-connection',
+  },
+  {
+    from: ['/goog-clientid', '/connections/social/google'],
+    to: 'https://marketplace.auth0.com/integrations/google-social-connection',
+  },
+  {
+    from: ['/ms-account-clientid', '/connections/social/microsoft-account'],
+    to: 'https://marketplace.auth0.com/integrations/microsoft-account-social-connection',
+  },
+  {
+    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: ['/connections/social/auth0-oidc', '/connections/enterprise/oidc'],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/oidc',
+  },
+  {
+    from: ['/connections/enterprise/okta'],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/okta',
+  },
+  {
+    from: ['/paypal-clientid', '/connections/social/paypal'],
+    to: 'https://marketplace.auth0.com/integrations/paypal-social-connection',
+  },
+  {
+    from: ['/planningcenter-clientid', '/connections/social/planning-center'],
+    to: 'https://marketplace.auth0.com/integrations/planningcenter-social-connection',
+  },
+  {
+    from: ['/salesforce-clientid', '/connections/social/salesforce'],
+    to: 'https://marketplace.auth0.com/integrations/salesforce-social-connection',
+  },
+  {
+    from: ['/renren-clientid', '/connections/social/renren'],
+    to: 'https://marketplace.auth0.com/integrations/renren-social-connection',
+  },
+  {
+    from: ['/shopify-clientid', '/connections/social/shopify'],
+    to: 'https://marketplace.auth0.com/integrations/shopify-social-connection',
+  },
+  {
+    from: ['/twitter-clientid', '/connections/social/twitter'],
+    to: 'https://marketplace.auth0.com/integrations/twitter-social-connection',
+  },
+  {
+    from: ['/vkontakte-clientid', '/connections/social/vkontakte'],
+    to: 'https://marketplace.auth0.com/integrations/vkontakte-social-connection',
+  },
+  {
+    from: ['/weibo-clientid', '/connections/social/weibo'],
+    to: 'https://marketplace.auth0.com/integrations/weibo-social-connection',
+  },
+  {
+    from: ['/wordpress-clientid', '/connections/social/wordpress'],
+    to: 'https://marketplace.auth0.com/integrations/wordpress-social-connection',
+  },
+  {
+    from: ['/yahoo-clientid', '/connections/social/yahoo'],
+    to: 'https://marketplace.auth0.com/integrations/yahoo-social-connection',
+  },
+  {
+    from: ['/yandex-clientid', '/connections/social/yandex'],
+    to: 'https://marketplace.auth0.com/integrations/yandex-social-connection',
+  },
+  {
+    from: ['/linkedin-clientid', '/connections/social/linkedin'],
+    to: 'https://marketplace.auth0.com/integrations/linkedin-social-connection',
+  },
+  {
+    from: '/connections/social/bitbucket',
+    to: 'https://marketplace.auth0.com/integrations/bitbucket-social-connection',
+  },
+  {
+    from: '/connections/social/digitalocean',
+    to: 'https://marketplace.auth0.com/integrations/digitalocean-social-connection',
+  },
+  {
+    from: '/connections/social/discord',
+    to: 'https://marketplace.auth0.com/integrations/discord-social-connection',
+  },
+  {
+    from: '/connections/social/docomo',
+    to: 'https://marketplace.auth0.com/integrations/daccount-social-connection',
+  },
+  {
+    from: '/connections/social/dribbble',
+    to: 'https://marketplace.auth0.com/integrations/dribbble-social-connection',
+  },
+  {
+    from: '/connections/social/dropbox',
+    to: 'https://marketplace.auth0.com/integrations/dropbox-social-connection',
+  },
+  {
+    from: '/connections/social/evernote-sandbox',
+    to: 'https://marketplace.auth0.com/integrations/evernote-sandbox-social-connection',
+  },
+  {
+    from: '/connections/social/figma',
+    to: 'https://marketplace.auth0.com/integrations/figma-social-connection',
+  },
+  {
+    from: '/connections/social/paypal-sandbox',
+    to: 'https://marketplace.auth0.com/integrations/paypal-sandbox-social-connection',
+  },
+  {
+    from: '/connections/social/quickbooks-online',
+    to: 'https://marketplace.auth0.com/integrations/quickbooks-social-connection',
+  },
+  {
+    from: ['/salesforce-community', '/connections/social/salesforce-community'],
+    to: 'https://marketplace.auth0.com/integrations/salesforce-community-social-connection',
+  },
+  {
+    from: '/connections/social/salesforce-sandbox',
+    to: 'https://marketplace.auth0.com/integrations/salesforce-sandbox-social-connection',
+  },
+  {
+    from: '/connections/social/slack',
+    to: 'https://marketplace.auth0.com/integrations/sign-in-with-slack',
+  },
+  {
+    from: '/connections/social/spotify',
+    to: 'https://marketplace.auth0.com/integrations/spotify-social-connection',
+  },
+  {
+    from: '/connections/social/stripe-connect',
+    to: 'https://marketplace.auth0.com/integrations/stripe-connect-social-connection',
+  },
+  {
+    from: '/connections/social/twitch',
+    to: 'https://marketplace.auth0.com/integrations/twitch-social-connection',
+  },
+  {
+    from: '/connections/social/vimeo',
+    to: 'https://marketplace.auth0.com/integrations/vimeo-social-connection',
+  },
+  {
+    from: '/connections/social/yammer',
+    to: 'https://marketplace.auth0.com/integrations/yammer-social-connection',
+  },
+  {
+    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: ['/adfs', '/connections/enterprise/adfs'],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/adfs',
+  },
+  {
+    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',
+  },
+  {
+    from: [
+      '/connections/passwordless/guides/embedded-login',
+      '/connections/passwordless/embedded-login',
+      '/connections/passwordless/implement-login/embedded-login',
+    ],
+    to: '/authenticate/passwordless/implement-login/embedded-login',
+  },
+  {
+    from: ['/password-strength', '/connections/database/password-strength'],
+    to: '/authenticate/database-connections/password-strength',
+  },
+  {
+    from: [
+      '/identityproviders',
+      '/applications/concepts/connections',
+      '/applications/connections',
+      '/clients/connections',
+      '/connections',
+    ],
+    to: '/authenticate/identity-providers',
+  },
+  {
+    from: [
+      '/connections/database/mysql',
+      '/mysql-connection-tutorial',
+      '/connections/database/custom-db/custom-db-connection-overview',
+      '/connections/database/custom-db',
+    ],
+    to: '/authenticate/database-connections/custom-db',
+  },
+  {
+    from: ['/connections/database/password', '/connections/database/password-options'],
+    to: '/authenticate/database-connections/password-options',
+  },
+  {
+    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: [
+      '/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: [
+      '/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: '/connections/social/imgur',
+    to: 'https://marketplace.auth0.com/integrations/imgur-social-connection',
+  },
+  {
+    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: [
+      '/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: [
+      '/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',
+  },
+  {
+    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: [
+      '/connections/nativesocial/facebook-native',
+      '/connections/nativesocial/facebook',
+      '/connections/social/facebook-native',
+    ],
+    to: '/authenticate/identity-providers/social-identity-providers/facebook-native',
+  },
+  {
+    from: [
+      '/connections/passwordless/email',
+      '/connections/passwordless/guides/email-otp',
+      '/connections/passwordless/email-otp',
+    ],
+    to: '/authenticate/passwordless/authentication-methods/email-otp',
+  },
+  {
+    from: [
+      '/connections/passwordless/sms',
+      '/connections/passwordless/guides/sms-otp',
+      '/connections/passwordless/sms-otp',
+    ],
+    to: '/authenticate/passwordless/authentication-methods/sms-otp',
+  },
+  {
+    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: [
+      '/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: [
+      '/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: ['/connections/identity-providers-legal', '/connections/legal'],
+    to: '/authenticate/identity-providers/legal',
+  },
+  {
+    from: ['/line', '/connections/social/line'],
+    to: 'https://marketplace.auth0.com/integrations/line-social-connection',
+  },
+  {
+    from: [
+      '/connections/passwordless/concepts/sample-use-cases-rules',
+      '/connections/passwordless/sample-use-cases-rules',
+    ],
+    to: '/authenticate/passwordless/sample-use-cases-rules',
+  },
+  {
+    from: ['/connections/azure-active-directory-native', '/connections/enterprise/azure-active-directory-native'],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/azure-active-directory-native',
+  },
+  {
+    from: ['/connections/passwordless/authentication-factors', '/connections/passwordless/authentication-methods'],
+    to: '/authenticate/passwordless/authentication-methods',
+  },
+  {
+    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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: ['/connections/azuread-adfs-email-verification', '/connections/enterprise/azuread-adfs-email-verification'],
+    to: '/authenticate/identity-providers/enterprise-identity-providers/azuread-adfs-email-verification',
+  },
+  {
+    from: ['/database/custom-db/templates/get-user', '/connections/database/custom-db/templates/get-user'],
+    to: '/authenticate/database-connections/custom-db/templates/get-user',
+  },
+  {
+    from: ['/connections/database/custom-db/templates/login'],
+    to: '/authenticate/database-connections/custom-db/templates/login',
+  },
+  {
+    from: ['/connections/database'],
+    to: '/authenticate/database-connections',
+  },
+  {
+    from: ['/connections/social/devkeys'],
+    to: '/authenticate/identity-providers/social-identity-providers/devkeys',
+  },
+  {
+    from: ['/connections/database/custom-db/overview-custom-db-connections'],
+    to: '/authenticate/database-connections/custom-db/overview-custom-db-connections',
+  },
+  {
+    from: ['/connections/passwordless/best-practices'],
+    to: '/authenticate/passwordless/best-practices',
+  },
+  {
+    from: ['/connections/database/custom-db/templates'],
+    to: '/authenticate/database-connections/custom-db/templates',
+  },
+  {
+    from: ['/connections/database/require-username'],
+    to: '/authenticate/database-connections/require-username',
+  },
+  {
+    from: ['/connections/database/custom-db/create-db-connection'],
+    to: '/authenticate/database-connections/custom-db/create-db-connection',
+  },
+  {
+    from: ['/connections/pass-parameters-to-idps'],
+    to: '/authenticate/identity-providers/pass-parameters-to-idps',
+  },
+  {
+    from: ['/connections/database/password-change'],
+    to: '/authenticate/database-connections/password-change',
+  },
+  {
+    from: ['/connections/pass-parameters-to-idps'],
+    to: '/authenticate/identity-providers/pass-parameters-to-idps',
+  },
+  {
+    from: ['/connections/database/custom-db/error-handling'],
+    to: '/authenticate/database-connections/custom-db/error-handling',
+  },
+  {
+    from: [`/authenticate/database-connections/test-custom-db`],
+    to: `/authenticate/database-connections/custom-db/test-custom-database-connections`,
+  },
+
+  /* MICROSITES */
+  {
+    from: ['/microsites/call-api/call-api-m2m-app'],
+    to: '/get-started/authentication-and-authorization-flow/client-credentials-flow',
+  },
+  {
+    from: ['/microsites/add-login/add-login-native-mobile-app'],
+    to: '/quickstart/native',
+  },
+  {
+    from: ['/microsites/add-login/add-login-regular-web-app'],
+    to: '/quickstart/webapp',
+  },
+  {
+    from: ['/microsites/add-login/add-login-single-page-app'],
+    to: '/quickstart/spa',
+  },
+  {
+    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: ['/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: ['/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: ['/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: ['/microsites/manage-users/define-maintain-custom-user-data'],
+    to: '/manage-users/user-accounts/metadata',
+  },
+  {
+    from: ['/microsites/manage-users/manage-users-and-user-profiles'],
+    to: '/manage-users/user-accounts/metadata',
+  },
+
+  /* ARCHITECTURE SCENARIOS */
+
+  {
+    from: ['/architecture-scenarios'],
+    to: '/get-started/architecture-scenarios',
+  },
+  {
+    from: ['/architecture-scenarios/application/mobile-api', '/architecture-scenarios/mobile-api'],
+    to: '/get-started/architecture-scenarios/mobile-api',
+  },
+  {
+    from: ['/architecture-scenarios/application/server-api', '/architecture-scenarios/server-api'],
+    to: '/get-started/architecture-scenarios/server-application-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: ['/architecture-scenarios/spa-api/part-1'],
+    to: '/get-started/architecture-scenarios/spa-api/part-1',
+  },
+  {
+    from: ['/architecture-scenarios/spa-api/part-2'],
+    to: '/get-started/architecture-scenarios/spa-api/part-2',
+  },
+  {
+    from: ['/architecture-scenarios/spa-api/part-3'],
+    to: '/get-started/architecture-scenarios/spa-api/part-3',
+  },
+  {
+    from: ['/architecture-scenarios/application/web-app-sso', '/architecture-scenarios/web-app-sso'],
+    to: '/get-started/architecture-scenarios/sso-for-regular-web-apps',
+  },
+  {
+    from: ['/architecture-scenarios/business/b2b', '/architecture-scenarios/b2b'],
+    to: '/get-started/architecture-scenarios/business-to-business',
+  },
+  {
+    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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: ['/architecture-scenarios/business/b2c', '/architecture-scenarios/b2c'],
+    to: '/get-started/architecture-scenarios/business-to-consumer',
+  },
+  {
+    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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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/b2c/b2c-launch',
+      '/architecture-scenarios/implementation/b2c/b2c-launch',
+      '/architecture-scenarios/b2c/launch',
+    ],
+    to: '/get-started/architecture-scenarios/business-to-consumer/launch',
+  },
+  {
+    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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: ['/architecture-scenarios/business/b2e', '/architecture-scenarios/b2e'],
+    to: '/get-started/architecture-scenarios/b2e',
+  },
+  {
+    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: [
+      '/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: ['/architecture-scenarios/mobile-api/part-1'],
+    to: '/get-started/architecture-scenarios/mobile-api/part-1',
+  },
+  {
+    from: ['/architecture-scenarios/mobile-api/part-2'],
+    to: '/get-started/architecture-scenarios/mobile-api/part-2',
+  },
+  {
+    from: ['/architecture-scenarios/mobile-api/part-3'],
+    to: '/get-started/architecture-scenarios/mobile-api/part-3',
+  },
+  {
+    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: [
+      '/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: ['/architecture-scenarios/server-api/part-1'],
+    to: '/get-started/architecture-scenarios/server-application-api/part-1',
+  },
+  {
+    from: ['/architecture-scenarios/server-api/part-2'],
+    to: '/get-started/architecture-scenarios/server-application-api/part-2',
+  },
+  {
+    from: ['/architecture-scenarios/server-api/part-3'],
+    to: '/get-started/architecture-scenarios/server-application-api/part-3',
+  },
+  {
+    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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: ['/security/incident-response-using-logs'],
+    to: '/secure/security-guidance/incident-response-using-logs',
+  },
+
+  /* Tokens */
+
+  {
+    from: ['/tokens', '/security/token-exp', '/token', '/tokens/concepts', '/tokens/guides', '/security/tokens'],
+    to: '/secure/tokens',
+  },
+  {
+    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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: ['/secure/tokens/access-tokens/token-binding'],
+    to: '/get-started/applications/configure-sender-constraining',
+  },
+  {
+    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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: ['/tokens/revoke-tokens', '/tokens/guides/revoke-tokens', '/security/tokens/revoke-tokens'],
+    to: '/secure/tokens/revoke-tokens',
+  },
+  {
+    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: ['/policies/requests', '/premium-support', '/support'],
+    to: '/troubleshoot/customer-support',
+  },
+  {
+    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: ['/support/matrix', '/support/product-support-matrix'],
+    to: '/troubleshoot/customer-support/product-support-matrix',
+  },
+  {
+    from: ['/sla', '/support/sla', '/support/sld', '/support/services-level-descriptions'],
+    to: '/troubleshoot/customer-support/services-level-descriptions',
+  },
+  {
+    from: ['/support/tickets', '/support/open-and-manage-support-tickets'],
+    to: '/troubleshoot/customer-support/open-and-manage-support-tickets',
+  },
+  {
+    from: ['/support/subscription', '/support/manage-subscriptions'],
+    to: '/troubleshoot/customer-support/manage-subscriptions',
+  },
+  {
+    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: [
+      '/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: [
+      '/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: [
+      '/support/how-auth0-versions-software',
+      '/tutorials/how-auth0-versions-software',
+      '/versioning',
+      '/support/versioning-strategy',
+    ],
+    to: '/troubleshoot/customer-support/versioning-strategy',
+  },
+  {
+    from: ['/support/reset-account-password', '/tutorials/reset-account-password', '/support/reset-account-passwords'],
+    to: '/troubleshoot/customer-support/reset-account-passwords',
+  },
+  {
+    from: ['/support/support-channels'],
+    to: '/troubleshoot/customer-support/support-channels',
+  },
+  {
+    from: ['/support/software-updates'],
+    to: '/troubleshoot/customer-support/software-updates',
+  },
+  {
+    from: ['/support/whitehat-security-support-tickets'],
+    to: '/troubleshoot/customer-support/responsible-disclosure-program-security-support-tickets',
+  },
+
+  /* Policies */
+
+  {
+    from: [
+      '/policies',
+      '/policies/dashboard-authentication',
+      '/policies/restore-deleted-tenant',
+      '/policies/unsupported-requests',
+      '/support/policies',
+    ],
+    to: '/troubleshoot/customer-support/operational-policies',
+  },
+  {
+    from: ['/policies/billing-policy', '/policies/billing', '/support/policies/billing-policy'],
+    to: '/troubleshoot/customer-support/operational-policies/billing-policy',
+  },
+  {
+    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: [
+      '/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: ['/policies/load-testing-policy', '/policies/load-testing', '/support/policies/load-testing-policy'],
+    to: '/troubleshoot/customer-support/operational-policies/load-testing-policy',
+  },
+  {
+    from: [
+      '/policies/penetration-testing-policy',
+      '/policies/penetration-testing',
+      '/support/policies/penetration-testing-policy',
+    ],
+    to: '/troubleshoot/customer-support/operational-policies/penetration-testing-policy',
+  },
+  {
+    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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/troubleshoot/customer-support/operational-policies/rate-limit-policy/understand-rate-limit-burst-capability',
+    ],
+    to: '/troubleshoot/customer-support/operational-policies/rate-limit-policy',
+  },
+  {
+    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: [
+      '/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: ['/troubleshoot/basics'],
+    to: '/troubleshoot',
+  },
+  {
+    from: ['/troubleshoot/basic-troubleshooting', '/troubleshoot/concepts/basics', '/troubleshoot/troubleshoot-basic'],
+    to: '/troubleshoot/basic-issues',
+  },
+  {
+    from: [
+      '/troubleshoot/basic-troubleshooting/verify-platform',
+      '/troubleshoot/guides/verify-platform',
+      '/troubleshoot/troubleshoot-basic/verify-platform',
+    ],
+    to: '/troubleshoot/basic-issues/verify-platform',
+  },
+  {
+    from: [
+      '/troubleshoot/basic-troubleshooting/verify-connections',
+      '/troubleshoot/guides/verify-connections',
+      '/troubleshoot/troubleshoot-basic/verify-connections',
+    ],
+    to: '/troubleshoot/basic-issues/verify-connections',
+  },
+  {
+    from: [
+      '/troubleshoot/basic-troubleshooting/verify-domain',
+      '/troubleshoot/guides/verify-domain',
+      '/troubleshoot/troubleshoot-basic/verify-domain',
+    ],
+    to: '/troubleshoot/basic-issues/verify-domain',
+  },
+  {
+    from: [
+      '/troubleshoot/guides/verify-rules',
+      '/troubleshoot/verify-rules',
+      '/troubleshoot/troubleshoot-basic/verify-rules',
+    ],
+    to: '/troubleshoot/basic-issues/verify-rules',
+  },
+  {
+    from: [
+      '/troubleshoot/guides/check-error-messages',
+      '/troubleshoot/check-error-messages',
+      '/troubleshoot/troubleshoot-basic/check-error-messages',
+    ],
+    to: '/troubleshoot/basic-issues/check-error-messages',
+  },
+  {
+    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: [
+      '/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: [
+      '/troubleshoot/references/invalid-token',
+      '/troubleshoot/invalid-token-errors',
+      '/troubleshoot/troubleshoot-basic/invalid-token-errors',
+    ],
+    to: '/troubleshoot/basic-issues/invalid-token-errors',
+  },
+  {
+    from: [
+      '/troubleshoot/concepts/auth-issues',
+      '/troubleshoot/troubleshoot-authentication-issues',
+      '/troubleshoot/troubleshoot-authentication',
+    ],
+    to: '/troubleshoot/authentication-issues',
+  },
+  {
+    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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/troubleshoot/references/saml-errors',
+      '/troubleshoot/troubleshoot-authentication-issues/saml-errors',
+      '/troubleshoot/troubleshoot-authentication/saml-errors',
+    ],
+    to: '/troubleshoot/authentication-issues/saml-errors',
+  },
+  {
+    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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/troubleshoot/concepts/integration-extensibility-issues',
+      '/troubleshoot/troubleshoot-integration-and-extensibility',
+    ],
+    to: '/troubleshoot/integration-extensibility-issues',
+  },
+  {
+    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: [
+      '/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: [
+      '/extensions/troubleshoot-extensions',
+      '/extensions/troubleshoot',
+      '/troubleshoot/troubleshoot-integration-and-extensibility/troubleshoot-extensions',
+    ],
+    to: '/troubleshoot/integration-extensibility-issues/troubleshoot-extensions',
+  },
+  {
+    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: ['/troubleshoot/tools'],
+    to: '/troubleshoot/troubleshooting-tools',
+  },
+  {
+    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: ['/scenarios', '/tutorials'],
+    to: '/',
+  },
+
+  /* Manage Users */
+
+  {
+    from: ['/users/concepts/overview-users', '/users'],
+    to: '/manage-users',
+  },
+  {
+    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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: ['/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: ['/metadata/lock', '/users/metadata/manage-metadata-lock'],
+    to: '/manage-users/user-accounts/metadata/manage-metadata-lock',
+  },
+  {
+    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: [
+      '/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: ['/sessions/session-layers', '/sessions/concepts/session-layers', '/users/sessions/session-layers'],
+    to: '/manage-users/sessions/session-layers',
+  },
+  {
+    from: ['/sessions/session-lifetime-limits', '/users/sessions/session-lifetime-limits'],
+    to: '/manage-users/sessions/session-lifetime-limits',
+  },
+  {
+    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: [
+      '/sessions/non-persistent-sessions',
+      '/users/sessions/session-lifetimes/non-persistent-sessions',
+      '/users/sessions/non-persistent-sessions',
+    ],
+    to: '/manage-users/sessions/non-persistent-sessions',
+  },
+  {
+    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: ['/sessions/cookies', '/sessions/concepts/cookies', '/sessions-and-cookies/cookies', '/users/cookies'],
+    to: '/manage-users/cookies',
+  },
+  {
+    from: ['/sessions/cookies/authentication-api-cookies', '/users/cookies/authentication-api-cookies'],
+    to: '/manage-users/cookies/authentication-api-cookies',
+  },
+  {
+    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: [
+      '/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: ['/users/guides/manage-users-using-the-dashboard', '/users/manage-users-using-the-dashboard'],
+    to: '/manage-users/user-accounts/manage-users-using-the-dashboard',
+  },
+  {
+    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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: ['/users/concepts/overview-user-migration', '/users/import-export-users', '/users/import-and-export-users'],
+    to: '/manage-users/user-migration',
+  },
+  {
+    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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: ['/users/guides/block-and-unblock-users', '/users/block-and-unblock-users'],
+    to: '/manage-users/user-accounts/block-and-unblock-users',
+  },
+  {
+    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: ['/users/guides/delete-users', '/users/delete-users'],
+    to: '/manage-users/user-accounts/delete-users',
+  },
+  {
+    from: ['/dashboard/guides/users/unlink-user-devices', '/users/unlink-devices-from-users'],
+    to: '/manage-users/user-accounts/unlink-devices-from-users',
+  },
+  {
+    from: ['/user-profile/user-picture', '/users/guides/change-user-pictures', '/users/change-user-picture'],
+    to: '/manage-users/user-accounts/change-user-picture',
+  },
+  {
+    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: [
+      '/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: ['/users/guides/view-users', '/users/view-user-details'],
+    to: '/manage-users/user-accounts/view-user-details',
+  },
+  {
+    from: ['/users/normalized/auth0/identify-users', '/users/identify-users'],
+    to: '/manage-users/user-accounts/identify-users',
+  },
+  {
+    from: [
+      '/users/search/v3',
+      '/users/normalized/auth0/retrieve-user-profiles',
+      '/users/search',
+      '/users-search',
+      '/users/user-search',
+    ],
+    to: '/manage-users/user-search',
+  },
+  {
+    from: [
+      '/users/search/v3/query-syntax',
+      '/users/user-search/user-search-query-syntax',
+    ],
+    to:  '/manage-users/user-search/user-search-query-syntax',
+  },
+  {
+    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: [
+      '/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: [
+      '/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: [
+      '/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: [
+      '/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: ['/users/search/v3/sort-search-results', '/users/user-search/sort-search-results'],
+    to: '/manage-users/user-search/sort-search-results',
+  },
+  {
+    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: [
+      '/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: [
+      '/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: ['/users/verify-emails'],
+    to: '/manage-users/user-accounts/verify-emails',
+  },
+
+  /* Videos */
+
+  {
+    from: ['/video-series/main/videos', '/videos'],
+    to: '/articles',
+  },
+  {
+    from: ['/videos/learn-identity', '/videos/learn-identity-series'],
+    to: '/articles',
+  },
+  {
+    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: ['/videos/learn-identity/02-oidc-and-oauth', '/videos/learn-identity-series/openid-connect-and-oauth2'],
+    to: '/articles',
+  },
+  {
+    from: ['/videos/learn-identity/03-web-sign-in', '/videos/learn-identity-series/web-sign-in'],
+    to: '/articles',
+  },
+  {
+    from: ['/videos/learn-identity/04-calling-an-api', '/videos/learn-identity-series/calling-an-api'],
+    to: '/articles',
+  },
+  {
+    from: [
+      '/videos/learn-identity/05-desktop-and-mobile-apps',
+      '/videos/learn-identity-series/desktop-and-mobile-apps',
+    ],
+    to: '/articles',
+  },
+  {
+    from: ['/videos/learn-identity/06-single-page-apps', '/videos/learn-identity-series/single-page-apps'],
+    to: '/articles',
+  },
+  {
+    from: ['/videos/get-started', '/videos/get-started-series'],
+    to: '/articles',
+  },
+  {
+    from: ['/videos/get-started/01-architecture-your-tenant', '/videos/get-started-series/architect-your-tenant'],
+    to: '/articles',
+  },
+  {
+    from: ['/videos/get-started/02-provision-user-stores', '/videos/get-started-series/provision-user-stores'],
+    to: '/articles',
+  },
+  {
+    from: ['/videos/get-started/03-provision-import-users', '/videos/get-started-series/provision-import-users'],
+    to: '/articles',
+  },
+  {
+    from: [
+      '/videos/get-started/04_01-authenticate-how-it-works',
+      '/videos/get-started-series/authenticate-how-it-works',
+    ],
+    to: '/articles',
+  },
+  {
+    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: [
+      '/videos/get-started/05_01-authorize-id-tokens-access-control',
+      '/videos/get-started-series/authorize-id-tokens-and-access-control',
+    ],
+    to: '/articles',
+  },
+  {
+    from: [
+      '/videos/get-started/05_02-authorize-get-validate-id-tokens',
+      '/videos/get-started-series/authorize-get-and-validate-id-tokens',
+    ],
+    to: '/articles',
+  },
+  {
+    from: ['/videos/get-started/06-user-profiles', '/videos/get-started-series/learn-user-profiles'],
+    to: '/articles',
+  },
+  {
+    from: ['/videos/get-started/07_01-brand-how-it-works', '/videos/get-started-series/brand-how-it-works'],
+    to: '/articles',
+  },
+  {
+    from: [
+      '/videos/get-started/07_02-brand-signup-login-pages',
+      '/videos/get-started-series/brand-signup-and-login-pages',
+    ],
+    to: '/articles',
+  },
+  {
+    from: [
+      '/videos/get-started/08-brand-emails-error-pages',
+      '/videos/get-started-series/brand-emails-and-error-pages',
+    ],
+    to: '/articles',
+  },
+  {
+    from: ['/videos/get-started/10-logout', '/videos/get-started-series/learn-logout'],
+    to: '/articles',
+  },
+
+  /* Forms */
+
+  {
+    from: ['/customize/forms/intro-to-forms', '/customize/forms/fields'],
+    to: '/customize/forms/nodes-and-components',
+  },
+
+  {
+    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 9496a56bab..1b67bb8bb4 100644
--- a/config/sections.yml
+++ b/config/sections.yml
@@ -6,24 +6,21 @@
 
 - id: "articles"
   title: "Articles"
-  url: "/overview"
-
-# - id: "sdks"
-#   title: "SDKs"
-#   url: "/sdks"
-
-- id: "apis"
-  title: "APIs"
-  url: "/api/info"
+  url: "/articles"
+  folder: ""
+  default: true
 
 - id: "quickstarts"
-  title: "QuickStarts"
+  title: "Quickstarts"
   url: "/quickstarts"
+  folder: "quickstart"
+
+- id: "apis"
+  title: "Auth0 APIs"
+  url: "/api"
+  folder: "api"
 
 - id: "libraries"
-  title: "Libraries"
+  title: "SDKs"
   url: "/libraries"
-
-- id: "appliance"
-  title: "Appliance"
-  url: "/appliance"
+  folder: "libraries"
diff --git a/config/sidebar.yml b/config/sidebar.yml
index 0f424d8130..4a250c9905 100644
--- a/config/sidebar.yml
+++ b/config/sidebar.yml
@@ -1,568 +1,1675 @@
-## ------------------------------------------------------------
-## Sidebar Nav Configuration
-## This document contains configuration for the sidebar
-##
-## ------------------------------------------------------------
-
 articles:
-
-  - title: Getting Started
-    url: "/overview"
+  - title: Get Started 
+    url: /get-started
     children:
-      - title: Overview
-        url: /overview
-
-      - title: "Clients"
-        url: "/clients"
-
-      - title: "APIs"
-        url: "/apis"
-
-      - title: Developer Videos
-        url: /videos
-
-      - title: Architecture Scenarios
-        url: /architecture-scenarios
-
-  - title: "Client Authentication"
-    url: "/client-auth"
-    children:
-
-      - title: "Overview"
-        url: "/client-auth"
-
-      - title: "For Mobile & Desktop Apps"
-        url: "/client-auth/mobile-desktop"
-
-      - title: "For Server-side Web Apps"
-        url: "/client-auth/server-side-web"
-
-      - title: "For Client-side Web Apps"
-        url: "/client-auth/client-side-web"
-
-  - title: "API Authorization"
-    url: "/api-auth"
-    children:
-
-      - title: "Which Flow to Use"
-        url: "/api-auth/which-oauth-flow-to-use"
-
-      - title: "From Server-side Apps"
-        url: "/api-auth/grant/authorization-code"
-
-      - title: "From Mobile Apps"
-        url: "/api-auth/grant/authorization-code-pkce"
-
-      - title: "From Client-side Apps"
-        url: "/api-auth/grant/implicit"
-
-      - title: "From a Service"
-        url: "/api-auth/grant/client-credentials"
-
-      - title: "From Trusted Clients"
-        url: "/api-auth/grant/password"
-
-      - title: "FAQ"
-        url: "/api-auth/faq"
-
-  - title: "Development Lifecycle"
-    url: "/dev-lifecycle"
-    children:
-
-      - title: "Setting Up Environments"
-        url: "/dev-lifecycle/setting-up-env"
-
-      - title: "Running and Developing Locally"
-        url: "/dev-lifecycle/local-testing-and-development"
-
-      - title: "Child Account Request Process"
-        url: "/dev-lifecycle/child-tenants"
-
-  - title: "Rules"
-    url: "/rules"
-    children:
-
-      - title: "Overview"
-        url: "/rules"
-
-      - title: "User Metadata in Rules"
-        url: "/rules/metadata-in-rules"
-
-      - 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: "Extensions"
-    url: "/extensions"
-    children:
-
-      - title: "Overview"
-        url: "/extensions"
-
-      - title: "Creating Extensions"
-        url: "/extensions/custom-extensions"
-
-      - title: "User Import / Export Extension"
-        url: "/extensions/user-import-export"
-
-      - title: "Authorization Extension"
-        url: "/extensions/authorization-extension"
-
-  - title: "Professional Services"
-    url: "/services"
-
-  - title: "Anomaly Detection"
-    url: "/anomaly-detection"
-
-  - title: "Identity Providers"
-    url: "/identityproviders"
-    children:
-
-      - title: "Overview"
-        url: "/identityproviders"
-
-      - title: "Custom Social Connections"
-        url: "/extensions/custom-social-extensions"
-
-      - title: "Database Identity Providers"
-        url: "/connections/database"
-        children:
-
-          - title: "Custom Database"
-            url: "/connections/database/mysql"
-
-          - title: "Migrating Users to Auth0"
-            url: "/connections/database/migrating"
-
-          - title: "Password Strength"
-            url: "/connections/database/password-strength"
-
-          - title: "Password Options"
-            url: "/connections/database/password-options"
-
-          - title: "Rate Limits"
-            url: "/connections/database/rate-limits"
-
-          - title: "Usernames"
-            url: "/connections/database/require-username"
-
-  - title: "Single Sign-On"
-    url: "/sso"
-    children:
-
-      - title: "Overview"
-        url: "/sso"
-
-      - title: "Client-side (Single Page Apps)"
-        url: "/sso/single-page-apps-sso"
-
-      - title: "Server-side (Regular Web Apps)"
-        url: "/sso/regular-web-apps-sso"
-
-  - title: "User Profile"
-    url: "/user-profile"
-    children:
-
-      - title: "Overview"
-        url: "/user-profile"
-        children:
-
-      - title: "Metadata"
-        url: "/metadata"
-        children:
-
-          - title: "Updating with Lock"
-            url: "/metadata/lock"
-
-          - title: "Updating with API"
-            url: "/metadata/management-api"
-
-          - title: "Data Storage Guidance"
-            url: "/user-profile/user-data-storage"
-
-      - title: "Normalized User Profile"
-        url: "/user-profile/normalized"
-
-      - title: "Progressive Profiling"
-        url: "/user-profile/progressive-profiling"
-
-      - title: "Linking User Accounts"
-        url: "/link-accounts"
-        children:
-
-          - title: "User Initiated Account Linking"
-            url: "/link-accounts/user-initiated-linking"
-
-          - title: "Server Side Account Linking"
-            url: "/link-accounts/suggested-linking"
-
-  - title: "Multifactor Authentication"
-    url: "/multifactor-authentication"
-    children:
-
-      - title: "Overview"
-        url: "/multifactor-authentication"
-
-      - title: "Auth0 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: "SMS"
-        url: "/multifactor-authentication#mfa-with-sms"
-
-      - title: "Google Authenticator"
-        url: "/multifactor-authentication/google-authenticator"
-
-      - title: "Duo Security"
-        url: "/multifactor-authentication/duo"
-
-      # - title: "Custom MFA"
-      #   url: "/multifactor-authentication#mfa-using-a-custom-provider"
-
-        # children:
-        #
-        #   - title: "Admin Guide"
-        #     url: "/multifactor-authentication/google-auth/admin-guide"
-        #
-        #   - title: "Dev Guide"
-        #     url: "/multifactor-authentication/google-auth/dev-guide"
-        #
-        #   - title: "User Guide"
-        #     url: "/multifactor-authentication/google-auth/user-guide"
-
-  - title: "Passwordless Authentication"
-    url: "/connections/passwordless"
-    children:
-
-      - title: "Overview"
-        url: "/connections/passwordless"
-
-      - title: "Email Passwordless Authentication"
-        url: "/connections/passwordless/email"
-
-      - title: "SMS Passwordless Authentication"
-        url: "/connections/passwordless/sms"
-
-      - title: "FAQ"
-        url: "/connections/passwordless/faq"
-
-  - title: "Email"
-    url: "/email"
-    children:
-
-      - title: "Overview"
-        url: "/email"
-
-      - title: "Custom Email Handling"
-        url: "/email/custom"
-
-      - title: "Customizing Your Emails"
-        url: "/email/templates"
-
-  - title: "Hosted Pages"
-    url: "/hosted-pages"
-    children:
-
-      - title: "Overview"
-        url: "/hosted-pages"
-
-      - title: "Hosted Login Page"
-        url: "/hosted-pages/login"
-
-      - title: "Hosted Password Reset Page"
-        url: "/hosted-pages/password-reset"
-
-      - title: "Hosted Guardian MFA Page"
-        url: "/hosted-pages/guardian"
-
-      - title: "Hosted Error Pages"
-        url: "/hosted-pages/error-pages"
-
-  - title: "Protocols"
-    url: "/protocols"
-    children:
-      - title: "OAuth 2.0"
-        url: "/protocols/oauth2"
-
-      - title: "OpenID Connect"
-        url: "/protocols/oidc"
-
-      - title: "SAML"
-        url: "/protocols/saml"
-
-      - title: "WS-Fed"
-        url: "/protocols/ws-fed"
-
-      - title: "LDAP"
-        url: "/protocols/ldap"
-
-  - title: "AD Connector"
-    url: "/connector"
-    children:
-
-      - title: "Overview"
-        url: "/connector"
-
-      - title: "Health Monitoring Extension"
-        url: "/extensions/adldap-connector"
-
-  - title: "CMS Plugins"
-    url: "/cms"
-    children:
-
-      - title: "Overview"
-        url: "/cms"
-
-      # - title: "Wordpress"
-      #   url: "/cms#wordpress-plugin"
-      #
-      # - title: "Joomla"
-      #   url: "/cms#joomla-extension"
-
-      - title: "SharePoint"
-        url: "https://github.com/auth0/auth0-sharepoint"
-        forceFullReload: true
-        external: true
-
-  - title: "Client Addons"
-    url: "/addons"
-
+      - title: How You Can Use Auth0
+        url: /get-started/auth0-overview
+      - title: Dashboard Overview
+        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/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: 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/server-api
+        children:
+          - 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/spa-api
+        children:
+          - 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/mobile-api
+        children:
+          - 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: Deployment Options
+        url: /deploy/deploy-options
+      - title: Private Cloud Deployment
+        url: /deploy/private-cloud
+        children:
+          - 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: Troubleshoot Deploy CLI
+            url: /deploy/deploy-cli-tool/troubleshoot-the-deploy-cli-tool
+            hidden: true
+  - title: Login
+    url: /login
+    children:
+      - 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: 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: 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: 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: 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: 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: Authorization Flows
+        url: /flows
+        children:
+          - 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: 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: 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: 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: 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: 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: Customize Translation of Lock Password Options
+            url: /i18n/password-options-translation
+            hidden: true
+  - title: Actions
+    url: /actions 
+    children:
+      - 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: 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: 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: 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: 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
+      - 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: Auth0 Logs to AWS Cloudwatch
+            url: /extensions/export-logs-to-cloudwatch
+            hidden: true
+          - title: Auth0 Logs to Azure Blob Storage
+            url: /extensions/export-logs-to-azure-blob-storage
+            hidden: true
+          - title: Auth0 Logs to Logentries
+            url: /extensions/export-logs-to-logentries
+            hidden: true
+          - title: Auth0 Logs to Loggly
+            url: /extensions/export-logs-to-loggly
+            hidden: true
+          - title: Auth0 Logs to Logstash
+            url: /extensions/export-logs-to-logstash
+            hidden: true
+          - title: Auth0 Logs to Mixpanel
+            url: /extensions/export-logs-to-mixpanel
+            hidden: true
+          - title: Auth0 Logs to Papertrail
+            url: /extensions/export-logs-to-papertrail
+            hidden: true
+          - title: Auth0 Logs to Sumo Logic
+            url: /extensions/auth0-logs-to-sumo-logic
+            hidden: true
+          - title: Auth0 Logs to Splunk
+            url: /extensions/export-logs-to-splunk
+            hidden: true
+  - title: Integrations
+    url: /integrations
+    children:
+      - 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: 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: 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: Streams
+        url: /monitor-auth0/streams
+        children:
+          - title: AWS EventBridge
+            url: /monitor-auth0/streams/stream-logs-to-amazon-eventbridge
+            hidden: true
+          - title: Azure Event Grid
+            url: /monitor-auth0/streams/stream-logs-to-azure-event-grid
+            hidden: true
+          - title: Datadog
+            url: /monitor-auth0/streams/stream-logs-to-datadog
+            hidden: true
+            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
+            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
+            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: Basic Issues
+        url: /troubleshoot/troubleshoot-basic
+        children:
+          - 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: 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: General Security Tips
+        url: /security/tips
+      - title: Security Bulletins
+        url: /security/security-bulletins
+        children:
+          - title: CVE 2018-6874
+            url: /security/security-bulletins/cve-2018-6874
+            hidden: true
+          - title: CVE 2018-6873
+            url: /security/security-bulletins/cve-2018-6873
+            hidden: true
+          - title: CVE 2018-7307
+            url: /security/security-bulletins/cve-2018-7307
+            hidden: true
+          - title: CVE 2017-16897
+            url: /security/security-bulletins/cve-2017-16897
+            hidden: true
+          - title: CVE 2017-17068
+            url: /security/security-bulletins/cve-2017-17068
+            hidden: true
+      - 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: JSON Web Tokens
+            url: /tokens/json-web-tokens
+            hidden: true
+            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: 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: Right to Access, Correct, and Erase Data
+            url: /compliance/gdpr/gdpr-right-to-access-correct-and-erase-data
+            hidden: true
+          - title: Data Minimization
+            url: /compliance/gdpr/gdpr-data-minimization
+            hidden: true
+          - title: Data Portability
+            url: /compliance/gdpr/gdpr-data-portability
+            hidden: true
+          - title: Protect and Secure User Data
+            url: /compliance/gdpr/gdpr-protect-and-secure-user-data
+            hidden: true
+          - title: Redirect Users to Consent Form
+            url: /compliance/gdpr/gdpr-redirect-users-consent-form-hosted-webtask
+            hidden: true
+          - title: Track Consent with Custom UI
+            url: /compliance/gdpr/gdpr-track-consent-with-custom-ui
+            hidden: true
+          - title: Track Consent with Lock
+            url: /compliance/gdpr/gdpr-track-consent-with-lock
+            hidden: true
+      - title: Data Processing
+        url: /compliance/data-processing
+  - title: Best Practices
+    url: /best-practices
+    children:
+      - 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: 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: 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: Managment API Endpoint Rate Limits
+                url: /policies/rate-limit-policy/management-api-endpoint-rate-limits
+                hidden: true
+              - title: Authentication API Endpoint Rate Limits
+                url: /policies/rate-limit-policy/management-api-endpoint-rate-limits
+                hidden: true
+              - title: User/Password Authentication Rate Limits
+                url: /policies/rate-limit-policy/database-connections-rate-limits
+                hidden: true
+          - 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: 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: true
-    children:
-
-      - title: API Tokens
-        url: "/api/management/v2/tokens"
-        forceFullReload: true
-
-      - title: Query String Syntax
-        url: "/api/management/v2/query-string-syntax"
-        forceFullReload: true
-
-      - title: User Search
-        url: "/api/management/v2/user-search"
-        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
 libraries:
-
-  - title: "Overview"
-    url: "/libraries"
-
-  - title: "Lock for Web"
-    url: "/libraries/lock"
-    children:
-
-      - title: "Overview"
-        url: "/libraries/lock"
-
-      - title: "Configuration Options"
-        url: "/libraries/lock/v10/customization"
-
-      - title: "API Reference"
-        url: "/libraries/lock/v10/api"
-
-      - title: "UI Customization"
-        url: "/libraries/lock/v10/ui-customization"
-
-      - title: "v10 Migration Guide"
-        url: "/libraries/lock/v10/migration-guide"
-
-      - title: "Internationalization"
-        url: "/libraries/lock/v10/i18n"
-
-      - title: "Customizing Errors"
-        url: "/libraries/lock/v10/customizing-error-messages"
-
-      - title: "Lock with auth0.js"
-        url: "/libraries/lock/v10/auth0js"
-
-      - title: "Popup Mode"
-        url: "/libraries/lock/v10/popup-mode"
-
-  - title: "Lock for iOS"
-    url: "/libraries/lock-ios"
-    children:
-
-      - title: "Overview"
-        url: "/libraries/lock-ios"
-
-      - title: "Customization"
-        url: "/libraries/lock-ios/customization"
-
-      - title: "Delegation API"
-        url: "/libraries/lock-ios/delegation-api"
-
-      - title: "Logging"
-        url: "/libraries/lock-ios/logging"
-
-      - title: "Objective-C API"
-        url: "/libraries/lock-ios/lock-ios-api"
-
-      - title: "Native Social Auth"
-        url: "/libraries/lock-ios/native-social-authentication"
-
-      - title: "Password Reset"
-        url: "/libraries/lock-ios/password-reset-ios"
-
-      - title: "Save/Refresh JWTs"
-        url: "/libraries/lock-ios/save-and-refresh-jwt-tokens"
-
-      - title: "Sending Auth Params"
-        url: "/libraries/lock-ios/sending-authentication-parameters"
-
-      - title: "SMS in Lock iOS"
-        url: "/libraries/lock-ios/sms-lock-ios"
-
-      - title: "SSO on Mobile Apps"
-        url: "/libraries/lock-ios/sso-on-mobile-apps"
-
-      - title: "Using Lock with Swift"
-        url: "/libraries/lock-ios/swift"
-
-      - title: "TouchID Authentication"
-        url: "/libraries/lock-ios/touchid-authentication"
-
-      - title: "Build Your Own UI"
-        url: "/libraries/lock-ios/use-your-own-ui"
-
-  - title: "Lock for Android"
-    url: "/libraries/lock-android"
-    children:
-
-      - title: "Overview"
-        url: "/libraries/lock-android"
-
-      - title: "Configuration Options"
-        url: "/libraries/lock-android/configuration"
-
-      - title: "Custom Auth Providers"
-        url: "/libraries/lock-android/custom-authentication-providers"
-
-      - title: "Custom Signup Fields"
-        url: "/libraries/lock-android/custom-fields"
-
-      - title: "Custom Theming"
-        url: "/libraries/lock-android/custom-theming"
-
-      - title: "Migration v1 to v2"
-        url: "/libraries/lock-android/migration-guide"
-
-      - title: "Passwordless Auth"
-        url: "/libraries/lock-android/passwordless"
-
-      - title: "Internationalization"
-        url: "/libraries/lock-android/internationalization"
-
-  - title: "Lock vs. Custom UI"
-    url: "/libraries/when-to-use-lock"
-
-  - title: "Auth0 SDK for Web"
-    url: "/libraries/auth0js"
-    children:
-
-      - title: "Auth0.js v8"
-        url: "/libraries/auth0js"
-
-      - title: "Migration Guide v8"
-        url: "/libraries/auth0js/migration-guide"
-
-      - title: "Auth0.js v7"
-        url: "/libraries/auth0js/v7"
-
-  - title: "Auth0 SDK for iOS"
-    url: "/libraries/auth0-swift"
-
-  - title: "Auth0 SDK for Android"
-    url: "/libraries/auth0-android"
-
-appliance:
-
-  - title: "Introduction"
-    url: "/appliance"
-
-  - title: "Support"
-    url: "/appliance/critical-issue"
-    expanded: true
-    children:
-      - title: Enterprise Support
-        url: /onboarding/enterprise-support
-      - title: Critical Issue
-        url: /appliance/critical-issue
-
-  - title: Appliance Planning
-    url: /appliance/appliance-overview
-    expanded: true
+  - title: Overview
+    url: /libraries
+  - title: Auth0 Single Page App SDK
+    url: /libraries/auth0-single-page-app-sdk
+    children:
+      - 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
+      - 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: /appliance/appliance-overview
-      - title: Geographic High-Availability
-        url: /appliance/geo-ha
-      - title: Infrastructure Requirements
-        url: /appliance/infrastructure
-      - title: Roles and Responsibilities
-        url: /appliance/raci
-      - title: Customer Onboarding
-        url: /onboarding/appliance-sprint
-      - title: Private Cloud Requirements
-        url: /appliance/private-cloud-requirements
-
-  - title: "Appliance Administration"
-    url: "/appliance/admin"
-    expanded: true
-    children:
-      - title: Administrator's Manual
-        url: /appliance/admin
-      - title: Dashboard/Configuration Area
-        url: /appliance/dashboard
-      - title: Monitoring Tools
-        url: /appliance/monitoring
-      - 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/geo-ha/disaster-recovery
-      - title: Release Notes
-        url: https://auth0.com/changelog/appliance
-        external: true
-        forceFullReload: true
+        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: 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/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: 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: 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: '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: 'Lab 1: Web Sign-In'
+        url: /identity-labs/lab-1-web-sign-in
+        children:
+          - 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: 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: 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: 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 917e8627b4..513dd8a13a 100644
--- a/config/vars.yml
+++ b/config/vars.yml
@@ -1,3 +1,11 @@
-lock_url: 'https://cdn.auth0.com/js/lock/10.9.1/lock.min.js'
-lock_passwordless_url: 'https://cdn.auth0.com/js/lock-passwordless-2.2.min.js'
-auth0js_url: 'https://cdn.auth0.com/w2/auth0-7.6.1.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.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/snippets/client-platforms/emberjs/use.md b/fr-ca/articles/libraries/lock-ios/_includes/_roadmap.md
similarity index 100%
rename from snippets/client-platforms/emberjs/use.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/acul/files/auth_config.md b/fr-ca/articles/quickstart/backend/acul/files/auth_config.md
new file mode 100644
index 0000000000..63471fea63
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/acul/files/auth_config.md
@@ -0,0 +1,12 @@
+---
+name: auth_config.json
+language: json
+---
+    
+```json
+//auth0-react-samples/Sample-01/src/auth_config.json
+{
+  "domain": "${account.namespace}",
+  "clientId": "${account.clientId}"
+}
+```
diff --git a/fr-ca/articles/quickstart/backend/acul/files/index.md b/fr-ca/articles/quickstart/backend/acul/files/index.md
new file mode 100644
index 0000000000..25b8cf231b
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/acul/files/index.md
@@ -0,0 +1,47 @@
+---
+name: index.tsx
+language: javascript
+---
+    
+```javascript
+import { LoginId } from '@auth0/auth0-acul-js';
+import { useState } from 'react';
+
+export const LoginIdScreen = () => {
+  const loginManager = new LoginId();
+  const [email, setEmail] = useState('');
+
+  return (
+    
        
+      
        
+         setEmail(e.target.value)}
+          className="w-full px-3 py-2 border border-gray-300 rounded-md shadow-sm placeholder-gray-400 focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-blue-500"
+        />
+
+        
+
+        {loginManager.transaction.alternateConnections?.map(({ name, strategy }) => (
+          
+        ))}
+      
        
+    
        
+  );
+};
+
+export default LoginIdScreen
+```
diff --git a/fr-ca/articles/quickstart/backend/acul/files/settings.md b/fr-ca/articles/quickstart/backend/acul/files/settings.md
new file mode 100644
index 0000000000..3ed683eb71
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/acul/files/settings.md
@@ -0,0 +1,34 @@
+---
+name: settings.json
+language: json
+---
+    
+```json
+{
+  "rendering_mode": "advanced",
+  "context_configuration": [
+    "screen.texts"
+  ],
+  "default_head_tags_disabled": false,
+  "head_tags": [
+    {
+      "attributes": {
+        "async": true,
+        "defer": true,
+        "integrity": [
+          "ASSET_SHA"
+        ],
+        "src": "http://127.0.0.1:8080/index.js"
+      },
+      "tag": "script"
+    },
+    {
+      "attributes": {
+        "href": "http://127.0.0.1:8080/index.css",
+        "rel": "stylesheet"
+      },
+      "tag": "link"
+    }
+  ]
+}
+```
diff --git a/fr-ca/articles/quickstart/backend/acul/interactive.md b/fr-ca/articles/quickstart/backend/acul/interactive.md
new file mode 100644
index 0000000000..4fb2d96313
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/acul/interactive.md
@@ -0,0 +1,115 @@
+---
+title: Build a Login ID screen using ACUL
+description: Learn how to build a Login screen using ACUL
+interactive:  true
+files:
+ - files/settings
+ - files/auth_config
+ - files/index
+github:
+  path: https://github.com/auth0-samples/auth0-react-samples/tree/master/Sample-01
+locale: fr-CA
+---
+
+# Build a Login ID screen using ACUL
+
+
+
        `
        
+
+## 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.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : 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.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : 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.
        Si vous suivez notre exemple de projet, définissez cette URL comme suit : http://localhost:3000.
        
+
+## Configure ACUL for Login ID screen {{{ data-action="code" data-code="settings.json" }}}
+
+
+
        Use Auth0 CLI to enable ACLU Login ID screen in your tenant. 
+
+
+
+In the root directory of your project, save the settings.json file.
        Enable ACUL by running the following command in your terminal:
        auth0 ul customize --rendering-mode advanced --prompt login-id --screen login-id --settings-file ./settings.json
+
+
        
+
+
        Development Setup: This example is using localhost (127.0.0.1:8080) for development. 
        For production, you will need to update these URLs to point to your CDN or static hosting service.
        
+
+## Initiate Universal Login {{{ data-action="code" data-code="auth_config.json" }}}
+
+
+
        Use one of the sample apps provided by Auth0 to initiate Universal Login
        In the root folder of your project, clone the Auth0 sample application using the following command:
+
+
+
+
        git clone https://github.com/auth0-samples/auth0-react-samples
+
+
        
+
+
        Change directory to the auth0-react-samples/Sample-01 folder and install the sample application using the following command:
        cd auth0-react-samples/Sample-01
+
+npm install
+
+
        
+
+
        Change directory  to the auth0-react-samples/Sample-01/src folder and add the auth_config.json file. Edit the file to add your tenant's Custom Domain.
        Run the application
        npm run dev
+
+
        
+
+
        ACUL Login ID screen Step 2 - Checkpoint 
        1. Open your application (default: http://localhost:3000)
        2. Select the Log In button on the sample app
        3. You should be redirected to your Auth0 domain
        After selecting Log In, you should see a blank page. 
        This is expected! It means Auth0 is trying to load your custom UI assets, which we have not created yet. 
        
+
+  
        
+
+  
        If you see the default Auth0 page instead of a blank page:
        1. Check if your custom domain is properly configured.
        2. Ensure your application is using the custom domain.
        
+
+  
        
+
+
        
+
+ 
        
+
+
        
+
+## Build a custom interface for login-id screen {{{ data-action="code" data-code="index.tsx" }}}
+
+
+
        Run a single-page application to build custom login screens. 
        Configure the Boilerplate application
        1. In the root folder of your project, open a new terminal and clone the Auth0 boilerplate application using the following command:
        git clone https://github.com/auth0-samples/auth0-acul-react-boilerplate
+
+
        
+
+
        2. Change directory to the auth0-acul-react-boilerplate folder and install the application and the ACUL JS SDK.
        // open the directory where you git clone the boilerplate
+
+cd auth0-acul-react-boilerplate && npm i
+
+
+
+// Install the ACUL JS SDK
+
+npm install @auth0/auth0-acul-js
+
+
        
+
+
        3. Build the application
        npm run build
+
+
        
+
+
        4. Serve the assets
        npx http-server dist -p 8080
+
+
        
+
+
        The assets are served from localhost during development. 
        For production, you'll need to serve these assets from a CDN or static hosting service.
        ACUL Login ID screen quickstart step 4 checkpoint 
        After selecting Log In, you are greeted with a “Hello World” page. 
        
+
+  
        
+
+  
        Make sure to have installed the ACUL JS SDK after installing the boilerplate application.
        
+
+  
        Build the ACUL Login ID screen 
        Change directory to the auth0-acul-react-boilerplate/src/screens/loginId/ and edit the index.tsx file.
        Rebuild the application with the following command:
        npm run build
+
+
        
+
+
        ACUL Login ID screen quickstart step 4 rebuild the app checkpoint 
        Select Log In. 
        You should now see a customized login page as shown below:
        
+
+  
        
+
+  
        
+
+  
        
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..481e4a0979
--- /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: https://github.com/auth0-samples/auth0-aspnetcore-webapi-samples/tree/master/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 ancienne, à l’aide du package Microsoft.AspNetCore.Authentication.JwtBearer.
        Si vous n'avez pas encore créé d’API dans votre tableau 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.
        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 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)
        
+
+## Installer des 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" }}}
+
+
+
        Configurer le logiciel médiateur d’authentification en le configurant 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 du logiciel médiateur au pipeline de 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 terminal, 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 spécifiques, 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 token 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 Identifiants client. Pour ce faire, enregistrez une Application de communication entre machines et incluez les valeurs suivantes à votre requête :
        • Identificateur client comme paramètre client_id .
        • Secret client comme paramètre client_secret .
        • Identificateur 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 requête
        
+
+
        
+
+  
        
+
+
+
+  
+
+  
        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 terminaisonAPI 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 (Autorisation) 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.
        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 .
        
+
+  
        
+
+  
        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/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..f7bdce9932
--- /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: https://github.com/auth0-samples/auth0-django-api/tree/master/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..4665fbb325
--- /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: https://github.com/auth0-samples/auth0-golang-api-samples/tree/master/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’identifiant d’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 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 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)
        
+
+## Installer des 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()
        
+
+
+
+
        Guide 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 .
        
+
+  
        
+
+  
        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/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..677396484d
--- /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: https://github.com/auth0-samples/auth0-spring-security5-api-sample/tree/master/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’identifiant d’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 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.
        
+
+## 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 des 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 de 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 requêtes non authentifiées
        • GET /api/private : disponible pour les requêtes authentifiées contenant un jeton d’accès sans permission supplémentaire
        • GET /api/private-scoped : disponible pour les requêtes 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 Protect API Endpoints (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, 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 disponible à l’adresse http://localhost:3010/. Pour en savoir plus sur la manière de tester et d’utiliser votre API, consultez l’article Utiliser votre API.
        
+
+  
        
+
+  
        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/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..ad7ab0c504
--- /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 montre comment intégrer Auth0 avec une nouvelle (ou existante) application Laravel 9 ou 10.
+interactive:  true
+files:
+ - files/routes/api
+github:
+  path: https://github.com/auth0-samples/laravel/tree/7.x/sample
+locale: fr-CA
+---
+
+# Ajouter l’autorisation à votre application Laravel
+
+
+
        La trousse SDK Laravel 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 montre 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.
        
+
+## 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-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 pour la trousse SDK pour votre application :
        php artisan vendor:publish --tag auth0
+
+
        
+
+
        
+
+## Configuration de la trousse SDK
+
+
+
        Exécuter la commande suivante à partir du répertoire de votre projet pour télécharger le CLI Auth0 :
        curl -sSfL https://raw.githubusercontent.com/auth0/auth0-cli/main/install.sh | sh -s -- -b .
+
+
        
+
+
        Ensuite, authentifiez le 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 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 électronique 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 la Management API Auth0. 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 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.
        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 la 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 guide rapide, cependant, vous pouvez simplement utiliser un jeton d’accès à partir de la vue « 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é.
        Guide 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'
        
+
+  
        
+
+  
        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.
        
+
+  
        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 support de la Management API est intégré à la trousse SDK Laravel Auth0, vous permettant d’interagir avec la 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..e3b612a992
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/nodejs/interactive.md
@@ -0,0 +1,53 @@
+---
+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: https://github.com/auth0-samples/auth0-express-api-samples/tree/master/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 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.
        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 le logiciel médiateur {{{ data-action="code" data-code="server.js#1:10" }}}
+
+
+
        Configurez express-oauth2-jwt-bearer avec votre domaine et votre identificateur API.
        Le logiciel médiateur 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.
        Le logiciel médiateur 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 de 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://${account.namespace}/api_path \
+
+  --header 'authorization: Bearer YOUR_ACCESS_TOKEN_HERE'
+
+
        
+
+
        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/publicest 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 .
        
+
+  
        
+
+  
        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/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..0e00587300
--- /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: https://github.com/auth0-samples/auth0-php-api-samples/tree/main/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.
        
+
+## Configurer 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.
        Consultez un exemple d’application si vous préférez explorer une configuration complète.
        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 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
        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 permet d’orienter le comportement de la trousse SDK en fonction du cas d’utilisation de votre application. Dans ce cas, vous souhaitez définir 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 sous vos Application Settings (Paramètres d’application) dans le champ Domain (Domaine). Si vous utilisez un domaine personnalisé, définissez-le 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 sous vos Application Settings (Paramètres d’application) dans le champ Client ID (ID client).
        • clientSecret: Le secret de l’application Auth0 que vous avez créée plus tôt dans ce guide rapide. Le secret client se trouve dans Auth0 Dashboard sous vos Application Settings (Paramètres d’application) dans le champ Client Secret (Secret client).
        • audience: 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 SDK Auth0 est maintenant 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## Écouter 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 Auth0 PHP, 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 spécifique 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..209c146e0a
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/python/interactive.md
@@ -0,0 +1,54 @@
+---
+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: https://github.com/auth0-samples/auth0-python-api-samples/tree/master/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'
+
+
        
+
+
        
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..36a3334922
--- /dev/null
+++ b/fr-ca/articles/quickstart/backend/rails/interactive.md
@@ -0,0 +1,74 @@
+---
+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: https://github.com/auth0-samples/auth0-rubyonrails-api-samples/tree/master/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’identifiant d’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 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 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 demande.
        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 le concern Secure dans votre ApplicationController {{{ data-action="code" data-code="app/controllers/application_controller.rb" }}}
+
+
+
        En ajoutant le concern 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 gérer 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
        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'
+
+
        
+
+
        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 .
        
+
+  
        
+
+  
        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/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..06208724a3
--- /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: https://github.com/auth0-samples/auth0-aspnet-owin-webapi-samples/tree/master/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’identifiant d’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 du Auth0 Dashboard. L’exemple suivant utilise la permission read:messages.
        Auth0 Dashboard> Applications > APIs (API) > [Specific API (API précise)] > Onglet Permissions (Autorisations)
        
+
+## Installer des dépendances
+
+
+
        Installez le NuGetPackage Microsoft.Owin.Security.Jwt. Ce package contient le logiciel médiateur 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 le logiciel médiateur {{{ data-action="code" data-code="Startup.cs" }}}
+
+
+
        Allez dans la méthode de Configuration de votre classe de 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 demande est valide; cependant, il n’inclut pas encore de mécanisme pour vérifier que le jeton a une 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 requêtes suivantes :
        • GET /api/public : disponible pour les requêtes non authentifiées.
        • GET /api/private : disponible pour les requêtes authentifiées contenant un jeton d’accès sans permission supplémentaire.
        • GET /api/private-scoped : disponible pour les requêtes authentifiées contenant un jeton d’accès dont la permission read:messages est accordée.
        Le logiciel médiateur 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 sécuriser 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 .
        
+
+  
        
+
+  
        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/fr-ca/articles/quickstart/config.yml b/fr-ca/articles/quickstart/config.yml
new file mode 100644
index 0000000000..a99856f831
--- /dev/null
+++ b/fr-ca/articles/quickstart/config.yml
@@ -0,0 +1,4 @@
+author:
+  name: Auth0
+  email: support@auth0.com
+  community: false
diff --git a/fr-ca/articles/quickstart/native/_includes/_authorization-create-rule.md b/fr-ca/articles/quickstart/native/_includes/_authorization-create-rule.md
new file mode 100644
index 0000000000..ef210437db
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/_includes/_authorization-create-rule.md
@@ -0,0 +1,11 @@
+First, you will create a rule that assigns users to either an `admin` role, or a single `user` role. Go to the [New Rule](${manage_url}/#/rules/new) page on the Auth0 dashboard and select the **Set Roles To A User** template, under **Access Control**.
+
+By default, this rule will assign the user an `admin` role if their email contains `@example.com`. Otherwise, they will be assigned a regular `user` role.
+
+You can modify this line in the default script to change the domain name to one suitable for your setup:
+
+`if (user.email.indexOf('@example.com') > -1)`
+
+::: note
+You can set roles other than `admin` and `user` or customize the rule as needed.
+:::
diff --git a/fr-ca/articles/quickstart/native/_includes/_authorization-introduction.md b/fr-ca/articles/quickstart/native/_includes/_authorization-introduction.md
new file mode 100644
index 0000000000..a96342dad8
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/_includes/_authorization-introduction.md
@@ -0,0 +1,5 @@
+Many identity providers will supply access claims, like roles or groups, with the user. You can request these in the token by setting `scope: openid roles` or `scope: openid groups`. However, not every identity provider supplies this type of information. Fortunately, Auth0 has an alternative, which is to create a rule for assigning different roles to different users.
+
+::: note
+This tutorial assumes that you have already completed the [rules tutorial](${ruleslink}) and that you know how to implement a basic rule in your app.
+:::
diff --git a/fr-ca/articles/quickstart/native/_includes/_callback-url-introduction.md b/fr-ca/articles/quickstart/native/_includes/_callback-url-introduction.md
new file mode 100644
index 0000000000..8b41d237de
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/_includes/_callback-url-introduction.md
@@ -0,0 +1,9 @@
+
+
+A callback URL is a URL in your application where Auth0 redirects the user after they have been authenticated. Auth0 adds parameters to the callback URL, including a token. 
+
+Callback URLs can be manipulated by attackers. For security, add your application's URL to the **Allowed Callback URLs** field in your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). 
+
+If you do not add your application's URL to the list of Allowed Callback URLs, your users will see a mismatch error when they try to log in.
+
+![Callback error](/media/articles/angularjs/callback_error.png)
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/native/_includes/_calling_api_create_api.md b/fr-ca/articles/quickstart/native/_includes/_calling_api_create_api.md
new file mode 100644
index 0000000000..755ffb537d
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/_includes/_calling_api_create_api.md
@@ -0,0 +1,7 @@
+## Create an Auth0 API
+
+In the [APIs section](${manage_url}/#/apis) of the Auth0 dashboard, click **Create API**. Provide a name and an identifier for your API.
+You will use the identifier later when you're preparing the Web Authentication.
+For **Signing Algorithm**, select **RS256**.
+
+![Create API](/media/articles/api-auth/create-api.png)
diff --git a/fr-ca/articles/quickstart/native/_includes/_calling_api_create_scope.md b/fr-ca/articles/quickstart/native/_includes/_calling_api_create_scope.md
new file mode 100644
index 0000000000..6ea9af9d0b
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/_includes/_calling_api_create_scope.md
@@ -0,0 +1,11 @@
+## Add a Scope
+
+By default, the Access Token does not contain any authorization information. To limit access to your resources based on authorization, you must use scopes. Read more about scopes in the [scopes documentation](/scopes).
+
+In the Auth0 dashboard, in the [APIs section](${manage_url}/#/apis), click **Scopes**. Add any scopes you need to limit access to your API resources.
+
+::: note
+You can give any names to your scopes. A common pattern is `:`. The example below uses the name `read:messages` for a scope.
+:::
+
+![create scope](/media/articles/api-auth/create-scope.png)
diff --git a/fr-ca/articles/quickstart/native/_includes/_cordova_setup.md b/fr-ca/articles/quickstart/native/_includes/_cordova_setup.md
new file mode 100644
index 0000000000..2c03b6254d
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/_includes/_cordova_setup.md
@@ -0,0 +1,30 @@
+To integrate Auth0 in a hybrid Cordova application, you can use the `@auth0/cordova` package available on npm. This package provides an interface with Cordova which allows you to use the [Proof Key for Code Exchange (PKCE)](https://tools.ietf.org/html/rfc7636) spec. PKCE is recommended for native and hybrid applications to mitigate the threat of authorization code interception.
+
+::: note
+Please note that PKCE authentication requires testing on either an emulated or real device. Attempting authentication when testing in the browser will fail because PKCE requires a device browser.
+:::
+
+<%= include('../../../_includes/_new_app') %>
+
+<%= include('../../../_includes/_callback_url') %>
+
+The **Callback URL** to be used for your application includes your app's package ID which is found in the `config.xml` file for your app.
+
+Go to the Application Settings section in your Auth0 dashboard and set your **Callback URL** in the **Allowed Callback URLs** box.
+
+```bash
+# replace YOUR_PACKAGE_ID with your app package ID
+YOUR_PACKAGE_ID://${account.namespace}/cordova/YOUR_PACKAGE_ID/callback
+```
+
+Add `file` as an allowed origin to the **Allowed Origins (CORS)** box.
+
+```bash
+file://*
+```
+
+Lastly, be sure that the **Application Type** for your application is set to **Native** in its settings.
+
+${snippet(meta.snippets.dependencies)}
+
+${snippet(meta.snippets.setup)}
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/native/_includes/_create_application.md b/fr-ca/articles/quickstart/native/_includes/_create_application.md
new file mode 100644
index 0000000000..a91678b6e6
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/_includes/_create_application.md
@@ -0,0 +1,3 @@
+## Create an application
+
+Create a new application in your [Auth0 dashboard](${manage_url}/#/application). For **Type**, select **Native**.
\ No newline at end of file
diff --git a/fr-ca/articles/quickstart/native/_includes/_dotnet-oidc-client-configuration.md b/fr-ca/articles/quickstart/native/_includes/_dotnet-oidc-client-configuration.md
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/fr-ca/articles/quickstart/native/_includes/_facebook_login_howto.md b/fr-ca/articles/quickstart/native/_includes/_facebook_login_howto.md
new file mode 100644
index 0000000000..9a6db5a92e
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/_includes/_facebook_login_howto.md
@@ -0,0 +1,62 @@
+## Set up the “Continue with Facebook” button
+
+This guide will help you add authentication with Auth0 to the application you built in the first step.
+
+### Request Facebook permissions
+
+Your application is already able to sign in with Facebook. However, to ensure you have a rich user profile, you need to update the permissions with which the Facebook Login Button was set up.
+
+${snippet(meta.snippets.facebook_button_permissions)}
+
+Now, to kick off the authentication process with Auth0, create a new method in which you will prepare the payload to be sent. 
+
+${snippet(meta.snippets.facebook_button_config)}
+
+## Integrate Facebook
+
+When you sign in with Facebook at Auth0, the backend will perform some checks in the background to ensure the user is who they say they are. To achieve this, it needs to be provided with a Session Access Token. 
+
+Furthermore, if a user needs to be created on Auth0 to represent this Facebook user, the backend will require some of their information, such as their name, last name, and email. The email, if provided, will be **flagged as non-verified** on the Auth0 user profile.
+
+To obtain the Session Access Token and the user profile, two additional requests need to be made against the Facebook API.
+
+### Fetch Facebook session Access Token
+
+Make a new GET request against the Facebook API's `/oauth/access_token` endpoint.
+Use the following query parameters:
+- `grant_type`: `fb_attenuate_token`.
+- `fb_exchange_token`: the access token received upon login.
+- `client_id`: your App ID. This value comes from the Facebook Developer's dashboard and should already be in use in your application if you have integrated Facebook Login successfully.
+
+Put the logic from this step in its own method. You will be calling it later from the previously-added method.
+
+${snippet(meta.snippets.facebook_fetch_session_token)}
+
+### Fetch Facebook user profile
+
+Now make another GET request, just like in the step above. The endpoint path will be the User ID value from the Facebook login result (for example, `/904636746222815`).
+Use the following parameters:
+- `access_token`: the access token received upon login.
+- `fields`: the fields from the user profile that you'd like to get back in the response. These are directly tied to the Facebook Login Button permissions that were configured at the beginning. When a permission is optional, the user must first consent to give access to it. For the purpose of signing up a user at Auth0, their full name and email will suffice. 
+
+${snippet(meta.snippets.facebook_fetch_profile)}
+
+## Integrate Auth0
+
+Now that the required artifacts have been obtained, you are ready to trade them for Auth0 user credentials, such as the ID and Access Tokens. But first, you must set up the Auth0 SDK to make that last request.
+
+### Get your application keys
+
+Go to the **Applications** section of the [Auth0 Dashboard](https://manage.auth0.com/) and select the existing application in which you enabled **Sign in with Facebook**. If you need help with this step, please check the requirements section at the top of this article.
+
+Copy the **Domain** and **Client ID** values from the application settings page. These are required by the SDK.
+
+${snippet(meta.snippets.facebook_app_credentials)}
+
+### Install the Auth0 SDK
+
+${snippet(meta.snippets.facebook_install_auth0_sdk)}
+
+### Exchange the received data for Auth0 tokens
+
+${snippet(meta.snippets.facebook_token_exchange)}
diff --git a/fr-ca/articles/quickstart/native/_includes/_facebook_login_prerequisites.md b/fr-ca/articles/quickstart/native/_includes/_facebook_login_prerequisites.md
new file mode 100644
index 0000000000..ae286d7f70
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/_includes/_facebook_login_prerequisites.md
@@ -0,0 +1,6 @@
+This tutorial describes how to implement login with the [Facebook SDK](https://developers.facebook.com/docs/).
+​
+## Before You Start
+​
+- Install and configure the [Facebook Login SDK](https://developers.facebook.com/docs/facebook-login/). You’ll also go through the process of creating a Facebook app in [https://developers.facebook.com](https://developers.facebook.com). **When you finish this step, you should have a mobile app running with Facebook Login integrated.**  
+- Configure your Auth0 application in the dashboard to use Facebook Native Sign In. See [Add Facebook Login to Native Apps](/connections/nativesocial/facebook). **When you finish this step, your application will be able to implement Facebook Native Login.**
diff --git a/fr-ca/articles/quickstart/native/_includes/_getting_started.md b/fr-ca/articles/quickstart/native/_includes/_getting_started.md
new file mode 100644
index 0000000000..23cbcdbe4f
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/_includes/_getting_started.md
@@ -0,0 +1,7 @@
+::: note
+**New to Auth?** Learn [How Auth0 works](/overview), how it [integrates with Native Applications](/architecture-scenarios/application/mobile-api) and which [protocol](/api-auth/grant/authorization-code-pkce) it uses.
+:::
+
+<%= include('../../../_includes/_new_app') %>
+
+
diff --git a/fr-ca/articles/quickstart/native/_includes/_ionic_setup.md b/fr-ca/articles/quickstart/native/_includes/_ionic_setup.md
new file mode 100644
index 0000000000..9638a40d51
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/_includes/_ionic_setup.md
@@ -0,0 +1,57 @@
+To integrate Auth0 in a hybrid Ionic app, you can use the `@auth0/cordova` package available on npm. This package provides an interface with Cordova which allows you to use the [Proof Key for Code Exchange (PKCE)](https://tools.ietf.org/html/rfc7636) spec. PKCE is recommended for native and hybrid applications to mitigate the threat of authorization code interception.
+
+::: note
+Please note that PKCE authentication requires testing on either an emulated or real device. Attempting authentication when testing in the browser will fail because PKCE requires a device browser.
+:::
+
+<%= include('../../../_includes/_new_app') %>
+
+<%= include('../../../_includes/_callback_url') %>
+
+The **Callback URL** to be used for your application includes your app's package ID which is found in the `config.xml` file for your app.
+
+Go to the Application Settings section in your Auth0 dashboard and set your **Callback URL** in the **Allowed Callback URLs** box.
+
+```bash
+# replace YOUR_PACKAGE_ID with your app package ID
+YOUR_PACKAGE_ID://${account.namespace}/cordova/YOUR_PACKAGE_ID/callback
+```
+
+Add `file` as an allowed origin to the **Allowed Origins (CORS)** box.
+
+```bash
+file://*
+```
+
+Lastly, be sure that the **Application Type** for your application is set to **Native** in the application settings.
+
+## Install the Dependencies
+
+The required dependencies for using Auth0 in an Ionic application are **auth0.js** and **auth0-cordova**. Install them with npm or yarn.
+
+```bash
+# installation with npm
+npm install auth0-js @auth0/cordova --save
+
+# installation with yarn
+yarn add auth0-js @auth0/cordova
+```
+
+## Add Cordova Plugins
+
+You must install the `SafariViewController` plugin from Cordova to be able to use Universal Login. The downloadable sample project already has this plugin added, but if you are embedding Auth0 in your own application, install the plugin via the command line.
+
+```bash
+ionic cordova plugin add cordova-plugin-safariviewcontroller
+```
+
+The `CustomURLScheme` plugin from Cordova is also required to handle redirects properly. The sample project has it already, but if you're adding Auth0 to your own project, install this plugin as well.
+
+```bash
+# replace YOUR_PACKAGE_ID with your app identifier
+ionic cordova plugin add cordova-plugin-customurlscheme --variable URL_SCHEME={YOUR_PACKAGE_ID} --variable ANDROID_SCHEME={YOUR_PACKAGE_ID} --variable ANDROID_HOST=${account.namespace} --variable ANDROID_PATHPREFIX=/cordova/{YOUR_PACKAGE_ID}/callback
+```
+
+## Modify config.xml
+
+Add `` to your config.xml. This will allow the Auth0 dialog to properly redirect back to your app.
diff --git a/fr-ca/articles/quickstart/native/_includes/_ios_config.md b/fr-ca/articles/quickstart/native/_includes/_ios_config.md
new file mode 100644
index 0000000000..d5e5a479a9
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/_includes/_ios_config.md
@@ -0,0 +1,62 @@
+
+
+## Add Auth0 Credentials
+
+You will need some details about this application to communicate with Auth0. You can get these details from the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) in the Auth0 dashboard.
+
+You need the following information: 
+* **Client ID**
+* **Domain**
+
+::: note
+If you download the sample from the top of this page, these details are filled out for you.
+:::
+
+Add your credentials in `Auth0.plist`. If the file does not exist in your project yet, create one with the information below ([Apple documentation on Property List Files](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html)):
+
+```xml
+
+
+
+
+
+
+  ClientId
+  ${account.clientId}
+  Domain
+  ${account.namespace}
+
+
+```
+
+<%= include('../../../_includes/_callback_url') %>
+
+In your application's `Info.plist` file, register your iOS Bundle identifier as a custom scheme:
+
+```xml
+
+
+CFBundleURLTypes
+
+    
+        CFBundleTypeRole
+        None
+        CFBundleURLName
+        auth0
+        CFBundleURLSchemes
+        
+            $(PRODUCT_BUNDLE_IDENTIFIER)
+        
+    
+
+```
+
+::: note
+If your `Info.plist` file is not in the format shown above, you can right-click `Info.plist` in Xcode and select **Open As** > **Source Code**.
+:::
+
+Go to your [Dashboard Settings](${manage_url}/#/applications/${account.clientId}/settings) and make sure that the **Allowed Callback URLs** field contains the following callback URL:
+
+```text
+{PRODUCT_BUNDLE_IDENTIFIER}://${account.namespace}/ios/{PRODUCT_BUNDLE_IDENTIFIER}/callback
+```
diff --git a/fr-ca/articles/quickstart/native/_includes/_ios_dependency_centralized.md b/fr-ca/articles/quickstart/native/_includes/_ios_dependency_centralized.md
new file mode 100644
index 0000000000..86e62af190
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/_includes/_ios_dependency_centralized.md
@@ -0,0 +1,49 @@
+
+
+## Install Dependencies
+
+### Cocoapods
+
+If you are using [Cocoapods](https://cocoapods.org), add this line to your `Podfile`:
+
+```ruby
+pod 'Auth0', '~> 1.0'
+```
+
+Then run `pod install`.
+
+::: note
+For more information on Cocoapods, check [their official documentation](https://guides.cocoapods.org/using/getting-started.html).
+:::
+
+### Carthage
+
+If you are using [Carthage](https://github.com/Carthage/Carthage), add the following line to your `Cartfile`:
+
+```ruby
+github "auth0/Auth0.swift" ~> 1.0
+```
+
+Then run `carthage bootstrap`.
+
+::: note
+For more information about Carthage usage, check [their official documentation](https://github.com/Carthage/Carthage#if-youre-building-for-ios-tvos-or-watchos).
+:::
+
+### SPM
+
+If you are using the Swift Package Manager, open the following menu item in Xcode:
+
+**File > Add Packages...**
+
+In the **Search or Enter Package URL** search box enter this url: 
+
+```text
+https://github.com/auth0/Auth0.swift.git
+```
+
+Then select the dependency rule and press **Add Package**.
+
+::: note
+For further reference on SPM, check [its official documentation](https://developer.apple.com/documentation/swift_packages/adding_package_dependencies_to_your_app).
+:::
diff --git a/fr-ca/articles/quickstart/native/_includes/_ios_link_accounts.md b/fr-ca/articles/quickstart/native/_includes/_ios_link_accounts.md
new file mode 100644
index 0000000000..956318d9bb
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/_includes/_ios_link_accounts.md
@@ -0,0 +1,6 @@
+## Link the Accounts
+
+Now, you can link the accounts. To do this, you need the following values: 
+- `id`: the logged-in user's ID (see `profile.sub`)
+- `accessToken`: a Management API access token for the saved account the user initially logged in to; must have the `update:current_user_identities` scope
+- `otherUserToken`: the ID Token for the second account received in the last login response
diff --git a/fr-ca/articles/quickstart/native/_includes/_ios_unlink_accounts.md b/fr-ca/articles/quickstart/native/_includes/_ios_unlink_accounts.md
new file mode 100644
index 0000000000..c4c1ea1510
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/_includes/_ios_unlink_accounts.md
@@ -0,0 +1,5 @@
+## Unlink the Accounts
+
+To unlink the accounts, you need to specify the following: 
+* `id`: the logged-in user's ID (see `profile.sub`)
+* `userId` and `provider`: the values in the `identity` object you want to unlink
diff --git a/fr-ca/articles/quickstart/native/_includes/_new_app.html b/fr-ca/articles/quickstart/native/_includes/_new_app.html
new file mode 100644
index 0000000000..6b84b0d4e5
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/_includes/_new_app.html
@@ -0,0 +1,5 @@
+<% if (account.userName) { %>
+  
        Fetch your credentials (Domain, Client ID, and Client Secret) from your dashboard and store somewhere safe. You will need them while configuing Angular in your application. The sample is configured with your `Default App` credentials if you prefer to start with having a look at it.
        
+<% } else { %>
+  
        Create an Auth0 account (or login) and an authentication application instance from your dashboard. Once you create an app, you'll be provided with credentials (Domain, Client ID, and Client Secret) which should be stored somewhere safe (do not commit this information to your git repo!). You can start be downloading the sample after you login as it is configured with your `Default App` credentials
        
+<% } %>
diff --git a/fr-ca/articles/quickstart/native/_includes/_new_app_no_sample.html b/fr-ca/articles/quickstart/native/_includes/_new_app_no_sample.html
new file mode 100644
index 0000000000..039e33abfb
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/_includes/_new_app_no_sample.html
@@ -0,0 +1,5 @@
+<% if (account.userName) { %>
+  
        Get your credentials (Domain, Client ID, and Client Secret) from the dashboard. Be sure to select Native as the Application Type. 
+<% } else { %>
+  
        Create an Auth0 account (or login) and add an authentication application instance from the dashboard. Once you create your application, you will be provided with credentials (Domain, Client ID, and Client Secret) which should be stored somewhere safe (do not commit this information to your git repo!). Be sure to select Native as the Application Type.
+<% } %>
diff --git a/fr-ca/articles/quickstart/native/_includes/_profile-metadata-explanation.md b/fr-ca/articles/quickstart/native/_includes/_profile-metadata-explanation.md
new file mode 100644
index 0000000000..c5503ba31a
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/_includes/_profile-metadata-explanation.md
@@ -0,0 +1 @@
+Auth0 allows you to store user information that has not come from the identity provider as metadata. There are two types of metadata, **user_metadata** and **app_metadata**. For more information, see: [Metadata](/users/concepts/overview-user-metadata).
\ No newline at end of file
diff --git a/articles/native-platforms/_includes/_rules-create-section.md b/fr-ca/articles/quickstart/native/_includes/_rules-create-section.md
similarity index 100%
rename from articles/native-platforms/_includes/_rules-create-section.md
rename to fr-ca/articles/quickstart/native/_includes/_rules-create-section.md
diff --git a/articles/native-platforms/_includes/_rules-introduction.md b/fr-ca/articles/quickstart/native/_includes/_rules-introduction.md
similarity index 100%
rename from articles/native-platforms/_includes/_rules-introduction.md
rename to fr-ca/articles/quickstart/native/_includes/_rules-introduction.md
diff --git a/articles/native-platforms/_includes/_rules-test-result-intro.md b/fr-ca/articles/quickstart/native/_includes/_rules-test-result-intro.md
similarity index 100%
rename from articles/native-platforms/_includes/_rules-test-result-intro.md
rename to fr-ca/articles/quickstart/native/_includes/_rules-test-result-intro.md
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..715af1d903
--- /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 fonction native Facebook Login (Connexion Facebook).
+interactive:  true
+files:
+ - files/performLogin + SimpleCallback
+ - files/onCreate
+ - files/fetchSessionToken
+ - files/fetchUserProfile
+ - files/exchangeTokens
+ - files/performLogin
+github:
+  path: https://github.com/auth0-samples/auth0-android-native-social-sample/tree/master/00-login-facebook
+locale: fr-CA
+---
+
+# Android – Connexion Facebook
+
+
+
        Ce tutoriel explique comment ajouter la connexion utilisateur à une application Android à l’aide de la fonction native Facebook Login (Connexion Facebook). Nous vous recommandons de vous connecter pour suivre ce guide rapide avec les exemples configurés pour votre compte.
        Configuration 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
        Configurez votre application Auth0 dans Dashboard pour utiliser la fonction Facebook Login (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 native Facebook Login (Connexion Facebook).
        
+
+## 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 électronique 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" }}}
+
+
+
        Pour lancer le processus d’authentification avec Auth0, créez une nouvelle méthode dans laquelle vous préparerez la charge utile à envoyer.
        Vous utiliserez une interface simple pour gérer nos callbacks 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 callback de connexion à Facebook.
        
+
+## Intégrer Facebook
+
+
+
        Lorsque vous vous connectez à Facebook avec Auth0, l'ordinateur 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, l'ordinateur 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’identificateur 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 (par exemple, /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’identificateur 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 du 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 Domain (Domaine) et Client ID (Identificateur 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 aux paramètres fictifs dans le 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 paramètres fictifs du manifeste.
        
+
+## Échange des 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 programme 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..d61de9c19a
--- /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: https://github.com/auth0-samples/auth0-android-sample/tree/master/00-Login-Kt
+locale: fr-CA
+---
+
+# Ajouter une connexion à votre application Android
+
+
+
        
+
+## Configurer Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. Vous allez configurer l’authentification pour votre projet dans l’application Auth0.
        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 vous intégrer. Dans Auth0, il est attribué à chaque application un identificateur 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 vous permettra de gérer vos applications.
        Consultez un exemple d’application si vous préférez explorer une configuration complète.
        Configuration des Callback URL
        Une Callback URL 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 espaces réservés dans le manifeste. Auth0 utilise des espaces réservés en interne pour définir un intent-filter, qui capture la Callback URL d’authentification. Vous devez définir le domaine du locataire Auth0 et le schéma de la Callback URL.
        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: identificateur de l’application Auth0 que vous avez configurée précédemment dans ce guide rapide. Vous pouvez la trouver dans Auth0 Dashboard, dans la rubrique des paramètres de votre application, dans le champ Client ID..
        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 l’espace réservé 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é, la Callback URL est appelée. La Callback URL contient le résultat final du processus d’authentification.
        Guide 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 Android vous redirige vers la page de 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 encore un réseau social.
        Une fois l’opération terminée, vérifiez qu’Auth0 vous redirige vers votre application.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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 paramètre fictif 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.
        Guide 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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 électronique 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 callback onSuccess renvoie les informations du profil utilisateur.
        
+
+  
        
+
+  
        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/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..31af025984
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/device/interactive.md
@@ -0,0 +1,561 @@
+---
+title: Flux d’autorisation de l’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 de l’appareil.
+interactive:  true
+
+github:
+  path: https://auth0.github.io/device-flow-playground/
+locale: fr-CA
+---
+
+# Flux d’autorisation de l’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 de l’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 de l’appareil.
        Prérequis
        
+
+## 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 point de terminaison d’autorisation de 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 de 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 Validation des jetons d’accès et Validation des 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 Allow Offline Access (Autoriser l’accès hors ligne) est activé pour l’API indiquée par le paramètre audience 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 du 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, votre application peut appeler le point de terminaison POST /oauth/token de Authentication API 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, consultez 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, le device_code a donc 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..34dac73071
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/flutter/interactive.md
@@ -0,0 +1,70 @@
+---
+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: https://github.com/auth0-samples/auth0-flutter-samples/tree/main/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 de profil utilisateur dans votre application. Ce guide explique comment intégrer Auth0 avec 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 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" de Flutter pour commencer avec une application simple.
        Vous devez également être familiarisé avec Outil de ligne de commande Flutter.
        
+
+## Configurer 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 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 identificateur 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, où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez explorer une configuration complète, consultez un exemple d'application.
        Configurer les URL Callback et les URL de déconnexion
        Les URL Callback et les URL de déconnexion sont les URL que Auth0 appelle pour rediriger vers votre application. Auth0 fait appel à la URL Callback après avoir authentifié l’utilisateur et à l’URL de déconnexion après avoir supprimé le témoin de session. Si les URL Callback et de déconnexion ne sont pas définies, les utilisateurs ne pourront pas se connecter ou se déconnecter de l’application et recevront une erreur.
        Définissez les URCallback et 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
        
+
+## Installez 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 paramètres fictifs dans le manifeste. Auth0 utilise des paramètres fictifs en interne pour définir un intent-filter, qui capture la Callback URL pour l’authentification. Vous devez définir le domaine du locataire Auth0 et le schéma de la Callback URL.
        L'exemple utilise les paramètres fictifs 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. Pour en savoir plus sur la définition de cette valeur, lisez le fichier 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 l’ID Team et l’identificateur de 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.
        Ajoutez 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’onglet Signing and Capabilities (Signature et capacités) des paramètres de la cible du Runner, puis appuyez sur le bouton + Capability (Capabilité). Sélectionnez ensuite 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 configurer 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. Vous pouvez alors accéder à l’identificateur 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 connecte l’utilisateur à votre application. Vérifiez que vous êtes redirigé vers Auth0 pour l’authentification, puis vers votre application.
        Vérifiez que vous pouvez accéder aux jetons sur le résultat de l’appel de 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.
        
+
+  
        
+
+## 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 5 - 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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’identification.
        Flutter - Étape 7 - Afficher les informations du profil utilisateur 
        Connectez-vous et inspectez la propriété user du résultat. Vérifiez les informations de profil utilisateur actuelles, telles que son email ou 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/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..7ab60b6db2
--- /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 montre comment intégrer Auth0 avec une application Ionic (Angular) & 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: https://github.com/auth0-samples/auth0-ionic-samples/tree/main/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 montre comment intégrer Auth0 avec une application Ionic (Angular) & Capacitor en utilisant la trousse SDK Angular Auth0.
        
+
+## Démarrage
+
+
+
        Ce 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 le Using Capacitor with Ionic Framework guide (Utiliser Capacitor avec Ionic Framework) pour commencer avec une application simple ou clonez nos exemples d’applications.
        Vous devez également connaître le Capacitor development workflow (flux de travail de développement Capacitor).
        
+
+## Configuration d'Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. Vous allez configurer le fonctionnement de l’authentification pour votre projet dans l'application Auth0.
        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 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 le 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, vous pouvez plutôt consulter une application faisant office d’exemple.
        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 qu’ils se sont authentifiés. 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
        Configurer les 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 qu’ils se sont déconnectés. 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 origines autorisées
        Pour pouvoir faire des requêtes à partir de votre application native vers Auth0, définissez les origines autorisées suivantes dans vos paramètres de l’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 paramètres de l’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 démarrage 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 terminal d’autorisation de Auth0.
        • @capacitor/app : Vous permet de souscrire à des événements d’application de haut niveau, utiles pour la gestion des rappels 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 du domaine présente dans les 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ésd’Auth0.
        • clientId : La valeur de l’identifiant client présente dans les Paramètres de l’application que vous avez créée dans le 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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 Chrome Custom Tabs 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 plate-forme 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.
        
+
+  
        
+
+  
        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
        
+
+  
        
+
+## Gérer le rappel de connexion {{{ data-action="code" data-code="app.component.ts" }}}
+
+
+
        Une fois que les utilisateurs se connectent avec la page de connexion universelle, ils se redirigent vers votre application via une URL avec un schéma d’URL personnalisé. L’événement appUrlOpen doit être géré dans 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. Pour vérifier le succès, vérifiez la présence des paramètres code et state dans l’URL.
        La méthode Browser.close() devrait fermer le navigateur lorsque cet événement est déclenché.
        Notez que le rappel de l’événement appUrlOpen est enveloppé dans ngZone.run. Les changements aux observables qui se produisent lorsque handleRedirectCallback est exécuté sont pris en compte par l’application Angular. Pour en savoir plus, lisez Using Angular with Capacitor (Utilisation d’Angular avec Capacitor). 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 l’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.
        
+
+  
        
+
+  
        Sorry about that. Here's a couple things to double check:
        
+
+  
        
+
+## 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 se rediriger vers le terminal de connexion Auth0 dans le navigateur pour effacer leur session de navigation. Encore une fois, le plugiciel du navigateur de Capacitor devrait effectuer cette redirection afin que l’utilisateur ne quitte pas votre application et ne vive pas une expérience sous-optimale.
        Pour y parvenir avec Ionic et Capacitor en conjonction avec la trousse SDK Auth0 :
        • Construire l’URL vers laquelle votre application Auth0 devrait 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 de Allowed Logout URLs (URL de déconnexions permises) dans le Auth0 Dashboard
        • Déconnectez-vous de la trousse SDK en appelant logout et passez votre URL de redirection comme paramètre logoutParams.returnTo .
        • Définir le paramètre openUrl sur un rappel 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 
        Fournissez 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.
        
+
+  
        
+
+  
        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
        
+
+  
        
+
+## 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érifier que vous êtes en mesure de récupérer et de voir les informations de votre profil à l’écran une fois que vous avez ouvert une session.
        
+
+  
        
+
+  
        Sorry about that. Here's a couple things to double check:
        • check that you are only reading the user's profile when isLoading is false
        • check that user resolves to an object and is not undefined
        
+
+  
        
diff --git a/fr-ca/articles/quickstart/native/ionic-react/01-login.md b/fr-ca/articles/quickstart/native/ionic-react/01-login.md
new file mode 100644
index 0000000000..1dd8536765
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/ionic-react/01-login.md
@@ -0,0 +1,228 @@
+---
+title: Login
+default: true
+description: This tutorial demonstrates how to add user login with Auth0 to an Ionic React & Capacitor application.
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - ionic
+  - react
+  - capacitor
+github:
+  path: react
+contentType: tutorial
+useCase: quickstart
+---
+
+
+
+<%= include('../_includes/ionic/_article_intro') %>
+
+<%= include('../_includes/_getting_started', { library: 'Ionic' }) %>
+
+<%= include('../_includes/ionic/_configure_urls') %>
+
+<%= include('../../_includes/_auth0-react-install.md') %>
+
+<%= include('../_includes/ionic/_install_plugins') %>
+
+### Configure the `Auth0Provider` component
+
+Under the hood, the Auth0 React SDK uses [React Context](https://reactjs.org/docs/context.html) to manage the authentication state of your users. One way to integrate Auth0 with your React app is to wrap your root component with an `Auth0Provider` that you can import from the SDK.
+
+Open `src/index.tsx` and wrap the `App` component in the `Auth0Provider` component.
+
+```javascript
+import React from 'react';
+import { createRoot } from 'react-dom/client';
+import { Auth0Provider } from '@auth0/auth0-react';
+import App from './App';
+
+const root = createRoot(document.getElementById('root'));
+
+root.render(
+  
+    
+  
+);
+```
+
+The `Auth0Provider` component takes the following props:
+
+- `domain`: The "domain" value present under the "Settings" of the application you created in your Auth0 dashboard, or your custom domain if using Auth0's [Custom Domains feature](http://localhost:3000/docs/custom-domains)
+- `clientId`: The "client ID" value present under the "Settings" of the application you created in your Auth0 dashboard
+- `useRefreshTokens`: To use auth0-react with Ionic on Android and iOS, it's required to enable refresh tokens.
+- `useRefreshTokensFallback`: To use auth0-react with Ionic on Android and iOS, it's required to disable the iframe fallback.
+- `authorizationParams.redirect_uri`: The URL to where you'd like to redirect your users after they authenticate with Auth0.
+
+<%= include('../_includes/ionic/_note_storage') %>
+
+:::panel Checkpoint
+Now that you have configured `Auth0Provider`, run your application to verify that the SDK is initializing correctly, and your application is not throwing any errors related to Auth0.
+:::
+
+## Add Login to Your Application
+
+<%= include('../_includes/ionic/_add_login_intro') %>
+
+Add a new file `LoginButton.tsx` with the following code:
+
+```js
+import { useAuth0 } from '@auth0/auth0-react';
+import { Browser } from '@capacitor/browser';
+import { IonButton } from '@ionic/react';
+
+const LoginButton: React.FC = () => {
+  const { loginWithRedirect } = useAuth0();
+
+  const login = async () => {
+    await loginWithRedirect({
+      async openUrl(url) {
+         // Redirect using Capacitor's Browser plugin
+        await Browser.open({
+          url,
+          windowName: "_self"
+        });
+      }
+    });
+  };
+
+  return Log in;
+};
+
+export default LoginButton;
+```
+
+This component:
+
+- defines a template with a simple button that logs the user in when clicked
+- uses `loginWithRedirect` to login using Auth0's Universal Login page
+- uses the `openUrl` callback to use Capacitor's Browser plugin to open the URL and show the login page to the user
+
+<%= include('../../_includes/_auth0-react-classes-info.md') %>
+
+### Handling the callback
+
+<%= include('../_includes/ionic/_handle_callback_intro') %>
+
+Add the following `useEffect` hook to your main `App` component:
+
+```js
+// Import Capacitor's app and browser plugins, giving us access to `addListener` and `appUrlOpen`,
+// as well as the bits needed for Auth0 and React
+import { App as CapApp } from '@capacitor/app';
+import { Browser } from '@capacitor/browser';
+import { useEffect } from 'react';
+import { useAuth0 } from '@auth0/auth0-react';
+
+// ...
+
+const App: React.FC = () => {
+  // Get the callback handler from the Auth0 React hook
+  const { handleRedirectCallback } = useAuth0();
+
+  useEffect(() => {
+    // Handle the 'appUrlOpen' event and call `handleRedirectCallback`
+    CapApp.addListener('appUrlOpen', async ({ url }) => {
+      if (url.includes('state') && (url.includes('code') || url.includes('error'))) {
+        await handleRedirectCallback(url);
+      }
+      // No-op on Android
+      await Browser.close();
+    });
+  }, [handleRedirectCallback]);
+
+  // ..
+};
+```
+
+<%= include('../_includes/ionic/_note_custom_schemes') %>
+
+:::panel Checkpoint
+Add the `LoginButton` component to your application, as well as the handler for the "appUrlOpen" event to your `App` component. When you click the login button, verify that your application redirects you to the Auth0 Universal Login Page and that you can now log in or sign up using a username and password or a social provider.
+
+Once that's complete, verify that Auth0 redirects you back to your application.
+:::
+
+## Add Logout to Your Application
+
+<%= include('../_includes/ionic/_add_logout_intro.md') %>
+
+Create a new file `LogoutButton.tsx` and add the following code to the file. Then, add the `LogoutButton` component to your app.
+
+```js
+import { useAuth0 } from '@auth0/auth0-react';
+import { Browser } from '@capacitor/browser';
+import { IonButton } from '@ionic/react';
+
+// This should reflect the URL added earlier to your "Allowed Logout URLs" setting
+// in the Auth0 dashboard.
+const logoutUri = 'YOUR_PACKAGE_ID://${account.namespace}/capacitor/YOUR_PACKAGE_ID/callback';
+
+const LogoutButton: React.FC = () => {
+  const { logout } = useAuth0();
+
+  const doLogout = async () => {
+    await logout({
+      logoutParams: {
+        returnTo: logoutUri,
+      },
+      async openUrl(url) {
+         // Redirect using Capacitor's Browser plugin
+        await Browser.open({
+          url,
+          windowName: "_self"
+        });
+      }
+    });
+  };
+
+  return Log out;
+};
+
+export default LogoutButton;
+```
+
+:::panel Checkpoint
+Add the `LogoutButton` component to your application. When you click it, verify that your Ionic application redirects you the address you specified as one of the "Allowed Logout URLs" in the "Settings" and that you are no longer logged in to your application.
+:::
+
+## Show User Profile Information
+
+The Auth0 React SDK helps you retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with logged-in users quickly in whatever component you need, such as their name or profile picture, to personalize the user interface. The profile information is available through the `user` property exposed by the `useAuth0()` hook. Take this `Profile` component as an example of how to use it:
+
+```js
+import { useAuth0 } from '@auth0/auth0-react';
+
+const Profile: React.FC = () => {
+  const { user, isLoading } = useAuth0();
+
+  // If the SDK is not ready, or a user is not authenticated, exit.
+  if (isLoading || !user) return null;
+
+  return (
+    
        
+      {user.name}
+      
        {user.name}
        
+      
        {user.email}
        
+    
        
+  );
+};
+
+export default Profile;
+```
+
+The `user` property contains sensitive information and artifacts related to the user's identity. As such, its availability depends on the user's authentication status. To prevent any render errors, use the `isAuthenticated` property from `useAuth0()` to check if Auth0 has authenticated the user before React renders any component that consumes the `user` property. Ensure that the SDK has completed loading before accessing the `isAuthenticated` property, by checking that `isLoading` is `false`.
+
+:::panel Checkpoint
+Add the `Profile` component to your application, and verify that you can display the `user.name` or [any other `user` property](https://auth0.com/docs/users/references/user-profile-structure#user-profile-attributes) within a component correctly after you have logged in.
+:::
diff --git a/fr-ca/articles/quickstart/native/ionic-react/download.md b/fr-ca/articles/quickstart/native/ionic-react/download.md
new file mode 100644
index 0000000000..dc7d46dcf4
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/ionic-react/download.md
@@ -0,0 +1,37 @@
+
+
+To run the sample follow these steps:
+
+1) Add the following URL to **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback
+```
+
+2) Add the following URL to **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback
+```
+
+3) Add the following to **Allowed Origins (CORS)s** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+capacitor://localhost, http://localhost
+```
+
+4) Check that mobile development environments for [Android](https://capacitorjs.com/docs/android) and [iOS](https://capacitorjs.com/docs/ios) are setup correctly. For iOS, [CocoaPods](https://cocoapods.org/) must be installed.
+
+5) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the sample directory:
+
+```bash
+npm install
+npm run build
+
+# to test it in iOS
+npx cap run ios
+# to test it in Android
+npx cap run android
+```
+
+Read more about the [Capacitor development workflow](https://capacitorjs.com/docs/basics/workflow) on Capacitor's docs site.
diff --git a/fr-ca/articles/quickstart/native/ionic-react/files/app.md b/fr-ca/articles/quickstart/native/ionic-react/files/app.md
new file mode 100644
index 0000000000..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..00c135a062
--- /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 montre 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: https://github.com/auth0-samples/auth0-ionic-samples/tree/main/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 de l’utilisateur dans votre application. Ce guide montre comment intégrer Auth0 avec une application Ionic (React) & Capacitor en utilisant la trousse SDK React Auth0.
        
+
+## Démarrage
+
+
+
        Ce 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 le Using Capacitor with Ionic Framework guide (Utilisez Capacitor avec Ionic Framework) pour commencer avec une application simple ou clonez nos exemples d’applications.
        Vous devez également connaître le flux de travail 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 vous intégrer. Dans Auth0, un identifiant client unique alphanumérique est attribué à chaque application 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, vous pouvez plutôt consulter une application faisant office d’exemple.
        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 qu’ils se sont authentifiés. 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.
        Configurer les 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 qu’ils se sont déconnectés. 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 native vers Auth0, définissez les origines autorisées suivantes dans vos 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 paramètres de l’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 React Hooks (Appels React) ou les Higher-Order Components (Composants d’ordre supérieur).
        Installer les plugiciels Capacitor
        Ce démarrage 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 terminal d’autorisation de Auth0.
        • @capacitor/app : Vous permet de souscrire à des événements d’application de haut niveau, utiles pour la gestion des rappels 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 domainprésente dans les paramètresde 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 2 - Configurer le composant Auth0Provider 
        Ajoutez la composante Auth0Provider d’une manière qui enveloppe votre composante 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## Ajouter une fonctionnalité de connexion à votre application {{{ data-action="code" data-code="login-button.tsx" }}}
+
+
+
        Dans une application Capacitor, le plugiciel de navigateur Capacitor effectue une redirection vers la page de connexion universelleAuth0. 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 Chrome Custom Tabs 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 plate-forme 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.
        
+
+  
        
+
+  
        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
        
+
+  
        
+
+## Gérer le rappel de connexion {{{ data-action="code" data-code="app.tsx" }}}
+
+
+
        Une fois que les utilisateurs se connectent avec la page de connexion universelle, ils se redirigent vers votre application via une URL avec un schéma d’URL personnalisé. L’événement appUrlOpen doit être géré dans 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. Pour vérifier le succès, vérifiez la présence des paramètres code et state 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 l’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.
        
+
+  
        
+
+  
        Sorry about that. Here's a couple things to double check:
        
+
+  
        
+
+## 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 se rediriger vers le terminal de connexion Auth0 dans le navigateur pour effacer leur session de navigation. Encore une fois, le plugiciel du navigateur de Capacitor devrait effectuer cette redirection afin que l’utilisateur ne quitte pas votre application et ne vive pas une expérience sous-optimale.
        Pour y parvenir avec Ionic et Capacitor en conjonction avec le SDK Auth0 :
        • Construire l’URL de votre application Auth0 devrait utiliser pour rediriger vers après la déconnexion. Il s’agit d’une URL qui utilise votre schéma personnalisé enregistré et le domaine Auth0. Ajoutez-le à votre configuration d’URLs de déconnexions permises dans le Auth0 Dashboard
        • Déconnectez-vous du SDK en appelant logout et passez votre URL de redirection comme paramètre logoutParams.returnTo .
        • Définir le paramètre openUrl sur un rappel 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 
        Permettre à 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 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 disponibles 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 vérifiant les propriétés isLoading et user. Une fois que isLoading est false et que le user a une valeur, le profil d’utilisateur peut être utilisé.
        Ionic & Capacitor (React) - Étape 8 - Afficher le profil utilisateur 
        Permettre à vos utilisateurs de voir leurs détails de leur profil utilisateur dans l’application et vérifier que vous êtes en mesure de récupérer et de voir les informations de votre profil à l’écran une fois que vous avez ouvert une session.
        
+
+  
        
+
+  
        Sorry about that. Here's a couple things to double check:
        • check that you are only reading the user's profile when isLoading is false
        • check that user resolves to an object and is not undefined
        
+
+  
        
diff --git a/fr-ca/articles/quickstart/native/ionic-vue/01-login.md b/fr-ca/articles/quickstart/native/ionic-vue/01-login.md
new file mode 100644
index 0000000000..f29168389b
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/ionic-vue/01-login.md
@@ -0,0 +1,271 @@
+---
+title: Login
+default: true
+description: This tutorial demonstrates how to add user login with Auth0 to an Ionic Vue & Capacitor application.
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - ionic
+  - vue
+  - capacitor
+github:
+  path: vue
+contentType: tutorial
+useCase: quickstart
+---
+
+
+
+<%= include('../_includes/ionic/_article_intro') %>
+
+<%= include('../_includes/_getting_started', { library: 'Ionic' }) %>
+
+<%= include('../_includes/ionic/_configure_urls') %>
+
+<%= include('../../_includes/_auth0-vue-install.md') %>
+
+<%= include('../_includes/ionic/_install_plugins') %>
+
+### Configure the `createAuth0` plugin
+
+The SDK exports `createAuth0`, a composable that contains all the services required for the SDK to function. To register this with your application:
+
+Open `src/main.ts` and install the plugin using `app.use`
+
+```javascript
+import { createApp } from "vue";
+import App from "./App.vue";
+import router from "./router";
+
+import { IonicVue } from "@ionic/vue";
+
+import { createAuth0 } from "@auth0/auth0-vue";
+import config from "./auth.config";
+
+// ..
+
+// Build the URL that Auth0 should redirect back to
+const redirect_uri = `<%= "${config.appId}" %>://${account.namespace}/capacitor/<%= "${config.appId}" %>/callback`;
+
+const app = createApp(App).use(IonicVue).use(router);
+
+app.use(
+  createAuth0({
+    domain: "${account.namespace}",
+    clientId: "${account.clientId}",
+    useRefreshTokens: true,
+    useRefreshTokensFallback: false,
+    authorizationParams: {
+      redirect_uri
+    }
+  })
+);
+
+router.isReady().then(() => {
+  app.mount("#app");
+});
+```
+
+The `createAuth0` plugin takes the following props:
+
+- `domain`: The "domain" value present under the "Settings" of the application you created in your Auth0 dashboard, or your custom domain if using Auth0's [Custom Domains feature](http://localhost:3000/docs/custom-domains)
+- `clientId`: The "client ID" value present under the "Settings" of the application you created in your Auth0 dashboard
+- `useRefreshTokens`: To use auth0-vue with Ionic on Android and iOS, it's required to enable refresh tokens.
+- `useRefreshTokensFallback`: To use auth0-vue with Ionic on Android and iOS, it's required to disable the iframe fallback.
+- `authorizationParams.redirect_uri`: The URL to where you'd like to redirect your users after they authenticate with Auth0.
+
+<%= include('../_includes/ionic/_note_storage') %>
+
+:::panel Checkpoint
+Now that you have configured `createAuth0` plugin, run your application to verify that the SDK is initializing correctly, and your application is not throwing any errors related to Auth0.
+:::
+
+## Add Login to Your Application
+
+<%= include('../_includes/ionic/_add_login_intro') %>
+
+Add a new file `LoginButton.vue` with the following code:
+
+```html
+
+
+
+```
+
+This component:
+
+- defines a template with a simple button that logs the user in when clicked
+- uses `loginWithRedirect` to login using Auth0's Universal Login page
+- uses the `openUrl` callback to use Capacitor's Browser plugin to open the URL and show the login page to the user
+
+### Handling the callback
+
+<%= include('../_includes/ionic/_handle_callback_intro') %>
+
+Add the following capacitor application listener to your main `App` component:
+
+```html
+
+
+
+```
+
+<%= include('../_includes/ionic/_note_custom_schemes') %>
+
+:::panel Checkpoint
+Add the `LoginButton` component to your application, as well as the handler for the "appUrlOpen" event to your `App` component. When you click the login button, verify that your application redirects you to the Auth0 Universal Login Page and that you can now log in or sign up using a username and password or a social provider.
+
+Once that's complete, verify that Auth0 redirects you back to your application.
+:::
+
+## Add Logout to Your Application
+
+<%= include('../_includes/ionic/_add_logout_intro.md') %>
+
+Create a new file `LogoutButton.vue` and add the following code to the file. Then, add the `LogoutButton` component to your app.
+
+```html
+
+
+
+```
+
+:::panel Checkpoint
+Add the `LogoutButton` component to your application. When you click it, verify that your Ionic application redirects you the address you specified as one of the "Allowed Logout URLs" in the "Settings" and that you are no longer logged in to your application.
+:::
+
+## Show User Profile Information
+
+The Auth0 Vue SDK helps you retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with logged-in users quickly in whatever component you need, such as their name or profile picture, to personalize the user interface. The profile information is available through the `user` property exposed by the `useAuth0()` composable. Take this `UserProfile` component as an example of how to use it:
+
+```html
+
+
+
+```
+
+The `user` property contains sensitive information and artifacts related to the user's identity. As such, its availability depends on the user's authentication status. To prevent any render errors, use the `isAuthenticated` property from `useAuth0()` to check if Auth0 has authenticated the user before Vue renders any component that consumes the `user` property. Ensure that the SDK has completed loading before accessing the `isAuthenticated` property, by checking that `isLoading` is `false`.
+
+:::panel Checkpoint
+Add the `UserProfile` component to your application, and verify that you can display the `user.name` or [any other `user` property](https://auth0.com/docs/users/references/user-profile-structure#user-profile-attributes) within a component correctly after you have logged in.
+:::
diff --git a/fr-ca/articles/quickstart/native/ionic-vue/download.md b/fr-ca/articles/quickstart/native/ionic-vue/download.md
new file mode 100644
index 0000000000..a0589fcf12
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/ionic-vue/download.md
@@ -0,0 +1,38 @@
+
+
+To run the sample follow these steps:
+
+1) Add the following URL to **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback
+```
+
+2) Add the following URL to **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback
+```
+
+3) Add the following to **Allowed Origins (CORS)s** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+capacitor://localhost, http://localhost
+```
+
+4) Check that mobile development environments for [Android](https://capacitorjs.com/docs/android) and [iOS](https://capacitorjs.com/docs/ios) are setup correctly. For iOS, [CocoaPods](https://cocoapods.org/) must be installed.
+
+5) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the sample directory:
+
+```bash
+npm install
+npm run build
+
+# to test it in iOS
+npx cap run ios
+
+# to test it in Android
+npx cap run android
+```
+
+Read more about the [Capacitor development workflow](https://capacitorjs.com/docs/basics/workflow) on Capacitor's docs site.
diff --git a/fr-ca/articles/quickstart/native/ionic-vue/files/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..a1d872a455
--- /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: https://github.com/auth0-samples/auth0-ionic-samples/tree/main/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.
        
+
+## Premiers pas
+
+
+
        Ce guide 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 le guide Using Capacitor with Ionic Framework guideguide (Utiliser Capacitor avec Ionic Framework) pour commencer avec une application simple ou clonez nos exemples d’applications.
        Vous devez également connaître le Flux de travail de développement Capacitor.
        
+
+## Configurer Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application installée dans Auth0 Dashboard. Vous allez configurer l’authentification pour votre projet dans l’application Auth0.
        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 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 guide rapide seront automatiquement mis à jour pour votre application dans le Dashboard, 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 Callback URL
        Une Callback URL 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
        Configurer les 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 native vers Auth0, définissez les origines autorisées suivantes 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 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.
        Guide 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## Ajouter une fonctionnalité de connexion à votre application {{{ data-action="code" data-code="LoginButton.vue" }}}
+
+
+
        Dans une application Capacitor, le plugiciel de navigateur Capacitor effectue une redirection vers la page de connexion universelleAuth0. 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 Chrome Custom Tabs 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.
        
+
+  
        
+
+  
        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
        
+
+  
        
+
+## Gérer le callback 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 via une URL avec un schéma d’URL personnalisé. L’événement appUrlOpen doit être géré dans 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. 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é.
        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.
        
+
+  
        
+
+  
        Sorry about that. Here's a couple things to double check:
        
+
+  
        
+
+## 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 Allowed Logout URLs 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.
        
+
+  
        
+
+  
        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
        
+
+  
        
+
+## 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 disponibles via la propriété user exposée par le 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 
        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 de voir les informations de votre profil à l’écran une fois que vous avez ouvert une session.
        
+
+  
        
+
+  
        
+
+  
        
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..64f69f191a
--- /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: https://github.com/auth0-samples/auth0-ios-swift-sample/tree/master/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 pour avoir 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.
        
+
+## Configurer 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électionner 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 à la callback URL après avoir authentifié l’utilisateur et l’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 callback URL et aux URL de déconnexion, en fonction de la plateforme de votre application. 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
+
+
        
+
+
        1. 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) > 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’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.
        Ajoutez la capacité de domaine associé.
        Dans Xcode, allez à l’onglet Signing and Capabilities (Signature et capacités) des paramètres cibles de votre application, puis appuyez sur le bouton + Capability (capacité) Puis sélectionnez Domaines associés.
        Xcode> Onglet Signing and Capabilities (Signature et capacités) > Add New (Ajouter nouveau) > Associated Domains (Domaines associés)
        Ensuite, ajoutez l’entrée suivante sous Domaines associé :
        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.
        
+
+## Configurer la trousse SDK {{{ data-action="code" data-code="Auth0.plist" }}}
+
+
+
        La trousse SDK Auth0.swift a besoin de votre domaine Auth0 et de votre ID client. Ces valeurs se trouvent dans la page des paramètres de votre application Auth0.
        • domain : Le domaine de votre locataire Auth0. Si vous avez un domaine personnalisé, utilisez-le à la place du domaine de votre locataire Auth0.
        • ID client : L’ID 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’ID 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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 afficher la page de connexion. Ensuite, affichez la page 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 apprendre davantage.
        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.
        • Choisir 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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 log out (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 (Connexion) et vérifiez que :
        • Une boîte d’alerte s’affiche demandant le consentement.
        • Choisir Continue (Continuer) ouvre une page dans un modal Safari.
        • Le modal Safari se ferme automatiquement par la suite.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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 ID token (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é.
        
+
+  
        
+
+  
        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/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..ec399f8b3d
--- /dev/null
+++ b/fr-ca/articles/quickstart/native/maui/interactive.md
@@ -0,0 +1,160 @@
+---
+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: https://github.com/auth0-samples/auth0-maui-samples/tree/master/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.
        
+
+## Configurer 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, vous pouvez plutôt consulter une application faisant office d’exemple.
        Configuration des callback URL
        Une callback URL 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.
        Configurer les 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 qu’ils se sont déconnectés. 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 d’implémentation de l’authentification Auth0 dans les applications MAUI.
        Utilisez le Gestionnaire de packages NuGet (Tools [Outils] -> Library Package Manager [Gestionnaire de packages de bibliothèque] -> Package Manager Console [Console du gestionnaire de package]) pour installer le package Auth0.OidcClient.MAUI.
        Sinon, vous pouvez utiliser la Console du gestionnaire de packages NuGet (Install-Package) ou le dotnet CLI (dotnet add).
        Install-Package Auth0.OidcClient.MAUI
+
+
        
+
+
        dotnet add package Auth0.OidcClient.MAUI
+
+
        
+
+
        
+
+## Configuration particulière de la plateforme
+
+
+
        Une configuration particulière à la plateforme est nécessaire pour utiliser la trousse SDK avec Android et Windows.
        Android
        Créer 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>
+
+
        
+
+
        • Appeler Activator.Default.CheckRedirectionActivation() dans le fichier propre à Windows 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 ID 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"
+
+});
+
+
        
+
+
        Par défaut, la trousse SDK utilisera les onglets personnalisés Chrome pour Android, ASWebAuthenticationSession pour iOS et macOS, et utilisera 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é. Éxecutez 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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 de connexion universelle d’Auth0.
        • Vous pouvez vous connecter ou vous inscrire.
        • Auth0 vous redirige vers votre 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.
        
+
+  
        
+
+## Ajouter 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 
        Executez 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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 voulez probablement pouvoir récupérer et utiliser 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 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..ac458a8482
--- /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: https://github.com/auth0-samples/auth0-xamarin-oidc-samples/tree/master/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 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. Vous allez configurer l’authentification pour votre projet dans l'application Auth0.
        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 identificateur client unique alphanumérique que votre code d’application utilisera pour appeler les API Auth0 via le SDK.
        Tous les paramètres que vous configurez à l’aide de ce guide rapide seront automatiquement mis à jour pour votre application dans le Dashboard, 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 Callback URL
        Une Callback URL 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
        Configurer 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 Application Type (Type d’application) de votre application est défini sur Native dans les Application Settings (Paramètres de l’application).
        
+
+## Installer le 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 Auth0.OidcClient.AndroidX ou Auth0.OidcClient.iOS , pour développer une application Android ou iOS.
        Sinon, vous pouvez utiliser la Package Manager Console (Console du gestionnaire de packages) NuGet (Install-Package) ou l'interface de ligne de commande dotnet (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.
        Guixe 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## Configurer Android {{{ data-action="code" data-code="MainActivity.cs#2:9" }}}
+
+
+
        Une fois un utilisateur authentifié avec succès, il est redirigé vers la Callback URL 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 Callback URL. 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 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 la Callback URL 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 transférant 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" }}}
+
+
+
        Après qu’un utilisateur s’est authentifié avec succès, il est redirigé vers la Callback URL de rappel que vous avez configurée précédemment dans ce guide rapide.
        Pour gérer le callback (rappel) 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 Identifier (Identificateur du bundle) de votre application et le Role (Rôle) sur None (Aucun).
        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 la Callback URL 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 pourrez accéder à User, IdentityToken, AccessToken et RefreshToken dans le LoginResult renvoyé par LoginAsync().
        Guide 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 d’Auth0.
        • Vous pouvez vous connecter ou vous inscrire.
        • Auth0 vous redirige vers votre 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.
        
+
+  
        
+
+## 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éconnecteront, 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 guide 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. 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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..4aee19e88b
--- /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: https://github.com/auth0-samples/auth0-angular-samples/tree/main/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.
        
+
+## Configurer 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 vous intégrer. Dans Auth0, il est attribué à chaque application un identificateur 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 vous permettra de gérer vos applications.
        Si vous préférez explorer une configuration complète, vous pouvez plutôt consulter une application faisant office d’exemple.
        Configuration des Callback URL
        Une Callback URL 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 Allowed Web Origins (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 lorsqu'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 un SDK Angular pour simplifier le processus d’implémentation 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 Domaine et ID client 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 s’est authentifié avec succès, il sera redirigé vers votre application et la Callback URL que vous avez configurée précédemment dans ce guide rapide.
        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. Verifiez 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 de connexion universelle d’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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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 sont 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 guide 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. Verifiez 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## Afficher les informations du profil utilisateur {{{ data-action="code" data-code="user-profile.ts" }}}
+
+
+
        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 Angular Auth0 fournit des informations sur les utilisateurs par le biais de l’observable user$ exposé par la classe AuthService. L’observable user$ contenant des informations et des objets 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 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 permet de déterminer 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.
        
+
+  
        
+
+  
        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/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..d968c9585b
--- /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 Flutter Auth0.
+interactive:  true
+files:
+ - files/main_view
+ - files/profile_view
+github:
+  path: https://github.com/auth0-samples/auth0-flutter-samples/tree/main/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 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 « Getting started » (Premiers pas) de Flutter pour commencer avec une application simple.
        Vous devez également être familiarisé avec Flutter command line tool (Outil de ligne de commande Flutter).
        
+
+## Configurer 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 détails sur cette application pour communiquer avec Auth0. Vous pouvez obtenir ces détails dans la section Application Settings (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
        • Identificateur client
        Si vous téléchargez l’exemple en haut de cette page, les détails sont renseignés pour vous.
        Configurer les Callback URL
        Une Callback URL est une URL intégrée dans votre application vers laquelle Auth0 redirige l’utilisateur après qu’il se soit authentifié. La Callback URL de votre application doit être ajoutée au champ Allowed Callback URLs (Callback URLs autorisées) dans les Application Settings (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 la Callback URL autorisée sur http://localhost:3000.
        Configurer les 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 Allowed Logout URLs (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 Allowed Logout URLs (URL de déconnexions autorisées) est http://localhost:3000.
        Configurer Allowed Web Origins (Origines Web autorisées)
        Vous devez ajouter l’URL de votre application au champ Allowed Web Origins (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 Allowed Web Origins (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 la balise 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 connecte l’utilisateur à votre application. Vérifiez que vous êtes redirigé vers Auth0 pour l’authentification, puis vers votre application.
        Vérifiez que vous pouvez accéder aux credentials après avoir appelé onLoad et que vous pouvez accéder à l’identificateur et aux jetons d’accès.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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 Allowed Logout URLs (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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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’identification.
        Flutter (Web) - Étape 5 - 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.
        
+
+  
        
+
+  
        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/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..8493eb5ca2
--- /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 de Auth0 React SDK.
+interactive:  true
+files:
+ - files/index
+ - files/login
+ - files/logout
+ - files/profile
+github:
+  path: https://github.com/auth0-samples/auth0-react-samples/tree/master/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 Auth0 React.
        Pour utiliser ce guide rapide, vous devez:
        • Vous inscrire pour avoir 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 après la connexion.
        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.
        
+
+## Configurer 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, vous pouvez plutôt consulter une application faisant office d’exemple.
        Configuration des callback URL
        Une callback URL 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.
        Configurer les 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 qu’ils se sont déconnectés. 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 rafraîchir 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 React Auth0 {{{ data-action="code" data-code="index.js" }}}
+
+
+
        Auth0 propose une React SDK [trousse SDK React] (auth0-react.js) pour simplifier le processus d’implémentation 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. Il se trouve en général dans Auth0 Dashboard sous 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’ID de l’application Auth0 que vous avez configurée précédemment dans ce démarrage rapide. Celui-ci figure dans Auth0 Dashboard, sous les paramètres de votre application du champ ID 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’a callback URL que vous avez configurée précédemment dans ce démarrage rapide. Cette valeur se trouve également dans Auth0 Dashboard, sous les paramètres de votre application, dans le champ Callback URL. 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.
        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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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. Après qu’un utilisateur s’est authentifié avec succès, il est redirigé vers la callback URL 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 d’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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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éconnectent, 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 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 
        Executez 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## Afficher les informations du profil utilisateur {{{ data-action="code" data-code="profile.js" }}}
+
+
+
        Maintenant que vos utilisateurs peuvent se connecter et se déconnecter, vous voulez probablement pouvoir récupérer et utiliser 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 
        Verifiez que :
        • Vous pouvez afficher user.name  ou toute autre propriété de l’utilisateur dans un composant adéquatement, après vous être connecté.
        
+
+  
        
+
+  
        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/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..ccc435e656
--- /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: https://github.com/auth0-samples/auth0-javascript-samples/tree/master/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.
        
+
+## Configurer 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 vous intégrer. Dans Auth0, il est attribué à chaque application un identificateur 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 vous permettra de gérer vos applications.
        Si vous préférez explorer une configuration complète, vous pouvez plutôt consulter une application faisant office d’exemple.
        Configuration des Callback URL
        Une Callback URL 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 Allowed Web Origins (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 lorsqu'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 d’implémentation de l’authentification et de l’autorisation Auth0 dans les applications JavaScript. Vous pouvez installer la trousse SDK Auth0 SPA en tant que package NPM ou à partir du CDN. Pour les besoins de ce guide 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 la Callback URL que vous avez configurée précédemment dans ce guide 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. Verifiez 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 de connexion universelle d’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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## Gérer le callback 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 callback 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 callback a réussi, les paramètres doivent être supprimés de l’URL afin d’éviter que le gestionnaire du callback ne soit déclenché lors du prochain chargement de la page.
        Guide rapide Javascript - Étape 5 - Point de contrôle 
        Votre callback provenant d’Auth0 devrait maintenant être correctement traité.
        Exécutez votre application et sélectionnez le bouton de connexion. Verifiez que :
        • Auth0 redirige bien vers votre application après l’authentification,
        • les paramètres de requête sont supprimés de l’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.
        
+
+  
        
+
+## 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 d’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 sont redirigés vers votre point de terminaison de déconnexion Auth0, qui les redirige immédiatement vers votre application et l’URL de déconnexion que vous avez configurée précédemment dans ce guide 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. Verifiez 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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.
        Guide 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.
        
+
+  
        
+
+  
        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/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..c3bafa990c
--- /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: https://github.com/auth0-samples/auth0-vue-samples/tree/master/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é.
        
+
+## Configurer 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 vous intégrer. Dans Auth0, il est attribué à chaque application un identificateur 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 vous permettra de gérer vos applications.
        Si vous préférez explorer une configuration complète, vous pouvez plutôt consulter une application faisant office d’exemple.
        Configuration des Callback URL
        Une Callback URL 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 Allowed Web Origins (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 correctement configurée, votre projet ne pourra pas actualiser silencieusement les jetons d’authentification, ce qui entraînera la déconnexion de vos utilisateurs lors de leur prochaine visite à 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 Vue Auth0 {{{ 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 Vue Auth0 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 sous les Settings (Paramètres) de votre application dans le champ Domain (Domaine). Si vous utilisez un domaine personnalisé, définissez ceci 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 le trouverez dans Auth0 Dashboard sous les paramètres de votre application dans le champ Client ID (Identificateur 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 rapide. Cette valeur se trouve dans Auth0 Dashboard, sous les Settings (Paramètres) de votre application, dans le champ Callback URLs (Callback URL). 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 la Composition API et l'Options API.
        Guide 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 initialisée correctement.
        • Votre application ne génère aucune erreur liée à 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.
        
+
+  
        
+
+## 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 la callback URL que vous avez configurée plus tôt dans ce guide rapide.
        Utilisation de l’Options API
        Si vous utilisez l’Options API, vous pouvez utiliser la même méthode loginWithRedirect à partir de la propriété globale $auth0 via l’accesseur this.
        Guide 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 d’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. 
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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 de Auth0 logout (Déconnexion Auth0), qui les redirige ensuite vers le paramètre logoutParams.returnTo spécifié.
        Utilisez la fonction logout exposée sur la valeur de retour de useAuth0, à laquelle vous pouvez accéder dans la fonction setup de votre composant, pour déconnecter l’utilisateur de votre application.
        Utilisation de l’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.
        Guide rapide Vue - Étape 4 - Point de contrôle 
        Executez votre application et cliquez sur le bouton de déconnexion, puis vérifiez que :
        • votre application Vue vous redirige vers l’adresse logoutParams.returnTo,
        • vous n’êtes plus connecté à votre application.
        
+
+  
        
+
+  
        
+
+  
        
+
+## 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é reactive 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’Options API
        Pour l’Options API, 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 
        Verifiez que :
        • vous pouvez afficher le user ou l’une des propriétés de l’utilisateur correctement dans un composant, après vous être connecté
        
+
+  
        
+
+  
        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/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/articles/server-platforms/_includes/_profile-metadata-explanation.md b/fr-ca/articles/quickstart/webapp/_includes/_profile-metadata-explanation.md
similarity index 100%
rename from articles/server-platforms/_includes/_profile-metadata-explanation.md
rename to fr-ca/articles/quickstart/webapp/_includes/_profile-metadata-explanation.md
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..39e034a581
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/apache/interactive.md
@@ -0,0 +1,51 @@
+---
+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
+github:
+  path: https://github.com/zmartzone/mod_auth_openidc/releases
+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 construire à partir de la source.
        Une fois le module installé, activez-le pour Apache avec la commande a2enmod. Pour en savoir plus, lisez la page de manuel a2enmod sur Ubuntu :
        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), situé dans le dossier /etc/apache2/mods-available.
        Pour Windows, vous devez utiliser le fichier /apache/conf/httpd.conf.
        
+
+## Configurer Auth0
+
+
+
        Dans Auth0 Dashboard :
        1. Rendez-vous dans Applications > Applications, puis sélectionnez votre application dans la liste.
        2. Passez à la vue Settings (Paramètres), puis localisez la section Application URIs (URI d’application).
        3. Ajoutez la valeur de OIDCRedirectURI à Allowed Callback URLs (URL de rappel autorisées).
        4. Localisez Advanced Settings (Paramètres avancés) au bas de la page.
        5. Passez à la vue OAuth.
        6. Définissez JSON Web Token (JWT) Signature Algorithm (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 basé sur la valeur d’une revendication dans le jeton d’identification 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..620bc7ea78
--- /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 ancienne, à l’aide du SDK Auth0.AspNetCore.Authentication
+interactive:  true
+files:
+ - files/Login.cshtml
+ - files/Logout.cshtml
+ - files/Profile
+ - files/Program
+github:
+  path: https://github.com/auth0-samples/auth0-aspnetcore-blazor-server-samples/tree/main/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 de l’utilisateur dans votre application. Ce guide explique comment intégrer Auth0 à n’importe quelle application Blazor Server, nouvelle ou ancienne, à l’aide du 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 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 au moyen de 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, vous pouvez plutôt consulter une application faisant office d’exemple.
        Configuration des callback URL
        Une callback URL 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.
        Configurer les 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 authentification. 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.Authentication dans votre application.
        Configurer l’intergiciel
        Pour activer l’authentification dans votre application Blazor Server, utilisez l’intergiciel fourni par la trousse SDK. Rendez-vous dans le fichier Program.cs et appelez builder.Services.AddAuth0WebAppAuthentication() pour enregistrer l’intergiciel due la trousse SDK.
        Assurez-vous de configurer le Domain et ClientId, vu que 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 de préciser les authenticationProperties correspondantes, que vous pouvez générer en utilisant LoginAuthenticationPropertiesBuilder.
        Après avoir appelé avec succès HttpContext.ChallengeAsync(), l’utilisateur est redirigé vers Auth0 et est connecté à la fois à l’intergiciel OIDC et à l’intergiciel de témoin après avoir été redirigé vers votre application. Cela permettra aux utilisateurs d’être authentifiés pour les 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## Afficher le profil utilisateur {{{ data-action="code" data-code="Profile.razor" }}}
+
+
+
        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'identification 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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, lancez 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.
        
+
+  
        
+
+  
        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/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..231ff5ee00
--- /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: https://github.com/auth0-samples/auth0-aspnetcore-mvc-samples/tree/master/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.
        
+
+## Configurer 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 vous intégrer. Dans Auth0, il est attribué à chaque application un identificateur 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 vous permettra de gérer vos applications.
        Si vous préférez explorer une configuration complète, vous pouvez plutôt consulter une application faisant office d’exemple.
        Configuration des Callback URL
        Une Callback URL est une URL intégrée dans votre application vers laquelle vous souhaitez qu’Auth0 redirige les utilisateurs après qu’ils se sont authentifiés. 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 qu’ils se sont déconnectés. 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.Authentication dans 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 le Domain et ClientId, car il s'agit de champs requis pour garantir que la trousse SDK sache quel locataire Auth0 et quelle application elle doit 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 de spécifier les authenticationProperties correspondantes, que vous pouvez développer en utilisant LoginAuthenticationPropertiesBuilder.
        Après avoir appelé avec succès HttpContext.ChallengeAsync(), l’utilisateur sera redirigé vers Auth0 et connecté à la fois au logiciel médiateur OIDC et au logiciel médiateur de témoins 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## Afficher le profil utilisateur
+
+
+
        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’identification 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 électronique 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 :
        • le profil de l’utilisateur s'affiche après avoir navigué vers votre action Profile après vous être connecté avec succès.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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, executez 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.
        
+
+  
        
+
+  
        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/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..38af859cc0
--- /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: https://github.com/auth0-samples/auth0-aspnet-owin-mvc-samples/tree/master/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, à l’aide du package NuGet Microsoft.Owin.Security.OpenIdConnect.
        
+
+## Configuration d’Auth0
+
+
+
        Pour utiliser les services Auth0, vous devez avoir une application configurées 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 au moyen de 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, vous pouvez plutôt consulter une application faisant office d’exemple.
        Configuration des callback URL
        Une callback URL 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.
        Configurer les 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 authentification. 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 adéquatement, 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 du champ Domaine. Si vous utilisez un domaine personnalisé, définisse-le plutôt sur la valeur de votre domaine personnalisé.
        • auth0:ClientId: L’ID 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 du champ ID client.
        
+
+## Configurer l’intergiciel {{{ data-action="code" data-code="Startup.cs#18:74" }}}
+
+
+
        Pour activer l’authentification dans votre application ASP.NET OWIN, rendez-vous à la méthode de configuration de votre classe de démarrage et configurez le témoin, ainsi que l’intergiciel OIDC.
        Il est essentiel d’enregistrer à la fois l’intergiciel de témoin et l’intergiciel OpenID Connect, vu que les deux sont nécessaires (dans cet ordre) pour que l’authentification fonctionnne. L’intergiciel OpenID Connect gère l’authentification avec Auth0. Une fois que les utilisateurs se sont authentifiés, leur identité est sauvegardée dans l’intergiciel de témoin.
        Dans l’extrait de code, AuthenticationType est défini sur Auth0. Utilisez AuthenticationType dans la section suivante pour adresser un défi à l’intergiciel OpenID Connect et commencer le flux d’authentification. L’événement de notification RedirectToIdentityProvider génère la bonne 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 de 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 AuthenticationPropertiescorrespondantes, y compris un RedirectUri.
        Après avoir appelé avec succès HttpContext.GetOwinContext().Authentication.Challenge, l’utilisateur est redirigé vers Auth0 et est connecté à la fois à l’intergiciel OIDC et à l’intergiciel de témoin après avoir été redirigé vers votre application. Cela permettra aux utilisateurs d’être authentifiés pour les requêtes suivantes.
        ASP.NET (OWIN) – Étape 4 – Point de contrôle 
        Maintenant que vous avez configuré la fonction de déconnexion, lancez votre application pour vérifier que :
        • Naviguer vers votre fonctionnalité de Login vous redirigera vers Auth0.
        • Saisir vos identifiants vous redirigera vers votre 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.
        
+
+  
        
+
+## 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, lancez votre application pour vérifier que :
        • Naviguer vers votre fonctionnalité de 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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, le 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.
        
+
+  
        
+
+  
        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/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..9f38c382f7
--- /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 du SDK Authlib.
+interactive:  true
+files:
+ - files/webappexample/templates/index
+ - files/webappexample/settings
+ - files/webappexample/urls
+ - files/webappexample/views
+github:
+  path: https://github.com/auth0-samples/auth0-django-web-app/tree/master/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 du SDK Authlib.
        
+
+## Configurer 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 au moyen de 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, où vous pourrez gérer vos applications à l’avenir.
        Si vous préférez examiner une configuration complète, vous pouvez consulter un exemple d’application.
        Configuration des callback URL
        Une callback URL 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.
        Configurer les 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 authentification. 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
        
+
+## Configurer 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
        Passez au 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 imports 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. Conservez tout autre contenu de ce tableau inchangé.
        À la fin de ce fichier, ajoutez le code pour charger la configuration d’Auth0.
        
+
+## Configurer 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.
        Apprenez-en davantage lsur es options de configuration possibles pour la méthode register() d’Authlib OAuth dans 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 : les routes de connexion, de rappel, de déconnexion et d’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 des utilisateurs et leur évite d'avoir à se connecter à nouveau lorsqu’ils reviennent.
        • 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.
        
+
+## Lancer votre application
+
+
+
        Vous êtes prêts pour lancer votre application! À partir de votre répertoire 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 – Lancer 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.
        
+
+  
        
+
+  
        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/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..2401a8e226
--- /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 le SDK OpenID Connect Express.
+interactive:  true
+files:
+ - files/server
+github:
+  path: https://github.com/auth0-samples/auth0-express-webapp-sample/tree/master/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 le SDK OpenID Connect Express.
        
+
+## Configurer 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 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 le 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, vous pouvez plutôt consulter une application faisant office d’exemple.
        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 qu’ils se sont authentifiés. 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.
        Configurer les 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 authentification. 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 maintenu 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 : localhost:3000, ce lien sera 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.
        
+
+  
        
+
+## 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 l’intergiciel requiresAuth pour les routes qui nécessitent une authentification. Toute route utilisant cet intergiciel 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.
        
+
+  
        
+
+  
        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/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..3de97842f7
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/golang/interactive.md
@@ -0,0 +1,83 @@
+---
+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 ancienne.
+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: https://github.com/auth0-samples/auth0-golang-web-app/tree/master/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 ancienne.
        
+
+## Configurer 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, vous pouvez plutôt consulter une application faisant office d’exemple.
        Configuration des callback URL
        Une callback URL 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.
        Configurer les 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 authentification. 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 Domaine. Pour les domaines personnalisés, définissez-le plutôt sur la valeur de votre domaine personnalisé.
        • AUTH0_CLIENT_ID: L’ID 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 ID client.
        • AUTH0_CLIENT_SECRET: Le secret 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 secret client.
        • AUTH0_CALLBACK_URL: L’URL utilisée par Auth0 pour rediriger l’utilisateur après une authentification réussie.
        
+
+## Configurer 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 les 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 et callback
        
+
+## 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 entrer ses identifiants.
        Pour appeler la route /login ajoutez un lien vers /login dans le modèle home.html situé dans le répertoire 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 de 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 est passé à 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. Inside 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..cac9529970
--- /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: https://github.com/auth0-samples/auth0-java-ee-sample/tree/master/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.
        Configuration des callback URL
        Une callback URL 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 Allowed Callback URLs (Callback URL 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, la Callback URL que vous devez ajouter au champ Allowed Callback URLs (URL de déconnexion 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 Allowed Logout URLs (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 Allowed Logout URLs (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’identification et un jeton d’accès.
        • Elle utilise le jeton d’identification 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 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 ID token (Jeton d’identification) 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..96b5a12465
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/java-spring-boot/interactive.md
@@ -0,0 +1,198 @@
+---
+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: https://github.com/auth0-samples/auth0-spring-boot-login-samples/tree/master/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.
        
+
+## Configurer 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 vous intégrer. Dans Auth0, il est attribué à chaque application un identificateur 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 vous permettra de gérer vos applications.
        Si vous préférez explorer une configuration complète, vous pouvez plutôt consulter une application faisant office d’exemple.
        Configuration des Callback URL
        Une Callback URL 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 Auth0 Universal Login (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.
        
+
+  
        
+
+  
        
+
+  
        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 « Allowed Logout URLs (URL de déconnexion autorisées » dans les « Application Settings (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..25bcf993d3
--- /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 à n’importe quelle application Java Servlet, nouvelle ou ancienne.
+interactive:  true
+files:
+ - files/web
+ - files/AuthenticationControllerProvider
+ - files/LoginServlet
+ - files/CallbackServlet
+ - files/HomeServlet
+ - files/LogoutServlet
+github:
+  path: https://github.com/auth0-samples/auth0-servlet-sample/tree/master/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 de l’utilisateur dans votre application. Ce guide explique comment intégrer Auth0 à n’importe quelle application Java Servlet, nouvelle ou ancienne.
        
+
+## Configurer 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, vous pouvez plutôt consulter une application faisant office d’exemple.
        Configuration des callback URL
        Une callback URL 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.
        Configurer les 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. Il 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 fichier 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
        Le projet faisant office d’exemple, 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 callback URL 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 Universal Login[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 Allowed Callback URLs (Callback URL 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 notreCallbackServlet 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 de 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, changez de répertoire en dossier racine de 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 widget affiche toutes les connexions vis réseau social et de base de données que vous avez définies pour cette application dans dashboard.
        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..e39d3d699d
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/laravel/interactive.md
@@ -0,0 +1,61 @@
+---
+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: https://github.com/auth0-samples/laravel/tree/bf356d877b5dae566286fc8400da94b8b4b0ac76/sample
+locale: fr-CA
+---
+
+# Ajouter une connexion à votre application Laravel
+
+
+
        La 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 montre comment intégrer Auth0 avec une nouvelle (ou existante) application Laravel 9 ou 10.
        
+
+## Installation de Laravel
+
+
+
        Si vous n’avez pas déjà configuré une application Laravel, ouvrez un terminal 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 du répertoire racine de votre projet Laravel, donc vous devriez 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 SDK Laravel Auth0:
        composer require auth0/login:^7.8 --update-with-all-dependencies
        Puis, générez un fichier de configuration pour la trousse SDK pour votre application :
        php artisan vendor:publish --tag auth0
        
+
+## Configuration de la trousse SDK
+
+
+
        Exécutez la commande suivante à partir du répertoire de votre projet pour télécharger le CLI Auth0 :
        curl -sSfL https://raw.githubusercontent.com/auth0/auth0-cli/main/install.sh | sh -s -- -b .
        Ensuite, authentifiez l'interface de ligne de commande 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 :
        Vous devez également créer une nouvelle API :
        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.
        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 le fichier de mise à jour de la trousse SDK 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.
        Vous pouvez également exiger que les utilisateurs authentifiés aient des autorisations spécifiques en combinant cela avec l'intergiciel can de Laravel.
        
+
+## Renseignements de l’utilisateur {{{ data-action="code" data-code="routes/web.php#14:24" }}}
+
+
+
        Les renseignements de l’utilisateur authentifié sont disponibles via la Facade  Auth de Laravel, ou de la fonction helper auth().
        Par exemple, pour récupérer l’identifiant et l’adresse courriel de l’utilisateur :
        
+
+## Gestion des utilisateurs {{{ data-action="code" data-code="routes/web.php#26:43" }}}
+
+
+
        Vous pouvez mettre à jour les informations utilisateur en utilisant le Management API Auth0. Tous les terminaux de gestion sont accessibles via la méthode management() de la trousse SDK.
        Avant de faire des appels au Management API, vous devez permettre à votre application de communiquer avec le Management API. Cela peut être fait à partir de la page API du Auth0 Dashboard, en choisissant Auth0 Management API et en sélectionnant l’onglet « Machine to Machine Applications » (Communications de machine à machine). Autorisez 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 des permissions requises peuvent être trouvées dans la documentation de la Management API.
        Un guide de référence rapide de toutes les méthodes du 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
        • User Repositories and Models (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.
        • Hooking Events (Événements de rappel) explique comment intercepter les événements déclenchés par la trousse SDK Auth0 pour Laravel, afin de personnaliser entièrement le comportement de votre intégration.
        • Le support du Management API est intégré à la trousse SDK Laravel Auth0, vous permettant d’interagir avec le 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..515f3b4950
--- /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_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/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..ba3ee3a1b4
--- /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: https://github.com/auth0-samples/auth0-nextjs-samples/tree/main/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.
        
+
+## Configurer 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 vous intégrer. Dans Auth0, il est attribué à chaque application un identificateur 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 vous permettra de gérer vos applications.
        Si vous préférez explorer une configuration complète, vous pouvez plutôt consulter une application faisant office d’exemple.
        Configuration des Callback URL
        Une Callback URL 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 côté dorsal et le contexte React avec les appels React côté 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 Route handler (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 anchor tag (balise d’ancrage). En cliquant sur ce lien, vos utilisateurs seront redirigés vers la page de connexion universelle d’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 
        Ajoutez le lien de déconnexion à votre application. Lorsque vous cliquez dessus, vérifiez que votre application Next.js vous redirige vers l’adresse que vous avez indiquée comme l’une des « Allowed Logout URLs (URL de déconnexions autorisées) » dans les « Paramètres ».
        
+
+  
        
+
+  
        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/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..36723e2e95
--- /dev/null
+++ b/fr-ca/articles/quickstart/webapp/nginx-plus/interactive.md
@@ -0,0 +1,73 @@
+---
+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
+github:
+  path: https://github.com/nginxinc/nginx-openid-connect
+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 dépôt de modèles nginx-openid-connect
+
+
+
        Clonez le dépôt nginx-openid-connect. Ce dépôt est accompagné d’un modèle de configuration.
        git clone https://github.com/nginxinc/nginx-openid-connect
        
+
+## Configurer 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 remplir 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. Rendez-vous dans Applications > Applications, puis sélectionnez votre application dans la liste.
        2. Passez à la vue Paramètres .
        3. Dans la section URI de l’application, ajoutez https://{yourDomain}/_codexch aux Callback URL autorisées (.
        4. Passez à la vue Identifiants.
        Dans la section Authentification des applications, définissez 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..8779c3c23e
--- /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: https://github.com/auth0-samples/auth0-php-web-app/tree/main/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.
        
+
+## Configurer 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 vous intégrer. Dans Auth0, il est attribué à chaque application un identificateur 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 vous permettra de gérer vos applications.
        Si vous préférez explorer une configuration complète, vous pouvez plutôt consulter une application faisant office d’exemple.
        Configuration des Callback URL
        Une Callback URL 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 Allowed Web Origins (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 la prochaine fois qu'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 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 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 à la Callback URL que vous avez configurée précédemment dans ce guide rapide. Vous pouvez également trouver cette valeur dans Auth0 Dashboard, dans la rubrique des paramètres de votre application, dans le champ Callback URLs (Callback URL). 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é. Exécutez votre application pour vérifier que :
        • La trousse SDK est initialisée correctement.
        • Votre application ne génère aucune erreur liée à Auth0.
        
+
+  
        
+
+  
        
+
+  
        
+
+## 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 la Callback URL que vous avez configurée précédemment dans ce guide 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 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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é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 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 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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.
        Le 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 
        Verifiez que :
        • vous pouvez afficher le nickname ou toute autre propriété de l’utilisateur adéquatement, après vous être connecté.
        
+
+  
        
+
+  
        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/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..c752c240a6
--- /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: https://github.com/auth0-samples/auth0-python-web-app/tree/master/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.
        
+
+## Configurer 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 vous intégrer. Dans Auth0, il est attribué à chaque application un identificateur 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 vous permettra de gérer vos applications.
        Si vous préférez explorer une configuration complète, vous pouvez plutôt consulter une application faisant office d’exemple.
        Configuration des Callback URL
        Une Callback URL 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. Vous devez trouver un bouton de connexion redirigeant vers Auth0 pour vous connecter, puis revenir à votre application pour voir vos informations de profil.
        
+
+  
        
+
+  
        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/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..645cddeeb2
--- /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: https://github.com/auth0-samples/auth0-rubyonrails-sample/tree/master/sample
+locale: fr-CA
+---
+
+# Ajouter une connexion à votre application Ruby on Rails
+
+
+
        
+
+## Configurer 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, vous pouvez plutôt consulter une application faisant office d’exemple.
        Configuration des Callback URL
        Une callback URL 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.
        Configurer les 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 qu’ils se sont déconnectés. 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 rafraîchir 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.
        
+
+## Configurer 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 ID 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 « callback URL authorisé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 construire 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 hash 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 sur le contrôleur d’action 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 callback URL 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## Ajouter 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é.
        
+
+  
        
+
+  
        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.
        
+
+  
        
+
+## 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 unConcern pour contrôler l’accès aux routes qui peuvent être partagées entre plusieurs contrôleurs. Le concern devrait rediriger automatiquement vers Auth0 lorsque l’utilisateur n’est pas authentifié. Au cas contraire, le concern devrait renvoyer le profil utilisateur actuel.
        Une fois que vous avez un concern, incluez-le 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 développement Web 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/ja-jp/articles/libraries/lock-ios/_includes/_roadmap.md b/ja-jp/articles/libraries/lock-ios/_includes/_roadmap.md
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/ja-jp/articles/libraries/lock-ios/index.yml b/ja-jp/articles/libraries/lock-ios/index.yml
new file mode 100644
index 0000000000..4e65cc67bb
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/index.yml
@@ -0,0 +1,9 @@
+versioning:
+  baseUrl: libraries/lock-ios
+  current: v2
+  versions:
+    - v1
+    - v2
+  defaultArticles:
+    v1: index
+    v2: index
diff --git a/ja-jp/articles/libraries/lock-ios/v1/customization.md b/ja-jp/articles/libraries/lock-ios/v1/customization.md
new file mode 100644
index 0000000000..ed76e46250
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/customization.md
@@ -0,0 +1,111 @@
+---
+section: libraries
+title: Customization
+description: Learn how to customize the look and feel of Lock
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock iOS: Customization
+
+<%= include('../_includes/_lock-version-1') %>
+
+Lock UI can be customized by creating your own `A0Theme` and overriding the default one before displaying `A0LockViewController`:
+
+```objc
+A0Theme *myAwesomeTheme = [[A0Theme alloc] init];
+//Customize your theme
+[[A0Theme sharedInstance] registerTheme:myAwesomeTheme];
+```
+```swift
+let myAwesomeTheme = A0Theme()
+//Customize your theme
+A0Theme.sharedInstance().register(myAwesomeTheme)
+```
+
+## How to configure your Theme
+
+**Lock**'s UI is composed of several parts that can be customized
+
+Here is a list of the available values that can be customized:
+
+![](/media/articles/libraries/lock-ios/customization/Lock-UI-Parts.png)
+
+You can either configure some type of properties which are:
+
+* Color: `UIColor` instance.
+* Image: `NSString` with image name.
+* Font: `UIFont` instance.
+
+Example Usage
+
+```
+myAwesomeTheme.registerColorForKey(UIColor.redColor(), "A0ThemePrimaryButtonNormalColor");
+```
+
+This is the list of properties that can be customized:
+
+### Primary Button
+
+* A0ThemePrimaryButtonNormalColor
+* A0ThemePrimaryButtonHighlightedColor
+* A0ThemePrimaryButtonNormalImageName
+* A0ThemePrimaryButtonHighlightedImageName
+* A0ThemePrimaryButtonFont
+* A0ThemePrimaryButtonTextColor
+
+### Secondary Button
+
+* A0ThemeSecondaryButtonBackgroundColor
+* A0ThemeSecondaryButtonNormalImageName
+* A0ThemeSecondaryButtonHighlightedImageName
+* A0ThemeSecondaryButtonFont
+* A0ThemeSecondaryButtonTextColor
+
+### TextField
+
+* A0ThemeTextFieldFont
+* A0ThemeTextFieldTextColor
+* A0ThemeTextFieldPlaceholderTextColor
+* A0ThemeTextFieldIconColor
+
+### Title
+
+* A0ThemeTitleFont
+* A0ThemeTitleTextColor
+
+### Icon
+
+* A0ThemeIconBackgroundColor
+* A0ThemeIconImageName
+
+### Background
+
+* A0ThemeScreenBackgroundColor
+* A0ThemeScreenBackgroundImageName
+
+### Message & Description
+
+* A0ThemeDescriptionFont
+* A0ThemeDescriptionTextColor
+* A0ThemeSeparatorTextFont
+* A0ThemeSeparatorTextColor
+
+### CredentialBox
+
+* A0ThemeCredentialBoxBorderColor
+* A0ThemeCredentialBoxSeparatorColor
+* A0ThemeCredentialBoxBackgroundColor
+
+### Close Button
+
+* A0ThemeCloseButtonTintColor
diff --git a/ja-jp/articles/libraries/lock-ios/v1/delegation-api.md b/ja-jp/articles/libraries/lock-ios/v1/delegation-api.md
new file mode 100644
index 0000000000..81be9f0cf1
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/delegation-api.md
@@ -0,0 +1,70 @@
+---
+section: libraries
+title: Delegation API
+description: Integrate with third-party apps with the delegation API.
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+  - delegation
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock iOS: Delegation API
+
+<%= include('../_includes/_lock-version-1') %>
+
+<%= include('../../../_includes/_deprecate-delegation') %>
+
+After a successful authentication, you can request credentials to access third party apps like Firebase or AWS that are configured in your Auth0 App's Add-On section. In order to do that you need to make a request to our [Delegation API](/api/authentication/reference#delegation) using a valid JWT.
+
+Here's an example
+
+```objc
+A0Lock *lock = [A0Lock sharedLock];
+NSString *token = ...; // Auth0's ID Token obtained on login
+A0AuthParameters *parameters = [A0AuthParameters newWithDictionary:@{
+                                                                     @"id_token": token,
+                                                                     A0ParameterAPIType: @"firebase",
+                                                                     }];
+[[lock apiClient] fetchDelegationTokenWithParameters:parameters success:^(NSDictionary *delegationToken) {
+    // delegationToken will have your firebase token
+} failure:^(NSError *error) {
+    // Something went wrong
+}];
+```
+
+```swift
+let client = A0Lock.shared().apiClient()
+let token = // Auth0's ID Token obtained on login
+let parameters = A0AuthParameters.new(with: [
+    "id_token": token,
+    A0ParameterAPIType: "firebase"
+    ])
+client.fetchDelegationToken(with: parameters,
+    success: { payload in
+        // payload will have your firebase token
+    },
+    failure: { error in
+        // Something went wrong
+    })
+```
+
+The only two parameters required are `id_token` and the `api_type` (the value of `A0ParameterAPIType` constant).
+
+`api_type` specifies the API credentials we want to retrieve, and the API supported are:
+
+* app: Your Auth0 application. This will get a new JWT token.
+* aws: Amazon Web Services API.
+* azure_sb: Windows Azure Service Bus.
+* firebase: Firebase API.
+* salesforce_api: Salesforce API.
+* salesforce_sandbox_api: Salesforce Sandbox API.
+* sap_api: SAP OData.
+* wams: Windows Azure Mobile Services.
diff --git a/ja-jp/articles/libraries/lock-ios/v1/index.md b/ja-jp/articles/libraries/lock-ios/v1/index.md
new file mode 100644
index 0000000000..57b47e6a6c
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/index.md
@@ -0,0 +1,430 @@
+---
+section: libraries
+toc: true
+url: /libraries/lock-ios/v1
+title: Lock v1 for iOS and macOS
+snippets:
+  dependencies: native-platforms/ios-objc/dependencies
+description: A widget that provides a frictionless login and signup experience for your native iOS and macOS apps.
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+contentType:
+  - index
+  - how-to
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock v1 for iOS and macOS
+
+<%= include('../_includes/_lock-version-1') %>
+
+Auth0 is an authentication broker that supports social identity providers as well as enterprise identity providers such as Active Directory, LDAP, G Suite and Salesforce.
+
+## Key features
+
+* **Integrates** your iOS app with **Auth0** (OS X coming soon).
+* Provides a elegant **native UI** to log in your users.
+* Provides support for **Social Providers** (Facebook, Twitter, and so on), **Enterprise Providers** (AD, LDAP, and so on) and **Username & Password** authentication.
+* Provides the ability to do **Single Sign-on (SSO)** with 2 or more mobile apps, similar to Facebook and Messenger apps.
+* [1Password](https://agilebits.com/onepassword) integration using the **iOS 8** [Extension](https://github.com/AgileBits/onepassword-app-extension).
+
+::: note
+Check out the [Lock.swift repository](https://github.com/auth0/Lock.swift/tree/v1) on GitHub.
+:::
+
+## Requirements
+
+iOS 7+. If you need to use our SDK with an earlier version, use the previous SDK pod `Auth0Client`, or see the [old-sdk](https://github.com/auth0/Lock.iOS-OSX/tree/old-sdk) branch of the Lock.iOS-OSX repo.
+
+## Installation
+
+Lock is available through [CocoaPods](http://cocoapods.org). To install it, simply add the following line to your Podfile:
+
+${snippet(meta.snippets.dependencies)}
+
+Then, in your project's `Info.plist` file, add the following string entries:
+
+* __Auth0ClientId__: The client ID of your Auth0 application.
+* __Auth0Domain__: Your Auth0 account domain.
+
+For example:
+![plist](/media/articles/libraries/lock-ios/plist.png)
+
+::: note
+You can find these values in your [Application Settings](${manage_url}/#/applications) in the Auth0 dashboard.
+:::
+
+You will also need to register a **Custom URL** type with a custom scheme in the following format:
+
+`a0{Your Client ID}`
+
+For example, if your Client ID is `Exe6ccNagokLH7mBmzFejP`, the custom scheme would be `a0Exe6ccNagokLH7mBmzFejP`.
+
+Before you can begin using Lock, you will need to import Lock into your codebase.
+
+If you are working in Objective-C, import this header when you need to use Lock's classes:
+
+```objc
+#import 
+```
+
+The same applies if you are working in Swift and Lock is included as a static library. In this case, the header must also be included in your _Objective-C Bridging Header_.
+
+::: note
+If you need help creating the Objective-C Bridging Header, see: [Swift and Objective-C in the Same Project](https://developer.apple.com/library/ios/documentation/swift/conceptual/buildingcocoaapps/MixandMatch.html).
+:::
+
+If you are working in Swift with Lock included as an framework, just include the module in your Swift files like this:
+
+```swift
+import Lock
+```
+
+Now you can initialize `A0Lock` (which handles authentication) and keep it in your `AppDelegate` as a **strong** property.
+
+::: note
+You can store `A0Lock` in a different location as long as you keep it alive as long as it is needed.
+:::
+
+This examples creates `A0Lock` inside `-application:didFinishLaunchingWithOptions:`
+
+**Objective C**:
+
+```objc
+self.lock = [A0Lock newLock];
+```
+
+**Swift**:
+
+```swift
+self.lock = A0Lock()
+```
+
+Then call this method:
+
+**Objective C**:
+
+```objc
+[self.lock applicationLaunchedWithOptions:launchOptions];
+```
+
+**Swift**:
+
+```swift
+lock.applicationLaunched(options: launchOptions)
+```
+
+Lastly, you will need to handle the already registered custom scheme in your `AppDelegate`. To do so, override the `-application:openURL:options:` method and add the following line:
+
+**Objective C**:
+
+```objc
+- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url
+            options:(NSDictionary *)options {
+    return [self.lock handleURL:url sourceApplication:app];
+}
+```
+
+**Swift**:
+
+```swift
+func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool {
+    return self.lock.handle(url, sourceApplication: app)
+}
+```
+
+This call is required to be able to return to your application when authenticating with Safari, or with native integration with Facebook or Twitter. This call checks the URL and handles those that have the custom scheme.
+
+## Usage
+
+### Email/password, enterprise, and social provider authentication
+
+`A0LockViewController` will handle email/password, enterprise, and social provider authentication based on the connections enabled on your application in the [Auth0 Dashboard](${manage_url}/#/connections/social).
+
+First, instantiate `A0LockViewController` and register the authentication callback that will receive the authenticated user's credentials. Then present it as a modal view controller:
+
+#### Objective C
+
+```objc
+A0Lock *lock = ... //Fetch Lock from where its stored
+A0LockViewController *controller = [lock newLockViewController];
+controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) {
+    // Do something with token & profile (such as save them).
+    // Lock will not save the Token and the profile for you.
+    // And dismiss the UIViewController.
+    [self dismissViewControllerAnimated:YES completion:nil];
+};
+[self presentViewController:controller animated:YES completion:nil];
+```
+
+#### Swift
+
+```swift
+let lock = ... // Fetch Lock from where its stored
+let controller: A0LockViewController = lock.newLockViewController()
+controller.onAuthenticationBlock = { (profile, token) in
+    // Do something with token & profile (such as save them).
+    // Lock will not save the Token and the profile for you.
+    // And dismiss the UIViewController.
+    self.dismiss(animated: true, completion: nil)
+}
+lock.present(controller, from: self)
+```
+
+You will see the Lock native login screen:
+
+
      Lock-iOS
      
+
+::: note
+By default, all social authentication will be done using Safari. If you want native integration, see: [Lock iOS: Native Social Authentication](/libraries/lock-ios/native-social-authentication).
+:::
+
+### Close Lock UI
+
+You can add a **Close** button to Lock UI. For this to function, you will need to set the `closable` property to allow the `A0AuthenticationViewController` to be dismissed. The default value is `NO`.
+
+If you want to handle the closing event, you will need to add the `onUserDismissBlock` block which will be called when the user dismisses the Login screen only if the `closable` property is set to `YES`.
+
+#### Objective C
+
+```objc
+A0Lock *lock = [A0Lock sharedLock];
+A0LockViewController *controller = [lock newLockViewController];
+controller.closable = YES;
+
+controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) {
+  // Do something with token & profile (such as save them).
+  // And dismiss the ViewController
+};
+
+controller.onUserDismissBlock = ^(){
+  NSLog(@"User closed Lock UI");
+};
+
+[self presentViewController:controller animated:YES completion:nil];
+```
+
+#### Swift
+
+```swift
+let controller: A0LockViewController = A0Lock.shared().newLockViewController()
+controller.closable = true
+
+controller.onAuthenticationBlock = { (profile, token) in
+    // Do something with token & profile (such as save them).
+    // And dismiss the ViewController
+}
+
+controller.onUserDismissBlock = { _ in
+    print("User closed Lock UI")
+}
+
+self.present(controller, animated: true, completion: nil)
+```
+
+### Sign-up
+
+There are different approaches to implement Sign-up functionality:
+
+1. You can add or hide the **Sign Up** button in Lock UI by setting the `disableSignUp` property which will hide the **Sign Up** button when set to `YES`. The default value  is `NO`.
+
+2. Another approach is to use the `A0LockSignUpViewController` directly:
+
+#### Objective-C
+
+```objc
+A0Lock *lock = [A0Lock sharedLock];
+A0LockSignUpViewController *controller = [lock newSignUpViewController];
+
+controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) {
+  // Do something with token & profile (such as save them).
+  // And dismiss the ViewController
+};
+
+[self presentViewController:controller animated:YES completion:nil];
+```
+
+#### Swift
+
+```swift
+let controller: A0LockViewController = A0Lock.shared().newSignUpViewController()
+controller.onAuthenticationBlock = { (profile, token) in
+    // Do something with token & profile (such as save them).
+    // And dismiss the ViewController
+}
+
+self.present(controller, animated: true, completion: nil)
+```
+
+
+3. A third option is to create your own sign up `viewController` to implement the sign-up logic with one of the `A0APIClient` methods:
+
+```
+- (NSURLSessionDataTask *)signUpWithEmail:(NSString *)email
+                                 username:(nullable NSString *)username
+                                 password:(NSString *)password
+                           loginOnSuccess:(BOOL)loginOnSuccess
+                               parameters:(nullable A0AuthParameters *)parameters
+                                  success:(A0APIClientSignUpSuccess)success
+                                  failure:(A0APIClientError)failure;
+```
+
+Your `viewController` should also implement the `A0LockEventDelegate` methods:
+
+```
+- (void)backToLock; - Dismisses all custom UIViewControllers pushed inside Lock and shows the main UI.
+- (void)dismissLock; - Dismisses A0LockViewController, like clicking the Close button if `closable` is true
+- (void)userAuthenticatedWithToken:(A0Token *)token profile:(A0UserProfile *)profile; - Calls `onAuthenticationBlock` of `A0LockViewController` with token and profile
+```
+
+After implementing your `viewController`, you will need to return it in a `customSignUp` block of `A0LockViewController`. The default value for this block is `nil`.
+
+**Objective-C**:
+
+```objc
+A0Lock *lock = [A0Lock sharedLock];
+
+A0LockViewController *controller = [lock newLockViewController];
+controller.closable = YES;
+
+controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) {
+    [self dismissViewControllerAnimated:YES completion:nil];
+};
+
+//Create custom SignUp view controller
+controller.customSignUp = ^ UIViewController *(A0Lock *lock, A0LockEventDelegate *delegate) {
+
+  YourCustomSignUpVC *signUpVC = …//your viewController;
+  signUpVC.delegate = delegate;
+  signUpVC.lock = lock;
+
+  return signUpVC;
+};
+
+UINavigationController *navController = [[UINavigationController alloc] initWithRootViewController:controller];
+
+if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) {
+  navController.modalPresentationStyle = UIModalPresentationFormSheet;
+}
+
+[self presentViewController:navController animated:YES completion:nil];
+```
+
+**Swift**:
+
+```swift
+let controller: A0LockViewController = A0Lock.shared().newLockViewController()
+
+controller.onAuthenticationBlock = { (profile, token) in
+    self.dismiss(animated: true, completion: nil)
+}
+
+// Create custom SignUp view controller
+controller.customSignUp = { (lock, delegate) in
+    let YourCustomSignUpVC = // Your viewController;
+    signUpVC.lock = lock
+    signUpVC.delegate = delegate
+
+    return signUpVC
+}
+
+let navController:UINavigationController = UINavigationController.init(rootViewController: controller)
+
+if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiom.pad) {
+    navController.modalPresentationStyle = UIModalPresentationStyle.formSheet
+
+}
+self.present(navController, animated: true, completion: nil)
+```
+
+### Automatic login after sign-up
+
+After a successful sign-up, the user can be logged in automatically using the `loginAfterSignUp` property. If `loginAfterSignUp` is set to `YES`, `A0AuthenticationViewController` will attempt to log in the user . Otherwise, it will call `onAuthenticationBlock` with both parameters set to `nil`. The default value of `loginAfterSignUp` is `YES`.
+
+### Disclaimer View
+
+If you want to show a disclaimer for your app, you will need to set `signUpDisclaimerView`. This view will appear at the bottom of the sign-up screen.
+
+## Logout
+
+To log out a user, call `clearSessions` for `A0Lock`. This method removes all stored sessions of any IdP in your application.
+
+:::note
+* If the user has logged in using Safari, their sessions will not be cleared.
+* If you stored the credentials in the keychain, you need to clear them there as well.
+:::
+
+### Objective-C
+
+```objc
+A0Lock *lock = [A0Lock sharedLock];
+[lock clearSessions];
+A0SimpleKeychain *keychain = [A0SimpleKeychain keychainWithService:];
+[keychain clearAll];
+//redirect the user to Login Page
+```
+
+### Swift
+
+```swift
+A0Lock.shared().clearSessions()
+let keychain = A0SimpleKeychain(service: )
+keychain.clearAll()
+//redirect the user to Login Page
+```
+
+## WebView
+
+When authenticating with a social connection, you can choose between using Safari or the embedded webView. To use embedded webView, set the `useWebView` property to `YES`. The default value is `YES`.
+
+### Objective-C
+
+```objc
+A0Lock *lock = [A0Lock sharedLock];
+A0LockViewController *controller = [lock newLockViewController];
+controller.useWebView = NO;
+
+controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) {
+  // Do something with token & profile (such as save them).
+  // And dismiss the ViewController
+};
+controller.onUserDismissBlock = ^(){
+[self presentViewController:controller animated:YES completion:nil];
+```
+
+### Swift
+
+```swift
+let controller: A0LockViewController = A0Lock.shared().newLockViewController()
+controller.useWebView = false
+controller.onAuthenticationBlock = { (profile, token) in
+    // Do something with token & profile (such as save them).
+    // And dismiss the ViewController
+}
+self.present(controller, animated: true, completion: nil)
+```
+
+## Additional Information
+
+See the [Swift](https://github.com/auth0-samples/auth0-ios-swift-sample) and [Objective-C](https://github.com/auth0-samples/auth0-ios-objc-sample) example apps.
+
+For more information on how to use Lock with Swift, see: [Lock iOS: Using Swift](/libraries/lock-ios/swift).
+
+For more information on Lock for CocoaPods, see the [Lock documentation in CocoaDocs](http://cocoadocs.org/docsets/Lock).
+
+## Further reading
+
+::: next-steps
+- [Customization of the Look and Feel of Lock iOS](/libraries/lock-ios/v1/customization)
+- [Lock iOS API](/libraries/lock-ios/v1/lock-ios-api)
+- [Native Social Authentication](/libraries/lock-ios/v1/native-social-authentication)
+- [Passwordless](/libraries/lock-ios/v1/passwordless)
+- [Sending Authentication Parameters](/libraries/lock-ios/v1/sending-authentication-parameters)
+- [Using Swift with Lock iOS v1](/libraries/lock-ios/v1/swift)
+:::
diff --git a/ja-jp/articles/libraries/lock-ios/v1/lock-ios-api.md b/ja-jp/articles/libraries/lock-ios/v1/lock-ios-api.md
new file mode 100644
index 0000000000..660eb5dbe3
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/lock-ios-api.md
@@ -0,0 +1,245 @@
+---
+section: libraries
+title: Lock Objective-C API
+description: Description of the Lock Objective-C API
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+  - objective-c
+contentType:
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock Objective-C API
+
+<%= include('../_includes/_lock-version-1') %>
+
+## A0Lock
+
+### A0Lock#newLock
+
+```objc
++ (instancetype)newLock;
+```
+
+Creates a new `A0Lock` instance using account information from Info.plist file.
+
+```objc
+A0Lock *lock = [A0Lock newLock];
+```
+
+#### A0Lock#newLockWithClientId:domain:
+
+```objc
++ (instancetype)newLockWithClientId:(NSString *)clientId domain:(NSString *)domain;
+```
+
+Creates a new `A0Lock` instance with Auth0 clientId and domain.
+
+```objc
+A0Lock *lock = [A0Lock newLockWithClientId:@"YOUR_CLIENT_ID" domain:@"YOUR_DOMAIN"];
+```
+
+#### A0Lock#newLockWithClientId:domain:configurationDomain:
+
+```objc
++ (instancetype)newLockWithClientId:(NSString *)clientId domain:(NSString *)domain configurationDomain:(NSString *)configurationDomain;
+```
+
+Creates a new `A0Lock` instance with Auth0 clientId, domain and configurationDomain.
+
+```objc
+A0Lock *lock = [A0Lock newLockWithClientId:@"YOUR_CLIENT_ID" domain:@"YOUR_DOMAIN" configurationDomain:@"YOUR_CONFIG_DOMAIN"];
+```
+
+#### A0Lock#apiClient
+
+```objc
+- (A0APIClient *)apiClient;
+```
+
+Returns an instance of the API application for Authentication API configured for your application.
+
+```objc
+A0APIClient *client = [lock apiClient];
+```
+
+#### A0Lock#newUserAPIClientWithIdToken
+
+```objc
+- (A0UserAPIClient *)newUserAPIClientWithIdToken:(NSString *)idToken;
+```
+
+Returns a new instance of the API client for Auth0 API with the credentials of a authenticated user obtained from the **ID Token**
+
+```objc
+A0UserAPIClient *client = [lock newUserAPIClientWithIdToken:@"AN ID TOKEN"];
+```
+
+#### A0Lock#handleURL:sourceApplication:
+
+```objc
+- (BOOL)handleURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication;
+```
+
+Handle URL received from AppDelegate when application is called from a third party at the end of an authentication flow.
+
+```objc
+[lock handleURL:URL sourceApplication:sourceApplication];
+```
+
+#### A0Lock#registerAuthenticators
+
+```objc
+- (void)registerAuthenticators:(NSArray *)authenticators;
+```
+
+Register IdP authenticators that will be used for Social & Enterprise connections. By default all Social & Enterprise authentications are performed by using the web flow with Safari but you can plug your own authenticator for a connection (for example, you can register `A0FacebookAuthenticator` in order to login with FB native SDK).
+
+```objc
+[lock registerAuthenticators:@[facebook, twitter]];
+```
+
+#### A0Lock#applicationLaunchedWithOptions
+
+```objc
+- (void)applicationLaunchedWithOptions:(NSDictionary *)launchOptions;
+```
+
+Handle application launched event.
+
+```objc
+[lock applicationLaunchedWithOptions:launchOptions];
+```
+
+#### A0Lock#clearSessions
+
+```objc
+- (void)clearSessions;
+```
+
+Remove all stored sessions of any IdP in your application. If the user logged in using Safari, those sessions will not be cleaned.
+
+```objc
+[lock clearSessions];
+```
+
+### A0LockViewController
+
+#### A0LockViewController#init
+
+```objc
+- (instancetype)initWithLock:(A0Lock *)lock;
+```
+
+Initialise 'A0LockViewController' using a `A0Lock` instance.
+
+```objc
+A0LockViewController *controller = [[A0LockViewController alloc] initWithLock:lock];
+```
+
+#### A0LockViewController#onAuthenticationBlock
+
+```objc
+@property (copy, nonatomic) void(^onAuthenticationBlock)(A0UserProfile *profile, A0Token *token);
+```
+
+Block that is called on successful authentication. It has two parameters profile and token, which will be non-nil unless login is disabled after signup.
+
+```objc
+controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) {
+  NSLog(@"Auth successful: profile %@, token %@", profile, token);
+};
+```
+
+#### A0LockViewController#onUserDismissBlock
+
+```objc
+@property (copy, nonatomic) void(^onUserDismissBlock)();
+```
+
+Block that is called on when the user dismisses the Login screen. Only when `closable` property is `YES`.
+
+```objc
+controller.onUserDismissBlock = ^() {
+  NSLog(@"User dismissed login screen.");
+};
+```
+
+#### A0LockViewController#usesEmail
+
+```objc
+@property (assign, nonatomic) BOOL usesEmail;
+```
+
+Enable the username to be treated as an email (and validated as one too) in all Auth0 screens. Default is `YES`
+
+```objc
+controller.usesEmail = NO;
+```
+
+#### A0LockViewController#closable
+
+```objc
+@property (assign, nonatomic) BOOL closable;
+```
+
+Allows the `A0LockViewController` to be dismissed by adding a button. Default is `NO`
+
+```objc
+controller.closable = YES;
+```
+
+#### A0LockViewController#loginAfterSignup
+
+```objc
+@property (assign, nonatomic) BOOL loginAfterSignUp;
+```
+
+After a successful Signup, `A0LockViewController` will attempt to login the user if this property is `YES` otherwise will call `onAuthenticationBlock` with both parameters nil. Default value is `YES`
+
+```objc
+controller.loginAfterSignup = NO;
+```
+
+#### A0LockViewController#authenticationParameters
+
+```objc
+@property (assign, nonatomic) A0AuthParameters *authenticationParameters;
+```
+
+List of optional parameters that will be used for every authentication request with Auth0 API. By default it only has  'openid' and 'offline_access' scope values. For more information check out our [Wiki](/libraries/lock-ios/sending-authentication-parameters)
+
+```objc
+controller.authenticationParameters.scopes = @[A0ScopeOfflineAccess, A0ScopeProfile];
+```
+
+### A0LockViewController#signupDisclaimerView
+
+```objc
+@property (strong, nonatomic) UIView *signUpDisclaimerView;
+```
+
+View that will appear in the bottom of Signup screen. It should be used to show Terms & Conditions of your app.
+
+```objc
+UIView *view = //..
+controller.signupDisclaimerView = view;
+```
+
+#### A0LockViewController#useWebView
+
+```objc
+@property (assign, nonatomic) BOOL useWebView;
+```
+
+When the authentication requires to open a web login, for example Linkedin, it will use an embedded UIWebView instead of Safari if it's `YES`. We recommend using Safari for Authentication since it will always save the User session. This means that if the user is already signed in, for example in Linkedin, and they click on the Linkedin button, it will just work. Default values is `NO`
+
+```objc
+controller.useWebView = YES
+```
diff --git a/ja-jp/articles/libraries/lock-ios/v1/logging.md b/ja-jp/articles/libraries/lock-ios/v1/logging.md
new file mode 100644
index 0000000000..f33ff75ea7
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/logging.md
@@ -0,0 +1,72 @@
+---
+section: libraries
+title: Logging
+description: Learn how to debug Lock by enabling logging.
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock iOS: Logging
+
+<%= include('../_includes/_lock-version-1') %>
+
+Lock logs several pieces of useful debugging information using [CocoaLumberjack](https://github.com/CocoaLumberjack/CocoaLumberjack).
+
+
+::: note
+If you are using a Lock version older than `1.10.0` please check [here](#lock-versions-1-10-0)
+:::
+
+By default all log messages are disabled but you can enable them in your `AppDelegate.m` (or `AppDelegate.swift`), for example if you want __Lock__'s error messages just add this line:
+
+```objc
+[A0LockLogger logError];
+```
+```swift
+A0LockLogger.logError()
+```
+
+Or if you want to all debug messages:
+
+```objc
+[A0LockLogger logAll];
+```
+```swift
+A0LockLogger.logAll()
+```
+
+::: note
+If you are already using `CocoaLumberjack`, you need to enable __Lock__'s log after you register CocoaLumberjack's loggers.
+:::
+
+## Lock versions < 1.10.0
+Go to `A0Logging.h` and change the `auth0LogLevel` variable with the Log Level you'll want to see. for example:
+```objc
+static const int auth0LogLevel = LOG_LEVEL_ALL;
+```
+
+And then you'll need to configure CocoaLumberjack (if you haven't done it for your app). You need to do it once so we recommend doing it in your `AppDelegate`:
+
+```objc
+#import 
+#import 
+#import 
+
+@implementation A0AppDelegate
+
+- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
+    [DDLog addLogger:[DDASLLogger sharedInstance]];
+    [DDLog addLogger:[DDTTYLogger sharedInstance]];
+    return YES;
+}
+
+@end
+```
diff --git a/ja-jp/articles/libraries/lock-ios/v1/native-social-authentication.md b/ja-jp/articles/libraries/lock-ios/v1/native-social-authentication.md
new file mode 100644
index 0000000000..56a08f5617
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/native-social-authentication.md
@@ -0,0 +1,97 @@
+---
+section: libraries
+title: Native Social Authentication
+description: How to enable native login for some the supported social social connections.
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+  - native
+  - social-connections
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock iOS: Native Social Authentication
+
+<%= include('../_includes/_lock-version-1') %>
+
+::: warning
+This feature relies on a deprecated grant type. Applications created after June 8th 2017 won't be able to use this feature.
+We recommend using browser-based flows, as explained in [Web-based auth](/libraries/auth0-swift#web-based-auth-ios-only-).
+:::
+
+**Lock** by default handles all social authentication with Safari (Web Login), but you can enable native login for some social connections. Currently we only provide integration with Facebook, Google & Twitter that can be included like this in your `Podfile`
+```ruby
+pod 'Lock-Facebook'
+pod 'Lock-Twitter'
+pod 'Lock-Google'
+```
+
+::: note
+We recommend to at least fix the major version instead of always obtaining the latest version, e.g `pod 'Lock-Facebook', '~> 2.0`
+:::
+
+## Configuration
+
+::: note
+Before following these steps, please check our [documentation](/libraries/lock-ios)
+:::
+
+### Facebook
+
+Lock uses Facebook iOS SDK to obtain user's Access Token so you'll need to configure it using your Facebook App info:
+
+First, add the following entries to the `Info.plist`:
+* _FacebookAppID_: `YOUR_FACEBOOK_APP_ID`
+* _FacebookDisplayName_: `YOUR_FACEBOOK_DISPLAY_NAME`
+
+Then register a custom URL Type with the format `fb`. For more information please check [Facebook Getting Started Guide](https://developers.facebook.com/docs/ios/getting-started).
+
+Here's an example of how the entries should look like in your `Info.plist` file:
+
+![FB plist](/media/articles/libraries/lock-ios/fb-plist.png)
+
+Finally, you need to register `A0FacebookAuthenticator` with your instance of `A0Lock`:
+
+```objc
+A0Lock *lock = ...//Get your Lock instance
+A0FacebookAuthenticator *facebook = [A0FacebookAuthenticator newAuthenticationWithDefaultPermissions];
+[lock registerAuthenticators:@[facebook]];
+```
+
+### Twitter
+
+Twitter authentication is done using [Reverse Auth](https://dev.twitter.com/docs/ios/using-reverse-auth) in order to obtain a valid Access Token that can be sent to Auth0 Server and validate the user. By default we use iOS Twitter Integration but we support OAuth Web Flow (with Safari) as a fallback mechanism in case a user has no accounts configured in his/her Apple Device.
+
+To support Twitter authentication you need to register `A0TwitterAuthenticator` with your instance of `A0Lock`:
+
+```objc
+A0Lock *lock = ...//Get your Lock instance
+NSString *twitterApiKey = ... //Remember to obfuscate your api key
+NSString *twitterApiSecret = ... //Remember to obfuscate your api secret
+A0TwitterAuthenticator *twitter = [A0TwitterAuthenticator newAuthenticatorWithKey:twitterApiKey                                                                            andSecret:twitterApiSecret];
+[lock registerAuthenticators:@[twitter]];
+```
+
+We need your twitter app's key & secret in order to sign the reverse auth request. For more info please read the Twitter documentation related to [Authorizing Requests](https://dev.twitter.com/docs/auth/authorizing-request) and [Reverse Auth](https://dev.twitter.com/docs/ios/using-reverse-auth).
+
+### Google
+
+Google authentication uses [Google Sign-In](https://developers.google.com/identity/sign-in/ios/) iOS library, so you'll need to register your iOS application in [Google Developer Console](https://console.developers.google.com/project) and get your clientId.
+
+We recommend following [this wizard](https://developers.google.com/mobile/add?platform=ios) instead and download the file `GoogleServices-Info.plist` that is generated at the end.
+
+Then add that file to your application's target and the last step is to register two custom URL for your application.
+
+The first URL should have a scheme equal to your application Bundle Identifier, the other one should be your Google clientId reversed, so if your clientID is `CLIENTID.apps.googleusercontent.com` the scheme will be `com.googleusercontent.apps.CLIENTID`.
+
+::: note
+This last value can be found in `GoogleServices-Info.plist` under the key `REVERSED_CLIENT_ID`. For more information please check Google's [documentation](https://developers.google.com/identity/sign-in/ios/).
+:::
+
+And finally with your Mobile clientID from Google, go to [Social Connections](${manage_url}/#/connections/social), select **Google** and add the clientID to the field named `Allowed Mobile Client IDs`
diff --git a/ja-jp/articles/libraries/lock-ios/v1/password-reset-ios.md b/ja-jp/articles/libraries/lock-ios/v1/password-reset-ios.md
new file mode 100644
index 0000000000..9d7462f62f
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/password-reset-ios.md
@@ -0,0 +1,66 @@
+---
+section: libraries
+title: Password Reset
+description: All you need to know about password reset with Lock for iOS.
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+  - passwords
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock iOS: Password Reset
+
+<%= include('../_includes/_lock-version-1') %>
+
+You can allow the user to reset their password for any database connections.
+
+If you use Lock UI, you can hide or show a **Reset password** button by setting the `disableResetPassword` property, which will default to `false`.
+
+If you implement a custom UI, you need to send a password reset email to the user using `A0APIClient`.
+
+::: note
+Please see [Password Strength in Auth0 Database Connections](/connections/database/password-strength) before implementing password reset.
+:::
+
+## Important considerations
+
+Passwords can only be changed for users signing in using database connections. If a user is signing in with a social or enterprise connection, their password would need to be reset in those platforms.
+
+## Example: Objective-C
+
+```objc
+A0Lock *lock = [A0Lock sharedLock];
+A0APIClient *client = [lock apiClient];
+A0AuthParameters *params = [A0AuthParameters newDefaultParams];
+params[A0ParameterConnection] = @"Username-Password-Authentication";
+                                // Or your configured DB connection
+
+[client requestChangePasswordForUsername:
+                              parameters:params
+                                 success:^{
+                                     NSLog(@"Please check your email!");
+                                 } failure:^(NSError * _Nonnull error) {
+                                     NSLog(@"Oops something went wrong: %@", error);
+                                 }];
+```
+
+## Example: Swift
+
+```swift
+let client = A0Lock.shared().apiClient()
+let params = A0AuthParameters.newDefaultParams();
+params[A0ParameterConnection] = "Username-Password-Authentication";
+// Or your configured DB connection
+client.requestChangePassword(forUsername: "", parameters: params,
+success: { _ in
+    print("Please check your email!")
+}, failure: { error in
+    print("Oops something went wrong: \(error)")
+})
+```
diff --git a/ja-jp/articles/libraries/lock-ios/v1/passwordless.md b/ja-jp/articles/libraries/lock-ios/v1/passwordless.md
new file mode 100644
index 0000000000..6296f23b3c
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/passwordless.md
@@ -0,0 +1,119 @@
+---
+section: libraries
+title: Passwordless in Lock iOS v1
+description: How to implement Passwordless authentication in Lock v1
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+  - passwordless
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Passwordless in Lock iOS v1
+
+<%= include('../_includes/_lock-version-1') %>
+
+<%= include('../../../_includes/_native_passwordless_warning') %>
+
+## Passwordless with SMS
+
+`A0SMSLockViewController` authenticates without using a password with SMS. In order to be able to authenticate the user, your application must have the SMS connection enabled and configured in your [dashboard](${manage_url}/#/connections/passwordless).
+
+First instantiate `A0SMSLockViewController` and register the authentication callback that will receive the authenticated user's credentials.
+
+The next step is register a block to return an API Token used to register the  phone number and send the login code with SMS. This token can be generated in  [Auth0 API v2 page](/api/v2), just select the scope `create:users` and copy the generated API Token.
+
+Finally present it to the user:
+```objc
+A0Lock *lock = ... //Fetch Lock from where its stored
+A0SMSLockViewController *controller = [lock newSMSViewController];
+controller.auth0APIToken = ^{
+    return @"Copy API v2 token here";
+};
+controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) {
+    // Do something with token & profile (such as save them).
+    // Lock will not save the Token and the profile for you.
+    // And dismiss the UIViewController.
+    [self dismissViewControllerAnimated:YES completion:nil];
+};
+[lock presentSMSController:controller fromController:self];
+```
+
+```swift
+let lock = ... // Fetch Lock from where its stored
+let controller: A0SMSLockViewController = lock.newSMSViewController()
+controller.onAuthenticationBlock = { (profile, token) in
+   // Do something with token & profile (such as save them).
+   // Lock will not save the Token and the profile for you.
+   // And dismiss the UIViewController.
+   self.dismiss(animated: true, completion: nil)
+}
+lock.presentSMSController(controller, from: self)
+```
+And you'll see SMS login screen
+
+![Lock SMS Screenshot](/media/articles/libraries/lock-ios/Lock-SMS-Screenshot.png)
+
+## Passwordless with Touch ID
+
+Lock provides passwordless authentication with Touch ID for your Auth0 DB connection. To start authenticating your users with Touch ID please follow those steps:
+
+1. Add `TouchID` subspec module of **Lock** to your `Podfile`
+  ```ruby
+  pod 'Lock/TouchID'
+  ```
+
+1. Import **Lock**'s umbrella header
+  ```objc
+  #import 
+  ```
+  ::: note
+  If your are coding in Swift, you need to import the header in your app's [Bridging Header](https://developer.apple.com/library/ios/documentation/swift/conceptual/buildingcocoaapps/MixandMatch.html).
+  :::
+
+1. Instantiate `A0TouchIDLockViewController` and register authentication callback
+  ```objc
+  A0TouchIDLockViewController *controller = [[A0TouchIDLockViewController alloc] init];
+  controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) {
+      //Store token & profile. For example in the keychain using SimpleKeychain.
+      [self dismissViewControllerAnimated:YES completion:nil];
+  };
+  ```
+  ```swift
+  let lock = A0Lock.shared()
+  let controller: A0TouchIDLockViewController = lock.newTouchIDViewController()
+  controller.onAuthenticationBlock = { (profile, token) in
+      // Do something with token & profile (such as save them).
+      // Lock will not save the Token and the profile for you.
+      // And dismiss the UIViewController.
+      self.dismiss(animated: true, completion: nil)
+  }
+  ```
+
+1. Present `A0TouchIDLockViewController` as the root controller of a `UINavigationController`
+  ```objc
+  UINavigationController *navController = [[UINavigationController alloc] initWithRootViewController:controller];
+  if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) {
+      navController.modalPresentationStyle = UIModalPresentationFormSheet;
+  }
+  [self presentViewController:navController animated:YES completion:nil];
+  ```
+  ```swift
+  let navController = UINavigationController(rootViewController: controller)
+  if UIDevice.current.userInterfaceIdiom == .pad {
+      navController.modalPresentationStyle = .FormSheet
+  }
+  self.presentViewController(navController, animated: true, completion:nil)
+  ```
+  ::: note
+  It's mandatory to present `A0TouchIDLockViewController` embedded in a `UINavigationController`.
+  :::
+
+And you'll see TouchID login screen.
+
+![Lock Screenshot](/media/articles/libraries/lock-ios/Lock-TouchID-Screenshot.png)
diff --git a/ja-jp/articles/libraries/lock-ios/v1/save-and-refresh-jwt-tokens.md b/ja-jp/articles/libraries/lock-ios/v1/save-and-refresh-jwt-tokens.md
new file mode 100644
index 0000000000..69be180f58
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/save-and-refresh-jwt-tokens.md
@@ -0,0 +1,146 @@
+---
+section: libraries
+title: Saving and Refreshing JWT Tokens
+description: Keeping your user logged in
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+  - tokens
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock iOS: Saving and Refreshing JWT Tokens
+
+<%= include('../_includes/_lock-version-1') %>
+
+<%= include('../../../_includes/_uses-delegation') %>
+
+When an authentication is performed with the `offline_access` scope included, it will return a Refresh Token that can be used to request a new JWT token and avoid asking the user his/her
+credentials again.
+
+::: note
+We are using [SimpleKeychain](https://github.com/auth0/SimpleKeychain) to handle iOS Keychain access.
+:::
+
+First thing we need to do is store the ID Token and Refresh Token in the iOS Keychain after a successful authentication.
+
+```objc
+A0LockViewController *controller = ...;
+controller.onAuthenticationBlock = ^(A0UserProfile *profile, A0Token *token) {
+    A0SimpleKeychain *keychain = [A0SimpleKeychain keychainWithService:@"Auth0"];
+    [keychain setString:token.idToken forKey:@"id_token"];
+    [keychain setString:token.refreshToken forKey:@"refresh_token"];
+    [keychain setData:[NSKeyedArchiver archivedDataWithRootObject:profile] forKey:@"profile"];
+    // Other stuff. Don't forget to dismiss lock
+};
+```
+
+```swift
+let controller: A0LockViewController = ...
+controller.onAuthenticationBlock = { (profile, token) in
+    guard let profile = profile, let token = token else {
+        return //it's a sign up
+    }
+    let keychain = A0SimpleKeychain(service: "Auth0")
+    keychain.setString(token.idToken, forKey: "id_token")
+    if let refreshToken = token.refreshToken {
+        keychain.setString(refreshToken, forKey: "refresh_token")
+    }
+    keychain.setData(NSKeyedArchiver.archivedData(withRootObject: profile), forKey: "profile")
+    // Other stuff. Don't forget to dismiss lock
+}
+```
+Once you have those stored, you can at any point request a new ID Token using either of by calling to Auth0`s **delegation** endpoint.
+
+## Using a non-expired ID Token
+
+```objc
+A0Lock *lock = [A0Lock sharedLock];
+A0SimpleKeychain *keychain = [A0SimpleKeychain keychainWithService:@"Auth0"];
+NSString* token = [keychain stringForKey:@"id_token"];
+A0APIClient *client = [lock apiClient];
+[client fetchNewIdTokenWithIdToken:token parameters:nil success:^(A0Token *token) {
+    [keychain setString:token.idToken forKey:@"id_token"];
+    //Just got a new ID Token!
+} failure:^(NSError *error) {
+    [keychain clearAll]; //Cleaning stored values since they are no longer valid
+    //ID Token is no longer valid.
+    //You should ask the user to login again!.
+}];
+```
+
+```swift
+let keychain = A0SimpleKeychain(service: "Auth0")
+if let token = keychain.stringForKey("id_token") {
+    let client = A0Lock.sharedLock().apiClient()
+    client.fetchNewIdTokenWithIdToken(token,
+        parameters: nil,
+        success: { token in
+            keychain.setString(token.idToken, forKey: "id_token")
+            //Just got a new ID Token!
+        }, failure: { error in
+            keychain.clearAll() //Cleaning stored values since they are no longer valid
+            //ID Token is no longer valid.
+            //You should ask the user to login again!.
+    })
+}
+```
+
+## Using Refresh Token
+
+```objc
+A0Lock *lock = [A0Lock sharedLock];
+A0SimpleKeychain *keychain = [A0SimpleKeychain keychainWithService:@"Auth0"];
+NSString* refreshToken = [keychain stringForKey:@"refresh_token"];
+A0APIClient *client = [lock apiClient];
+[client fetchNewIdTokenWithRefreshToken:refreshToken parameters:nil success:^(A0Token *token) {
+    [keychain setString:token.idToken forKey:@"id_token"];
+    //Just got a new ID Token!
+} failure:^(NSError *error) {
+    [keychain clearAll]; //Cleaning stored values since they are no longer valid
+    //Refresh Token is no longer valid.
+    //You should ask the user to login again!.
+}];
+```
+
+```swift
+let keychain = A0SimpleKeychain(service: "Auth0")
+if let token = keychain.stringForKey("refresh_token") {
+    let client = A0Lock.sharedLock().apiClient()
+    client.fetchNewIdTokenWithRefreshToken(token,
+        parameters: nil,
+        success: { token in
+            keychain.setString(token.idToken, forKey: "id_token")
+            //Just got a new ID Token!
+        }, failure: { error in
+            keychain.clearAll() //Cleaning stored values since they are no longer valid
+            //Refresh Token is no longer valid.
+            //You should ask the user to login again!.
+    })
+}
+```
+
+## Retrieving the user profile from Keychain
+
+If you need to show profile information in your application, just retrieve the saved profile and pick what you need. For example:
+
+```objc
+A0SimpleKeychain *keychain = [A0SimpleKeychain keychainWithService:@"Auth0"];
+A0UserProfile *profile = [NSKeyedUnarchiver unarchiveObjectWithData:[keychain dataForKey:@"profile"]];
+self.nameLabel.text = profile.name;
+self.emailLabel.text = profile.email;
+```
+
+```swift
+let keychain = A0SimpleKeychain(service: "Auth0")
+if let data = keychain.dataForKey("profile"), let profile = NSKeyedUnarchiver.unarchiveObjectWithData(data) {
+  self.nameLabel.text = profile.name
+  self.emailLabel.text = profile.email
+}
+```
diff --git a/ja-jp/articles/libraries/lock-ios/v1/sending-authentication-parameters.md b/ja-jp/articles/libraries/lock-ios/v1/sending-authentication-parameters.md
new file mode 100644
index 0000000000..325e52750d
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/sending-authentication-parameters.md
@@ -0,0 +1,89 @@
+---
+section: libraries
+title: Sending Authentication Parameters
+description: How to send authentication parameters, and what parameters are supported when using Lock iOS.
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock iOS: Sending Authentication Parameters
+
+<%= include('../_includes/_lock-version-1') %>
+
+You can send parameters, before displaying `A0AuthenticationViewController` or when calling any API method using `A0APIClient`, by adding them to a `A0AuthParameters` object. By default `A0AuthParameters` has the parameter `scope` with `openid offline_access` and `device` with the name obtained from calling
+```objc
+[[UIDevice currentDevice] name];
+```
+The following example adds a `scope` parameter with the value `login`.
+```objc
+A0AuthParameters *parameters = [A0AuthParameters newDefaultParams];
+parameters.scope = @"login";
+```
+
+The following parameters are supported:
+* `access_token`
+* `scope`
+* `protocol`
+* `device`
+* `connection_scopes`
+* `nonce`
+* `offline_mode`
+* `state`.
+
+There are other extra parameters that will depend on the provider. For example, Google allows you to get back a `refresh_token` only if you explicitly ask for `access_type=offline`.
+
+We support sending arbitrary parameters like this:
+
+```objc
+A0AuthParameters *parameters = [A0AuthParameters newDefaultParams];
+[parameters setValue:@"offline" forKey:@"access_type"];
+[parameters setValue:@"foo" forKey:@"my_arbitrary_param"];
+```
+
+## Supported parameters
+### scope:`NSString`
+
+There are different values supported for scope:
+
+* `'openid'`: It will return, not only the Access Token, but also an ID Token, which is a JSON Web Token (JWT). The JWT will only contain the user id (sub claim). You can use objc constant `A0ScopeOpenId`.
+* `'openid profile'`:(not recommended): will return all the user attributes in the token. This can cause problems when sending or receiving tokens in URLs (for example, when using response_type=token) and will likely create an unnecessarily large token(especially with Azure AD which returns a fairly long JWT). Keep in mind that JWTs are sent on every API request, so it is desirable to keep them as small as possible. You can use objc constant `A0ScopeProfile`.
+* `'openid {attr1} {attr2} {attrN}'`: If you want only specific user's attributes to be part of the ID Token (for example: `scope: 'openid name email picture'`).
+
+Also, when you need to keep the ID Token alive, you can request a Refresh Token adding to the scope the value `offline_access` (Or use the constant `A0ScopeOfflineAccess`).
+
+By default in Auth0.iOS, the scope is set to `openid offline_access`.
+
+### device:`NSString`
+
+This value is only required when one of the scopes is `offline_access`. By default it has the name of the device obtained from calling the following method:
+
+```objc
+[[UIDevice currentDevice] name];
+```
+
+### connection_scopes:`NSDictionary`
+
+The `connection_scopes` parameter allows for dynamically specifying scopes on any connection. This is useful if you want to initially start with a set of scopes (defined on the dashboard), but later on request the user for extra permissions or attributes.
+
+The object keys must be the names of the connections and the values must be arrays containing the scopes to request to append to the dashboard specified scopes. An example is shown below:
+
+```objc
+A0AuthParameters *parameters = [A0AuthParameters newDefaultParams];
+parameter.connectionScopes = @{
+  @"facebook": [@"public_profile", @"user_friends"],
+  @"google-oauth2": [@"https://www.googleapis.com/auth/orkut"],
+  // none for twitter
+};
+```
+
+::: note
+The values for each scope are not transformed in any way. They must match exactly the values recognized by each identity provider.
+:::
diff --git a/ja-jp/articles/libraries/lock-ios/v1/swift.md b/ja-jp/articles/libraries/lock-ios/v1/swift.md
new file mode 100644
index 0000000000..de468cce8c
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/swift.md
@@ -0,0 +1,58 @@
+---
+section: libraries
+title: Using Lock with Swift
+description: How to use Swift with Lock iOS.
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+  - swift
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock iOS: Using Swift
+
+<%= include('../_includes/_lock-version-1') %>
+
+**Lock** was written in Objective-C but it can be used from a pure Swift project or a Hybrid project (Swift & Objective-C).
+
+## Create Objective-C Bridging Header
+In order to use **Lock** classes in any Swift file, you need to add a Objective-C Bridging Header to your project. The easiest way is to create a dummy Objective-C file in your Swift project (or Swift file in a Objective-C project), this will make Xcode prompt to create the bridging header, just press _"YES"_. After that you can delete the dummy file from your project and open the bridging header file which is called `-Bridging-Header.h`.
+
+::: note
+For more information, please check [this guide](https://developer.apple.com/library/ios/documentation/swift/conceptual/buildingcocoaapps/MixandMatch.html) from Apple.
+:::
+
+## Use Lock
+In `-Bridging-Header.h` just add the following line
+```objc
+#import 
+```
+
+And **Lock** classes will be available in all your Swift codebase. So to show `A0LockViewController` just use the following snippet:
+
+```swift
+let authController: A0LockViewController = A0Lock.shared().newLockViewController()
+authController.onAuthenticationBlock = { (profile, token) in
+    guard let profile = profile, let token = token else {
+        return //it's a sign up
+    }
+
+    let keychain = A0SimpleKeychain(service: "Auth0")
+    keychain.setString(token.idToken, forKey: "id_token")
+    if let refreshToken = token.refreshToken {
+        keychain.setString(refreshToken, forKey: "refresh_token")
+    }
+    keychain.setData(NSKeyedArchiver.archivedData(withRootObject: profile), forKey: "profile")
+
+    // Other stuff
+
+    self.dismiss(animated: true, completion: nil)
+}
+self.present(authController, animated: true, completion: nil)
+```
diff --git a/ja-jp/articles/libraries/lock-ios/v1/use-your-own-ui.md b/ja-jp/articles/libraries/lock-ios/v1/use-your-own-ui.md
new file mode 100644
index 0000000000..e7cd769663
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v1/use-your-own-ui.md
@@ -0,0 +1,163 @@
+---
+section: libraries
+title: Build your own UI
+description: Customize the UI of Lock in your App
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+  - custom-ui
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock iOS: Build your own UI
+
+<%= include('../_includes/_lock-version-1') %>
+
+<%= include('../../../_includes/_package', {
+  org: 'auth0',
+  repo: 'native-mobile-samples',
+  path: 'iOS/custom-ui-sample-swift'
+}) %>
+
+**Otherwise, if you already have an existing application, please follow the steps below.**
+
+1.  Add the following dependencies to your project using Cocoapods:
+  ```ruby
+  pod "Lock/Core", "~> 1.16"
+  pod "Lock-Facebook", "~> 2.0" #If you need FB native integration
+  pod "Lock-Twitter", "~> 1.1" #If you need Twitter native integration
+  ```
+
+2. Open your app's `Info.plist` file and add two new entries `Auth0ClientId` and `Auth0Domain` with the following values `${account.clientId}` and `${account.namespace}`
+
+3. Create a new instantiate of `A0Lock` and store it where is easily accessible:
+  ```objc
+  self.lock = [A0Lock newLock];
+  ```
+  ```swift
+  self.lock = A0Lock()
+  ```
+
+4. When you need to login your user with email/password credentials, just paste the following code
+  ```objc
+  NSString *email = ... // User's email
+  NSString *password = ... // User's password
+  A0Lock *lock = ... // Get your Lock instance
+  A0APIClient *client = [lock apiClient];
+  A0APIClientAuthenticationSuccess success = ^(A0UserProfile *profile, A0Token *token) {
+    NSLog(@"We did it!. Logged in with Auth0.");
+  };
+  A0APIClientError failure = ^(NSError *error){
+    NSLog(@"Oops something went wrong: %@", error);
+  };
+  A0AuthParameters *params = [A0AuthParameters newDefaultParams];
+  params[A0ParameterConnection] = @"Username-Password-Authentication"; // Or your configured DB connection
+  [client loginWithUsername:email
+                   password:password
+                 parameters:params
+                    success:success
+                    failure:error];
+  ```
+
+  ```swift
+  let email = ... // User's email
+  let password = ... // User's password
+  let lock = ... // Get your Lock instance
+  let client = lock.apiClient()
+  let parameters = A0AuthParameters(dictionary: [A0ParameterConnection : "Username-Password-Authentication"])
+  client.login(withUsername: email, password: password, parameters: parameters, success: { profile, token in
+      print("We did it!. Logged in with Auth0.")
+  }, failure: { error in
+      print("Oops something went wrong: \(error)")
+  })
+  ```
+::: note
+More details about the parameters you can use check [this wiki page](/libraries/lock-ios/sending-authentication-parameters).
+:::
+
+After that, you may want to save the user's token to be able to use them later, you can find how to do it [here](/libraries/lock-ios/save-and-refresh-jwt-tokens).
+
+## Social Authentication
+
+1. In your `AppDelegate` method named `application:didFinishLaunchingWithOptions` add the following line:
+  ```objc
+  A0Lock *lock = ... //Get your Lock instance
+  [lock applicationLaunchedWithOptions:launchOptions];
+  ```
+  ```swift
+  let lock = ... // Get your Lock instance
+  lock.applicationLaunched(options: launchOptions)
+  ```
+
+2. Also add the following lines to your `AppDelegate` too
+  ```objc
+- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary *)options {
+    A0Lock *lock = ... // Get your Lock instance
+    return [lock handleURL:url sourceApplication:app];
+  }
+  ```
+  ```swift
+  func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool {
+    let lock = ... // Get your Lock instance
+    return lock.handle(url, sourceApplication: app)
+  }
+  ```
+
+3. Configure Facebook Native Integration
+  ```objc
+  A0Lock *lock = ... //Get your Lock instance
+  A0FacebookAuthenticator *facebook = [A0FacebookAuthenticator newAuthenticatorWithDefaultPermissions];
+  [lock registerAuthenticators:@[facebook]];
+  ```
+  ```swift
+  let lock = ... //Get your Lock instance
+  let facebook = A0FacebookAuthenticator.newAuthenticatorWithDefaultPermissions()
+  lock.registerAuthenticators([facebook])
+  ```
+  ::: note
+  You need to configure your iOS App for Facebook, please check [this guide](/libraries/lock-ios/native-social-authentication#facebook) for more information.
+  :::
+
+4. Configure Twitter Native Integration
+  ```objc
+  NSString *twitterApiKey = ... //Remember to obfuscate your api key
+  NSString *twitterApiSecret = ... //Remember to obfuscate your api secret
+  A0TwitterAuthenticator *twitter = [A0TwitterAuthenticator newAuthenticationWithKey:twitterApiKey andSecret:twitterApiSecret];
+  A0Lock *lock = ... //Get your Lock instance
+  [lock registerAuthenticators:@[twitter]];
+  ```
+  ```swift
+  let twitterApiKey = ... //Remember to obfuscate your api key
+  let twitterApiSecret = ... //Remember to obfuscate your api key
+  let twitter = A0TwitterAuthenticator.newAuthenticationWithKey(twitterApiKey, andSecret:twitterApiSecret)
+  let lock = ... //Get your Lock instance
+  lock.registerAuthenticators([twitter])
+  ```
+
+5. Authenticate with a social connection
+  ```objc
+  void(^success)(A0UserProfile *, A0Token *) = ^(A0UserProfile *profile, A0Token *token) {
+    NSLog(@"We did it!. Logged in with Auth0.");
+  };
+  void(^error)(NSError *) = ^(NSError *error) {
+    NSLog(@"Oops something went wrong: %@", error);
+  };
+  A0Lock *lock = ... //Get your Lock instance
+  [[lock identityProviderAuthenticator] authenticateWithConnectionName:@"facebook" parameters:nil success:success failure:failure];
+  ```
+  ```swift
+  let success = { (profile: A0UserProfile, token: A0Token) in
+    println("We did it!. Logged in with Auth0.")
+  }
+  let failure = { (error: NSError) in
+    println("Oops something went wrong: \(error)")
+  }
+  let lock = ... //Get your Lock instance
+  lock.identityProviderAuthenticator().authenticateWithConnectionName("facebook", parameters: nil, success: success, failure: failure)
+  ```
diff --git a/ja-jp/articles/libraries/lock-ios/v2/configuration.md b/ja-jp/articles/libraries/lock-ios/v2/configuration.md
new file mode 100644
index 0000000000..20831500fb
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v2/configuration.md
@@ -0,0 +1,248 @@
+---
+section: libraries
+toc: true
+url: /libraries/lock-ios/v2/configuration
+title: Lock for iOS v2 Configuration Options
+description: Behavior configuration options available with Lock v2 for iOS
+topics:
+  - libraries
+  - lock
+  - ios
+contentType:
+  - reference
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock v2 for iOS - Configuration Options
+
+There are numerous options to configure Lock's behavior listed below. In addition, there are also quite a few options available to alter Lock's appearance and style in the [Style Customization Options](/libraries/lock-ios/v2/customization) page.
+
+## Configuring Lock's behavior
+
+Configuration options can be added to your Lock initialization using `withOptions`.
+
+```swift
+Lock
+  .classic()
+  .withOptions {
+    $0.closable = true
+    $0.usernameStyle = [.Username]
+    $0.allow = [.Login, .ResetPassword]
+  }
+  .present(from: self)
+```
+
+## Behavior Options
+
+### closable
+
+Allows Lock to be dismissed by the user. By default this is `false`.
+
+```swift
+.withOptions {
+  $0.closable = true
+}
+```
+
+### scope
+
+Scope used for authentication. By default is `openid`. It will return not only the **Access Token**, but also an **ID Token** which is a JSON Web Token (JWT) containing user information. See the documentation on [Scopes](/scopes) for more information about authentication scopes.
+
+```swift
+.withOptions {
+  $0.scope = "openid name email picture"
+}
+```
+
+#### Refresh Tokens
+
+Specifying the `offline_access` scope in your Lock options will allow a [Refresh Token](/tokens/concepts/refresh-tokens) to be returned along with the access\_token and the id\_token. Refresh Tokens can be saved and used to acquire a new Access Token when the old one expires. For more information about using Refresh Tokens for Auth0 authentication, take a look at the reference documentation for the [Auth0.Swift SDK](/libraries/auth0-swift), which you would use to implement Refresh Tokens, or at the [Swift Quickstart Guide](/quickstart/native/ios-swift/03-user-sessions), which provides a comprehensive example of use of Auth0 in Swift development, including the management of Refresh Tokens.
+
+### termsOfService
+
+By default Lock will use Auth0's [Terms of Service](https://auth0.com/terms) and [Privacy Policy](https://auth0.com/privacy), but other URLs can be filled in to link to other terms and policies.
+
+```swift
+.withOptions {
+  $0.termsOfService = "https://mycompany.com/terms"
+  $0.privacyPolicy = "https://mycompany.com/privacy"
+}
+```
+
+### Show Terms of Service
+
+Database connections display the Terms of Service dialog. Default is `true`. Note that the Terms of Service will always be shown if the `mustAcceptTerms` flag is enabled.
+
+```swift
+.withOptions {
+    $0.showTerms = true
+}
+```
+
+### Require users to accept the Terms of Service
+
+Database connection require explicit acceptance of the Terms of Service.
+
+```swift
+.withOptions {
+    $0.mustAcceptTerms = true
+}
+```
+
+## Web Authentication Options
+
+### leeway
+
+Clock skew used for ID token validation. It expands the time window in which the ID token will still be considered valid, to account for the difference between server time and client time. By default is **60000 milliseconds** (60 seconds).
+
+```swift
+.withOptions {
+  $0.leeway = 30000 // 30 seconds
+}
+```
+
+### maxAge
+
+Allowable elapsed time (in milliseconds) since the user last authenticated. Used for ID token validation. If set, the ID token will contain an `auth_time` claim with the authentication timestamp. Defaults to `nil`.
+
+```swift
+.withOptions {
+  $0.maxAge = 86400000 // 1 day
+}
+```
+
+## Database options
+
+### allow
+
+Which database screens will be accessible, the default is enable all screens such as `.Login, .Signup, .ResetPassword`.
+
+```swift
+.withOptions {
+  $0.allow = [.Login, .ResetPassword]
+}
+```
+
+### initialScreen
+
+The first screen to present to the user. The default is `.Login`, other options include `.Signup` and `ResetPassword`.
+
+```swift
+.withOptions {
+  $0.initialScreen = .login
+}
+```
+
+### usernameStyle
+
+Specify the type of identifier the login will require.  The default is either: `[.Username, .Email]`, but it can also accept `[.Username]` or `[.Email]`. However it's important to note that this option is only active if you have set the `requires_username` flag to `true` in your [Auth0 Dashboard](${manage_url}/#/)
+
+```swift
+.withOptions {
+  $0.usernameStyle = [.Username]
+}
+```
+
+#### Custom Signup Fields
+
+When signing up the default information requirements are the user's *email* and *password*. You can expand your data capture requirements as needed. Capturing additional signup fields here will store them in the `user_metadata`, which you can read more about in [Metadata](/users/concepts/overview-user-metadata). Note that you must specify the icon to use with your custom text field.
+
+```swift
+.withOptions {
+  $0.customSignupFields = [
+    CustomTextField(name: "first\_name", placeholder: "First Name", icon: LazyImage(name: "ic_person", bundle: Lock.bundle)),
+    CustomTextField(name: "last\_name", placeholder: "Last Name", icon: LazyImage(name: "ic_person", bundle: Lock.bundle))
+  ]
+}
+```
+
+::: note
+You can also specify icons from other bundles, such as in the following example:
+CustomTextField(name: "slack_handle", placeholder: "Slack Handle", icon: LazyImage(name: "ic_slack", bundle: Bundle(identifier: "CustomBundle")))
+:::
+
+## Enterprise Options
+
+There are also configuration options specific to Enterprise connections:
+
+### enterpriseConnectionUsingActiveAuth
+
+By default Enterprise connections will use Web Authentication. However, you can specify which connections will alternatively use credential authentication and prompt for a username and password.
+
+```swift
+.withOptions {
+  $0.enterpriseConnectionUsingActiveAuth = ["enterprisedomain.com"]
+}
+```
+
+### activeDirectoryEmailAsUsername
+
+When in credential authentication mode, should the user require their email as an identifier?  The default is `false`, and instead requires a username.
+
+```swift
+.withOptions {
+  $0.activeDirectoryEmailAsUsername = true
+}
+```
+
+## Logging Options
+
+Lock provides options to easily turn on and off logging capabilities, as well as adjust other logging related settings.
+
+### logLevel
+
+By default this is `.off`, *Syslog* logging levels are supported.
+
+```swift
+.withOptions {
+  $0.logLevel = .all
+}
+```
+
+### logHttpRequest
+
+Whether or not to log Auth0.swift API requests. By default this is `false`.
+
+```swift
+.withOptions {
+  $0.logHttpRequest = true
+}
+```
+
+### loggerOutput
+
+Specify logger output handler, by default this uses the `print` statement.
+
+```swift
+.withOptions {
+  $0.loggerOutput = CleanroomLockLogger()
+}
+```
+
+In the code above, the *loggerOutput* has been set to use [CleanroomLogger](https://github.com/emaloney/CleanroomLogger). This can typically be achieved by implementing the *loggerOutput* protocol.  You can of course use your favorite logger library. Below is an example of usage handling logger output with CleanroomLogger.
+
+```swift
+class CleanroomLockLogger: LoggerOutput {
+  func message(_ message: String, level: LoggerLevel, filename: String, line: Int) {
+    let channel: LogChannel?
+    switch level {
+    case .debug:
+        channel = Log.debug
+    case .error:
+        channel = Log.error
+    case .info:
+        channel = Log.info
+    case .verbose:
+        channel = Log.verbose
+    case .warn:
+        channel = Log.warning
+    default:
+        channel = nil
+    }
+    channel?.message(message, filePath: filename, fileLine: line)
+  }
+}
+```
diff --git a/ja-jp/articles/libraries/lock-ios/v2/custom-fields.md b/ja-jp/articles/libraries/lock-ios/v2/custom-fields.md
new file mode 100644
index 0000000000..3ce74320cf
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v2/custom-fields.md
@@ -0,0 +1,44 @@
+---
+section: libraries
+title: Custom Fields at Signup
+description: Adding additional fields to signups with Lock v2 for iOS
+topics:
+  - libraries
+  - lock
+  - ios
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock v2 for iOS - Custom Fields at Signup
+
+**Lock v2 for iOS** allows you to specify additional fields that the user must complete before creating a new account. The extra fields will be shown after the basic fields (email, username, password).
+
+## Adding custom fields
+
+When signing up the default information requirements are the user's *email* and *password*. You can expand your data capture requirements as needed. Capturing additional signup fields here will store them in the `user_metadata`, which you can read more about in [Metadata](/users/concepts/overview-user-metadata).
+
+```swift
+.withOptions {
+  $0.customSignupFields = [
+    CustomTextField(name: "first\_name", placeholder: "First Name", icon: LazyImage(name: "ic_person", bundle: Lock.bundle)),
+    CustomTextField(name: "last\_name", placeholder: "Last Name", icon: LazyImage(name: "ic_person", bundle: Lock.bundle))
+  ]
+}
+```
+
+::: note
+You must specify the icon to use with your custom text field.
+:::
+
+That's it! If you have enabled users Sign Up in the Application's Dashboard, after they complete the basic fields (email/username, password) and hit Submit, they will be prompted to fill the remaining fields.
+
+::: note
+Note that the user must fill all of the custom fields before being able to complete signup.
+:::
+
+When requesting a user Sign Up or Sign In, the extra fields will be attached to the `user_metadata` attribute in the request body. You can access them by querying the user profile at any time, even from the Dashboard in the User's section.
diff --git a/ja-jp/articles/libraries/lock-ios/v2/customization.md b/ja-jp/articles/libraries/lock-ios/v2/customization.md
new file mode 100644
index 0000000000..438a224801
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v2/customization.md
@@ -0,0 +1,371 @@
+---
+section: libraries
+toc: true
+url: /libraries/lock-ios/v2/customization
+title: Lock for iOS v2 Style Customization Options
+description: Styling and customization options for the style of Lock v2 for iOS
+topics:
+  - libraries
+  - lock
+  - ios
+contentType:
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Lock v2 for iOS - Style Customization Options 
+
+There are numerous options to configure Lock's style and appearance listed below. In addition, there are also quite a few options available to alter Lock's behavior and functionality in the [Behavior Configuration Options](/libraries/lock-ios/v2/configuration) page.
+
+## Customizing Lock's appearance
+
+Style customization options can be added to your Lock initialization using `withStyle`.
+
+```swift
+Lock
+  .classic()
+  .withStyle {
+	  $0.title = "Company LLC"
+	  $0.logo = LazyImage(name: "company_logo")
+	  $0.primaryColor = UIColor(red: 0.6784, green: 0.5412, blue: 0.7333, alpha: 1.0)
+	}
+  .present(from: self)
+```
+
+## Header Style Options
+
+### headerBlur 
+
+Blur effect style used. It can be any value defined in `UIBlurEffectStyle`.
+
+```swift
+.withStyle {
+  $0.headerBlur = .extraLight
+}
+```	
+
+### headerColor
+
+Color used as the header background color. By default it has no color, just a blur.
+
+```swift
+.withStyle {
+  $0.headerColor = UIColor? = nil
+}
+```	
+
+### logo
+
+Header logo image
+
+```swift
+.withStyle {
+  $0.logo = LazyImage(name: "company_logo")
+}
+``` 
+
+### headerCloseIcon
+
+The "close" icon in the header can be altered.
+
+```swift
+.withStyle {
+  $0.headerCloseIcon = LazyImage(name: "ic_close")
+}
+``` 
+
+### headerBackIcon
+
+The "back" icon in the header can be altered.
+
+```swift
+.withStyle {
+  $0.headerBackIcon = LazyImage(name: "ic_close")
+}
+``` 
+
+## Title Style Options
+
+### hideTitle
+
+Hide header title and show only the logo. By default this option is false.
+
+```swift
+.withStyle {
+  $0.hideTitle = false
+}
+```	
+
+### title
+
+Title text used in the header
+
+```swift
+.withStyle {
+  $0.title = "Company LLC"
+}
+```
+
+### titleColor
+
+Color used as the header title color.
+
+```swift
+.withStyle {
+  $0.titleColor = UIColor.black
+}
+```	
+
+## Button and Component Style Options
+
+### buttonTintColor
+
+Color used as the primary button tint color.
+
+```swift
+.withStyle {
+  $0.buttonTintColor = UIColor.white
+}
+```	
+
+### disabledColor
+
+Color used as the Lock disabled component color.
+
+```swift
+.withStyle {
+  $0.disabledColor = UIColor(red: 0.8902, green: 0.898, blue: 0.9059, alpha: 1.0)
+}
+```
+
+### disabledTextColor
+
+Color used as the Lock disabled component text color.
+
+```swift
+.withStyle {
+  $0.disabledTextColor = UIColor(red: 0.5725, green: 0.5804, blue: 0.5843, alpha: 1.0)
+}
+```	
+
+### hideButtonTitle
+
+Hide primary button title and show only the icon. By default this option is false.
+
+```swift
+.withStyle {
+  $0.hideButtonTitle = false
+}
+```	
+
+### primaryColor
+
+Color used as the Lock primary color.
+
+```swift
+.withStyle {
+  $0.primaryColor = UIColor.orange
+}
+```
+
+## Input Field Styles
+
+### inputTextColor
+
+The color of input field text.
+
+```swift
+.withStyle {
+  $0.inputTextColor = UIColor.black
+}
+```
+
+### inputPlaceholderTextColor
+
+The color of the placeholder text in input fields.
+
+```swift
+.withStyle {
+  $0.inputPlaceholderTextColor = UIColor(red: 0.780, green: 0.780, blue: 0.804, alpha: 1.00)
+}
+```
+
+### inputBorderColor
+
+The color of the border of input fields.
+
+```swift
+.withStyle {
+  $0.inputBorderColor = UIColor(red: 0.780, green: 0.780, blue: 0.804, alpha: 1.00)
+}
+```
+
+### inputBorderColorError
+
+The color of the border of input fields which have invalid values.
+
+```swift
+.withStyle {
+  $0.inputBorderColorError = UIColor.red
+}
+```
+
+### inputBackgroundColor
+
+The color of the background of input fields.
+
+```swift
+.withStyle {
+  $0.inputBackgroundColor = UIColor.white
+}
+```
+
+### inputIconBackgroundColor
+
+The color of the background of input field icons.
+
+```swift
+.withStyle {
+  $0.inputIconBackgroundColor = UIColor(red: 0.9333, green: 0.9333, blue: 0.9333, alpha: 1.0)
+}
+```
+
+### inputIconColor
+
+The color of the input field icons.
+
+```swift
+.withStyle {
+  $0.inputIconColor = UIColor(red: 0.5725, green: 0.5804, blue: 0.5843, alpha: 1.0)
+}
+```
+
+## Status Bar Styles
+
+### UIStatusBarAnimation
+
+The Lock Controller Status Bar update animation.
+
+```swift
+.withStyle {
+  $0.UIStatusBarAnimation = .none
+}
+```
+
+### statusBarHidden
+
+The Lock Controller Status Bar's visibility.
+
+```swift
+.withStyle {
+  $0.statusBarHidden = false
+}
+```
+
+### UIStatusBarStyle
+
+The Lock Controller Status Bar style.
+
+```swift
+.withStyle {
+  $0.UIStatusBarStyle = .default
+}
+```
+
+### UISearchBarStyle
+
+The Lock Passwordless Search Bar style.
+
+```swift
+.withStyle {
+  $0.UISearchBarStyle = .default
+}
+```
+
+## Other Style Options
+
+### textColor
+
+The color for the text in the body.
+
+```swift
+.withStyle {
+  $0.textColor = UIColor.black
+}
+```
+
+### backgroundColor
+
+Color used as the Lock background color.
+
+```swift
+.withStyle {
+  $0.backgroundColor = UIColor.white
+}
+```
+
+### backgroundImage
+
+Image used as the Lock background
+
+```swift
+.withStyle {
+  $0.backgroundImage = LazyImage(name: "company_logo")
+}
+```
+
+### oauth2
+
+Any non-db OAuth2 connection can have styles customized by mapping a connection name with an `AuthStyle`
+
+```swift
+.withStyle {
+  $0.oauth2["slack"] = AuthStyle(
+    name: "Slack",
+    color: UIColor(red: 0.4118, green: 0.8078, blue: 0.6588, alpha: 1.0),
+    withImage: LazyImage(name: "ic_slack")
+  )
+}
+```
+
+### seperatorTextColor
+
+Social separator label color.
+
+```swift
+.withStyle {
+  $0.seperatorTextColor = UIColor(red: 0.0, green: 0.0, blue: 0.0, alpha: 0.54)
+}
+```
+
+### secondaryButtonColor
+
+The color of secondary buttons.
+
+```swift
+.withStyle {
+  $0.secondaryButtonColor = UIColor.black
+}
+```
+
+### tabTextColor
+
+The color of the text on the database login tab.
+
+```swift
+.withStyle {
+  $0.tabTextColor = UIColor(red: 0.3608, green: 0.4, blue: 0.4353, alpha: 0.6)
+}
+```
+
+### tabTintColor
+
+The color of the tinting on the database login tab.
+
+```swift
+.withStyle {
+  $0.tabTintColor = UIColor(red: 0.3608, green: 0.4, blue: 0.4353, alpha: 0.6)
+}
+```
diff --git a/ja-jp/articles/libraries/lock-ios/v2/index.md b/ja-jp/articles/libraries/lock-ios/v2/index.md
new file mode 100644
index 0000000000..ccde6a136d
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v2/index.md
@@ -0,0 +1,228 @@
+---
+section: libraries
+toc: true
+title: Lock v2 for iOS
+description: A widget that provides a frictionless login and signup experience for your native iOS apps.
+mobileimg: media/articles/libraries/lock-ios.png
+topics:
+  - libraries
+  - lock
+  - ios
+contentType:
+  - reference
+  - index
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock v2 for iOS
+
+::: warning
+Auth0 encourages the use of [web authentication via Universal Login](/guides/login/universal-vs-embedded) rather than native username/password authentication whenever possible.
+:::
+
+This reference guide will show you how to implement the Lock user interface, and give you the details on configuring and customizing Lock in order to use it as the UI for your authentication needs. However, if you'd like to learn how to do more with Auth0 and Swift, such as how to save, call and refresh Access Tokens, get user profile info, and more, check out the [Auth0.swift SDK](/libraries/auth0-swift). Or, take a look at the [Swift Quickstart](/quickstart/native/ios-swift) to walk through complete examples and see options, both for using Lock as the interface, and for using a custom interface. 
+
+::: note
+Check out the [Lock.swift repository](https://github.com/auth0/Lock.swift) on GitHub.
+:::
+
+## Requirements
+
+- iOS 9+
+- Xcode 10+
+- Swift 4+
+
+<%= include('../_includes/_dependencies') %>
+
+## Setup
+
+### Integrate with your Application
+
+Lock needs to be notified when the application is asked to open a URL. You can do this in the `AppDelegate` file.
+
+```swift
+func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey : Any] = [:]) -> Bool {
+  return Lock.resumeAuth(url, options: options)
+}
+```
+
+### Import Lock
+
+Import **Lock** wherever you'll need it
+
+```swift
+import Lock
+```
+
+### Auth0 Credentials
+
+In order to use Lock you need to provide your Auth0 Client Id and Domain, which can be found in your [Auth0 Dashboard](${manage_url}), under your Application's settings.
+
+In your application bundle you can add a `plist` file named `Auth0.plist` that will include your credentials with the following format.
+
+```xml
+
+
+
+
+  ClientId
+  ${account.clientId}
+  Domain
+  ${account.namespace}
+
+
+```
+
+## Implementation of Lock Classic
+
+Lock Classic handles authentication using Database, Social, and Enterprise connections.
+
+### OIDC Conformant Mode
+
+It is strongly encouraged that this SDK be used in OIDC Conformant mode. When this mode is enabled, it will force the SDK to use Auth0's current authentication pipeline and will prevent it from reaching legacy endpoints. By default this is `false`
+
+```swift
+.withOptions {
+    $0.oidcConformant = true
+}
+```
+
+::: note
+For more information, please see our [Introduction to OIDC Conformant Authentication](/api-auth/intro) and the [OIDC adoption guide](/api-auth/tutorials/adoption).
+:::
+
+To show Lock, add the following snippet in your `UIViewController`.
+
+```swift
+Lock
+    .classic()
+    // withConnections, withOptions, withStyle, and so on
+    .withOptions {
+      $0.oidcConformant = true
+      $0.scope = "openid profile"
+    }
+    .onAuth { credentials in
+      // Let's save our credentials.accessToken value
+    }
+    .present(from: self)
+```
+
+## Use Auth0.Swift Library to access user profile
+
+To access user profile information, you will need to use the `Auth0.Swift` library:
+
+```swift
+guard let accessToken = credentials.accessToken else { return }
+Auth0
+    .authentication()
+    .userInfo(withAccessToken: accessToken)
+    .start { result in
+        switch result {
+        case .success(let profile):
+            // You've got a UserProfile object
+        case .failure(let error):
+            // You've got an error
+        }
+}
+```
+
+Check out the [Auth0.Swift Library Documentation](/libraries/auth0-swift) for more information about its uses.
+
+## Specify Connections
+
+Lock will automatically load the connections configured for your application. If you wish to override the default behavior, you can manually specify which connections it should display to users as authentication options. This can be done by calling the method and supplying a closure that can specify the connection(s).
+
+Adding a database connection:
+
+```swift
+.withConnections {
+    $0.database(name: "Username-Password-Authentication", requiresUsername: true)
+}
+```
+
+Adding multiple social connections:
+
+```swift
+.withConnections {
+    $0.social(name: "facebook", style: .Facebook)
+    $0.social(name: "google-oauth2", style: .Google)
+}
+```
+
+## Styling and Customization
+
+Lock provides many styling options to help you apply your own brand identity to Lock using `withStyle`. For example, changing the primary color and header text of your Lock widget:
+
+### Customize your title, logo, and primary color
+
+```swift
+.withStyle {
+  $0.title = "Company LLC"
+  $0.logo = LazyImage(named: "company_logo")
+  $0.primaryColor = UIColor(red: 0.6784, green: 0.5412, blue: 0.7333, alpha: 1.0)
+}
+```
+
+::: note
+You can see the complete set of styling options to alter the appearance of Lock for your app in the [Customization Guide](/libraries/lock-ios/v2/customization).
+:::
+
+## Configuration Options
+
+There are numerous options to configure Lock's behavior. Below is an example of Lock configured to allow it to be closable, to limit it to only usernames (and not emails), and to only show the Login and Reset Password screens.
+
+```swift
+Lock
+  .classic()
+  .withOptions {
+    $0.closable = true
+    $0.usernameStyle = [.Username]
+    $0.allow = [.Login, .ResetPassword]
+  }
+```
+
+::: note
+You can see the complete set of behavior configuration options to alter the way Lock works for your app in the [Configuration Guide](/libraries/lock-ios/v2/configuration).
+:::
+
+## Password Manager Support
+
+By default, password manager support using [1Password](https://1password.com/) is enabled for database connections. 1Password support will still require the user to have the 1Password app installed for the option to be visible in the login and signup screens. You can disable 1Password support using the enabled property of the passwordManager.
+
+```swift
+.withOptions {
+    $0.passwordManager.enabled = false
+}
+```
+
+By default the `appIdentifier` will be set to the app's bundle identifier and the `displayName` will be set to the app's display name. You can customize these as follows:
+
+```swift
+.withOptions {
+    $0.passwordManager.appIdentifier = "www.myapp.com"
+    $0.passwordManager.displayName = "My App"
+}
+```
+
+You will need to add the following to your app's `info.plist`:
+
+```
+LSApplicationQueriesSchemes
+
+    org-appextension-feature-password-management
+
+```
+
+<%= include('../_includes/_roadmap') %>
+
+## Next Steps
+
+::: next-steps
+- [Customizing the Style of Lock](/libraries/lock-ios/v2/customization)
+- [Customizing the Behavior of Lock](/libraries/lock-ios/v2/configuration)
+- [Adding Custom Signup Fields to Lock](/libraries/lock-ios/v2/custom-fields)
+- [Lock Internationalization](/libraries/lock-ios/v2/internationalization)
+- [Logging out Users](/logout)
+:::
diff --git a/ja-jp/articles/libraries/lock-ios/v2/internationalization.md b/ja-jp/articles/libraries/lock-ios/v2/internationalization.md
new file mode 100644
index 0000000000..cda2d77a2b
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v2/internationalization.md
@@ -0,0 +1,70 @@
+---
+section: libraries
+title: Internationalization in Lock v2 for iOS
+description: Internationalization support in Lock v2 for iOS
+topics:
+  - libraries
+  - lock
+  - ios
+  - i18n
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+
+# Internationalization
+
+By default, **Lock v2 for iOS** displays all text in English. If you wish to display text in another language, or you wish to alter the text values for your application, you may provide a `Lock.strings` file and define values to be used for the various text items that Lock might display.
+
+More information about how to handle languages can be found in the official Apple documentation on [Internationalization and Localization](https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPInternational/Introduction/Introduction.html#//apple_ref/doc/uid/10000171i-CH1-SW1)
+
+## Lock String Values
+
+For a full list of the terms used by Lock, see the base [Lock.strings](https://raw.githubusercontent.com/auth0/Lock.swift/master/Lock/Base.lproj/Lock.strings) file in the Lock.swift repository.
+
+### Providing alternative English strings
+
+If you want to change some or all of the existing terms, you can do this by downloading and adding the [Lock.strings](https://raw.githubusercontent.com/auth0/Lock.swift/master/Lock/Base.lproj/Lock.strings) file to your project.
+
+Select the **Lock.strings** file and in the `File inspector` click on `Localize...`
+
+![xcode localizable](/media/articles/libraries/lock-ios/xcode_localize.png)
+
+Then select `English`:
+
+![xcode localizable](/media/articles/libraries/lock-ios/xcode_localize_english.png)
+
+Now lets take a couple of terms in **Lock.strings** and update them with alternative text:
+
+```text
+// Forgot password
+"com.auth0.lock.database.button.forgot_password" = "Did you forget your password?";
+// tos & privacy
+"com.auth0.lock.database.button.tos" = "Signing up is an indication of your agreement to our terms of\n service and privacy policy";
+```
+
+### Supporting other languages
+
+To add another language you first of all need to add the new language under `Project/Info`
+
+![xcode add language](/media/articles/libraries/lock-ios/xcode_add_language.png)
+
+Add the new language and ensure that **Lock.strings** is selected
+
+![xcode add language](/media/articles/libraries/lock-ios/xcode_add_language_step_2.png)
+
+You will notice under **Lock.strings** a new file has been created for your specified language, based upon the **Reference Language** selection.
+
+Now you are ready to translate to your desired language.
+
+### Notes
+
+Some terms use parameters and it's important to note their placement in your translation.  In particular multiple parameter terms such as:
+
+```text
+// No more than %@{count} identical characters in a row (such as, \"%@{identical sample}\" not allowed)
+"com.auth0.lock.error.password.no_more_identical" = "No more than %1$d identical characters in a row (such as, \"%2$@\" not allowed)";
+```
diff --git a/ja-jp/articles/libraries/lock-ios/v2/logging.md b/ja-jp/articles/libraries/lock-ios/v2/logging.md
new file mode 100644
index 0000000000..821a5dae26
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v2/logging.md
@@ -0,0 +1,73 @@
+---
+section: libraries
+title: Logging in Lock for iOS v2
+description: Logging in Lock for iOS v2
+topics:
+  - libraries
+  - lock
+  - ios
+  - logs
+contentType:
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Logging in Lock for iOS v2
+
+Lock provides options to easily turn on and off logging capabilities, as well as adjust other logging related settings.
+
+## logLevel
+
+By default this is `.off`, *Syslog* logging levels are supported.
+
+```swift
+.withOptions {
+  $0.logLevel = .all
+}
+```
+
+## logHttpRequest
+
+This option allows you to choose whether or not to log Auth0.swift API requests. By default this is `false`.
+
+```swift
+.withOptions {
+  $0.logHttpRequest = true
+}
+```
+
+## loggerOutput
+
+You can specify a logger output handler, by default this uses the `print` statement.
+
+```swift
+.withOptions {
+  $0.loggerOutput = CleanroomLockLogger()
+}
+```
+
+In the code above, the `loggerOutput` has been set to use [CleanroomLogger](https://github.com/emaloney/CleanroomLogger). This can typically be achieved by implementing the `loggerOutput` protocol.  You can of course use your favorite logger library. Below is an example of usage handling logger output with CleanroomLogger.
+
+```swift
+class CleanroomLockLogger: LoggerOutput {
+  func message(_ message: String, level: LoggerLevel, filename: String, line: Int) {
+    let channel: LogChannel?
+    switch level {
+    case .debug:
+        channel = Log.debug
+    case .error:
+        channel = Log.error
+    case .info:
+        channel = Log.info
+    case .verbose:
+        channel = Log.verbose
+    case .warn:
+        channel = Log.warning
+    default:
+        channel = nil
+    }
+    channel?.message(message, filePath: filename, fileLine: line)
+  }
+}
+```
\ No newline at end of file
diff --git a/ja-jp/articles/libraries/lock-ios/v2/migration.md b/ja-jp/articles/libraries/lock-ios/v2/migration.md
new file mode 100644
index 0000000000..274c9bd896
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v2/migration.md
@@ -0,0 +1,292 @@
+---
+section: libraries
+toc: true
+url: /libraries/lock-ios/v2/migration
+title: Migrating from v1 to v2 of Lock for iOS
+description: A migration guide to assist with migration from Lock v1 (Swift) to Lock v2 (Swift).
+public: false
+topics:
+  - libraries
+  - lock
+  - ios
+  - migrations
+contentType:
+  - reference
+  - how-to
+useCase:
+  - add-login
+  - enable-mobile-auth
+  - migrate
+---
+# Migrating from Lock iOS v1 to v2
+
+Lock 2.0 is the latest major release of Lock iOS-OSX. This guide is provided in order to ease the transition of existing applications using Lock 1.x to the latest APIs.
+
+## Requirements
+
+- iOS 9.0+
+- Xcode 8.0+
+- Swift 3.0+
+
+### Objective-C support
+
+Lock v2 cannot be used from Objective-C, since its public API relies on Swift features and that makes them unavailable in ObjC codebases.
+
+If you are willing to have some Swift code in your existing application, you can follow this [guide](https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/MixandMatch.html) on how to mix Objective-C and Swift and then use Lock v2 from the Swift files.
+
+If that's not an option, we recommend sticking with Lock v1 or using [Auth0.swift](/libraries/auth0-swift) to build your own interface for user logins and signups.
+
+## Benefits of upgrading
+
+- **Complete Swift 3 Compatibility:** The new version includes the adoption of the new [API Design Guidelines](https://swift.org/documentation/api-design-guidelines/).
+- **Improved UI:** having a professional looking login box that displays well on any device.
+- **Extensive configuration:** Lock provides improved configuration options to help customize the experience to your users needs.
+- **Safari controller for web-based Auth:** Following Google's recent ban of WebView based auth, Lock (and Auth0.swift) will always use `SFSafariViewController` when web auth is needed.
+- **API Authorization support:** Adds support for Auth0 [API Authorization](https://auth0.com/docs/api-auth)
+
+## Changes from v1
+
+Lock 2.0 has adopted to all of the new Swift 3 changes and conventions, including the new [API Design Guidelines](https://swift.org/documentation/api-design-guidelines/). Because of this, almost every API in Lock has been modified in some way. This guide will attempt to identify the most common usages and how they have changed, to help you get started with Lock 2.0. For yet more information on Lock 2.0, you can also see the [Lock 2.0 Reference](libraries/lock-ios) documentation.
+
+### Integration with your Application
+
+Lock needs to be notified for some of your application state changes and some events/notifications your application receives from the OS. You can do all these things in the `AppDelegate`
+
+#### Application finished launching
+
+In Lock v1 you'd add the following:
+
+```swift
+func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
+  A0Lock.sharedLock().applicationLaunchedWithOptions(launchOptions)
+  //Your code
+  return true
+}
+```
+
+In Lock v2, this is no longer required.
+
+#### Application is asked to open URL
+
+In Lock v1 you'd add the following:
+
+```swift
+func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool {
+  return A0Lock.shared().handle(url, sourceApplication: app)
+}
+```
+
+In Lock v2 you need to instead use the following:
+
+```swift
+func application(_ app: UIApplication, open url: URL, options: [UIApplication.OpenURLOptionsKey: Any] = [:]) -> Bool {
+  return Lock.resumeAuth(url, options: options)
+}
+```
+
+#### Application is asked to continue a User Activity
+
+If you are using Lock passwordless and have specified the `.magicLink` option to send the user a universal link then you will need to add the following to your `AppDelegate.swift`:
+
+```swift
+func application(_ application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([Any]?) -> Void) -> Bool {
+    return Lock.continueAuth(using: userActivity)
+}
+```
+
+### Usage
+
+`Lock` by default will handle Email/Password, Enterprise & Social authentication based on your application's connections enabled in your [Auth0 Dashboard](${manage_url}) under "Connections" in your application settings.
+
+#### Auth0 credentials
+
+Like in v1, in your application bundle you can add a `plist` file named `Auth0.plist` with the following format:
+
+```xml
+
+
+
+
+  ClientId
+  ${account.clientId}
+  Domain
+  ${account.namespace}
+
+
+```
+
+This will load your Auth0 credentials.
+
+#### Classic mode (Database, Enterprise & Social authentication)
+
+In v1 to show Lock from a `UIViewController` you'd add the following code:
+
+```swift
+let lock = A0Lock.shared()
+let controller = lock.newLockViewController()
+controller.onAuthenticationBlock = {(profile, token) in
+  // Do something with token & profile, such as save them.
+  // Lock will not save the Token and the profile for you.
+  // And dismiss the UIViewController.
+  self.dismissViewController(animated: true, completion: nil)
+}
+lock.present(controller, from: self)
+```
+
+In v2, to show Lock, the following code will be necessary:
+
+```swift
+Lock
+  .classic()
+  .onAuth { credentials in
+    print("Authenticated!")
+  }
+  .present(from: self)
+```
+
+So, in the `onAuth` callback, you'd only receive the credentials of the user when the authentication is successful.
+
+::: note
+In contrast with Lock v1, in v2, Lock will dismiss itself so there is no need to call `dismissViewController(animated:, completion:)` in any of the callbacks.
+:::
+
+In the case you need to know about the errors or signup, there are the corresponding `onError` and `onSignUp` callbacks that can be employed.
+
+```swift
+Lock
+  .classic()
+  .onAuth { credentials in
+    print("Authenticated!")
+  }
+  .onSignUp { email, attributes in
+    print("New user with email \(email)!")
+  }
+  .onError { error in
+    print("Failed with error \(error.localizedString)")
+  }
+  .present(from: self)
+```
+
+::: note
+The callback `onSignUp` is only called when the "login after signup" is disabled.
+:::
+
+#### Passwordless mode (Email & SMS connections)
+
+In v1 to show Lock Passwordless from a `UIViewController` you'd need to use either:
+
+Email:
+
+```swift
+let lock = A0Lock.shared()
+let controller: A0EmailLockViewController = lock.newEmailViewController()
+controller.useMagicLink = true
+controller.onAuthenticationBlock = { (profile, token) in
+    // Do something with token & profile, such as save them.
+    // Lock will not save the Token and the profile for you.
+    // And dismiss the UIViewController.
+    self.dismiss(animated: true, completion: nil)
+}
+lock.presentEmailController(controller, from: self)
+```
+
+or SMS:
+
+```swift
+let lock = A0Lock.shared()
+let controller: A0SMSLockViewController = lock.newSMSViewController()
+controller.useMagicLink = true
+controller.onAuthenticationBlock = { (profile, token) in
+    // Do something with token & profile, such as save them.
+    // Lock will not save the Token and the profile for you.
+    // And dismiss the UIViewController.
+    self.dismiss(animated: true, completion: nil)
+}
+lock.presentSMSController(controller, from: self)
+```
+
+In V2 both email and sms now use the same method:
+
+```swift
+Lock
+    .passwordless()
+    .onAuth { credentials in
+      print("Authenticated!")
+    }
+    .present(from: self)
+```
+
+**Notes:**
+
+- Passwordless can only be used with a single connection and will prioritize the use of email connections over SMS.
+- The `audience` option is not available in Passwordless.
+
+#### Configuration options
+
+If you needed to tweak Lock behaviour using its options in v1, you would use the following format:
+
+```swift
+let controller = A0Lock.shared().newLockViewController()
+controller?.closable = true
+controller?.connections = ["facebook", "github", "my-database"]
+```
+
+In Lock v2 you can do it all before presenting Lock by using this format:
+
+```swift
+Lock
+  .withOptions { options in
+    options.closable = true
+    options.allowedConnections = ["facebook", "github", "my-database"]
+  }
+  // continue configuring and then present Lock
+```
+
+#### UI customizations
+
+In v1 all UI customizations were performed using the `A0Theme` object in this format:
+
+```swift
+let theme = A0Theme()
+theme.register(.blue, forKey: A0ThemeTitleTextColor)
+A0Theme.sharedInstance().register(theme)
+```
+
+In Lock v2, the UI customization is done using the `withStyle` function:
+
+```swift
+Lock
+  .classic()
+  .withStyle { style in
+    style.titleColor = .blue
+  }
+  // other customizations
+  .present(from: self)
+```
+
+## Use Auth0.Swift Library to access user profile
+
+Lock can no longer directly access user profile information. To do so, you will now need to use the [Auth0.Swift library](/libraries/auth0-swift). Below is an example of accessing `userInfo` with `Auth0.Swift`:
+
+```swift
+guard let accessToken = credentials.accessToken else { return }
+Auth0
+    .authentication()
+    .userInfo(token: accessToken)
+    .start { result in
+        switch result {
+        case .success(let profile):
+            // You've got a UserProfile object
+        case .failure(let error):
+            // You've got an error
+        }
+}
+```
+
+### Delegation
+
+<%= include('../../../_includes/_deprecate-delegation') %>
+
+Delegation is not available through Lock. It can be implemented via a legacy method in [Auth0.Swift](/libraries/auth0-swift) for tenants which existed prior to June 2017.
+
+<%= include('../_includes/_roadmap') %>
diff --git a/ja-jp/articles/libraries/lock-ios/v2/passwordless.md b/ja-jp/articles/libraries/lock-ios/v2/passwordless.md
new file mode 100644
index 0000000000..5f9478eca3
--- /dev/null
+++ b/ja-jp/articles/libraries/lock-ios/v2/passwordless.md
@@ -0,0 +1,59 @@
+---
+section: libraries
+title: Lock Passwordless for iOS
+description: Using Passwordless authentication with Lock for iOS v2
+topics:
+  - libraries
+  - lock
+  - ios
+  - passwordless
+contentType:
+  - reference
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Lock Passwordless for iOS
+
+Lock Passwordless handles passwordless authentication using email and sms connections.
+
+To use Passwordless Authentication you need Lock.Swift version 2.14.0 or greater.
+
+To show Lock, add the following snippet in your `UIViewController`.
+
+```swift
+Lock
+    .passwordless()
+    .withOptions {
+         $0.oidcConformant = true
+    }
+    // withConnections, withOptions, withStyle, and so on.
+    .onAuth { credentials in
+      // Save the Credentials object
+    }
+    .present(from: self)
+```
+
+**Notes:**
+
+- Passwordless can only be used with a single connection and will prioritize the use of email connections over SMS.
+
+### Passwordless Method
+
+When using Lock Passwordless the default `passwordlessMethod` is `.code` which sends the user a one time passcode to login. If you want to use [Universal Links](/dashboard/guides/applications/enable-universal-links) you can add the following:
+
+```swift
+.withOptions {
+    $0.passwordlessMethod = .magicLink
+}
+```
+
+### Activity callback
+
+If you are using Lock Passwordless and have specified the `.magicLink` option to send the user a universal link then you will need to add the following to your `AppDelegate.swift`:
+
+```swift
+func application(_ application: UIApplication, continue userActivity: NSUserActivity, restorationHandler: @escaping ([Any]?) -> Void) -> Bool {
+    return Lock.continueAuth(using: userActivity)
+}
+```
diff --git a/ja-jp/articles/libraries/lock/index.yml b/ja-jp/articles/libraries/lock/index.yml
new file mode 100644
index 0000000000..a120986e44
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/index.yml
@@ -0,0 +1,7 @@
+versioning:
+  baseUrl: libraries/lock
+  current: v11
+  versions:
+    - v11
+  defaultArticles:
+    v11: index
diff --git a/ja-jp/articles/libraries/lock/v11/api.md b/ja-jp/articles/libraries/lock/v11/api.md
new file mode 100644
index 0000000000..58949c9ed4
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/api.md
@@ -0,0 +1,308 @@
+---
+section: libraries
+toc: true
+description: Details on the Lock v11 API.
+topics:
+  - libraries
+  - lock
+contentType:
+  - reference
+useCase:
+  - add-login
+---
+# Lock API Reference
+
+Lock has many methods, features, and configurable options. This reference is designed to direct you to the ones that you need, and discuss how to use them. Click below to go straight the method you're looking for, or just browse! If you're looking for information about events emitted by Lock, they're listed under the [on()](#on-) method section!
+
+- [new Auth0Lock](#auth0lock) - Instantiating Lock
+- [getUserInfo()](#getuserinfo-) - Obtaining the profile of a logged in user
+- [show()](#show-) - Showing the Lock widget
+- [on()](#on-) - Listening for events
+- [resumeAuth()](#resumeauth-) - Use to complete authentication flow when `autoParseHash` is false
+- [checkSession()](#checksession-) - Get a new token from Auth0 for an authenticated user
+- [logout()](#logout-) - Log out the user
+
+## Auth0Lock
+
+```js
+new Auth0Lock(clientID, domain, options)
+```
+
+Initializes a new instance of `Auth0Lock` configured with your application's `clientID` and your account's `domain` from your [Auth0](${manage_url}/) management dashboard. The third and optional parameter is an `options` object used to configure Lock for your application's needs. You can find this information at your [application settings](${manage_url}/#/applications).
+
+- **clientId {String}**: Required parameter. Your application's _clientId_ in Auth0.
+- **domain {String}**: Required parameter. Your Auth0 _domain_. Usually _your-account.auth0.com_.
+- **options {Object}**: Optional parameter. Allows for the configuration of Lock's appearance and behavior. See [the configuration options page](/libraries/lock/v11/configuration) for details.
+
+**Example:**
+
+```js
+var Auth = (function() {
+
+  var privateStore = {};
+
+  function Auth() {
+    // Instantiate Lock - without custom options
+    this.lock = new Auth0Lock(
+      '',
+      ''
+    );
+  }
+
+  Auth.prototype.getProfile = function() {
+    return privateStore.profile;
+  };
+
+  Auth.prototype.authn = function() {
+    // Listening for the authenticated event and get profile
+    this.lock.on("authenticated", function(authResult) {
+      // Use the token in authResult to getUserInfo() and save it if necessary
+      this.getUserInfo(authResult.accessToken, function(error, profile) {
+        if (error) {
+          // Handle error
+          return;
+        }
+
+        //save Access Token only if necessary
+        privateStore.accessToken = accessToken;
+        privateStore.profile = profile;
+
+        // Update DOM
+      });
+    });
+  };
+  return Auth;
+}());
+```
+
+## getUserInfo()
+
+```js
+getUserInfo(accessToken, callback)
+```
+
+Once the user has logged in and you are in possession of a token, you can use that token to obtain the user's profile with `getUserInfo`. This method replaces the deprecated `getProfile()`.
+
+- **accessToken {String}**: User token.
+- **callback {Function}**: Will be invoked after the user profile been retrieved.
+
+**Example:**
+
+```js
+lock.getUserInfo(accessToken, function(error, profile) {
+  if (!error) {
+    alert("hello " + profile.name);
+  }
+});
+```
+
+## show()
+
+```js
+show(options)
+```
+
+The `show` method displays the widget. Beginning with Lock version 10.2.0, the `show` method can now accept an `options` object as a parameter. Note that this parameter is meant to be used as a way to _override_ your Lock's `options` for this particular displaying of the widget - options should be _set_ when instantiating Lock, and _overridden_, only if needed for your specific use case, here.
+
+The following subset of `options` to be overridden from the values they were given (or their defaults) when Lock was instantiated:
+
+- [allowedConnections](/libraries/lock/v11/configuration#allowedconnections-array-)
+- [auth.params](/libraries/lock/v11/configuration#params-object-)
+- [allowLogin](/libraries/lock/v11/configuration#allowlogin-boolean-)
+- [allowSignUp](/libraries/lock/v11/configuration#allowsignup-boolean-)
+- [allowForgotPassword](/libraries/lock/v11/configuration#allowforgotpassword-boolean-)
+- [initialScreen](/libraries/lock/v11/configuration#initialscreen-string-)
+- [rememberLastLogin](/libraries/lock/v11/configuration#rememberlastlogin-boolean-)
+
+For more detail on the entire list of configurable options that can be chosen when instantiating Lock, as opposed to the limited subset above that can be overridden in the `show` method, please see the [user configurable options page](/libraries/lock/v11/configuration).
+
+Options override examples:
+
+```js
+// Show the Lock widget, without overriding any options
+lock.show();
+```
+
+```js
+// Show the Lock widget, overriding some options
+lock.show({
+  allowedConnections: ["twitter", "facebook"],
+  allowSignUp: false
+});
+```
+
+::: panel When to set your configuration options
+Options should be set when first instantiating Lock `var lock = new Auth0Lock(clientId, domain, options);`. Options should only be passed to `show` in order to override your previously set options while displaying the widget at this particular time and place.
+
+Previous users of Lock 9 should note that this is a different behavior from `options` in Lock 9, where all options were set as parameters of `show` and not at instantiation.
+:::
+
+There is an additional option that can be set in the `show` method called `flashMessage`.
+
+### flashMessage
+
+This object is _only_ available as an option for the `show` method, not for use in the normal `options` object when instantiating Lock. The `flashMessage` object shows an error or success flash message when Lock is shown. It has the following parameters:
+
+- **type** {String}: The message type, it should be either `error` or `success`.
+- **text** {String}: The text to show.
+
+An example of usage:
+
+```js
+lock.show({
+  flashMessage:{
+    type: 'success',
+    text: 'Amazing Success!!'
+  }
+});
+```
+
+![Lock - Flash Message](/media/articles/libraries/lock/v10/flashMessage.png)
+
+A practical application of the `flashMessage` option is to handle authorization errors. The `flashMessage` can be populated with error description text.
+
+```js
+lock.on('authorization_error', function(error) {
+  lock.show({
+    flashMessage: {
+      type: 'error',
+      text: error.errorDescription
+    }
+  });
+});
+```
+
+So, if `tester@example.com` were now to try to sign in, being a user who is blocked, the user will be shown Lock again, and receive the following error message:
+
+![Lock - Flash Message](/media/articles/libraries/lock/v10/flashmessage2.png)
+
+Rather than simply failing to login, and Lock closing.
+
+## hide()
+
+```js
+hide()
+```
+
+The `hide` method closes the widget if it is currently open. The widget closes itself under most circumstances, so this method would primarily be invoked in specific use cases only. For instance, one might wish to listen for the `unrecoverable_error` event and then `hide` the Lock and redirect to their own custom error page. Another example is users who are implementing [popup mode](/libraries/lock/v11/popup-mode), and might need to manually `hide` the widget after the `authenticated` event fires.
+
+Example usage to hide (close) the Lock widget in popup mode:
+
+```js
+// Listen for authenticated event and hide Lock
+lock.on("authenticated", function() {
+  lock.hide();
+
+  // Whatever else you'd like to do on authenticated event
+
+});
+```
+
+## on()
+
+```js
+on(event, callback)
+```
+
+Lock will emit events during its lifecycle. The `on` method can be used to listen for particular events and react to them.
+
+- `show`: emitted when Lock is shown. Has no arguments.
+- `hide`: emitted when Lock is hidden. Has no arguments.
+- `unrecoverable_error`: emitted when there is an unrecoverable error, for instance when no connection is available. Has the error as the only argument.
+- `authenticated`: emitted after a successful authentication. Has the authentication result as the only argument. The authentication result contains the token which can be used to get the user's profile or stored to log them in on subsequent checks. 
+- `authorization_error`: emitted when authorization fails. Has error as the only argument.
+- `hash_parsed`: every time a new Auth0Lock object is initialized in redirect mode (the default), it will attempt to parse the hash part of the url looking for the result of a login attempt. This is a low level event for advanced use cases and `authenticated` and `authorization_error` should be preferred when possible. After that this event will be emitted with `null` if it couldn't find anything in the hash. It will be emitted with the same argument as the `authenticated` event after a successful login or with the same argument as `authorization_error` if something went wrong. This event won't be emitted in [popup mode](/libraries/lock/v11/authentication-modes) because there is no need to parse the url's hash part.
+- `forgot_password ready`: emitted when the "Forgot password" screen is shown. (Only in Version >`10.18`)
+- `forgot_password submit`: emitted when the user clicks on the submit button of the "Forgot password" screen. (Only in Version >`10.14`)
+- `signin ready`: emitted when the "Sign in" screen is shown.
+- `signup ready`: emitted when the "Sign up" screen is shown.
+- `signin submit`: emitted when the user clicks on the submit button of the "Login" screen. (Only in Version >`10.18`)
+- `signup submit`: emitted when the user clicks on the submit button of the "Sign Up" screen. (Only in Version >`10.18`)
+- `federated login`: emitted when the user clicks on a social connection button. Has the connection name and the strategy as arguments. (Only in Version >`10.18`)
+- `socialOrPhoneNumber ready`: emitted when the Passwordless screen with Social + Phone Number is shown
+- `socialOrPhoneNumber submit`: emitted when the Passwordless screen with Social + Phone Number is submitted
+- `socialOrEmail ready`: emitted when the Passwordless screen with Social + Email is shown
+- `socialOrEmail submit`: emitted when the Passwordless screen with Social + Email is submitted
+- `vcode ready`: emitted when the Passwordless screen with the one-time-password is shown
+- `vcode submit`: emitted when the Passwordless screen with the one-time-password is submitted
+
+The `authenticated` event listener has a single argument, an `authResult` object. This object contains the following properties: `accessToken`, `idToken`, `state`, `refreshToken` and `idTokenPayload`.
+
+An example use of the `authenticated` event:
+
+```js
+var Auth = (function() {
+
+  var privateStore = {};
+
+  function Auth() {
+    this.lock = new Auth0Lock(
+      '',
+      ''
+    );
+  }
+
+  Auth.prototype.getProfile = function() {
+    return privateStore.profile;
+  };
+
+  Auth.prototype.authn = function() {
+    // Listening for the authenticated event
+    this.lock.on("authenticated", function(authResult) {
+      // Use the token in authResult to getUserInfo() and save it if necessary
+      this.getUserInfo(authResult.accessToken, function(error, profile) {
+        if (error) {
+          // Handle error
+          return;
+        }
+        
+        privateStore.profile = profile;
+      
+      });
+    });
+  };
+  return Auth;
+}());
+```
+
+## resumeAuth()
+
+This method can only be used when you set the [auth.autoParseHash](/libraries/lock/v11/configuration#autoparsehash-boolean-) option to `false`. You'll need to call `resumeAuth` to complete the authentication flow. This method is useful when you're using a client-side router that uses a `#` to handle urls (angular2 with `useHash`, or react-router with `hashHistory`).
+
+- **hash** {String}: The hash fragment received from the redirect.
+- **callback** {Function}: Will be invoked after the parse is done. Has an error (if any) as the first argument and the authentication result as the second one. If there is no hash available, both arguments will be `null`.
+
+```js
+lock.resumeAuth(hash, function(error, authResult) {
+  if (error) {
+    alert("Could not parse hash");
+  }
+  //This is just an example; you should not log Access Tokens in production.
+  console.log(authResult.accessToken);
+});
+```
+
+## checkSession()
+
+The `checkSession` method allows you to acquire a new token from Auth0 for a user who is already authenticated against Auth0 for your domain. It takes the following parameters:
+
+- **options** {Object}: Optional. Accepts any valid OAuth2 parameters that would normally be sent to `/authorize`. If you omit them, it will use the ones provided when initializing Auth0.
+- **callback** {Function}: Will be invoked with the token renewal result. Has an error (if any) as the first argument and the authentication result as the second one.
+
+```js
+lock.checkSession({}, function(err, authResult) {
+  // handle error or new tokens
+});
+```
+
+## logout()
+
+Logs out the user.
+
+- **options** {Object}: This is optional and follows the same rules as [auth0.js logout](/libraries/auth0js#logout)
+
+```js
+lock.logout({
+  returnTo: 'https://myapp.com/bye-bye'
+});
+```
diff --git a/ja-jp/articles/libraries/lock/v11/authentication-modes.md b/ja-jp/articles/libraries/lock/v11/authentication-modes.md
new file mode 100644
index 0000000000..b11a8d6310
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/authentication-modes.md
@@ -0,0 +1,62 @@
+---
+section: libraries
+description: Details about Authentication Modes with Lock v11.
+toc: true
+topics:
+  - libraries
+  - lock
+contentType:
+  - how-to
+  - concept
+useCase:
+  - add-login
+---
+# Lock Authentication Modes
+
+Lock can function in two different modes. The default mode is **redirect mode**. In this mode, your user is redirected to be authenticated, and then is returned to the application. In the second mode, **popup mode**, a popup window allows the user to authenticate with the identity provider without leaving the application.
+
+## Redirect Mode
+
+When you click the IdP button (For example, Facebook) with redirect mode, you are redirected to Facebook momentarily. Redirect mode is the default with Lock v11, and is the recommended mode for almost all use cases. Once you successfully login (to Facebook, in this example), Facebook will redirect you back to your app (through Auth0). The majority of examples or samples in the reference documentation employ redirect mode.
+
+## Popup Mode
+
+If after you click on the IdP button (Facebook for example), a popup (new tab or window) is opened, it means you are using popup mode. In that popup, you'll see that Facebook page is displayed. Once you successfully login to Facebook, the popup will be closed and your web app will recognize that the user has been authenticated. The web app has **never been redirected to any other page**.
+
+Implementing Lock with Popup Mode is again a simple change of the `redirect` option from its default.
+
+```js
+var lock = new Auth0Lock(
+  '${account.clientId}',
+  '${account.namespace}',
+  {
+    auth: {
+      redirect: false
+    }
+  }
+);
+```
+
+::: note
+Multi-factor authentication (MFA) is not supported when Lock is in popup mode and embedded in your application.
+:::
+
+::: note
+Popup mode does not work with Universal Login.
+:::
+
+Some Auth0 features such as [Single Sign-out (SSO)](/sso/current/sso-auth0) between multiple applications depend on users being redirected to Auth0 to set a cookie on `'${account.namespace}'`.
+
+When using popup mode, a popup window will be displayed in order to set this cookie. If prompts are unnecessary, this popup window will be blank and be in a hidden iframe to minimize disruption. The reason for this is that cross-origin requests sent from your application to Auth0 are not be able to set cookies.
+
+If you do not want to display a popup window and do not need SSO between multiple applications, you can set `sso: false` when using Lock or auth0.js.
+
+For example:
+
+```js
+var options = {
+  auth: {
+    sso: false
+  }
+}
+```
diff --git a/ja-jp/articles/libraries/lock/v11/configuration.md b/ja-jp/articles/libraries/lock/v11/configuration.md
new file mode 100644
index 0000000000..d5c1e9492c
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/configuration.md
@@ -0,0 +1,973 @@
+---
+section: libraries
+toc: true
+description: Lock v11 has many configurable options that allow you to change the behavior, appearance, and connectivity of the Lock widget - this resource provides the details on those options for you!
+topics:
+  - libraries
+  - lock
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+---
+# Lock Configuration Options
+
+The **Auth0Lock** can be configured through the `options` parameter sent to the constructor. These options can alter the way that the Lock widget behaves, how it deals with connections, additional signup fields that you require for your project, the language and text values, colors, and images on the widget, and many more. Take a look at the index below if you know what you are looking for, or browse the options for more details.
+
+```js
+var lock = new Auth0Lock('clientID', 'account.auth0.com', options);
+```
+
+## UI
+
+| Option | Description |
+| --- | --- |
+| [allowAutocomplete](#allowautocomplete-boolean-) | Enable or disable autocompletion on the email or username inputs |
+| [allowPasswordAutocomplete](#allowpasswordautocomplete-boolean-) | Enable or disable autocompletion on password input |
+| [allowShowPassword](#allowshowpassword-boolean-) | Specifies if the user can choose to show password while typing it |
+| [allowedConnections](#allowedconnections-array-) | List of connections that will be available to perform authentication |
+| [autoclose](#autoclose-boolean-) | Specifies if Lock closes after a login |
+| [autofocus](#autofocus-boolean-) | Specifies if focus is set on the first input field |
+| [avatar](#avatar-object-) | Specifies if an avatar and a username should be displayed on the Lock's header once an email or username has been entered and how to obtain it |
+| [closable](#closable-boolean-) | Determines whether or not Lock can be closed |
+| [container](#container-string-) | The HTML element where Lock will be rendered. This causes Lock to appear inline instead of in a modal window |
+| [flashMessage](#) | Shows an `error` or `success` flash message when Lock is shown |
+| [language](#language-string-) | Specifies the language of the widget |
+| [languageDictionary](#languagedictionary-object-) | Change text in particular sections of Lock |
+| [popupOptions](#popupoptions-object-) | Customize the location of the popup in the screen |
+| [rememberLastLogin](#rememberlastlogin-boolean-) | Whether or not to show a screen that allows you to quickly log in with the account you used the last time |
+| [scrollGlobalMessagesIntoView](#scrollglobalmessagesintoview-boolean-) | Specify if a globalMessage should be scrolled into the user's viewport |
+
+## Theme
+
+Theme options are grouped in the `theme` property of the `options` object.
+
+| Option | Description |
+| --- | --- |
+| [authButtons](#authbuttons-object-) | Customize the appearance of specific connection buttons |
+| [labeledSubmitButton](#labeledsubmitbutton-boolean-) | whether or not the submit button has text |
+| [logo](#logo-string-) | What logo should be used |
+| [primaryColor](#primarycolor-string-) | Color of the primary button on the widget |
+
+## Authentication
+
+Authentication options are grouped in the `auth` property of the `options` object.
+
+| Option | Description |
+| --- | --- |
+| [audience](#audience-string-) | The API which will be consuming your Access Token |
+| [autoParseHash](#autoparsehash-boolean-) | Whether or not to automatically parse hash and continue |
+| [connectionScopes](#connectionscopes-object-) | Specify connection scopes |
+| [params](#params-object-) | Option to send parameters at login |
+| [redirect](#redirect-boolean-) | Whether or not to use redirect mode |
+| [redirectUrl](#redirecturl-string-) | The URL to redirect to after auth |
+| [responseMode](#responsemode-string-) | Option to send response as POST |
+| [responseType](#responsetype-string-) | Response as a code or token |
+| [sso](#sso-boolean-) | Determines whether Single Sign-On is enabled or not in Lock |
+
+### Database
+
+| Option | Description |
+| --- | --- |
+| [additionalSignUpFields](#additionalsignupfields-array-) | Additional fields collected at signup |
+| [allowLogin](#allowlogin-boolean-) | Whether or not to allow login on widget |
+| [allowForgotPassword](#allowforgotpassword-boolean-) | Whether or not to allow forgot password on widget |
+| [allowSignUp](#allowsignup-boolean-) | Whether or not to allow signup on widget |
+| [defaultDatabaseConnection](#defaultdatabaseconnection-string-) | Default shown DB connection |
+| [initialScreen](#initialscreen-string-) | Which screen to show when the widget is opened |
+| [loginAfterSignUp](#loginaftersignup-boolean-) | After signup, whether or not to auto login |
+| [forgotPasswordLink](#forgotpasswordlink-string-) | Link to a custom forgot password page |
+| [showTerms](#showterms-boolean-) | Specify if signup terms should be display |
+| [mustAcceptTerms](#mustacceptterms-boolean-) | Whether or not terms must be accepted (checkbox) |
+| [prefill](#prefill-object-) | Prefill values for email/username fields |
+| [signUpLink](#signuplink-string-) | Set a custom url to fire when clicking "sign up" |
+| [usernameStyle](#usernamestyle-string-) | Limit username field to accept only "username" values or only "email" values |
+| [signUpFieldsStrictValidation](#signUpFieldsStrictValidation-boolean-) | Strict format validation for username and email fields at signup |
+
+## Enterprise
+
+| Option | Description |
+| --- | --- |
+| [defaultEnterpriseConnection](#defaultenterpriseconnection-string-) | Specifies a connection if more than one present |
+
+## Passwordless
+
+| Option | Description |
+| --- | --- |
+| [passwordlessMethod](#passwordlessmethod-string-) | When using `Auth0LockPasswordless` with an email connection, you can use this option to pick between sending a [code](/connections/passwordless/spa-email-code) or a [magic link](/connections/passwordless/spa-email-link) to authenticate the user |
+
+### Other
+
+| Option | Description |
+| --- | --- |
+| [configurationBaseUrl](#configurationbaseurl-string-) | Override your application's base URL |
+| [languageBaseUrl](#languagebaseurl-string-) | Override your language file base URL |
+| [hashCleanup](#hashcleanup-boolean-) | Override the default removal of the hash from the URL |
+| [connectionResolver](#connectionresolver-function-) | Optional callback function for choosing a connection based on the username information |
+
+---
+
+## UI Options
+
+### allowAutocomplete {Boolean}
+
+Determines whether or not the email or username fields will allow autocomplete (``). Defaults to `false`.
+
+```js
+var options = {
+  allowAutocomplete: true
+};
+```
+
+### allowPasswordAutocomplete {Boolean}
+
+Determines whether or not the password field will allow autocomplete (``). Defaults to `false`.
+
+Set `allowPasswordAutocomplete` to `true` for password manager support and to avoid other cases of adverse behavior.
+
+```js
+var options = {
+  allowPasswordAutocomplete: true
+};
+```
+
+### allowShowPassword {Boolean}
+
+This option determines whether or not to add a checkbox to the UI which, when selected, will allow the user to show their password when typing it. The option defaults to `false`.
+
+```js
+var options = {
+  allowShowPassword: true
+};
+```
+
+Lock with `allowShowPassword` set to `true` and toggled to show the password:
+
+![Lock - Avatar](/media/articles/libraries/lock/v11/customization/lock-allowshowpassword.png)
+
+### allowedConnections {Array}
+
+Array of connections that will be used for the `signin|signup|reset` actions. Defaults to all enabled connections.
+
+```js
+// The following will only display
+// username and password sign in form
+var options = {
+  allowedConnections: ['Username-Password-Authentication']
+};
+
+// ... social connections only
+var options = {
+  allowedConnections: ['twitter', 'facebook', 'linkedin']
+};
+
+// ... enterprise connections only
+var options = {
+  allowedConnections: ['qraftlabs.com']
+};
+```
+
+Examples of `allowedConnections`:
+
+![Lock - Allowed Connections](/media/articles/libraries/lock/v11/customization/lock-allowedconnections-database.png)
+
+![Lock - Allowed Connections](/media/articles/libraries/lock/v11/customization/lock-allowedconnections-social.png)
+
+### autoclose {Boolean}
+
+Determines whether or not the Lock will be closed automatically after a successful sign in. Defaults to false.
+
+::: note
+If the Lock is not `closable` it won't be closed, even if this option is set to true.
+:::
+
+```js
+var options = {
+  autoclose: true
+};
+```
+
+### autofocus {Boolean}
+
+If true, the focus is set to the first field on the widget. Defaults to `false` when being rendered on a mobile device, or if a `container` option is provided; defaults to `true` in all other cases.
+
+```js
+var options = {
+  autofocus: false
+};
+```
+
+### avatar {Object}
+
+By default, Gravatar is used to fetch the user avatar and display name, but you can obtain them from anywhere with the `avatar` option.
+
+```js
+var options = {
+  avatar: {
+    url: function(email, cb) {
+      // Obtain the avatar url for the email input by the user, Lock
+      // will preload the image before displaying it.
+      // Note that in case of an error you call cb with the error in
+      // the first arg instead of `null`.
+      var url = obtainAvatarUrl(email);
+      cb(null, url);
+    },
+    displayName: function(email, cb) {
+      // Obtain the display name for the email input by the user.
+      // Note that in case of an error you call cb with the error in
+      // the first arg instead of `null`.
+      var displayName = obtainDisplayName(email);
+      cb(null, displayName);
+    }
+  }
+};
+```
+
+Or, if you want to display no avatar at all, simply pass in `null`.
+
+```js
+var options = {
+  avatar: null
+};
+```
+
+Default behavior with Gravatar:
+
+![Lock - Avatar](/media/articles/libraries/lock/v11/customization/lock-avatar.png)
+
+### closable {Boolean}
+
+Determines whether or not the Lock can be closed. When a `container` option is provided its value is always `false`, otherwise it defaults to `true`.
+
+```js
+var options = {
+  closable: false
+};
+```
+
+![Lock - Closable](/media/articles/libraries/lock/v11/customization/lock-closable.png)
+
+### container {String}
+
+The `id` of the html element where the widget will be shown.
+
+This makes the widget appear inline within your `div` instead of in a modal pop-out window.
+
+```html
+
      
+
+
+```
+
+![Lock - Container](/media/articles/libraries/lock/v11/customization/lock-container.png)
+
+### flashMessage {Object}
+
+Shows an `error` or `success` flash message when Lock is shown. This object has the following properties:
+
+- type {String}: The message type, supported types are `error`, `info`, and `success`
+- text {String}: The text to show.
+
+```js
+var options = {
+  flashMessage: {
+    type: 'success',
+    text: 'Welcome!'
+  }
+};
+```
+
+### language {String}
+
+Specifies the language of the widget. Defaults to "en". See the [internationalization directory](https://github.com/auth0/lock/blob/master/src/i18n/) for a current list of provided languages.
+
+```js
+// select a supported language
+var options = {
+  language: 'es'
+};
+```
+
+![Lock - Language](/media/articles/libraries/lock/v11/customization/lock-language.png)
+
+### languageDictionary {Object}
+
+Allows customization of every piece of text displayed in the Lock. Defaults to {}. See English language [Language Dictionary Specification](https://github.com/auth0/lock/blob/master/src/i18n/en.js) for the full list of `languageDictionary` values able to be altered with this object.
+
+```js
+var options = {
+  languageDictionary: {
+    emailInputPlaceholder: "something@youremail.com",
+    title: "Log me in"
+  },
+};
+```
+
+![Lock - Language Dictionary](/media/articles/libraries/lock/v11/customization/lock-languagedictionary.png)
+
+Additionally, check out the [Customizing Error Messages](/libraries/lock/v11/customizing-error-messages) page or the [Internationalization](/libraries/lock/v11/i18n) page for more information about the use of the `languageDictionary` option.
+
+### popupOptions {Object}
+
+Allows the customization the location of the popup in the screen. Any position and size feature allowed by window.open is accepted. Defaults to {}.
+
+Options for the `window.open` [position and size][windowopen-link] features. This only applies if `redirect` is set to `false`.
+
+```js
+var options = {
+  auth: {
+      redirect: false
+  },
+  popupOptions: { width: 300, height: 400, left: 200, top: 300 }
+};
+```
+
+### rememberLastLogin {Boolean}
+
+Determines whether or not to show a screen that allows you to quickly log in with the account you used the last time.
+Requests Single Sign-on (SSO) data and enables a **Last time you signed in with[...]** message. Defaults to `true`. This information comes from the user's Auth0 session, so this ability will last as long as their Auth0 session would (which is [configurable](/dashboard/reference/settings-tenant#login-session-management).
+
+```js
+var options = {
+  rememberLastLogin: false
+};
+```
+::: note
+New tenants [automatically have Seamless SSO enabled](https://auth0.com/docs/dashboard/guides/tenants/enable-sso-tenant). With this enabled, the `rememberLastLogin` option will not be relevant because if there is a session in place then the hosted login page will not be displayed at all. Using Seamless SSO is highly recommended because it provides a seamless authentication experience: users log in once and won’t have to enter credentials again when they navigate either through the applications you have built, or third party apps. If the user is not logged in they will be redirected to the login screen, as expected.
+:::
+
+::: note
+The **Last time you signed in with [...]** message will not be available under the following circumstances:
+
+- You used Lock in a [Hosted Login Page](/universal-login) with the session established using [Passwordless authentication](/connections/passwordless).
+- You used Lock in an [embedded login scenario](/guides/login/universal-vs-embedded#embedded-login-with-auth0) where `responseType: code` (indicating the [Authorization Code Flow](/flows/concepts/auth-code), which is used for Regular Web Apps).
+:::
+
+### scrollGlobalMessagesIntoView {Boolean}
+
+Determines whether or not a `globalMessage` should be scrolled into the user's viewport. Defaults to `true`.
+
+## Theme Options
+
+Theme options are grouped in the `theme` property of the `options` object.
+
+```js
+var options = {
+  theme: {
+    labeledSubmitButton: false,
+    logo: "https://example.com/assets/logo.png",
+    primaryColor: "green",
+    authButtons: {
+      connectionName: {
+        displayName: "...",
+        primaryColor: "...",
+        foregroundColor: "...",
+        icon: "https://.../logo.png"
+      }
+    }
+  }
+};
+```
+
+### authButtons {Object}
+
+Allows the customization of buttons in Lock with custom OAuth2 connections. Each custom connection whose button you desire to customize should be listed by name, each with their own set of parameters. The customizable parameters are listed below:
+
+- **displayName** {String}: The name to show instead of the connection name when building the button title, such as `LOGIN WITH MYCONNECTION` for login).
+- **primaryColor** {String}: The button's background color. Defaults to `#eb5424`.
+- **foregroundColor** {String}: The button's text color. Defaults to `#FFFFFF`.
+- **icon** {String}: The URL of the icon for this connection. For example: `http://site.com/logo.png`.
+
+```js
+var options = {
+  theme: {
+    authButtons: {
+      "testConnection": {
+        displayName: "Test Conn",
+        primaryColor: "#b7b7b7",
+        foregroundColor: "#000000",
+        icon: "http://example.com/icon.png"
+      },
+      "testConnection2": {
+        primaryColor: "#000000",
+        foregroundColor: "#ffffff",
+      }
+    }
+  }
+};
+```
+
+### labeledSubmitButton {Boolean}
+
+This option indicates whether or not the submit button should have a label, and defaults to `true`. When set to `false`, an icon will be shown instead.
+
+```js
+var options = {
+  theme: {
+    labeledSubmitButton: false
+  }
+};
+```
+
+![Lock - Labeled Submit Button](/media/articles/libraries/lock/v11/customization/lock-theme-labeledsubmitbutton.png)
+
+If the label is set to true, which is the default, the label's text can be customized through the [languageDictionary](#languagedictionary-object-) option.
+
+### logo {String}
+
+The value for `logo` is a URL for an image that will be placed in the Lock's header, and defaults to Auth0's logo. It has a recommended max height of `58px` for a better user experience.
+
+```js
+var options = {
+  theme: {
+    logo: 'https://example.com/logo.png'
+  }
+};
+```
+
+![Lock - Theme - Logo](/media/articles/libraries/lock/v11/customization/lock-theme-logo.png)
+
+### primaryColor {String}
+
+The `primaryColor` property defines the primary color of the Lock; all colors used in the widget will be calculated from it. This option is useful when providing a custom `logo`, to ensure all colors go well together with the `logo`'s color palette. Defaults to `#ea5323`.
+
+```js
+var options = {
+  theme: {
+    logo: 'https://example.com/logo.png',
+    primaryColor: '#31324F'
+  }
+};
+```
+
+![Lock - Theme - Primary Color](/media/articles/libraries/lock/v11/customization/lock-theme-primarycolor.png)
+
+## Authentication Options
+
+Authentication options are grouped in the `auth` property of the `options` object.
+
+The default scope used by Lock is `openid profile email`.
+
+```js
+var options = {
+  auth: {
+   params: {
+    param1: "value1",
+    scope: "openid profile email"
+   },
+   autoParseHash: true,
+   redirect: true,
+   redirectUrl: "some url",
+   responseMode: "form_post",
+   responseType: "token",
+   sso: true,
+   connectionScopes: {
+    connectionName: [ 'scope1', 'scope2' ]
+   }
+  }
+};
+```
+
+### audience {String}
+
+The `audience` option indicates the API which will be consuming the Access Token that is received after authentication.
+
+```js
+var options = {
+  auth: {
+    audience: 'https://${account.namespace}/userinfo',
+  }
+}
+```
+
+### autoParseHash {Boolean}
+
+When `autoParseHash` is set to `true`, Lock will parse the `window.location.hash` string when instantiated. If set to `false`, you'll have to manually resume authentication using the [resumeAuth](/libraries/lock/v11/api#resumeauth-) method.
+
+```js
+var options = {
+  auth: {
+    autoParseHash: false
+  }
+};
+```
+
+### connectionScopes {Object}
+
+This option allows you to set scopes to be sent to the oauth2/social connection for authentication.
+
+```js
+var options = {
+  auth: {
+    connectionScopes: {
+      'facebook': ['scope1', 'scope2']
+    }
+  }
+};
+```
+
+A listing of particular scopes for your social connections can be acquired from the provider in question. For example, [Facebook for Developers](https://developers.facebook.com/docs/facebook-login/permissions/) reference has a listing of separate permissions that can be requested for your connection.
+
+### params {Object}
+
+You can send parameters when starting a login by adding them to the options object. The example below adds a `state` parameter with a value equal to `foo` and also adds a `scope` parameter (which includes the scope, and then the requested attributes). [Read here][authparams-link] to learn more about what `authParams` can be set.
+
+```js
+var options = {
+  auth: {
+    params: {
+      state: 'foo',
+      scope: 'openid email user_metadata app_metadata picture'
+    }
+  }
+};
+```
+
+::: note
+For more details about supported parameters check the [Authentication Parameters][authparams-link] documentation page.
+:::
+
+### redirect {Boolean}
+
+Defaults to true. When set to true, redirect mode will be used. If set to false, [popup mode](/libraries/lock/v11/authentication-modes#popup-mode) is chosen.
+
+```js
+var options = {
+  auth: {
+    redirect: false
+  }
+};
+```
+
+### redirectUrl {String}
+
+The URL Auth0 will redirect back to after authentication. Defaults to the empty string "" (no redirect URL).
+
+```js
+var options = {
+  auth: {
+    redirectUrl: 'http://testurl.com'
+  }
+};
+```
+
+::: note
+When the `redirectUrl` is provided (set to non blank value) the `responseType` option will be defaulted to `code` if not manually set.
+:::
+
+### responseMode {String}
+
+Should be set to `"form_post"` if you want the code or the token to be transmitted via an HTTP POST request to the `redirectUrl`, instead of being included in its query or fragment parts.
+
+Otherwise, this option should be omitted, and is omitted by default.
+
+```js
+var options = {
+  auth: {
+    responseMode: 'form_post'
+  }
+};
+```
+
+### responseType {String}
+
+The value of `responseType` should be set to "token" for Single-Page Applications, and "code" otherwise. Defaults to "code" when redirectUrl is provided, and to "token" otherwise.
+
+```js
+var options = {
+  auth: {
+    responseType: 'token'
+  }
+};
+```
+
+::: note
+When the `responseType` is set to `code`, Lock will never show the **Last time you logged in with** message, and will always prompt the user for credentials.
+:::
+
+## Database Options
+
+### additionalSignUpFields {Array}
+
+Extra input fields can be added to the sign up screen with the `additionalSignUpFields` option. Each option added in this manner will then be added to that user's `user_metadata`. See [Metadata](/users/concepts/overview-user-metadata) for more information. Every input must have a `name` and a `placeholder`, and an `icon` URL can also be provided. Also, the initial value can be provided with the `prefill` option, which can be a string with the value or a function that obtains it. Other options depend on the type of the field, which is defined via the type option and defaults to "text".
+
+::: panel Intended for use with database signup only
+`additionalSignUpFields` are intended for use with database signups only. If you have social sign ups too, you can ask for the additional information after the users sign up (see this [page about custom signup](/libraries/custom-signup) for more details). You can use the `databaseAlternativeSignupInstructions` i18n key to display these instructions.
+:::
+
+The new fields are rendered below the regular sign up input fields in the order they are provided.
+
+#### Text Fields
+
+Text fields are the default type of additional signup field. Note that a `validator` function can also be provided.
+
+```js
+var options = {
+  additionalSignUpFields: [{
+    name: "address",
+    placeholder: "enter your address",
+    // The following properties are optional
+    icon: "https://example.com/assests/address_icon.png",
+    prefill: "street 123",
+    validator: function(address) {
+      return {
+         valid: address.length >= 10,
+         hint: "Must have 10 or more chars" // optional
+      };
+    }
+  },
+  {
+    name: "full_name",
+    placeholder: "Enter your full name"
+  }]
+}
+```
+
+If you don't specify a `validator` the text field will be **required**. If you want to make the text field optional, use a validator that always returns `true` like this:
+
+```js
+var options = {
+  additionalSignUpFields: [{
+    name: "favorite_color",
+    placeholder: "Enter your favorite color (optional)",
+    validator: function() { 
+      return true;
+    }
+  }]
+}
+```
+
+If you want to save the value of the attribute in the root of your profile, use `storage: 'root'`. Only a subset of values can be stored this way. The list of attributes that can be added to your root profile is [here](/api/management/v2#!/Users/patch_users_by_id). By default, every additional sign up field is stored inside the user_metadata object.
+
+```js
+var options = {
+  additionalSignUpFields: [{
+    name: "name",
+    storage: "root"
+  }]
+};
+```
+
+![Lock - Additional Signup Fields](/media/articles/libraries/lock/v11/customization/lock-additionalsignupfields.png)
+
+#### Select Field
+
+The signup field `type: "select"` will allow you to use select elements for the user to choose a value from.
+
+```js
+var options = {
+  additionalSignUpFields: [{
+    type: "select",
+    name: "location",
+    placeholder: "choose your location",
+    options: [
+      {value: "us", label: "United States"},
+      {value: "fr", label: "France"},
+      {value: "ar", label: "Argentina"}
+    ],
+    // The following properties are optional
+    icon: "https://example.com/assests/location_icon.png",
+    prefill: "us"
+  }]
+}
+```
+
+The `options` array items for `select` fields must adhere to the following format:
+`{label: “non empty string”, value: “non empty string”}`, and at least one option must be defined.
+
+The `options` and `prefill` values can be provided through a function:
+
+```js
+var options = {
+  additionalSignUpFields: [{
+    type: "select",
+    name: "location",
+    placeholder: "choose your location",
+    options: function(cb) {
+      // obtain options, in case of error you call cb with the error in the
+      // first arg instead of null
+      cb(null, options);
+    },
+    icon: "https://example.com/assests/location_icon.png",
+    prefill: function(cb) {
+      // obtain prefill, in case of error you call cb with the error in the
+      // first arg instead of null
+      cb(null, prefill);
+    }
+  }]
+}
+```
+
+#### Checkbox Field
+
+The third type of custom signup field is the `type: "checkbox"`. The `prefill` value can determine the default state of the checkbox (`true` or `false`), and it is required.
+
+```js
+var options = {
+  additionalSignUpFields: [{
+    type: "checkbox",
+    name: "newsletter",
+    prefill: "true",
+    placeholder: "I hereby agree that I want to receive marketing emails from your company"
+  }]
+}
+```
+
+#### Hidden field
+
+The signup field `type: "hidden"` will allow you to use a hidden input with a fixed value.
+
+```js
+var options = {
+  additionalSignUpFields: [{
+    type: "hidden",
+    name: "signup_code",
+    value: "abc123"
+  }]
+}
+```
+
+::: note
+Some use cases may be able to use `additionalSignUpFields` data for email templates, such as an option for language preferences, the value of which could then be used to set the language of templated email communications.
+:::
+
+### allowLogin {Boolean}
+
+When set to `false` the widget won't display the login screen. This is useful if you want to use the widget just for signups (the login and signup tabs in the signup screen will be hidden) or to reset passwords (the back button in the forgot password screen will be hidden). In such cases you may also need to specify the `initialScreen`, `allowForgotPassword` and `allowSignUp` options. It defaults to `true`.
+
+```js
+//
+var options = {
+  allowLogin: false
+};
+```
+
+![Lock - Allow Login](/media/articles/libraries/lock/v11/customization/lock-allowlogin.png)
+
+### allowForgotPassword {Boolean}
+
+When set to false, `allowForgotPassword` hides the "Don't remember your password?" link in the Login screen, making the Forgot Password screen unreachable. Defaults to true.
+
+::: note
+Keep in mind that if you are using a database connection with a custom database which doesn't have a change password script the Forgot Password screen won't be available.
+:::
+
+```js
+//
+var options = {
+  allowForgotPassword: false
+};
+```
+
+![Lock - Allow Forgot Password](/media/articles/libraries/lock/v11/customization/lock-allowforgotpassword.png)
+
+### allowSignUp {Boolean}
+
+When set to `false`, hides the login and sign up tabs in the login screen, making the sign up screen unreachable. Defaults to `true`. Keep in mind that if the database connection has sign ups disabled or you are using a custom database which doesn't have a create script, then the sign up screen won't be available.
+
+Also bear in mind that this option **only** controls client-side appearance, and does not completely stop new sign ups from determined anonymous visitors. If you are looking to fully prevent new users from signing up, you must use the **Disable Sign Ups** option in the dashboard, in the connection settings.
+
+```js
+var options = {
+  allowSignUp: false
+};
+```
+
+![Lock - Social Button Style](/media/articles/libraries/lock/v11/customization/lock-allowsignup.png)
+
+### defaultDatabaseConnection {String}
+
+Specifies the database connection that will be used when there is more than one available.
+
+```js
+var options = {
+  defaultDatabaseConnection: 'test-database'
+};
+```
+
+### initialScreen {String}
+
+The name of the screen that will be shown when the widget is opened. Valid values are `login`, `signUp`, and `forgotPassword`. If this option is left unspecified, the widget will default to the first screen that is available from that list.
+
+```js
+var options = {
+  initialScreen: 'forgotPassword'
+};
+```
+
+### loginAfterSignUp {Boolean}
+
+Determines whether or not the user will be automatically signed in after a successful sign up. Defaults to `true`.
+
+```js
+var options = {
+  loginAfterSignUp: false
+};
+```
+
+### forgotPasswordLink {String}
+
+Set the URL for a page that allows the user to reset their password. When set to a non-empty string, the user will be sent to the provided URL when clicking the "Don't remember your password?" link in the login screen.
+
+```js
+var options = {
+  forgotPasswordLink: 'https://yoursite.com/reset-password'
+};
+```
+
+### showTerms {Boolean}
+
+When set to `true` displays the `languageDictionary.signUpTerms` string. Defaults to `true`.
+
+### mustAcceptTerms {Boolean}
+
+When set to `true` displays a checkbox input alongside the terms and conditions that must be checked before signing up. The terms and conditions can be specified via the `languageDictionary` option. This option will only take effect for users signing up with database connections. Defaults to `false`.
+
+```js
+var options = {
+  mustAcceptTerms: true
+};
+```
+
+### prefill {Object}
+
+Allows to set the initial value for the email and/or username inputs. When omitted, no initial value will be provided.
+
+```js
+var options = {
+  prefill: {
+    email: "someone@auth0.com",
+    username: "someone",
+    phoneNumber: "+1234567890"
+  }
+};
+```
+
+### signUpLink {String}
+
+Set the URL to be requested when clicking on the Signup button.
+
+::: panel Side effects
+When set to a non empty string, this option forces `allowSignUp` to `true`.
+:::
+
+```js
+var options = {
+  signUpLink: 'https://yoursite.com/signup'
+};
+```
+
+### usernameStyle {String}
+
+Determines what will be used to identify the user for a Database connection that has the `requires_username` flag set (if it is not set, `usernameStyle` option will be ignored). Possible values are `"username"` and `"email"`. By default both `username` and `email` are allowed; setting this option will limit logins to use one or the other.
+
+```js
+var options = {
+  // Limits logins to usernames only, not emails
+  usernameStyle: 'username'
+};
+```
+
+### signUpFieldsStrictValidation {Boolean}
+
+This option enables strict format validation for username and email fields at the signup screen. This ensures presenting validation errors instead of the generic "We're sorry, something went wrong when attempting to sign up." message. Defaults to `false`.
+
+```js
+var options = {
+  signUpFieldsStrictValidation: true
+};
+```
+
+## Enterprise Options
+
+### defaultEnterpriseConnection {String}
+
+Specifies the enterprise connection which allows to login using a username and a password that will be used when there is more than one available or there is a database connection. If a `defaultDatabaseConnection` is provided the database connection will be used and this option will be ignored.
+
+```js
+var options = {
+  defaultEnterpriseConnection: 'test-database'
+};
+```
+
+### defaultADUsernameFromEmailPrefix {Boolean}
+
+Resolve the AD placeholder username from the email's prefix. Defaults to `true`.
+
+```js
+var options = {
+  defaultADUsernameFromEmailPrefix: false
+};
+```
+
+## Passwordless Options
+
+### passwordlessMethod {String}
+
+When using `Auth0LockPasswordless` with an email connection, you can use this option to pick between sending a [code](/connections/passwordless/spa-email-code) or a [magic link](/connections/passwordless/spa-email-link) to authenticate the user. Available values for email connections are `code` and `link`. Defaults to `code`. SMS passwordless connections will always use `code`.
+
+## Other Options
+
+### configurationBaseUrl {String}
+
+This option can provide a URL to override the application settings base URL. By default, it uses Auth0's CDN URL when the domain has the format `*.auth0.com`. For example, if your URL is `contoso.eu.auth0.com`, then by default, the `clientBaseUrl` is `cdn.eu.auth0.com`. If the `clientBaseUrl` option is set to something else instead, it uses the provided domain. This would only be necessary if your specific use case dictates that your application not use the default behavior.
+
+```js
+var options = {
+  clientBaseUrl: "https://www.example.com"
+};
+```
+
+### languageBaseUrl {String}
+
+Overrides the language source url for Auth0's provided translations. By default, this option uses Auth0's CDN URL `https://cdn.auth0.com` since this is where all of the provided translations are stored. By providing another value, you can use another source for the language translations if needed.
+
+```js
+var options = {
+  languageBaseUrl: "https://www.example.com"
+};
+```
+
+### hashCleanup {Boolean}
+
+When the `hashCleanup` option is enabled, it will remove the hash part of the callback URL after the user authentication. It defaults to true.
+
+```js
+var options = {
+  hashCleanup: false
+};
+```
+
+### connectionResolver {Function}
+
+When in use, provides an extensibility point to make it possible to choose which connection to use based on the username information.
+
+Has `username`, `context`, and `callback` as parameters. The callback expects an object like: `{type: 'database', name: 'connection name'}`. **This only works for database connections.** Keep in mind that this resolver will run in the form's `onSubmit` event, so keep it simple and fast.
+
+This is a beta feature. If you find a bug, please open a GitHub [issue](https://github.com/auth0/lock/issues/new).
+
+### leeway {Integer}
+
+The `leeway` option can be set to an integer - a value in seconds - which can be used to account for clock skew in ID Token expirations. Typically the value is no more than a minute or two at maximum.
+
+```js
+var options = {
+  leeway: 30
+};
+```
+
+
+
+[authparams-link]: /libraries/lock/v11/sending-authentication-parameters
+[windowopen-link]: https://developer.mozilla.org/en-US/docs/Web/API/Window.open#Position_and_size_features
diff --git a/ja-jp/articles/libraries/lock/v11/customizing-error-messages.md b/ja-jp/articles/libraries/lock/v11/customizing-error-messages.md
new file mode 100644
index 0000000000..1d06250ce5
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/customizing-error-messages.md
@@ -0,0 +1,50 @@
+---
+section: libraries
+description: Customizing error messages with Lock v11
+topics:
+  - libraries
+  - lock
+  - error-messages
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+---
+# Customizing Lock Error Messages
+
+You can customize the error messages that will be displayed in certain situations by providing a [languageDictionary option](/libraries/lock/v11/configuration#languagedictionary-object-). A full listing of available `languageDictionary` fields to customize can be found in the GitHub repository's [English Dictionary file for Lock v11](https://github.com/auth0/lock/blob/master/src/i18n/en.js). Below is an example of some customized error messages:
+
+```js
+// Examples of customized error messages in the languageDictionary option
+var options = {
+  languageDictionary: {
+    error: {
+      login: {
+        "lock.invalid_email_password": "Custom message about invalid credentials",
+        "lock.network": "Custom message indicating a network error and suggesting the user check connection",
+        "lock.unauthorized": "Custom message about a failure of permissions",
+        "too_many_attempts": "Custom message indicating the user has failed to login too many times."
+      },
+      signUp: {
+        "invalid_password": "Custom message indicating a password was invalid",
+        "user_exists": "Custom message indicating that a user already exists"
+      }
+    }
+  }
+};
+
+// Initiating our Auth0Lock
+var lock = new Auth0Lock(
+  '${account.clientId}',
+  '${account.namespace}',
+  options
+);
+```
+
+## Custom errors in Rules
+
+If you are returning custom error codes from a [rule](/rules) or a [custom database script](/connections/database/custom-db#error-handling), you can handle custom errors:
+
+* In your application's redirect URL by reading the `error` and `error_mesage` query string parameters.
+* By redirecting the user back to your hosted pages with a custom error message and displaying the message with a [flash message](/libraries/lock/v11/api#flashmessage).
diff --git a/ja-jp/articles/libraries/lock/v11/i18n.md b/ja-jp/articles/libraries/lock/v11/i18n.md
new file mode 100644
index 0000000000..cdd35c7c3e
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/i18n.md
@@ -0,0 +1,116 @@
+---
+section: libraries
+description: Lock v11 supports multiple languages, and allows for the addition of other custom language files, as well as for customizing the values of specific pieces of text that are displayed in the Lock widget.
+topics:
+  - libraries
+  - lock
+  - i18n
+contentType:
+  - how-to
+  - concept
+useCase:
+  - add-login
+---
+# Lock Internationalization
+
+You can change the language of Lock by using the `language` configuration option. This will pull the corresponding language file from the `i18n` directory in Lock.
+
+## Provided languages
+
+Take a look at the [i18n directory](https://github.com/auth0/lock/blob/master/src/i18n/) for language files.
+
+| Language | Code | Source |
+|----------|------|--------|
+| Afrikaans | `'af'` | [af.js](https://github.com/auth0/lock/blob/master/src/i18n/af.js) |
+| Catalan | `'ca'` | [ca.js](https://github.com/auth0/lock/blob/master/src/i18n/ca.js) |
+| Chinese | `'zh'` | [zh.js](https://github.com/auth0/lock/blob/master/src/i18n/zh.js) |
+| Chinese (Taiwan) | `'zh-tw'` | [zh-tw.js](https://github.com/auth0/lock/blob/master/src/i18n/zh-tw.js) |
+| Croatian | `'hr'` | [hr.js](https://github.com/auth0/lock/blob/master/src/i18n/hr.js) |
+| Czech | `'cs'` | [cs.js](https://github.com/auth0/lock/blob/master/src/i18n/cs.js) |
+| Danish | `'da'` | [da.js](https://github.com/auth0/lock/blob/master/src/i18n/da.js) |
+| Dutch | `'nl'` | [nl.js](https://github.com/auth0/lock/blob/master/src/i18n/nl.js) |
+| English | `'en'` | [en.js](https://github.com/auth0/lock/blob/master/src/i18n/en.js) |
+| Estonian | `'et'` | [et.js](https://github.com/auth0/lock/blob/master/src/i18n/et.js) |
+| Farsi (Persian) | `'fa'` | [fa.js](https://github.com/auth0/lock/blob/master/src/i18n/fa.js) |
+| Finnish | `'fi'` | [fi.js](https://github.com/auth0/lock/blob/master/src/i18n/fi.js) |
+| French | `'fr'` | [fr.js](https://github.com/auth0/lock/blob/master/src/i18n/fr.js) |
+| German | `'de'` | [de.js](https://github.com/auth0/lock/blob/master/src/i18n/de.js) |
+| Greek | `'el` | [el.js](https://github.com/auth0/lock/blob/master/src/i18n/el.js) |
+| Hebrew | `'he'` | [he.js](https://github.com/auth0/lock/blob/master/src/i18n/he.js) |
+| Hungarian | `'hu'` | [hu.js](https://github.com/auth0/lock/blob/master/src/i18n/hu.js) |
+| Italian | `'it'` | [it.js](https://github.com/auth0/lock/blob/master/src/i18n/it.js) |
+| Japanese | `'ja'` | [ja.js](https://github.com/auth0/lock/blob/master/src/i18n/ja.js) |
+| Korean | `'ko'` | [ko.js](https://github.com/auth0/lock/blob/master/src/i18n/ko.js) |
+| Lithuanian | `'lt'` | [lt.js](https://github.com/auth0/lock/blob/master/src/i18n/lt.js) |
+| Norwegian | `'no'` | [no.js](https://github.com/auth0/lock/blob/master/src/i18n/no.js) |
+| Norwegian (Bokmål) | `'nb'` | [nb.js](https://github.com/auth0/lock/blob/master/src/i18n/nb.js) |
+| Norwegian (Nynorsk) | `'nn'` | [nn.js](https://github.com/auth0/lock/blob/master/src/i18n/nn.js) |
+| Polish | `'pl'` | [pl.js](https://github.com/auth0/lock/blob/master/src/i18n/pl.js) |
+| Portuguese (Brazil) | `'pt-br'` | [pt-br.js](https://github.com/auth0/lock/blob/master/src/i18n/pt-br.js) |
+| Romanian | `'ro'` | [ro.js](https://github.com/auth0/lock/blob/master/src/i18n/ro.js) |
+| Russian | `'ru'` | [ru.js](https://github.com/auth0/lock/blob/master/src/i18n/ru.js) |
+| Slovak | `'sk'` | [sk.js](https://github.com/auth0/lock/blob/master/src/i18n/sk.js) |
+| Slovenian | `'sl'` | [sl.js](https://github.com/auth0/lock/blob/master/src/i18n/sl.js) |
+| Spanish | `'es'` | [es.js](https://github.com/auth0/lock/blob/master/src/i18n/es.js) |
+| Swedish | `'sv'` | [sv.js](https://github.com/auth0/lock/blob/master/src/i18n/sv.js) |
+| Turkish | `'tr'` | [tr.js](https://github.com/auth0/lock/blob/master/src/i18n/tr.js) |
+| Ukrainian | `'ua'` | [ua.js](https://github.com/auth0/lock/blob/master/src/i18n/uk.js) |
+| Vietnamese | `'vi'` | [vi.js](https://github.com/auth0/lock/blob/master/src/i18n/vi.js) |
+
+## Set language option
+
+To use the following examples, you'll need to first include Lock in your page:
+
+```html
+
+
+```
+
+Next define your `options` object and include the `language` option. The `language` option needs to be a string matching the name of the corresponding file in the `i18n` directory [within Lock](https://github.com/auth0/lock/tree/master/src/i18n). Then instantiate Lock.
+
+For example,
+
+```js
+// Select a supported language
+var options = {
+  language: 'es'
+};
+
+// Initiating our Auth0Lock
+var lock = new Auth0Lock(
+  '${account.clientId}',
+  '${account.namespace}',
+  options
+);
+```
+
+::: panel Missing translation values
+Translation data for Lock comes from language files which have key-value pairs representing various translations. For some languages, certain values may be missing, in which case you will see a warning: `language does not have property `. We encourage you to submit a [pull request](https://github.com/auth0/lock/tree/master/src/i18n) to add these missing values. Alternatively, you may define the missing values in your Lock `options` (see below).
+:::
+
+## Replace dictionary terms
+
+You can also customize your own specific dictionary items using the `languageDictionary` option. This is useful if you are using one of the supported languages, but change the specific wording of a few items. For example, you might re-word the `title` or change the way other labels display to the user while leaving the remaining text on the widget intact.
+
+```js
+// Customize some languageDictionary attributes
+var options = {
+  languageDictionary: {
+    emailInputPlaceholder: "something@youremail.com",
+    title: "Log me in"
+  },
+};
+
+// Initiating our Auth0Lock
+var lock = new Auth0Lock(
+  '${account.clientId}',
+  '${account.namespace}',
+  options
+);
+```
+
+::: note
+For an example of available `languageDictionary` property names and how to structure a `language` file, see the [English dictionary file for Lock](https://github.com/auth0/lock/blob/master/src/i18n/en.js).
+:::
+
+The `languageBaseUrl` option, which takes a string value (a URL), overrides the language source URL for Auth0's provided translations. By default, it uses the Auth0's CDN URL `https://cdn.auth0.com` because that is where the provided language translations are stored. By providing another value, you can use your own source for the language translations as needed for your applications. Your language source should be a JavaScript file.
diff --git a/ja-jp/articles/libraries/lock/v11/index.md b/ja-jp/articles/libraries/lock/v11/index.md
new file mode 100644
index 0000000000..babcef08a8
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/index.md
@@ -0,0 +1,250 @@
+---
+section: libraries
+toc: true
+title: Lock v11 for Web
+description: A widget that provides a frictionless login and signup experience for your web apps.
+img: media/articles/libraries/lock-web.png
+topics:
+  - libraries
+  - lock
+contentType:
+  - how-to
+  - index
+useCase:
+  - add-login
+---
+# Lock v11 for Web
+
+Lock is an embeddable login form that can be [configured to your needs](/libraries/lock/v11/configuration) and is recommended for use in single-page apps, preferably in conjunction with [Universal Login](/universal-login), which should be used whenever possible. Lock enables you to easily add social identity providers, so that your users can log in seamlessly using any desired provider.
+
+<%= include('../../../_includes/_embedded_login_warning') %>
+
+## Lock Installation
+
+You can install Lock v11 via several methods. Select any of the following installation sources that best suit your environment and application.
+
+### Installation Sources
+
+Install via [npm](https://npmjs.org):
+
+```sh
+npm install auth0-lock
+```
+
+Install via [bower](http://bower.io):
+
+```sh
+bower install auth0-lock
+```
+
+Include via our CDN (Replace `.x` and `.y` with the latest minor and patch release numbers from the [Lock Github repository](https://github.com/auth0/lock/releases):
+
+```html
+
+
+
+
+
+```
+
+::: panel Updating patch versions
+It is recommended that production applications use a specific patch version, or at the very least a specific minor version. Regardless of the method by which Lock is included, the recommendation is that the version should be locked down and only manually updated, to ensure that those updates do not adversely affect your implementation. Check the [GitHub repository](https://github.com/auth0/lock/releases) for a current list of releases.
+:::
+
+### Mobile
+
+If you are targeting mobile audiences, Auth0 recommends that you add the following meta tag to your application's `head`:
+
+```html
+
+```
+
+### Bundling Dependencies
+
+If you are using browserify or webpack to build your project and bundle its dependencies, after installing the `auth0-lock` module, you will need to bundle it with all its dependencies. Examples are available for [Browserify](https://github.com/auth0/lock/tree/master/examples/bundling/browserify) and [webpack](https://github.com/auth0/lock/tree/master/examples/bundling/webpack).
+
+### Cross-Origin Authentication
+
+<%= include('../../../_includes/_embedded_login_warning') %>
+
+Embedding Lock within your application requires [cross-origin authentication](/cross-origin-authentication) to be properly configured. Specifically, you need to set the **Allowed Web Origins** property to the domain making the request. You can find this field in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings).
+
+![Allowed Web Origins](/media/articles/libraries/lock/allowed-origins.png)
+
+Make sure you read about the [limitations of cross-origin authentication](/cross-origin-authentication#limitations) before implementing Lock. 
+
+## Usage
+
+### 1. Initializing Lock
+
+First, you'll need to initialize a new `Auth0Lock` object, and provide it with your Auth0 client ID (the unique client ID for each Auth0 application, which you can get from the [management dashboard](${manage_url})) and your Auth0 domain (for example, `yourname.auth0.com`).
+
+```js
+// Initializing our Auth0Lock
+var lock = new Auth0Lock(
+  '${account.clientId}',
+  '${account.namespace}'
+);
+```
+
+### 2. Authenticating and Getting User Info
+
+Next, listen using the `on` method for the `authenticated` event. When the event occurs, use the `accessToken` which was received to call the `getUserInfo` method and acquire the user's profile information (as needed).
+
+```js
+var Auth = (function() {
+
+  var wm = new WeakMap();
+  var privateStore = {};
+  var lock;
+
+  function Auth() {
+    this.lock = new Auth0Lock(
+      '',
+      ''
+    );
+    wm.set(privateStore, {
+      appName: "example"
+    });
+  }
+
+  Auth.prototype.getProfile = function() {
+    return wm.get(privateStore).profile;
+  };
+
+  Auth.prototype.authn = function() {
+    // Listening for the authenticated event
+    this.lock.on("authenticated", function(authResult) {
+      // Use the token in authResult to getUserInfo() and save it if necessary
+      this.getUserInfo(authResult.accessToken, function(error, profile) {
+        if (error) {
+          // Handle error
+          return;
+        }
+
+        //we recommend not storing Access Tokens unless absolutely necessary
+        wm.set(privateStore, {
+          accessToken: authResult.accessToken
+        });
+
+        wm.set(privateStore, {
+          profile: profile
+        });
+
+      });
+    });
+  };
+  return Auth;
+}());
+
+```
+
+You can then manipulate page content and display profile information to the user (for example, displaying their name in a welcome message).
+
+```html
+ 
      Welcome 
      
+```
+
+::: note
+Note that if you are storing the user profile, you will want to `JSON.stringify` the profile object and then, when using it later, `JSON.parse` it, because it will need to be stored in `localStorage` as a string rather than a JSON object.
+:::
+
+### 3. Showing Lock
+
+Here you're showing the Lock widget after the user clicks a login button; you can just as easily show Lock automatically when arriving at a page by just using `lock.show();` on page load.
+
+This will show the Lock widget, and paired with the above, you're now ready to handle logins!
+
+```js
+document.getElementById('btn-login').addEventListener('click', function() {
+  lock.show();
+});
+```
+
+## Passwordless
+
+::: note
+Lock's Passwordless Mode is only available in Lock v11.2.0 and later. Please use the [latest release of Lock](https://github.com/auth0/lock/releases) for this feature!
+:::
+
+You can use Lock's Passwordless Mode to allow users to authenticate using just an email or mobile number. They will receive the code and then return to input it, or click the link, and they can be authenticated without remembering a password.
+
+In Lock v11, in order to implement Passwordless Mode, you initialize Lock in a slightly different manner, with `Auth0LockPasswordless` rather than with `Auth0Lock`:
+
+```js
+var lockPasswordless = new Auth0LockPasswordless(
+ '${account.clientId}',
+ '${account.namespace}'
+);
+```
+
+### Passwordless options
+
+Additionally, Lock's Passwordless Mode has a couple of configuration options that are unique to it.
+
+In order to indicate which connection type you would like, you initialize Lock with the `allowedConnections` option with either `email` or `sms` as the value:
+
+```js
+var passwordlessOptions = {
+  allowedConnections: ['sms']
+}
+```
+
+::: note
+Remember to enable the passwordless connection of your choice in the [Dashboard](${manage_url}) under **Connections -> Passwordless**, and then to enable it for your application, that way when Lock tries to use it, it is already set up and linked to the application.
+:::
+
+If you choose to use `email`, you have one more option to select - whether you wish your users to receive a code to input, or a "magic link" to use. This is done via the `passwordlessMethod` option, which takes values of `code` or `link`.
+
+```js
+var passwordlessOptions = {
+  allowedConnections: ['email'],
+  passwordlessMethod: 'code'
+}
+```
+
+### Passwordless example
+
+```js
+var passwordlessOptions = {
+  allowedConnections: ['email'],
+  passwordlessMethod: 'code',
+  auth: {
+    redirectUrl: 'http://localhost:3000/callback',   
+    responseType: 'token id_token',
+    params: {
+      scope: 'openid email'               
+    }          
+  }
+}
+
+var lockPasswordless = new Auth0LockPasswordless(
+ '${account.clientId}',
+ '${account.namespace}',
+ passwordlessOptions
+);
+```
+
+<%= include('../../_includes/_embedded_sso') %>
+
+<%= include('../../../_includes/_co_authenticate_errors', { library : 'Lock v11'}) %>
+
+## Browser Compatibility
+
+Browser compatibility is ensured for **Chrome**, **Safari**, **Firefox** and **IE >= 10**. Auth0 currently uses [zuul](https://github.com/defunctzombie/zuul) along with [Saucelabs](https://saucelabs.com) to run integration tests on each push.
+
+## More Examples
+
+The below widget displays brief examples of implementing Auth0 in several ways: Lock as a modal "popup" widget, Lock embedded inline in a div, Lock Passwordless, a custom UI with [Auth0.js](/libraries/auth0js), and a simple link using the API.
+
+<%= include('../../../_includes/_lock-sdk') %>
+
+## Next Steps
+
+This document has shown how to use Lock 11 within a Single-Page Application (SPA). Take a look at the following resources to see how Lock can be used with other kinds of web apps, or how it can be customized for your needs:
+
+::: next-steps
+* [Lock v11 API Reference](/libraries/lock/v11/api)
+* [Lock Configuration Options](/libraries/lock/v11/configuration)
+* [Lock UI Customization](/libraries/lock/v11/ui-customization)
+:::
diff --git a/ja-jp/articles/libraries/lock/v11/migration-angular.md b/ja-jp/articles/libraries/lock/v11/migration-angular.md
new file mode 100644
index 0000000000..1eb1e5647d
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-angular.md
@@ -0,0 +1,21 @@
+---
+section: libraries
+title: Migrating Angular applications to Lock v11
+description: How to migrate Angular applications to Lock v11
+public: false
+topics:
+  - libraries
+  - lock
+  - migrations
+  - angular
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating Angular Applications to Lock v11
+
+Angular applications can use Lock directly without any kind of wrapper library.
+
+All Angular applications will be using Lock 10, so you can follow the [Migrating from Lock v10](/libraries/lock/v11/migration-v10-v11) guide.
diff --git a/ja-jp/articles/libraries/lock/v11/migration-angularjs-v10.md b/ja-jp/articles/libraries/lock/v11/migration-angularjs-v10.md
new file mode 100644
index 0000000000..621be6bea3
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-angularjs-v10.md
@@ -0,0 +1,53 @@
+---
+section: libraries
+title: Migrating Angular 1.x Applications to from Lock v10 to Lock v11
+description: How to migrate Angular 1.x Applications from Lock v10 to v11
+public: false
+toc: true
+topics:
+  - libraries
+  - lock
+  - migrations
+  - angular
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating Angular 1.x applications from Lock v10 to v11
+
+## Migration steps
+
+<%= include('../../_includes/_get_lock_latest_version') %>
+
+### Update angular-lock
+
+AngularJS (a.k.a. Angular 1.x) applications usually use the [angular-lock package](https://www.npmjs.com/package/angular-lock). To use Lock v11 you need to update to the latest version (3.x).
+
+You can update the angular-lock library using npm or yarn.
+
+```bash
+# installation with npm
+npm install --save angular-lock
+ 
+# installation with yarn
+yarn add angular-lock
+```
+
+The script files need to be added to your build system, or added to the project with a script tag.
+
+```html
+
+```
+
+<%= include('../../_includes/_configure_embedded_login', { library : 'Lock v11'}) %>
+<%= include('../../_includes/_change_get_profile') %>
+<%= include('../../_includes/_oidc_conformant') %>
+
+## Behavioral Changes in Lock v11
+
+<%= include('../../_includes/_popup_mode') %>
+<%= include('../../_includes/_last_logged_in_window') %>
+<%= include('../../_includes/_ip_ranges') %>
+<%= include('../../_includes/_default_values_lock') %>
diff --git a/ja-jp/articles/libraries/lock/v11/migration-angularjs-v8.md b/ja-jp/articles/libraries/lock/v11/migration-angularjs-v8.md
new file mode 100644
index 0000000000..8152ec0ef0
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-angularjs-v8.md
@@ -0,0 +1,22 @@
+---
+section: libraries
+title: Migrating Angular 1.x Applications to from Lock v8 to Lock v11
+description: How to migrate Angular 1.x Applications from Lock v8 to v11
+public: false
+toc: true
+topics:
+  - libraries
+  - lock
+  - migrations
+  - angular
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating Angular 1.x Applications from Lock v8 to v11
+
+Lock v8 is [very similar](/libraries/lock/v9/migration-guide) to Lock v9 from an API standpoint. 
+
+You can follow the instructions on [how to migrate Angular 1.x applications from Lock v9 to v11]((/libraries/lock/v11/migration-v9-v11), as they also are applicable for Lock 8.
diff --git a/ja-jp/articles/libraries/lock/v11/migration-angularjs-v9.md b/ja-jp/articles/libraries/lock/v11/migration-angularjs-v9.md
new file mode 100644
index 0000000000..6217541cf6
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-angularjs-v9.md
@@ -0,0 +1,207 @@
+---
+section: libraries
+title: Migrating Angular 1.x Applications to from Lock v9 to Lock v11
+description: How to migrate Angular 1.x Applications from Lock v9 to v11
+public: false
+toc: true
+topics:
+  - libraries
+  - lock
+  - migrations
+  - angular
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating Angular 1.x Applications from Lock v9 to v11
+
+This guide will help you migrating your Angular 1.x application from Lock 9 to Lock v11. 
+
+<%= include('../../_includes/_get_lock_latest_version') %>
+
+## Add the angular-lock library
+
+Most Angular 1.x apps used the [auth0-angular](https://www.npmjs.com/package/auth0-angular) which is currently deprecated. This guide will use [auth0-lock](https://www.npmjs.com/package/auth0-lock) 3.0 to simplify using Lock v11.
+
+Use npm to uninstall the old library and install the new one.
+
+```
+npm uninstall auth0-angular --save
+npm install angular-lock --save
+```
+
+Then include it in your `index.html` file:
+
+```html
+
+
+```
+
+## Update the app.js file
+
+In your `app.js` file:
+
+* Add `auth0.lock` to your Angular module
+* Inject `lockProvider` in your configuration
+* Initialize a Lock instance in `config()`
+* Inject your authentication service in `run()` and call the method that listens for authentication events (we will implement changes in the authentication service next)
+
+```js
+// app.js
+(function() {
+  'use strict';
+
+  angular
+    .module('app', ['ngRoute', 
+//   'auth0' 
+     'auth0.lock']) // Add auth0.lock
+      .config(config)
+      .run(run);
+
+  config.$inject = [
+    '$locationProvider',
+    '$routeProvider',
+ // 'authProvider',
+    'lockProvider' // Inject lockProvider
+  ];
+
+  function config(
+    $locationProvider,
+    $routeProvider,
+//  authProvider
+    lockProvider // Provide lockProvider
+  ) {
+    $routeProvider
+      .when('/', {
+        controller: 'HomeController',
+        templateUrl: 'app/home/home.html',
+        controllerAs: 'vm'
+      })
+      .otherwise({
+        redirectTo: '/'
+  });
+
+  $locationProvider.hashPrefix('');
+  $locationProvider.html5Mode(true);
+
+  // Configure Auth0 Lock instance
+  // Read more about configuration here:
+  // https://auth0.com/docs/libraries/lock/v11
+  lockProvider.init({
+     domain: '${account.namespace}'),
+     clientID: '${account.clientId}',
+     options: {
+       autoclose: true,
+       auth: {
+         responseType: 'token id_token',
+         audience: 'https://' + '${account.namespace}' + '/userinfo',
+         params: {
+           scope: 'openid profile email'
+         }
+       }
+     }
+   });
+  }
+
+  // Inject authentication service and
+  // run method to handle authentication
+  run.$inject = ['authService'];
+
+  function run(authService) {
+    authService.handleAuthentication();
+  }
+
+}());
+```
+
+## Update the authentication service
+
+If you are using an authentication service, you will need to make a few minor changes there as well. Lock v11 provides events so you can execute functionality when the user is authenticated, when there is an authentication error, and so on. You can read more at the [Lock v11 documentation](/libraries/lock/v11).
+
+```js
+// auth.service.js
+(function() {
+  'use strict';
+
+  angular.module('app').service('authService', authService);
+
+  // Inject 'lock'
+  authService.$inject = ['lock', '$location'];
+
+  function authService(lock, $location) {
+ 
+    function login() {
+      // Display the Lock widget using the
+      // instance initialized in the app.js config
+      lock.show();
+    }
+
+    function logout() {
+      // Remove tokens and expiry time from localStorage
+      localStorage.removeItem('access_token');
+      localStorage.removeItem('id_token');
+      localStorage.removeItem('expires_at');
+      $location.path('/');
+    }
+
+    function handleAuthentication() {
+      // Uncomment if you are not using HTML5Mode
+      // lock.interceptHash();
+
+      lock.on('authenticated', function(authResult) {
+        if (authResult && authResult.accessToken && authResult.idToken) {
+          console.log('Authenticated!', authResult);
+          _setSession(authResult);
+        }
+      });
+      lock.on('authorization_error', function(err) {
+        console.log(err);
+        alert(
+          'Error: ' + err.error + '. Check the console for further details.'
+        );
+      });
+    }
+
+    function _setSession(authResult) {
+      // Set the time that the Access Token will expire
+      var expiresAt = JSON.stringify(
+        authResult.expiresIn * 1000 + new Date().getTime()
+      );
+      // Save tokens and expiration to localStorage
+      localStorage.setItem('access_token', authResult.accessToken);
+      localStorage.setItem('id_token', authResult.idToken);
+      localStorage.setItem('expires_at', expiresAt);
+    }
+
+    function isAuthenticated() {
+      // Check whether the current time is
+      // past the Access Token's expiry time
+      var expiresAt = JSON.parse(localStorage.getItem('expires_at'));
+        return new Date().getTime() < expiresAt;
+    }
+
+    return {
+      login: login,
+      logout: logout,
+      handleAuthentication: handleAuthentication,
+      isAuthenticated: isAuthenticated
+    };
+  }
+})();
+```
+
+::: note
+If you are not using a service, you can implement the `handleAuthentication()` method's functionality in your app's `run()` method, and implement the `login()`, `logout()`, and `_setSession()` functionality in the controller where your login is located.
+:::
+
+<%= include('../../_includes/_configure_embedded_login', { library : 'Lock v11'}) %>
+<%= include('../../_includes/_change_get_profile') %>
+
+## Behavioral Changes in Lock v11
+
+<%= include('../../_includes/_popup_mode') %>
+<%= include('../../_includes/_last_logged_in_window') %>
+<%= include('../../_includes/_ip_ranges') %>
+<%= include('../../_includes/_default_values_lock') %>
diff --git a/ja-jp/articles/libraries/lock/v11/migration-cordova.md b/ja-jp/articles/libraries/lock/v11/migration-cordova.md
new file mode 100644
index 0000000000..ce7a0e9ef2
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-cordova.md
@@ -0,0 +1,21 @@
+---
+title: Migration from Lock 10 in Cordova Apps
+description: Learn how to migrate from Lock 10 in your Cordova app.
+public: false
+topics:
+  - libraries
+  - lock
+  - migrations
+  - cordova
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+
+# Migration from Lock in Cordova Applications
+
+For Cordova applications, the only migration path forward at this time is to [migrate to Universal Login](/guides/login/migration-embedded-universal). Embedded Lock will not be supported in Cordova apps going forward, as part of an effort to align Auth0's Cordova support with more stringent standards and security policies.
+
+Instead of updating embedded Lock versions, Cordova apps using Auth0 should instead use the [auth0-cordova](https://github.com/auth0/auth0-cordova) library to initiate Universal Login in Cordova apps. See the [Cordova Quickstart](/quickstart/native/cordova/01-login) for an example of setting this up.
diff --git a/ja-jp/articles/libraries/lock/v11/migration-guide.md b/ja-jp/articles/libraries/lock/v11/migration-guide.md
new file mode 100644
index 0000000000..a815c11a66
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-guide.md
@@ -0,0 +1,68 @@
+---
+section: libraries
+title: Migrating to Lock v11
+description: How to migrate to Lock v11
+public: false
+topics:
+  - libraries
+  - lock
+  - migrations
+contentType:
+  - how-to
+  - reference
+  - concept
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating to Lock v11
+
+[Lock v11](/libraries/lock) operates with enhanced security and removes dependencies that have been deprecated as per Auth0's roadmap. In some cases, these security enhancements may impact application behavior when upgrading from an earlier version of Lock. 
+
+## Should I migrate to v11?
+
+Everyone should migrate to v11. All previous versions are deprecated, and the Legacy Lock API was removed from service on August 6, 2018. For applications that use Lock within an Auth0 login page, this migration is recommended; for applications with Lock embedded within them, this migration is mandatory.
+
+## Migration instructions
+
+The documents below describe all the changes that you should be aware of when migrating from different versions of Lock. Make sure you go through the relevant guide(s) before upgrading.
+
+* [Migrating from the lock-passwordless widget](/libraries/lock/v11/migration-lock-passwordless)
+* [Migrating from Lock v10](/libraries/lock/v11/migration-v10-v11)
+* [Recommendations for migrating from Lock v10 when Single Sign-on (SSO) is required](/guides/login/migration-sso)
+* [Migrating from Lock v10 in Angular 1.x Applications](/libraries/lock/v11/migration-angularjs-v10)
+* [Migrating from Lock v10 in Angular 2+ Applications](/libraries/lock/v11/migration-angular)
+* [Migrating from Lock v10 in React Applications](/libraries/lock/v11/migration-react)
+* [Migrating from Lock v10 in Cordova Applications](/libraries/lock/v11/migration-cordova)
+* [Migrating from Lock v9](/libraries/lock/v11/migration-v9-v11)
+* [Migrating from Lock v9 in Angular 1.x Applications](/libraries/lock/v11/migration-angularjs-v9)
+* [Migrating from Lock v8](/libraries/lock/v11/migration-v8-v11)
+* [Migrating from Lock v8 in Angular 1.x Applications](/libraries/lock/v11/migration-angularjs-v8)
+
+If you have any questions or concerns, you can discuss them in the [Auth0 Community](https://community.auth0.com/), submit them using the [Support Center](${env.DOMAIN_URL_SUPPORT}), or directly through your account representative, if applicable. 
+
+<%= include('../../../_includes/_embedded_login_warning') %>
+
+## Troubleshooting
+
+### Lock takes too long to display the login options
+
+If Lock takes a lot of time to display the login options, it could be because the [Allowed Web Origins](/libraries/lock/v11/migration-v10-v11#configure-auth0-for-embedded-login) property is not correctly set.
+
+To verify that this is a problem check your logs at [Dashboard > Logs](${manage_url}/#/logs). If you see an entry with the following error description, set the [Allowed Web Origins](/libraries/lock/v11/migration-v10-v11#configure-auth0-for-embedded-login) property and try again.
+
+```text
+The specified redirect_uri 'https://YOUR_APP_URL' does not have a registered domain.
+```
+
+### I upgraded but I still get deprecation warnings in the logs
+
+You have already migrated to Lock 11 but you still see this error in your logs:
+
+```text
+Legacy Lock API: This feature is being deprecated. Please refer to our documentation to learn how to migrate your application.
+```
+
+These deprecation notices most likely originate from a user visiting the Universal Login [page](/universal-login) directly without initiating the authentication flow from your app. This can happen if a user bookmarks the login page directly. After August 6, 2018, these users will not be able to log in.
+
+See [Check Deprecation Errors](/troubleshoot/guides/check-deprecation-errors) for more information on deprecation-related errors.
diff --git a/ja-jp/articles/libraries/lock/v11/migration-lock-passwordless.md b/ja-jp/articles/libraries/lock/v11/migration-lock-passwordless.md
new file mode 100644
index 0000000000..3108edcae5
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-lock-passwordless.md
@@ -0,0 +1,208 @@
+---
+section: libraries
+toc: true
+description: Migration Guide from lock-passwordless to Lock v11 with Passwordless Mode
+public: false
+topics:
+  - libraries
+  - lock
+  - migrations
+  - passwordless
+contentType:
+  - how-to
+  - reference
+  - concept
+useCase:
+  - add-login
+  - migrate
+---
+# Migration Guide for lock-passwordless to Lock v11 with Passwordless Mode
+
+The following instructions assume you are migrating from the **lock-passwordless** widget to Lock v11.2+ using **Passwordless Mode**.
+
+The [lock-passwordless](https://github.com/auth0/lock-passwordless) widget was previously a standalone library, separate from [Lock](/libraries/lock). Now, you can migrate your apps to use the Passwordless Mode which is integrated directly into Lock v11. Lock v11 with Passwordless Mode is the latest method by which to deploy a login widget for passwordless authentication in your apps.
+
+To get started, you will need to remove **lock-passwordless** from your project, and instead include the [latest release version of Lock v11](https://github.com/auth0/lock/releases). 
+
+::: note
+To use Passwordless Mode, you must use Lock v11.2 or above.
+:::
+
+Beyond that, you will then need to take a careful look at each of the sections in this migration guide in order to find out which changes you will need to make to your implementation. Of particular importance will be the following:
+
+* The initialization of `Auth0LockPasswordless`
+* Your calls to Lock methods (now the same methods as used in Lock v11)
+* Your previously implemented customization options, which will need inspected and changed to use the corresponding options for Lock v11.
+
+## General changes and additions
+
+### Importing Auth0LockPasswordless
+
+You can import Auth0LockPasswordless in the same ways as you would normally import Lock; using the CDN or via NPM.
+
+#### Using the CDN
+
+If you're loading from the CDN, you can still use `Auth0LockPasswordless`. The difference is that you'll provide your options in the constructor, like we do with `Auth0Lock`:
+
+
      
+  
      
+    
+  
      
+  
      
+    
      
+    
      
+    <script src="http://cdn.auth0.com/js/lock-passwordless-2.2.3.min.js"></script>
+    <script>
+      var lock = new Auth0LockPasswordless(clientID, domain);
+    </script>
+    
      
+    
      
+    
      
+    
      
+    <script src="${lock_url}"></script>
+    <script>
+      // example use of options
+      var options = {
+        closable: false
+      }
+      var lock = new Auth0LockPasswordless(clientID, domain, options);
+    </script>
+    
      
+    
      
+  
      
+
      
+
+#### Using npm + module bundler
+
+
      
+  
      
+    
+  
      
+  
      
+    
      
+    
      
+    import Auth0LockPasswordless from 'auth0-lock-passwordless';
+    var lock = new Auth0LockPasswordless(clientID, domain);
+    
      
+    
      
+    
      
+    
      
+    import {Auth0LockPasswordless} from 'auth0-lock';
+    var options = {
+      closable: false
+    };
+    var lock = new Auth0LockPasswordless(clientID, domain, options);
+    
      
+    
      
+  
      
+
      
+
+### Initialization options
+
+`Auth0LockPasswordless` has the same [options available](/libraries/lock/v11/configuration) as `Auth0Lock` in addition to a single new option that determines if you want to use a Magic Link or a Email Code when using an email passwordless connection. For this property, `passwordlessMethod`, only two values are accepted:
+
+- `code` if you want to use an Email Code
+- `link` if you want to use a Magic Link
+
+
      
+  
      
+    
+  
      
+  
      
+    
      
+    
      
+    var options = {
+      passwordlessMethod: 'code'
+    };
+    var lock = new Auth0LockPasswordless(clientID, domain, options);
+    
      
+    
      
+    
+  
      
+
      
+
+### Choose between SMS or email
+
+We recommend that you setup which passwordless connections you want enabled in [the dashboard](${manage_url}/#/connections/passwordless), but if you want to have more than one passwordless connection enabled in the dashboard, you can restrict `Auth0LockPasswordless` to use only one of them using the [allowedConnections](/libraries/lock/v11/customization#allowedconnections-array-) option.
+If you have both `sms` and `email` passwordless connections enabled in the dashboard, `Auth0LockPasswordless` will use `email` by default.
+
+
      
+  
      
+    
+  
      
+  
      
+    
      
+    
      
+    var options = {
+      allowedConnections: ['sms']
+    };
+    var lock = new Auth0LockPasswordless(clientID, domain, options);
+    
      
+    
      
+    
      
+    
      
+    var options = {
+      allowedConnections: ['email'],
+      passwordlessMethod: 'code'
+    };
+    var lock = new Auth0LockPasswordless(clientID, domain, options);
+    
      
+    
      
+  
      
+
      
+
+### Show the widget
+
+In the old `lock-passwordless`, you could call the passwordless method directly (sms, socialOrMagiclink, socialOrSms etc). In Lock v11, you'll have to use [the show method](/libraries/lock/v11/api#show-) in order to display the widget.
+
+```js
+var lock = new Auth0LockPasswordless(clientID, domain);
+lock.show();
+```
+
+### Subscribe to events
+
+Lock exposes a few events that you can subscribe to in order to be notified when the user is authenticated or an error occurs. So, instead of callbacks from `lock-passwordless`, you have to subscribe to events that you want to know about. To read more about Lock events, see [here](/libraries/lock/v11/api#on-).
+
+```js
+var lock = new Auth0LockPasswordless(clientID, domain);
+lock.on("authenticated", function(authResult) {
+  alert(authResult.accessToken);
+});
+```
+
+### Customization options
+
+Some options have to be renamed.
+
+* `dict` is now [languageDictionary](/libraries/lock/v11/configuration#languagedictionary-object-)
+* `connections` is now [allowedConnections](/libraries/lock/v11/configuration#allowedconnections-array-)
+* `socialBigButtons` is no longer available as an option and all the social connection buttons will be shown with a "big" style.
+* all the authentication options were moved into an [auth object](/libraries/lock/v11/configuration#auth-object-)
+
+## Further Reading
+
+::: next-steps
+- [Lock 11 Reference - an overview on how Lock works](/libraries/lock/v11)
+- [Lock 11 Configuration - details on the available configuration options for Lock](/libraries/lock/v11/configuration)
+:::
diff --git a/ja-jp/articles/libraries/lock/v11/migration-react.md b/ja-jp/articles/libraries/lock/v11/migration-react.md
new file mode 100644
index 0000000000..fbac6ae04c
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-react.md
@@ -0,0 +1,23 @@
+---
+section: libraries
+title: Migrating React applications to Lock v11
+description: How to migrate React applications to Lock v11
+public: false
+topics:
+  - libraries
+  - lock
+  - migrations
+  - react
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating React Applications to Lock v11
+
+React applications use Lock directly without any kind of wrapper library.
+
+Most React applications will be using Lock v10, so you can follow the [Migrating from Lock v10](/libraries/lock/v11/migration-v10-v11) guide.
+
+If you were an early React and Auth0 adopter, and are using Lock v9, you can follow the [Migrating from Lock v9](/libraries/lock/v11/migration-v9-v11) guide.
diff --git a/ja-jp/articles/libraries/lock/v11/migration-v10-v11.md b/ja-jp/articles/libraries/lock/v11/migration-v10-v11.md
new file mode 100644
index 0000000000..16e9b75071
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-v10-v11.md
@@ -0,0 +1,41 @@
+---
+section: libraries
+title: Migrating from Lock v10 to v11
+description: How to migrate from Lock v10 to v11
+public: false
+toc: true
+topics:
+  - libraries
+  - lock
+  - migrations
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrate from Lock v10 to v11
+
+This guide includes all the information you need to update your Lock v10 application to [Lock v11](/libraries/lock).
+
+## Migration demo
+
+
       
      
+
+## Migration steps
+
+<%= include('../../_includes/_migrate_universal') %>
+<%= include('../../_includes/_get_lock_latest_version') %>
+<%= include('../../_includes/_configure_embedded_login', { library : 'Lock v11'}) %>
+<%= include('../../_includes/_change_get_profile') %>
+<%= include('../../_includes/_oidc_conformant') %>
+<%= include('../../_includes/_configure_custom_domain', { library : 'Lock v11'}) %>
+<%= include('../../_includes/_verifying_migration') %>
+
+## Behavioral changes in Lock v11
+
+<%= include('../../_includes/_popup_mode') %>
+<%= include('../../_includes/_last_logged_in_window') %>
+<%= include('../../_includes/_ip_ranges') %>
+<%= include('../../_includes/_default_values_lock') %>
+<%= include('../../_includes/_embedded_sso') %>
diff --git a/ja-jp/articles/libraries/lock/v11/migration-v8-v11.md b/ja-jp/articles/libraries/lock/v11/migration-v8-v11.md
new file mode 100644
index 0000000000..2f2e3e53c6
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-v8-v11.md
@@ -0,0 +1,22 @@
+---
+section: libraries
+title: Migrating from Lock v8 to v11
+description: How to migrate from Lock v8 to v11
+public: false
+toc: true
+topics:
+  - libraries
+  - lock
+  - migrations
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating from Lock v8 to v11
+
+Lock v8 is [very similar](/libraries/lock/v9/migration-guide) to Lock v9 from an API standpoint.
+
+You can follow the instructions on [how to migrate from Lock v9 to Lock v11](/libraries/lock/v11/migration-v9-v11), as they also are applicable for Lock v8.
+
diff --git a/ja-jp/articles/libraries/lock/v11/migration-v9-v11.md b/ja-jp/articles/libraries/lock/v11/migration-v9-v11.md
new file mode 100644
index 0000000000..cb56f72034
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/migration-v9-v11.md
@@ -0,0 +1,201 @@
+---
+section: libraries
+title: Migrating from Lock v9 to v11
+description: How to migrate from Lock v9 to v11
+public: false
+toc: true
+topics:
+  - libraries
+  - lock
+  - migrations
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - migrate
+---
+# Migrating from Lock v9 to v11
+
+This guide includes all the information you need to update your Lock v9 applications to [Lock v11](/libraries/lock).
+
+## Migration Steps
+
+Given that Lock v10 is very similar to Lock v11 you can read the [Lock v9 to Lock v10 migration guide](/libraries/lock/v10/migration-guide).
+
+Building Single-Page Applications with Lock v9 has some key differences with the way they should be built in Lock v11. Lock v11 uses OIDC conformant APIs that are more secure, and some of the coding patterns with Lock v9 need to be changed.
+
+<%= include('../../_includes/_get_lock_latest_version') %>
+
+### Using Lock in SPAs with Popup Mode
+
+In Lock v9 the code to use `popup mode` looked similar to the below example.
+
+```js
+var lock = new Auth0Lock('${account.clientId}', '${account.namespace}');
+function login()
+{
+    lock.show({
+            responseType : "token",
+            authParams: {
+                scope: 'openid email offline_access'
+            }
+        },
+        function (err, profile, id_token, access_token, state, refresh_token) {
+            if (!err) {
+                setSession(profile, id_token, access_token, refresh_token);
+                lock.getProfile(hash.id_token, function(err, userInfo) {
+                    if (!err) {
+                        /// use the userInfo
+                    }
+                });
+            }
+        }
+    })
+}
+```
+
+In Lock v11, the code would instead use the following format.
+
+```js
+var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', {
+        {
+            popup: true,
+            auth: {
+                responseType: 'token id_token',
+                audience: 'https://' + '${account.namespace}' + '/userinfo',
+                params: {
+                    scope: 'openid email profile'
+                }
+            }
+        }
+    );
+
+lock.on('authenticated', function(authResult) {
+    if (authResult && authResult.accessToken && authResult.idToken) {
+        setSession(authResult);
+
+        lock.getUserInfo(authResult.accessToken, function(err, userInfo) {
+             if (!err) {
+                // use the userInfo
+            }
+        });
+    }
+});
+function login()
+{
+    lock.show()
+}
+```
+
+Note that the parameters that were passed to `show()` in Lock v9 are used to initialize Lock in Lock v11, and that the callback specified in `show()` is replaced by an `authenticated` event handler. 
+
+### Using Lock in SPAs with Redirect Mode
+
+In Lock v9 the code to use `redirect mode` looked similar to the below example.
+
+```js
+var lock = new Auth0Lock('${account.clientId}', '${account.namespace}');
+var hash = lock.parseHash();
+
+if (hash) {
+    if (!hash.error) {
+        setSession(hash.profile, hash.id_token, hash.access_token, hash.refresh_token);
+
+        lock.getProfile(hash.id_token, function(err, userInfo) {
+            if (!err) {
+                // use the userInfo
+            }
+        });
+    } 
+}
+
+function login() {
+    lock.show({
+        callbackURL: '${account.callback}',
+        responseType : "token",
+        authParams: {
+            scope: 'openid email offline_access'
+        }
+    });
+}
+```
+
+In Lock v11, the code should instead use the following format.
+
+```js
+var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', {
+        {
+            auth: {
+                redirectUrl: '${account.callback}',
+                responseType: 'token id_token',
+                params: {
+                    scope: 'openid email profile'
+                }
+            }
+        }
+    );
+
+lock.on('authenticated', function(authResult) {
+    if (authResult && authResult.accessToken && authResult.idToken) {
+        setSession(authResult);
+        // use authResult.idTokenPayload for profile information
+    }
+});
+
+function login() {
+    lock.show()
+}
+```
+
+Note that the parameters that were passed to `show()` in Lock v9 are used to initialize Lock in Lock v11, and that instead of calling `parseHash()`, you need to write an `authenticated` event handler.
+
+### Using Lock in Web Applications
+
+When using Lock v9 for Web Applications, the code would be similar to the below example.
+
+```js
+var lock = new Auth0Lock('${account.clientId}', '${account.namespace}');
+
+function login() {
+    lock.show({
+     auth: {
+      redirectUrl: '${account.callback}',
+      responseType: 'code',
+      params: {
+        scope: 'openid profile email' 
+      }
+    }
+  }
+```
+
+In Lock v11, the code should instead use the following format.
+
+```js
+var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', {
+    {
+        auth: {
+            redirectUrl: '${account.callback}',
+            responseType: 'code',
+            params: {
+                scope: 'openid email profile'
+            }
+        }
+    }
+);
+
+function login() {
+    lock.show()
+}
+```
+
+Note that, once more, the parameters that were passed to `show()` in Lock v9 are used to initialize Lock in Lock v11.
+
+<%= include('../../_includes/_configure_embedded_login', { library : 'Lock v11'}) %>
+<%= include('../../_includes/_legacy_flows') %>
+<%= include('../../_includes/_change_get_profile') %>
+
+## Behavioral Changes in Lock v11
+
+<%= include('../../_includes/_popup_mode') %>
+<%= include('../../_includes/_default_values_lock') %>
+<%= include('../../_includes/_ip_ranges') %>
diff --git a/ja-jp/articles/libraries/lock/v11/selecting-the-connection-for-multiple-logins.md b/ja-jp/articles/libraries/lock/v11/selecting-the-connection-for-multiple-logins.md
new file mode 100644
index 0000000000..928c694dac
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/selecting-the-connection-for-multiple-logins.md
@@ -0,0 +1,139 @@
+---
+section: libraries
+description: How to select different connection types for multiple login options with Lock V11.
+topics:
+  - libraries
+  - lock
+  - connections
+contentType:
+  - how-to
+useCase:
+  - add-login
+  - customize-connections
+---
+# Selecting from Multiple Connection Options
+
+With Auth0 you can offer users multiple methods of authenticating. This is important with SaaS or multi-tenant apps, where many organization use a single app. Each organization might use different systems such as LDAP, Active Directory, G Suite, or username/password stores.
+
+In Auth0, you can associate different *connections* (methods of authentication) to specific applications, or directly to a tenant (as [domain connections](/api/management/guides/connections/promote-connection-domain-level)). When a user logs in, one of these connections will need to be selected as the one to use.
+
+![](/media/articles/hrd/sd4h-6wlwOsQA1PCQKLAmtQ.png)
+
+::: note
+Selecting the appropriate Identity Providers from multiple options is called "Home Realm Discovery".
+:::
+
+If you use at most one database connection and zero or more social connections the selection process is straightforward. The user will either:
+
+* Click on one of the social identity providers buttons (e.g. "Log in with Google")
+* Enter their email and password (meaning "I will use the database connection").
+
+But if the application or tenant have other connection types enabled (like enterprise connections or multiple databases) the selection process might be more involved. How do you indicate that a user wants to use a specific database connection if more than one is enabled? What if a user wants to use an enterprise connection to log in using Single Sign-on (SSO)?
+
+If you implement [a custom login UI](/libraries/when-to-use-lock#when-to-implement-lock-vs-a-custom-ui) you have full control over the authentication flow. You can choose the connection based on context (like the given email address) or by asking the user, then provide the `connection` parameter to one of Auth0.js' [login methods](/libraries/auth0js/v9#login).
+
+## Lock and multiple connections
+
+Lock has built in functionality for identity provider selection. For social connections, it shows logos for all those enabled in a particular app. It also provides username/email and password fields if a database connection or Active Directory connection are enabled. 
+
+## Using email domains with enterprise connections
+
+An additional feature in Lock is the use of email domains as a way of routing authentication requests. Enterprise connections in Auth0 can be mapped to `domains`. For example, when configuring an ADFS or a SAML-P identity provider:
+
+![](/media/articles/libraries/lock/enterprise-connection.png)
+
+If a connection has domains mapped to it, then the password input field gets disabled automatically when a user enters an email with a mapped domain.
+
+![Lock using HRD/SSO](/media/articles/libraries/lock/hrd-sso.png)
+
+In the example above the domain `auth0.com` has been mapped to an enterprise connection.
+
+Notice that you can associate multiple domains to a single connection.
+
+## Selecting among multiple database connections
+
+If your application has multiple database connections enabled, Lock needs to know which one to use. You can provide a [`connectionResolver` option](https://github.com/auth0/lock#other-options), which takes a function that decides the connection to use based on the user input and context. In this example an alternative database connection is used if the email domain is "auth0.com":
+
+```
+var options = {
+  connectionResolver: function (username, context, cb) {
+    var domain = username.indexOf('@') !== -1 && username.split('@')[1];
+    if (domain && domain ==='auth0.com') {
+      // If the username is test@auth0.com, the connection used will be the `auth0-users` connection.
+      cb({ type: 'database', name: 'auth0-users' });
+    } else {
+      // Use the default approach to figure it out the connection
+      cb(null);
+    }
+  }
+}
+```
+
+You can use the [`defaultDatabaseConnection` option](/libraries/lock/v11/configuration#defaultdatabaseconnection-string-) to specify the database connection that will be used by default.
+
+## Filtering available connections programmatically
+
+The [`allowedConnections` option](/libraries/lock/v11/configuration#allowedconnections-array-) in Lock lets you indicate which of the available connections should be presented as an option to the user.
+
+This lets you tailor the experience based on additional input or context (e.g. "Click here to log in as a student, or here to log in as a faculty member").
+
+
+```js
+var lock = new Auth0Lock(
+  '${account.clientId}',
+  '${account.namespace}',
+  {
+    allowedConnections: ['YOUR CONNECTION HERE'];
+  }
+);
+```
+
+::: note
+Note that you can also provide the `allowedConnections` option to the `lock.show()` method if providing it at instantiation is not ideal for your use case. Please refer to the [API documentation](/libraries/lock/v11/api#show-) for the `show` method for more information.
+:::
+
+# Sending realm information from the application
+
+Sometimes the application requesting an authentication can know, in advance, the realm intented to be used by the user. E.g. a multi-tenant application might use URLs in the form of: `https://{customer}.yoursite.com` or `https://www.yoursite.com/{customer}`. When a user arrives at your application with the vanity URL, you can pick up that `tenant` value and pass it as the `login_hint` in the `authorize` request:
+
+```
+https://{YOUR_AUTH0_DOMAIN}/authorize?client_id=[...]&login_hint={customer}
+```
+
+`login_hint` is a hint to the authorization server (Auth0) to indicate what the user might use to log in. In this case, based on the URL where the user landed, we treat the "customer" as the realm.
+
+The default hosted login page code uses it to pre-fill the email field in Lock, but we can modify the code to alter the default database connection to be used if a realm is provided instead of an actual email address:
+
+```js
+// from the default Hosted Login Page template
+var config = JSON.parse(decodeURIComponent(escape(window.atob('@@config@@'))));
+[...]
+
+var loginHint = config.extraParams.login_hint;
+var realmHint;
+
+// if the login hint is not an email address, we treat it as a realm hint
+if (loginHint && loginHint.indexOf('@') < 0) {
+  realmHint = loginHint;
+  loginHint = null;
+}
+
+// now we map the realm into an actual database
+var defaultDatabaseConnection;
+if (realmHint === 'acme') {
+  defaultDatabaseConnection = 'acme-users';
+} else if (realmHint === 'auth0') {
+  defaultDatabaseConnection = 'auth0-DB';
+}
+    
+// When configuring Lock, we provide the values obtained before
+var lock = new Auth0Lock(config.clientID, config.auth0Domain, {
+  [...] // other options
+  prefill: loginHint ? { email: loginHint, username: loginHint } : null,
+  defaultDatabaseConnection: defaultDatabaseConnection
+}
+```
+
+The above code is, of course, just a sample. You could expand this logic to filter out social connections, or to set a default connection to be used even if an email address is provided as a `login_hint`. 
+
+Mapping the "customer" as a realm is an arbitrary design decision for this example. But it is generally a good idea to isolate applications from the actual "connection" concept used within Auth0 and use the more abstract "realm" concept instead, possibly doing a realm-to-connection mapping within the hosted login page (where it's easier to make changes if necessary).
diff --git a/ja-jp/articles/libraries/lock/v11/sending-authentication-parameters.md b/ja-jp/articles/libraries/lock/v11/sending-authentication-parameters.md
new file mode 100644
index 0000000000..fa5e7055ff
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/sending-authentication-parameters.md
@@ -0,0 +1,85 @@
+---
+section: libraries
+description: Lock v11 documentation on setting authentication parameters.
+topics:
+  - libraries
+  - lock
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+---
+# Lock Authentication Parameters
+
+You can send parameters when starting a login by adding them to the options object. The example below adds a `state` parameter with a value equal to `'foo'`.
+
+```js
+var options = {
+  auth: {
+    params: {state: 'foo'},
+  }
+};
+```
+
+The following parameters are supported: `scope`, `device`, `nonce` and `state`.
+
+::: note
+This would be analogous to triggering the login with `https://${account.namespace}/authorize?state=foo&...`.
+:::
+
+## Supported parameters
+
+### scope {string}
+
+```js
+var options = {
+  auth: {
+    params: {scope: 'openid email user_metadata app_metadata picture'},
+  }
+};
+```
+
+There are different values supported for scope. Keep in mind that JWTs are sent on every API request, so it is desirable to keep them as small as possible.
+
+The default `scope` value in Lock v11 is `openid profile email`. This minimum scope value is required to make the **Last time you logged in with** feature work correctly.
+
+::: panel Running Lock Locally
+If you don't specify at least the above scope when initializing Lock, and you are running your website from `http://localhost` or `http://127.0.0.1`, you will get the following error in the browser console:
+
+`Consent required. When using getSSOData, the user has to be authenticated with the following scope: openid profile email`
+
+That will not happen when you run your application in production or if you specify the `openid profile email` scope. You can read more about this in the [User consent and third-party applications](/api-auth/user-consent#skipping-consent-for-first-party-applications) document.
+:::
+
+For more information about scopes, see the [scopes documentation page](/scopes).
+
+#### Example: retrieve a token
+
+In Lock v11, if you wish to receive a token with the ability to fetch the user's profile data, you should add the `scope` parameter.
+
+```js
+var options = {
+  auth: {
+    params: {
+        scope: 'openid profile'
+    }
+  }
+};
+```
+
+::: note
+There is also a `connectionScopes` configuration option for Lock v11, which allows you to specify scopes on any specific connection. This will be useful if you want to initially start with a set of scopes (defined on the dashboard), but later on request additional permissions or attributes from a specific connection. Read more about it on the [Lock Configuration Options](/libraries/lock/v11/configuration#connectionscopes-object-) page.
+:::
+
+### state {string}
+
+The `state` parameter is an arbitrary state value that will be maintained across redirects. It is useful to mitigate [XSRF attacks](http://en.wikipedia.org/wiki/Cross-site_request_forgery) and for any contextual information, [such as a return url](/protocols/oauth2/redirect-users) that you might need after the authentication process is finished. If a custom state parameter is not provided, Lock will automatically generate one. For more information, see [State Parameter](/protocols/oauth-state).
+
+### nonce {string}
+
+The `nonce` parameter is used to help prevent replay attacks, and will be automatically generated by Lock if a custom value is not provided.
+
+### device {string}
+
+The `device` parameter sets the name of the device or browser requesting authentication.
diff --git a/ja-jp/articles/libraries/lock/v11/ui-customization.md b/ja-jp/articles/libraries/lock/v11/ui-customization.md
new file mode 100644
index 0000000000..6bbb747ae9
--- /dev/null
+++ b/ja-jp/articles/libraries/lock/v11/ui-customization.md
@@ -0,0 +1,129 @@
+---
+section: libraries
+description: Customizing the appearance of your Lock widget can be important for branding and a cohesive UI, and this resource highlights the ways in which you can do so while implementing Lock in your project.
+topics:
+  - libraries
+  - lock
+  - lock-ui
+contentType:
+  - how-to
+  - reference
+useCase:
+  - add-login
+---
+# Lock UI Customization
+
+You can customize the appearance of your Lock widget in a few different ways. The best and safest way to do so is with the provided JavaScript options.
+
+## JavaScript Options
+
+You can set up a variety of customizations to your Lock via the `options` parameter when you instantiate your Lock. Some of them allow you to customize your UI. The UI customization options are a work in progress - we expect to be adding more as we go.
+
+First, you'll define the `options` object, containing whichever options you're wanting to customize. Then you'll need to include that options object as the third parameter when you instantiate Lock; more on that below.
+
+### Theming Options
+
+There are a couple of theming options currently available, namespaced under the `theme` property.
+
+#### logo {String}
+
+![Lock - Theme - Logo](/media/articles/libraries/lock/v11/customization/lock-theme-logo.png)
+
+The value for `logo` is a URL for an image that will be placed in the Lock's header, and defaults to Auth0's logo. It has a recommended max height of `58px` for a better user experience.
+
+```js
+var options = {
+  theme: {
+    logo: 'https://example.com/logo.png'
+  }
+};
+```
+
+#### primaryColor {String}
+
+![Lock - Theme - Primary Color](/media/articles/libraries/lock/v11/customization/lock-theme-primarycolor.png)
+
+The `primaryColor` property defines the primary color of the Lock; all colors used in the widget will be calculated from it. This option is useful when providing a custom `logo`, to ensure all colors go well together with the `logo`'s color palette. Defaults to `#ea5323`.
+
+```js
+var options = {
+  theme: {
+    logo: 'https://example.com/logo.png',
+    primaryColor: '#31324F'
+  }
+};
+```
+
+#### authButtons {Object}
+
+Allows the customization of buttons in Lock. Each custom connection whose button you desire to customize should be listed by name, each with their own set of parameters. The customizable parameters are listed below:
+
+- **displayName** {String}: The name to show instead of the connection name when building the button title, such as `LOGIN WITH MYCONNECTION` for login).
+- **primaryColor** {String}: The button's background color. Defaults to `#eb5424`.
+- **foregroundColor** {String}: The button's text color. Defaults to `#FFFFFF`.
+- **icon** {String}: The URL of the icon for this connection. For example: `http://site.com/logo.png`.
+
+```js
+var options = {
+  theme: {
+    authButtons: {
+      "testConnection": {
+        displayName: "Test Conn",
+        primaryColor: "#b7b7b7",
+        foregroundColor: "#000000",
+        icon: "http://example.com/icon.png"
+      },
+      "testConnection2": {
+        primaryColor: "#000000",
+        foregroundColor: "#ffffff",
+      }
+    }
+  }
+};
+```
+
+### Customizing Text
+
+The `languageDictionary` option allows customization of every piece of text displayed in the Lock. Defaults to {}. See below for an example.
+
+```js
+var options = {
+  languageDictionary: {
+    emailInputPlaceholder: "something@youremail.com",
+    title: "Log me in"
+  },
+};
+```
+
+![Lock - Language Dictionary](/media/articles/libraries/lock/v11/customization/lock-languagedictionary.png)
+
+::: note
+For a complete list of the items able to be customized using `languageDictionary`, see the [English Language Dictionary Specification](https://github.com/auth0/lock/blob/master/src/i18n/en.js) in the repository.
+:::
+
+### Instantiating Lock
+
+Finally, you'll want to go ahead and instantiate your Lock, with the `options` object that you've defined with your custom options in it.
+
+```js
+// Initiating our Auth0Lock
+var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', options);
+```
+
+## Overriding CSS
+
+Customizing your Lock by overriding its CSS isn't recommended. The issue is that with new releases of Lock, some styling may change, leading to unintended problems if you are overriding the CSS. Additionally, it's possible to simply overlook use of styles in other places and while the change may look fine in one view, it might not in another.
+
+If you still intend to override CSS to further style your Lock, we recommend that you use a specific patch version of Lock rather than a major or minor version, so that you limit the amount of unexpected results that may occur when you alter the styles, and then another patch is deployed that might cause unexpected behavior in your UI due to the changes. This can be done by ensuring that you specify that patch version (`x.y.z`) when including Lock, or downloading it.
+
+Additionally, we of course recommend that you test your CSS changes exhaustively, to ensure that the experience is the one you intend it to be for your customers.
+
+::: panel-warning Regarding Lock CSS Themes
+At this time, Auth0 doesn't offer any alternative pre-made CSS themes for Lock v11, and the ones that existed for earlier versions of Lock will not work with Lock v11.
+:::
+
+## Further Information
+
+If you're looking for more detailed information while working to customize Lock for your application, check out the [configuration options](/libraries/lock/v11/configuration) page or the [Lock API](/libraries/lock/v11/api) page!
+
+If you have specific theming options that you would like to see added, let us know. We are working on improving the customization options that are available through JavaScript, and this list will be updated as new options are added.
diff --git a/ja-jp/articles/libraries/secure-local-development.md b/ja-jp/articles/libraries/secure-local-development.md
new file mode 100644
index 0000000000..577adafce8
--- /dev/null
+++ b/ja-jp/articles/libraries/secure-local-development.md
@@ -0,0 +1,143 @@
+---
+section: libraries
+description: Securing local development servers to work with samesite cookies
+topics:
+  - libraries
+  - samesite
+contentType:
+  - guide
+---
+
+# Secure Local Development
+Local development environments typically run on non-secure channels (ie: `http://localhost`) out of the box.  This guide will discuss when you should run a secure local server and how to setup `https` on localhost.
+
+## When to use a secure local server
+Testing over non-secure channels `http` is generally safe for local servers that don't communicate with external services, like Auth0.  However, when your local server is communicating with external services, we recommend running your local server on `https` for the following reasons:
+
+- Communication between an external service and your localhost should be encrypted to protect any sensitive information.
+- It tests a very critical part of the development stack if you run your server on secure channels in production.
+- Cookies using a Secure attribute or SameSite attribute set to `None` will not be sent across insecure channels, disrupting authentication and other functionality.
+
+## How to set up a secure local server
+When you visit a secure web page (served over https), your browser will verify the SSL certificate supplied by the server with a Certificate Authority. When loading a secure web page from a local server, you can create an authority just for your machine and generate certificates that only your browser will trust.
+
+The process to do this is:
+
+1. Create and install a local Certificate Authority
+2. Generate an SSL certificate for the domain being used (ie. localhost) using this new Authority.
+3. Serve the SSL certificate from your web application
+
+### 1. Install Mkcert Utility
+To get started, download [mkcert](https://github.com/FiloSottile/mkcert) and follow the [installation instructions](https://github.com/FiloSottile/mkcert#installation) for your specific operating system.
+
+### 2. Install local Certificate Authority
+The Certificate Authority is a trusted entity that the web browser uses to verify the certificate supplied by a webserver.  Installing a local Certificate Authority will allow you to generate your own SSL Certificates to be used locally.
+
+```powershell
+> mkcert -install
+# Using the local CA at "/Users/$HOME/Library/Application Support/mkcert" ✨
+# The local CA is now installed in the system trust store! 👍
+# The local CA is now installed in the Firefox trust store (requires browser restart)! 🦊
+```
+
+### 3. Generate an SSL Certificate
+The next step is to generate the SSL certificate. This example will assume you are running your local server on `https://localhost:{port}`.
+
+```powershell
+> mkcert localhost
+# Using the local CA at "/Users/$HOME/Library/Application Support/mkcert" ✨
+
+# Created a new certificate valid for the following names 📜
+#  - "localhost"
+
+# The certificate is at "./localhost.pem" and the key at "./localhost-key.pem" ✅
+```
+
+:::note
+The utility saves the certificate `localhost.pem` and a key file `localhost-key.pem` in the folder where the command was executed.
+:::
+
+### 4. Serve the SSL certificate
+Now that you have generated an SSL certificate and key, you need to load them when starting your server. The way certificates are loaded depends on the technology used to serve the application. Please see below for examples.
+
+#### Node.js with Express
+
+```js
+// app.js
+
+const express = require('express');
+const https = require('https');
+const fs = require('fs');
+
+const key = fs.readFileSync('./localhost-key.pem');
+const cert = fs.readFileSync('./localhost.pem');
+
+https.createServer({key, cert}, express()).listen('3000', () => {
+  console.log('Listening on https://localhost:3000');
+});
+```
+
+#### webpack DevServer
+
+```js
+// webpack.config.js
+
+module.exports = {
+  //...
+  devServer: {
+    https: {
+      key: fs.readFileSync('./localhost-key.pem'),
+      cert: fs.readFileSync('./localhost.pem'),
+    }
+  }
+};
+```
+
+#### Apache (including PHP, Python, Ruby)
+
+The actual path of the files mentioned below will differ depending on the OS and install method. The paths below are from Homebrew-installed Apache on macOS.
+
+```
+# /usr/local/etc/httpd/httpd.conf
+# Find and uncomment the lines below
+
+LoadModule socache_shmcb_module lib/httpd/modules/mod_socache_shmcb.so
+# ...
+LoadModule ssl_module lib/httpd/modules/mod_ssl.so
+# ...
+Include /usr/local/etc/httpd/extra/httpd-ssl.conf
+```
+
+```
+# /usr/local/etc/httpd/extra/httpd-ssl.conf
+
+# Listen 8443
+Listen 443
+# ...
+
+# Change the line below and comment out the two lines referenced below
+# 
+
+# ...
+# DocumentRoot "/usr/local/var/www"
+# ServerName www.example.com:8443
+```
+
+```
+# /usr/local/etc/httpd/extra/httpd-vhosts.conf
+
+
+    # Make sure this path points to your local application.
+    DocumentRoot "/path/to/application/root"
+    ServerName localhost
+    SSLEngine on
+    SSLCertificateFile "/usr/local/etc/httpd/localhost.pem"
+    SSLCertificateKeyFile "/usr/local/etc/httpd/localhost-key.pem"
+
+```
+
+#### Nginx (for PHP)
+
+#### WordPress
+
+The WordPress documentation has some [specific considerations for running WordPress over HTTPS](https://make.wordpress.org/support/user-manual/web-publishing/https-for-wordpress/). Please see the Apache or nginx sections above for specifics on loading the certificates.
diff --git a/ja-jp/articles/libraries/when-to-use-lock.md b/ja-jp/articles/libraries/when-to-use-lock.md
new file mode 100644
index 0000000000..fba0c02d30
--- /dev/null
+++ b/ja-jp/articles/libraries/when-to-use-lock.md
@@ -0,0 +1,167 @@
+---
+section: libraries
+description: When customizing the Classic Universal Login page what tools should you use? Lock (Auth0's drop-in authentication widget) or a custom UI built on top of an Auth0 SDK? This guide will help you decide.
+topics:
+  - libraries
+  - lock
+  - custom-ui
+contentType:
+  - concept
+useCase:
+  - add-login
+  - enable-mobile-auth
+---
+# Universal Login Page Customization
+
+When adding Auth0 to your web apps, the best solution is to use Auth0's Universal Login. If you plan to use the [New Experience](/universal-login/new), you won't even need to choose an Auth0 library to use inside of the login page, and can stop here. If you are using the [Classic Experience](/universal-login/classic), this guide will help you choose a technology to power your login page.
+
+Universal Login is less complex than embedding the authentication process within your app. It also prevents the dangers of cross-origin authentication.
+
+The Classic login page uses the Lock Widget by default for user authentication. It also has templates for Lock in Passwordless Mode and for a custom UI built with the Auth0.js SDK. 
+
+* [Lock for Web](/libraries/lock), Auth0's drop-in login and signup widget
+* The [Auth0 SDK for Web](/libraries/auth0js) with your custom designed interface
+* Or, a custom user interface that you have created which directly ties into the [Authentication API](/auth-api).
+
+::: note
+Passwordless authentication from native mobile apps currently must use Universal Login - there is no native passwordless option at this time.
+:::
+
+## When to Implement Lock vs. a Custom UI
+
+**Lock** is a drop-in authentication widget that provides a standard set of behaviors and a customizable user interface.  
+
+**Auth0 SDKs** are client-side libraries that **do not** come with a user interface but allow for expanded customization of the behavior and appearance of the login page.
+
+The **Authentication API** provides integration without requiring the use of Auth0 SDKs. The best option to choose will depend on the needs of your app.
+
+Below is a quick overview of reasons you might want to use Lock, versus using an Auth0 SDK or the authentication API. There are details about each option (Lock, Auth0 SDKs, Authentication API) below the table, to assist you in finding the right way to implement Auth0 in your application!
+
+
+    
+        
+            
+            
+            
+        
+    
+    
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+        
+            
+            
+            
+        
+    
+
      Desired UI Attributes:LockCustom UI
      Has a simple design that fits in with most modern websites with just a few tweaks to its options.YesNo
      Adapts to your configuration and only show the allowable options in the appropriate situationsYesNo
      Chooses the correct connection automaticallyYesNo
      Remembers the last used connection for a given userYesNo
      Automatically accommodates internationalizationYesNo
      Automatically provides password policy checking at signupYesNo
      Provide secure authentication via Auth0YesYes
      Potential to provide auth without having to create custom code to deal directly with Auth0's APIYesYes
      Follows strict appearance requirements as set by your companyNoYes
      Allows you to retain your existing UI for authenticationNoYes
      Allows for expert usage of HTML, CSS, and JavaScript for customizationNoYes
      Handles multiple databases or Active Directory connectionsNoYes
      
+
+## Lock
+
+**Lock** is a login form that makes it easy for your users to authenticate using a selected connection. **Lock** will automatically handle most of the details involved in creating and authenticating users. [Lock](/libraries/lock) is provided as a drop-in solution for the Classic Universal Login experience.
+
+![](/media/articles/libraries/lock/lock-default.png)
+
+With **Lock**, you will be implementing a UI that:
+
+* Is robust and provides an excellent user experience on any device with any resolution
+* Has a simple design that fits in with most websites with just a few tweaks to its custom color
+* Adapts to your configuration, displaying the appropriate form controls for each available connection and only those which are allowed (such as sign up or password reset)
+* Selects the correct connection automatically. You may specify a desired default behavior for ambiguous cases
+* Remembers the last used connection for a given user
+* Automatically accommodates internationalization
+* Provides instant password policy checking at sign up
+
+Although you cannot alter Lock's behavior significantly, you can configure several [basic options](/libraries/lock/customization) to make Lock look and behave differently.
+
+![](/media/articles/libraries/lock/lock-phantom.png)
+
+### When to use Lock
+
+Consider using **Lock** if:
+
+* You like the structure, look, and feel of **Lock**
+* You prefer a quicker and easier implementation of Auth0 and a ready-made responsive UI
+* Your process includes many of the use cases that **Lock** handles out of the box:
+  * Enterprise logins
+  * Databases with password policies
+  * User signup and password reset
+  * Authentication using social providers
+  * Avatars
+
+## Custom User Interface
+
+If the requirements of your app cannot be met by the standardized behavior of **Lock**, or if you have a complex custom authentication process, a custom user interface is needed. You also might prefer this option if you already have a user interface which you would prefer to keep.
+
+With Auth0's library for [Web](/libraries/auth0js), you can customize the behavior and flow of the process used to trigger signup and authentication. You can also directly use the [Authentication API](/auth-api), without any wrapper at all, if you so choose.
+
+![](/media/articles/libraries/lock-vs-customui/customui.png)
+
+Unlike with **Lock**, neither of these options includes a user interface. You will have complete control over the user experience for signup and authentication flow, and for the UI aspects of layout, look and feel, branding, internationalization, RTL support, and more.
+
+### When to use a custom user interface
+
+Consider implementing a custom user interface in conjunction with an Auth0 library or the Authentication API for your app if:
+
+* You have strict requirements for the appearance of the user interface
+* You have strict requirements for file sizes - the Auth0 libraries are significantly smaller than Lock, and if you instead choose to deal with the API directly, that would not require any additional weight.
+* You are comfortable with HTML, CSS, and JavaScript - you'll be creating your own UI
+* You only need to handle username/password and social provider authentication
+* You have multiple database or Active Directory Connections
+
+## See Also
+
+You can also see specific examples of the usage of both Lock and Auth0 SDKs for a wide variety of programming languages and platforms in our [Quickstarts](/quickstart). These guides may further assist you in your decision about which to use for your specific app needs.
diff --git a/ja-jp/articles/login/embedded/index.md b/ja-jp/articles/login/embedded/index.md
new file mode 100644
index 0000000000..a2f469081e
--- /dev/null
+++ b/ja-jp/articles/login/embedded/index.md
@@ -0,0 +1,15 @@
+---
+description: A brief overview of Embedded Login with Auth0
+topics:
+  - login
+  - embedded-login
+  - hosted-pages
+contentType: index
+useCase: customize-hosted-pages
+---
+
+# Embedded Login
+
+Embedded Login is the scenario in which users login directly in your application, and credentials are transmitted to the Auth0 server. There are security concerns with this approach, particularly if you do not use the [Custom Domains](/custom-domains) feature at Auth0, as this potentially opens your application up to [cross-origin authentication](/cross-origin-authentication) issues.
+
+If you need to implement embedded login, you need to have a custom domain set up, so that this can be mitigated. You can then use one of our libraries (Such as the [Lock Widget](/libraries/lock) or [auth0.js SDK](/libraries/auth0js)) to implement login in your application, or do it via our [API](/api/authentication).
diff --git a/ja-jp/articles/login/index.md b/ja-jp/articles/login/index.md
new file mode 100644
index 0000000000..ec29764282
--- /dev/null
+++ b/ja-jp/articles/login/index.md
@@ -0,0 +1,74 @@
+---
+description: Overview of Universal Login with Auth0
+topics:
+  - login
+  - universal-login
+  - password-reset
+  - mfa
+  - error-pages
+  - hosted-pages
+contentType: index
+toc: true
+useCase: customize-hosted-pages
+---
+# Login with Auth0
+
+Auth0 provides two ways to implement authentication for your applications: 
+
+* Universal Login: users log in to your application through a page hosted by Auth0.
+* Embedded Login: users log in to your application through a page you host.
+
+For the vast majority use cases, we recommend Universal Login. It's safe and easy to implement. Check out [our comparison guide](/guides/login/universal-vs-embedded) for more on the differences between Universal Login and Embedded Login within your application.
+
+## Universal Login
+
+Universal Login is Auth0's implementation of the login flow, which is the key feature of an Authorization Server. With Universal Login, users are redirected from your application to a login page hosted by Auth0. Auth0 then authenticates the user and returns them to your application. Since login and authentication take place on the same domain, credentials are not sent across origins, increasing security and protecting against attacks such as phishing and man-in-the-middle.
+
+Universal Login functionality and features are driven from web pages served by Auth0, so you can adjust the login experience in real-time without changing your application code. Universal Login page appearance and behavior is customizable right from the [Dashboard](${manage_url}).
+
+### Classic or New?
+
+There are two versions of Universal Login:
+
+* Classic Universal Login: Auth0-hosted pages built with [Lock.js](/libraries/lock) and other Javascript widgets, or with a library like [Auth0.js](/libraries/auth0js). HTML and CSS can also be customized.
+* New Universal Login: Auth0-hosted pages, rendered server-side, that do not use [Lock.js](/libraries/lock) or other Javascript widgets and libraries. Can only be customized based on the configuration available. HTML, CSS, and JS cannot be customized.
+
+In the [Dashboard](${manage_url}), the dialog shown below lets you select which Experience will be used for default, non-customized pages:
+
+![Login Page](/media/articles/universal-login/experience-picker.png)
+
+To learn more about each experience and their differences, check out the following articles:
+
+* [Classic Universal Login Experience](/universal-login/classic) 
+* [New Universal Login Experience](/universal-login/new)
+* [New Universal Login Limitations](/universal-login/new-experience-limitations)
+
+### Implementing Universal Login
+
+In addition to configuring Universal Login for your tenant's applications, you will also need to complete a few other steps:
+
+1. Set up a connection(s) in the [Dashboard](${manage_url}) (Choose **Connections** in the Dashboard's sidebar, then choose a type and pick one to configure, such as a database or a social login provider). 
+1. Set up your application in the [Dashboard](${manage_url}/#/applications). 
+1. Configure your application's code to call Auth0's [`/authorize`](/api/authentication#login) endpoint in order to trigger Universal Login, and then to deal with the response. You can either do this directly or use one of our SDKs to make the process easier.
+
+For step by step instructions on setting up your application to use Universal Login, check out our [Quickstart guides](/quickstarts).
+
+### Simple Customization
+
+![Customization Settings for Login Page](/media/articles/universal-login/settings.png)
+
+In the [Dashboard](${manage_url}), you can see the settings for your login page by navigating to [Universal Login](${manage_url}/#/login_setting) and looking at the Settings tab.
+
+The settings available here are:
+
+* Logo
+* Primary Color
+* Background Color
+
+These settings, once changed, will take effect on all your Universal Login pages if you have not enabled customization of the pages' code. The settings will also work if you have enabled customization but are using the predefined templates and have not changed those options in the code.
+
+If you select the New Universal Login Experience, you can also configure the favicon URL and a custom font URL using [the Branding API](/api/management/v2#!/Branding).
+
+## Embedded Login
+
+Embedded Login refers to implementations where users log in on a page hosted by your application, and credentials are sent to Auth0. There are security concerns with this approach since login and authentication take place on the different domains. If you need to implement Embedded Login, you need to have a [custom domain](/custom-domains) set up, so that this can be mitigated. You can then use one of our libraries (Such as the [Lock Widget](/libraries/lock) or [auth0.js SDK](/libraries/auth0js)) to implement login in your application, or do it via our [API](/api/authentication).
diff --git a/ja-jp/articles/login/spa/authenticate-with-cookies.md b/ja-jp/articles/login/spa/authenticate-with-cookies.md
new file mode 100644
index 0000000000..aa00106d1a
--- /dev/null
+++ b/ja-jp/articles/login/spa/authenticate-with-cookies.md
@@ -0,0 +1,221 @@
+---
+title: Single-Page App Authentication Using Cookies
+description: Use your backend server to authenticate a single page app with cookies
+topics:
+  - login
+  - spa
+contentType: how-to
+toc: true
+useCase: spa-cookies
+---
+
+# Single-Page App Authentication Using Cookies
+
+Securing a single-page application (SPA) can be a challenge. However, if your SPA:
+
+* is served to the client using your own backend
+* has the same domain as your backend
+* makes API calls that require authentication to your backend
+
+Then you can simplify your implementation by using cookies to authenticate your SPA. In the following guide you'll find an overview of this approach as well as a sample implementation using [Node.js](https://nodejs.org/en/).
+
+## How it works
+
+The steps below show how tokens are retrieved and used. In this approach, the [Form Post Response Mode](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html) is used instead of a traditional [Authorization Code flow](/flows/concepts/auth-code). This is because Form Post Response Mode is a simpler way to implement login when it’s your own resource you are requesting access to.
+
+![SPA Cookie Authentication](/media/articles/login/spa/image1.png)
+
+1. The user accesses a protected route using the browser, or performs some action that requires an authentication step to be initiated (such as clicking on a Login button)
+2. The browser client redirects to a `/login` route on the backend, or to the protected route depending on what the user did
+3. The backend constructs a request to the authorization server’s `/authorize` endpoint and redirects the browser client there
+4. The user is prompted to authenticate themselves using whatever method the authorization server presents
+5. The authorization server POSTs the tokens to the redirect URI as a URL-encoded form post. The backend is able to retrieve those tokens by parsing the body data.
+
+At this point, the user is authenticated and the backend has the required tokens. A cookie can now be created to represent this state on the client. The client browser is then redirected to a route that serves the SPA and also receives the authentication cookie.
+
+From now on, this cookie is traded between the client and backend when API calls are made using an AJAX call. On each request, the backend verifies if the cookie is still valid and if so, allows the request to continue.
+
+![Cookie Exchange Between Client & Backend](/media/articles/login/spa/image2.png)
+
+### Dealing with invalid or missing cookies
+
+When implementing this approach you'll need to handle cases where the authentication cookie is invalid or missing. The API call to the backend from the client happens in the background, so the client has to deal with any response from the server indicating the user should reauthenticate.
+
+In the following sample application, this case is handled in a naive way by prompting the user to reauthenticate if the API call results in a 302 Redirect result. The 302 occurs because, upon unsuccessful validation of the cookie, the server tries to redirect to the authorization endpoint of the authorization server and sends this response to the client.
+
+## Example: Authenticating a SPA using cookies
+
+The example application uses Node.js and Express to demonstrate the concepts covered above.
+
+### Prerequisites
+
+To follow along, make sure you have the [latest version of Node](https://nodejs.org/en/download/) installed.
+
+Once Node is installed, [download or clone the source code](https://github.com/auth0-blog/spa-cookie-demo/) and open the project folder inside a terminal window.
+
+```bash
+// Clone the tutorial respository using SSH
+git clone git@github.com:auth0-blog/spa-cookie-demo
+// ... or if you use HTTPS:
+git clone https://github.com/auth0-blog/spa-cookie-demo.git
+// Move into the project directory
+cd spa-cookie-demo
+```
+The `master` branch represents the state of the application before any authentication is added. If you would like to refer to the final version of the application, `checkout` the `with-oidc` branch:
+```bash
+git checkout with-oidc
+```
+### Initialize the Node.js application
+Install the application dependencies by running `npm install` from your terminal window. To run the application, use `npm run dev`. This starts the Express server. Go to [http://localhost:3000](http://localhost:3000) in your browser to view the application.
+::: note
+The development server uses [`nodemon`](https://www.npmjs.com/package/nodemon), which automatically restarts whenever it detects any file changes.
+:::
+### Explore the application
+With the application open at [http://localhost:3000](http://localhost:3000), click the **Call API** button. You should see a message displayed on the screen.
+![Call API Message](/media/articles/login/spa/image3.png)
+Note that you were able to make the API call without being logged in. Let's fix that by adding authentication some middleware that requires the user to authenticate before the API call can be made.
+### Adding authentication middleware
+Inside the terminal, run the following command to install the additional libraries:
+```bash
+npm install express-session express-openid-connect
+```
+- [`express-openid-connect`](https://www.npmjs.com/package/express-openid-connect) — OpenID Connect middleware for Express. Creates authentication sessions and protects application routes
+- [`express-session`](https://www.npmjs.com/package/express-session) — session middleware for Express; required by `express-openid-connect`
+Next, open `server/index.js` and add in the middleware libraries underneath the existing `require` statements at the top of the file:
+```js
+// server/index.js
+// Other 'require' statements...
+// NEW - bring in our new middleware libraries
+const { auth } = require("express-openid-connect")
+const session = require("express-session")
+```
+The  `express-session` middleware can now be configured by adding the following code above the existing configuration for `body-parser` further down the file:
+```js
+// server/index.js
+// Existing config for morgan
+app.use(morgan("dev", {
+  stream: {
+    write: m => debug(m)
+  }
+}))
+// NEW - add this configuration for express-session
+app.use(
+  session({
+    secret: process.env.APP_SECRET || "keyboard cat",
+    resave: false,
+    saveUninitialized: true,
+    cookie: {
+      secure: process.env.NODE_ENV === "production",
+      httpOnly: true
+    }
+  })
+)
+// Existing config for body-parser
+app.use(bodyParser.urlencoded({
+  extended: false
+}))
+```
+Finally, add in the configuration for the `express-openid-connect` middleware. The location of this is important; it should be inserted _after_ the configuration for the static file server, but _before_ the definition of the API routes. This ensures the static files can be served without requiring authentication, but the API routes are secured:
+```js
+// server/index.js
+// Existing config for the static file server
+app.use(express.static(join(__dirname, "..", "public")))
+// NEW - Configure the OpenID Connect middleware
+app.use(
+  auth({
+    required: req => req.originalUrl !== "/"
+  })
+)
+// Existing config for the API routes
+app.use("/api", require("./api"))
+```
+Note that in this case, the authentication step is only applied if the request is for something other than the homepage. This lets us show some kind of UI even if the user is not logged in. We can display a "log in" button if they have not yet authenticated, or some other UI if they have.
+After these changes, your server script should more-or-less look like this:
+```js
+require("dotenv").config()
+const express = require("express")
+const helmet = require("helmet")
+const morgan = require("morgan")
+const debug = require("debug")("app:server")
+const session = require("express-session")
+const bodyParser = require("body-parser")
+const {
+  auth
+} = require("express-openid-connect")
+const {
+  join
+} = require("path")
+const app = express()
+app.use(helmet())
+app.use(morgan("dev", {
+  stream: {
+    write: m => debug(m)
+  }
+}))
+// Set up express-session (required by express-openid-connect)
+app.use(
+  session({
+    secret: process.env.APP_SECRET || "keyboard cat",
+    resave: false,
+    saveUninitialized: true,
+    cookie: {
+      secure: process.env.NODE_ENV === "production",
+      httpOnly: true
+    }
+  })
+)
+app.use(bodyParser.urlencoded({
+  extended: false
+}))
+app.use(express.static(join(__dirname, "..", "public")))
+// Set up authentication middleware, only strictly required if
+// the request isn't for the home page
+app.use(
+  auth({
+    required: req => req.originalUrl !== "/"
+  })
+)
+app.use("/api", require("./api"))
+app.get("/*", (req, res) => {
+  res.sendFile(join(__dirname, "..", "public", "index.html"))
+})
+const port = process.env.PORT || 3000
+app.listen(port, () => debug("Application listening on port " + port))
+```
+### Setting up the environment
+In order for the application to work with authentication, `express-openid-connect` requires some environment variables to be present. For this application, these variables can be specified in a `.env` file.
+Create a `.env` file in the root of the project directory and populate it with the following:
+```bash
+ISSUER_BASE_URL=
+CLIENT_ID=
+BASE_URL=http://localhost:3000
+```
+### Setting up an Auth0 app
+If you don't already have an Auth0 account, you can [sign up for a free Auth0 account here](https://auth0.com/signup).
+Next, set up an Auth0 Client and API so Auth0 can interface with your app and API.
+![Create App Dashboard](/media/articles/login/spa/image4.png)
+1. Go to your [Auth0 Dashboard](${manage_url}) and click the [Create Application](https://manage.auth0.com/#/applications/create) button.
+2. Name your new app, select **Regular Web Applications** and click the **Create** button.
+3. In the **Settings** for your new Auth0 app, add `http://localhost:3000/callback` to the **Allowed Callback URLs**.
+4. Add `http://localhost:3000` to the **Allowed Logout URLs**.
+5. Click the **Save Changes** button.
+6. If you'd like, you can [set up some social connections](${manage_url}/#/connections/social). You can then enable them for your app in the **Application** options under the **Connections** tab. The example shown in the screenshot above utilizes username/password database, Facebook, Google, and Twitter.
+On the **Settings** screen, note the domain and client ID settings at the top.
+![Application Settings](/media/articles/login/spa/image5.png)
+These are the two values that need to be configured as part of the application. Reopen the `.env` file and set these values:
+```
+ISSUER_BASE_URL=${account.namespace}
+CLIENT_ID=${account.clientId}
+BASE_URL=http://localhost:3000
+```
+### Running the application
+With the server and environment configuration done, find your browser window that has the application open. If you've closed the browser and stopped the server, run the following from the terminal to restart the application
+```bash
+npm run dev
+```
+Then open [http://localhost:3000](http://localhost:3000) in the browser. From a user interface perspective, the application should look the same. However, this time when the **Call API** button is clicked, you should receive a warning that the user is not logged in. Also note that you do not see the "Hello, World" message as before, since the call to the API has been rejected.
+![User Is Not Logged In](/media/articles/login/spa/image6.png)
+Click the "Log in now" to login. Once you have been authenticated, you'll return to the application and see an updated UI that reflects your newly-logged in state. You should be able to press the **Call API** button once more to invoke an API call to the server, and it now works!
+![User Is Logged In](/media/articles/login/spa/image7.png)
+You can click the "Profile" link at the top of the page to show user information retrieved from the ID token.
+![User Profile](/media/articles/login/spa/image8.png)
\ No newline at end of file
diff --git a/ja-jp/articles/logout/_includes/_logout-endpoint.md b/ja-jp/articles/logout/_includes/_logout-endpoint.md
new file mode 100644
index 0000000000..e1ee68dda9
--- /dev/null
+++ b/ja-jp/articles/logout/_includes/_logout-endpoint.md
@@ -0,0 +1,4 @@
+The [logout endpoint](/api/authentication?javascript#logout) in Auth0 works in one of two ways:
+
+- Clears the Single Sign-on (SSO) cookie in Auth0.
+- Clears the SSO cookie in Auth0 and sign out the user from the IdP (such as ADFS or Google).
diff --git a/ja-jp/articles/logout/guides/logout-applications.md b/ja-jp/articles/logout/guides/logout-applications.md
new file mode 100644
index 0000000000..2368fd165f
--- /dev/null
+++ b/ja-jp/articles/logout/guides/logout-applications.md
@@ -0,0 +1,27 @@
+---
+title: Log Users Out of Applications
+description: Learn how to force a user to log out of applications using the Auth0 logout endpoint. 
+topics:
+  - logout
+contentType: 
+  - how-to
+useCase:
+  - manage-logout
+---
+
+# Log Users Out of Applications
+
+Enterprise users typically have Single Sign-on (SSO) enabled for multiple applications (e.g., SharePoint, a few .NET applications, a few Java applications, Zendesk). In this case, when users sign out, often they must be signed out for all of their applications.
+
+<%= include('../_includes/_logout-endpoint') %>
+
+Redirecting users to the logout endpoint **does not** cover the scenario where users need to be signed out of all of the applications they used. If you need to provide this functionality you will have to handle this in one of two ways:
+*  Have short timeouts on your local session and redirect to Auth0 at short intervals to re-authenticate. NOTE: this can be done by calling `checkSession` from the client which does this redirect in a hidden iFrame.  If you take the hidden iFrame approach you need to be aware of rate limits and third-party cookie issues.
+* Handle this entirely at the application level by providing your applications a way to notify all other applications when a logout occurs.
+
+## Keep reading
+
+* [Log Users Out of Auth0](/logout/guides/logout-auth0)
+* [Log Users Out of Identity Providers](/logout/guides/logout-idps)
+* [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps)
+* [Log Users Out of Auth0 as the SAML Identity Provider](/protocols/saml/saml-configuration/logout)
diff --git a/ja-jp/articles/logout/guides/logout-auth0.md b/ja-jp/articles/logout/guides/logout-auth0.md
new file mode 100644
index 0000000000..638f134afd
--- /dev/null
+++ b/ja-jp/articles/logout/guides/logout-auth0.md
@@ -0,0 +1,30 @@
+---
+title: Log Users Out of Auth0
+description: Learn how to force a user to log out of Auth0 using the Auth0 logout endpoint. 
+topics:
+  - logout
+contentType: how-to
+useCase:
+  - manage-logout
+---
+
+# Log Users Out of Auth0
+
+The [logout endpoint](/api/authentication?javascript#logout) in Auth0 works in one of two ways:
+
+1. **Clears the Single Sign-on (SSO) cookie in Auth0.** To force a logout, redirect the user to the following URL:
+
+```text
+https://${account.namespace}/v2/logout
+```
+
+2. **Clears the SSO cookie in Auth0 and sign out the user from the IdP (such as ADFS or Google).** To [log the user out of both Auth0 *and* the IdP](/logout/guides/logout-idps), you must include the `federated` querystring parameter with your call to the logout endpoint.
+
+Redirecting the user to this URL clears all Single Sign-on (SSO) cookies set by Auth0 for the user.
+
+## Keep reading
+
+* [Log Users Out of Applications](logout/guides/logout-applications)
+* [Log Users Out of Identity Providers](/logout/guides/logout-idps)
+* [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps)
+* [Log Users Out of Auth0 as the SAML Identity Provider](/protocols/saml/saml-configuration/logout)
diff --git a/ja-jp/articles/logout/guides/logout-idps.md b/ja-jp/articles/logout/guides/logout-idps.md
new file mode 100644
index 0000000000..c62112ac76
--- /dev/null
+++ b/ja-jp/articles/logout/guides/logout-idps.md
@@ -0,0 +1,73 @@
+---
+title: Log Users Out of Identity Providers
+description: Learn how to force a user to log out of their identity provider. 
+topics:
+  - logout
+  - federated-logout
+contentType: how-to
+useCase:
+  - manage-logout
+---
+# Log Users Out of Identity Providers
+
+Although this is not common practice, you can force the user to log out of their identity provider. 
+
+For many providers, Auth0 will give you this behavior by simply having you add the `federated` query parameter to the redirect to `/v2/logout`. This will then additionally redirect the user to their identity provider and log them out there as well.  
+
+To do this, add a `federated` querystring parameter to the logout URL:
+
+```text
+https://${account.namespace}/v2/logout?federated
+```
+
+## Limitations
+
+There are a few limitations to federated logout to keep in mind:
+ 
+* No validation is performed on any URL provided as a value to the returnTo parameter, nor any querystring or hash information provided as part of the URL.
+
+* The behavior of federated logouts with social providers is inconsistent. Each provider will handle the returnTo parameter differently and for some, it will not work. Please check your social provider's settings to determine how it will behave.
+
+* If you are working with social identity providers such as Google or Facebook, you must set your Client ID and Secret for these providers in the Dashboard for the logout to function properly.
+
+* If you are an Auth0 Enterprise user, you will typically have SSO enabled for multiple applications, for example, SharePoint, a few .NET applications, a few Java applications, Zendesk, etc. In this case, it's very common that when users sign out, this needs to happen for all of their applications.  
+
+::: panel-warning Single logout
+Redirecting users to the Auth0 `logout` endpoint does not cover all scenarios where users need to be signed out of all of the applications they use. Other than when Auth0 is using SAML, Auth0 does not natively support Single Logout. Single Logout can be achieved by having each application check the active session after their tokens expire, or you can force log out by terminating your application sessions at the application level. 
+
+You can configure Single Logout URLs for SAML that can log out of all SAML sessions, although Auth0 supports front-channel SAML SLO only, Auth0 does not support back-channel SLO.
+Auth0 provides quickstart guides that show you how to implement logout functionality in your specific type of application and provides sample code. These quickstarts support native/mobile apps, single-page apps, and web apps. 
+:::
+
+## Federated logout support
+
+The following identity providers support federated logout:
+
+* Evernote
+* Facebook
+* Fitbit
+* GitHub
+* Google
+  * Apps
+  * OAuth 2.0
+* Microsoft
+  * Active Directory Federation Services
+  * Office 365
+  * Windows Azure Active Directory
+  * Windows Live
+* Salesforce/Salesforce Sandbox
+* Twitter
+* Yahoo
+* Yammer
+
+::: panel-warning Clear your application session
+The Auth0 [logout endpoint](/api/authentication?javascript#logout) logs you out from Auth0 and, optionally, from your identity provider. It does *not* log you out of your application! This is something that you must implement on your side. You need to log out the user from your application by clearing their session. 
+:::
+
+## Keep reading
+
+* [Log Users Out of Auth0](/logout/guides/logout-auth0)
+* [Log Users Out of Applications](logout/guides/logout-applications)
+* [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps)
+* [Log Users Out of Auth0 as the SAML Identity Provider](/protocols/saml/saml-configuration/logout)
+* [Sessions](/sessions)
diff --git a/ja-jp/articles/logout/guides/logout-saml-idps.md b/ja-jp/articles/logout/guides/logout-saml-idps.md
new file mode 100644
index 0000000000..a2bf39e8c8
--- /dev/null
+++ b/ja-jp/articles/logout/guides/logout-saml-idps.md
@@ -0,0 +1,44 @@
+---
+title: Log Users Out of SAML Identity Providers
+description: Learn how to log users out of an external SAML identity provider. 
+topics:
+  - logout
+  - SAML-logout
+  - identity-providers
+contentType: how-to
+useCase:
+  - manage-logout
+---
+
+# Log Users Out of SAML Identity Providers
+
+To logout users from an external SAML identity provider, you must configure a [SAML logout URL](/saml-sp-generic#1-obtain-information-from-idp) in the SAML connection settings. If you don't configure a logout URL, Auth0 will use the __SAML login URL__.
+
+Auth0 will initiate a logout by sending a SAML logout request to the external identity provider if the `federated` query string parameter is included when redirecting the user to the [logout endpoint](/api/authentication?javascript#logout).
+
+The external SAML identity provider will need to know where to send SAML logout requests (if initiating the logout) and responses. The __SingleLogout service URL__ that will consume this SAML messages is the following:
+
+```text
+https://${account.namespace}/logout
+```
+
+When viewing the logout metadata for your Auth0 Connection, you will notice two `SingleLogoutService` bindings with the above URL.
+
+* **SAML Request Binding** (also known as the **Protocol Binding**): Used for the transaction from Auth0 to the IdP. If the IdP provides a choice, select `HTTP-Redirect`.
+   
+* **SAML Response Binding**: Used for transactions from the IdP to Auth0. It indicates to Auth0 what protocol the IdP will use to respond. If the IdP provides a choice, indicate that `HTTP-POST` should be used for Authentication Assertions.
+
+::: panel Unable to Logout Using a SAML Identity Provider
+When logging in (with Auth0 as the SAML Service Provider), the SAML identity provider uniquely identifies the user's session with a `SessionIndex` attribute in the `AuthnStatement` element of the SAML assertion. The `SessionIndex` value must be used again when the user logs out.
+
+Occasionally, the `SessionIndex` value may not be present in the initial login assertion. When the user logs out, the request to the SAML identity provider will fail due to the missing value.
+
+In these cases, Auth0 may not be able to complete a logout request to the SAML identity provider even if the logout URL has been configured correctly.
+:::
+
+## Keep reading
+
+* [Log Users Out of Auth0](/logout/guides/logout-auth0)
+* [Log Users Out of Applications](logout/guides/logout-applications)
+* [Log Users Out of Identity Providers](/logout/guides/logout-idps)
+* [Log Users Out of Auth0 as the SAML Identity Provider](/protocols/saml/saml-configuration/logout)
diff --git a/ja-jp/articles/logout/guides/redirect-users-after-logout.md b/ja-jp/articles/logout/guides/redirect-users-after-logout.md
new file mode 100644
index 0000000000..1d7fc0ad91
--- /dev/null
+++ b/ja-jp/articles/logout/guides/redirect-users-after-logout.md
@@ -0,0 +1,85 @@
+---
+title: Redirect Users After Logout
+description: Learn how to redirect users after logout. 
+topics:
+  - logout
+  - redirect
+contentType: how-to
+useCase:
+  - manage-logout
+---
+
+# Redirect Users After Logout
+
+You can redirect users to a specific URL after they logout. You will need to register the redirect URL in your tenant or application settings. Auth0 only redirects to whitelisted URLs after logout. If you need different redirects for each application, you can whitelist the URLs in your application settings.
+
+1. Add a `returnTo` querystring parameter with the target URL as the value. Encode the target URL being passed in. For example, to redirect the user to `http://www.example.com` after logout, make the following request:
+
+   ```text
+   https://${account.namespace}/v2/logout?returnTo=http%3A%2F%2Fwww.example.com
+   ```
+
+2. Add the non-encoded `returnTo` URL (for these examples, it is `http://www.example.com`) as an **Allowed Logout URLs** in one of two places:
+
+   - **Tenant Settings**: For logout requests that do not include the `client_id` parameter you must add the `returnTo` URL (for example `http://www.example.com`) to the **Allowed Logout URLs** list in the [Advanced tab of your Tenant Settings](${manage_url}/#/tenant/advanced). For example:
+
+     ```text
+     https://${account.namespace}/v2/logout?returnTo=http%3A%2F%2Fwww.example.com
+     ```
+
+     To add a list of URLs that the user may be redirected to after logging out at the tenant level, go to the [Tenant Settings > Advanced](${manage_url}/#/tenant/advanced) of the Auth0 Dashboard.
+
+     ![Tenant level logout screen](/media/articles/logout/tenant-level-logout.png)
+
+   - **Auth0 Application Settings**: For logout requests that include the `client_id` parameter you must add the `returnTo` URL (for example `http://www.example.com`) to the **Allowed Logout URLs** list in the **Settings** tab of your Auth0 app that is associated with the specified `CLIENT_ID`. For example:
+
+     ```text
+     https://${account.namespace}/v2/logout?returnTo=http%3A%2F%2Fwww.example.com&client_id=CLIENT_ID
+     ```
+    
+     To redirect the user after they log out from a specific application, you must add the URL used in the `returnTo` parameter of the redirect URL to the **Allowed Logout URLs** list in the **Settings** tab of your Auth0 application that is associated with the `CLIENT_ID` parameter.
+
+    ![Application level logout screen](/media/articles/logout/client-level-logout.png)
+
+   When providing the URL list, you can:
+
+   * Specify multiple, valid, comma-separated URLs.
+   * Use `*` as a [wildcard for subdomains](/applications/reference/wildcard-subdomains) (such as `http://*.example.com`).
+
+::: warning
+If the `client_id` parameter is included and the `returnTo` URL is NOT set, the server returns the user to the first Allowed Logout URLs set in the Dashboard.
+:::
+
+::: note
+In order to avoid validation errors, make sure that you include the protocol part of the URL. For example, setting the value to `*.example.com` will result in a validation error, so you should use `http://*.example.com` instead.
+:::
+
+## Limitations
+
+* The validation of URLs provided as values to the `returnTo` parameter, the querystring, and hash information provided as part of the URL are not taken into account.
+
+* The behavior of federated logouts with social providers is inconsistent. Each provider will handle the `returnTo` parameter differently and for some it will not work. Please check your social provider's settings to ensure that they will accept the `returnTo` parameter and how it will behave.
+
+* The URLs provided in the **Allowed Logout URLs** list are case-sensitive, so the URL used for logouts must match the case of the logout URL configured on the dashboard. However, do note that the scheme and host parts are case insensitive. For example, if your URL is `http://www.Example.Com/FooHoo.html`, the `http://www.Example.Com` portion is case insensitive, while the `FooHoo.html` portion is case sensitive.
+
+::: note
+If you are working with social identity providers such as Google or Facebook, you must set your `Client ID` and `Secret` for these providers in the [Dashboard](${manage_url}) for the logout to function properly.
+:::
+
+## Additional requirements for Facebook
+
+If you are using Facebook, you will also need to encode the `returnTo` parameter. For example:
+
+```text
+https://${account.namespace}/v2/logout?federated&
+      returnTo=https%3A%2F%2F${account.namespace}%2Flogout%3FreturnTo%3Dhttp%3A%2F%2Fwww.example.com
+      &access_token=[facebook access_token]
+```
+
+## Keep reading
+
+* [Log Users Out of Auth0](/logout/guides/logout-auth0)
+* [Log Users Out of Applications](logout/guides/logout-applications)
+* [Log Users Out of Identity Providers](/logout/guides/logout-idps)
+* [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps)
+* [Log Users Out of Auth0 as the SAML Identity Provider](/protocols/saml/saml-configuration/logout)
diff --git a/ja-jp/articles/logout/index.md b/ja-jp/articles/logout/index.md
new file mode 100644
index 0000000000..55c25449b5
--- /dev/null
+++ b/ja-jp/articles/logout/index.md
@@ -0,0 +1,64 @@
+---
+description: Understand how logout works with Auth0. 
+topics:
+  - logout
+contentType: index
+useCase:
+  - manage-logout
+---
+
+# Logout
+
+You can log a user out of the Auth0 session and (optionally) from the identity provider (IdP) session. When you're implementing the logout functionality, there are typically three session layers you need to consider:
+
+1. **Application Session Layer**: The first layer is the session inside your application. Though your application uses Auth0 to authenticate users, you'll still need to track that the user has logged in to your application. In a regular web application, you achieve this by storing information inside a cookie. [Log users out of your applications](/logout/guides/logout-applications) by clearing their session. You should handle the application session in your application.
+
+2. **Auth0 Session Layer**: Auth0 also maintains a session for the user and stores their information inside a cookie. The next time a user is redirected to the Auth0 Lock screen, the user's information will be remembered. [Log users out of Auth0](/logout/guides/logout-auth0) by clearing the Single Sign-on (SSO) cookie.
+
+3. **Identity Provider Session Layer**: The last session layer is the identity provider layer (for example, Facebook or Google). When users attempt to sign in with any of these providers and they are already signed into the provider, they will not be prompted again to sign in. The users may be asked to give permission to share their information with Auth0 and, in turn, your application. It is not necessary to log the users out of this session layer, but you can force the logout. (For more information, see [Log Users Out of Identity Providers](/logout/guides/logout-idps) and [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps).)
+
+## Quickstarts for logout functionality
+
+For guidance on how to implement logout functionality in your specific type of application and sample code, refer to our [Quickstarts](/quickstarts) for the following types of applications:
+
+### Native/Mobile Apps
+
+* [Android](/quickstart/native/android/03-session-handling#log-out)
+* [Chrome Extension](/quickstart/native/chrome)
+* [Cordova](/quickstart/native/cordova)
+* [Ionic 3+](/quickstart/native/ionic3)
+* [iOS Objective-C](/quickstart/native/ios-objc/03-user-sessions#on-logout-clear-the-keychain)
+* [iOS Swift](/quickstart/native/ios-swift/03-user-sessions#on-logout-clear-the-keychain)
+
+### Single-Page Apps
+
+* [Angular 2+](/quickstart/spa/angular2)
+* [JavaScript](/quickstart/spa/vanillajs)
+* [React](/quickstart/spa/react)
+* [Vue](/quickstart/spa/vuejs)
+
+### Web Apps
+
+* [ASP.NET (OWIN)](/quickstart/webapp/aspnet-owin/01-login#add-login-and-logout-methods)
+* [ASP.NET Core](/quickstart/webapp/aspnet-core/01-login#add-login-and-logout-methods)
+* [Java](/quickstart/webapp/java)
+* [Java Spring MVC](/quickstart/webapp/java-spring-mvc)
+* [Java Spring Security](/quickstart/webapp/java-spring-security-mvc)
+* [NancyFX](/quickstart/webapp/nancyfx)
+* [Node.js](/quickstart/webapp/nodejs)
+* [PHP (Laravel)](/quickstart/webapp/laravel)
+* [PHP (Symfony)](/quickstart/webapp/symfony)
+* [Python](/quickstart/webapp/python#6-logout)
+* [Ruby on Rails](/quickstart/webapp/rails/02-session-handling#logout-action)
+
+## Redirect users after logout
+
+After users log out, you can [redirect users](/logout/guides/redirect-users-after-logout) to a specific URL. You need to register the redirect URL in your tenant or application settings. Auth0 only redirects to whitelisted URLs after logout. If you need different redirects for each application, you can whitelist the URLs in your application settings.
+
+## Keep reading
+
+* [Log Users Out of Auth0](/logout/guides/logout-auth0)
+* [Log Users Out of Applications](logout/guides/logout-applications)
+* [Log Users Out of Identity Providers](/logout/guides/logout-idps)
+* [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps)
+* [Log Users Out of Auth0 as the SAML Identity Provider](/protocols/saml/saml-configuration/logout)
diff --git a/ja-jp/articles/logs/concepts/logs-admins-devs.md b/ja-jp/articles/logs/concepts/logs-admins-devs.md
new file mode 100644
index 0000000000..802913210f
--- /dev/null
+++ b/ja-jp/articles/logs/concepts/logs-admins-devs.md
@@ -0,0 +1,37 @@
+---
+description: Examples of how logs are used if you are an administrator or a developer. 
+topics:
+  - logs
+contentType: concept
+useCase:
+  - analyze-logs
+  - integrate-analytics
+---
+# Administrator and Developer Log Usage Examples
+
+## Administrator
+
+If you are an administrator, there are many helpful metrics and bits of information you can gather from the Logs. If a customer has raised a support ticket that they are unable to sign in to your service or application, you can verify in the logs that they have indeed tried, and are attempting in the manner they say they are. They may think it's a password issue, but you may discover they never completed setting up their multi-factor authentication (MFA). Additionally, Logs can help expose some business metrics you may not have had available before. These could include:
+
+- Finding prime times of usage for different regions
+- Identifying a target audience
+- Detecting patterns in user behavior that can be optimized
+- Identifying problematic actors by IP address
+- Calculating frequency and type of Anomaly Detection triggers
+
+ The deeper the analysis, the more you can learn about your customers and your business.
+
+## Developer
+
+When debugging an issue, or setting up an integrations, logs are as good as gold. You can utilize the logs as a history of events to see where a flow may be broken, or where customers are getting confused. You can also detect nefarious behavior, or verify that Auth0 anomaly detection is being triggered during questionable behavior. We support searching the logs for specific events using our Dashboard or Management API directly, but also support exporting logs to your existing log processing systems, like Splunk or Sumo Logic, for deeper analysis over time. See [Export Auth0 logs to an external service](/extensions#export-auth0-logs-to-an-external-service) for more information. 
+
+## Keep reading
+
+* [Log Data Retention](/logs/references/log-data-retention)
+* [View Log Data in the Dashboard](/logs/guides/view-log-data-dashboard)
+* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api)
+* [View Anomaly Detection Events](/anomaly-detection/guides/use-tenant-data-for-anomaly-detection)
+* [Log Event Type Codes](/logs/references/log-event-type-codes)
+* [Log Search Query Syntax](/logs/references/query-syntax)
+* [Log Event Filters](/logs/references/log-event-filters)
+* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge)
\ No newline at end of file
diff --git a/ja-jp/articles/logs/guides/migrate-logs-v2-v3.md b/ja-jp/articles/logs/guides/migrate-logs-v2-v3.md
new file mode 100644
index 0000000000..8c803ae79c
--- /dev/null
+++ b/ja-jp/articles/logs/guides/migrate-logs-v2-v3.md
@@ -0,0 +1,79 @@
+---
+title: Migrate from Logs Search v2 to v3
+description: Learn how to migrate from Auth0 Logs Search v2 to v3.
+topics:
+  - logs
+  - search
+contentType: how-to 
+useCase:
+  - logs
+---
+
+# Migrate from Logs Search v2 to v3
+
+To provide our customers with the most reliable and scalable solution, Auth0 has deprecated Tenant Logs Search Engine v2 in favor of v3.
+Auth0 is proactively migrating customers unaffected by this change, while those who are potentially affected are being notified to opt-in for v3 during the provided grace period.
+
+## Am I affected by the migration?
+
+Affected customers are those who meet all of the following criteria:
+* With tenants created before or on May 21st, 2019
+* With tenants hosted in Auth0's public cloud in the AU or EU regions
+* Who use the [GET /api/v2/logs](/api/v2#!/Logs/get_logs) or the [GET /api/v2/users/{user_id}/logs](/api/v2#!/Users/get_logs_by_user) endpoint with the parameter `include_totals=true` or the `q` parameter.
+* Who paginate through more than 1000 results
+* Who use the Delegated Admin Extension
+  * Older versions of the extension will continue to work after your Tenant is migrated to Logs Search Engine v3, however you might notice pagination totals being incorrect when viewing logs. Updating to v3.7 of the extension will address this.
+
+The following tenants are NOT affected:
+* Cloud customers in the US region. The US region has been fully migrated and is already using Search Engine v3.
+* Private Cloud customers (Migration for Private Cloud customers will begin at a later date).
+* Cloud tenants in the EU and AU regions that:
+  * are not using the `GET /api/v2/logs` or `GET /api/v2/users/{user_id}/logs` endpoints of Management API at all.
+  * are consuming the logs from the Dashboard Logs section only.
+  * are using the `GET /api/v2/logs endpoint` with the by checkpoint method (using `from` parameter).
+  * are consuming logs using any of the [Auth0 Logs to External Service Dashboard extensions](/extensions#export-auth0-logs-to-an-external-service) (which use the by checkpoint method).
+  
+## How can I check to see if I've migrated all my queries?
+
+You can search your tenant logs with the following to look for queries that would throw errors after you migrate to v3:
+
+```
+type:depnote AND description:*logs*
+```
+
+These log entries include a `description` field that specifies the deprecated behavior you're using. You can also check the `details.request.path` and `client_name` fields to see what application is calling either `GET /api/v2/logs` or `GET /api/v2/users/{user_id}/logs`.
+
+::: note
+Auth0 generates only one log of the same **type** and **description** every 60 minutes. No matter how many calls you make using deprecated features to the impacted endpoints, you will still see a single log for *each* deprecated feature each hour.
+
+If you implement changes to your queries, you'll need to allow 60 minutes to elapse before you can conclusively determine that the lack of new `depnote` logs means the deprecated behavior has been removed from your code.
+:::
+
+## What’s changing?
+
+The breaking changes are minor, but you should review your queries to make sure the results you are getting are as expected.
+
+Breaking changes are related to:
+#### Pagination
+*  When your tenant is migrated to logs v3 the value of the `total` field returned in the summary result when calling `GET /api/v2/logs` or `GET /api/v2/users/{user_id}/logs` is changing. When searching for logs using search engine v2, the totals field in your results tells you the number of logs that match the query you provided. However, in v3, the totals field tells you how many logs are returned in the page (similar to what the length field returns). To avoid any potential disruption, if your application relies on the total field for pagination purposes, you should update your logic to handle this change appropriately. 
+* There is an existing limit of 100 logs per request. When your tenant is migrated to logs v3 you may only paginate through a maximum of 1,000 search results, resulting in calls for anything over 1,000 results returning an error. To avoid any potential disruption, you should review your queries to avoid this limit or handle errors accordingly.
+#### `q` parameter validation
+* The query syntax when using the `q` parameter in the `GET /api/v2/logs` has minor changes that need to be taken into account. When your tenant is migrated to logs v3 this validation will be enforced resulting in this query returning an error. To avoid any potential disruption, you should review your queries to make sure they comply with the supported query syntax.
+* The `q` parameter includes an invalid field. When your tenant is migrated to logs v3 this validation will be enforced resulting in this call returning an error. To avoid any potential disruption, you should review your queries to make sure that only searchable fields are included. 
+
+## How to Migrate?
+
+After reviewing your queries, you can opt-in to Tenant Logs Search Engine v3 via the Dashboard. Go to *Tenant Settings > Advanced*, then scroll down to *Migrations*. Toggle the *Legacy Logs Search V2* switch to off. 
+Toggling this switch to off disables the deprecated logs search engine v2 and forces the use of search engine v3.
+
+::: note
+If you do not see the **Legacy Logs Search V2** toggle, you've already been migrated to v3. No further action is required.
+:::
+
+![](/media/articles/logs/tenant-logs-migration.png)
+ 
+If you need help with the migration, contact us using the [Support Center](https://support.auth0.com/).
+
+## Keep reading
+
+* [Logs](/logs)
diff --git a/ja-jp/articles/logs/guides/retrieve-logs-mgmt-api.md b/ja-jp/articles/logs/guides/retrieve-logs-mgmt-api.md
new file mode 100644
index 0000000000..c8cec6a38d
--- /dev/null
+++ b/ja-jp/articles/logs/guides/retrieve-logs-mgmt-api.md
@@ -0,0 +1,88 @@
+---
+description: Learn how to retrieve logs using the Auth0 Management API get_logs endpoint by checkpoint or by search criteria. 
+topics:
+  - logs
+contentType: how-to
+useCase:
+  - analyze-logs
+  - integrate-analytics
+---
+
+# Retrieve Logs Using the Management API
+
+You can use the Management API v2 to retrieve your logs using the [/api/v2/logs](/api/v2#!/Logs/get_logs) endpoint, which supports two types of consumption: [by checkpoint](/logs#get-logs-by-checkpoint) or [by search criteria](#get-logs-by-search-criteria).
+
+::: note
+We highly recommend using [the checkpoint approach](#get-logs-by-checkpoint) to export logs to the external system of your choice and perform any search or analysis there, as logs stored in our system are subject to the [retention period](/logs/references/log-data-retention). You can use any of the [Export Auth0 logs to an external service](/extensions#export-auth0-logs-to-an-external-service) extensions to export the logs to the system of your choice (like Sumo Logic, Splunk or Loggly).
+:::
+
+If you would like to perform a search for specific events you can also use the [search criteria approach](#get-logs-by-search-criteria), which is also the one used by the Management Dashboard.
+
+::: note
+When you query for logs with the [list or search logs](/api/v2#!/Logs/get_logs) endpoint, you can retrieve a maximium of 100 logs per request.
+:::
+
+## Get logs by checkpoint
+
+This method allows to retrieve logs from a particular `log_id`. For searching by checkpoint use the following parameters:
+
+| Parameter | Description |
+| -- | -- |
+| `from` | Log Event Id to start retrieving logs. You can limit the amount of logs using the take parameter. |
+| `take` | The total amount of entries to retrieve when using the from parameter. |
+
+::: note
+When fetching logs by checkpoint, the `q` or any parameter other than `from` and `take` will be ignored. Also the order by date is not guaranteed.
+:::
+
+## Get logs by search criteria
+
+This method retrieves log entries that match the specified search criteria (or list all entries if no criteria is used). To search by criteria use the following parameters:
+
+| Parameter | Description |
+| -- | -- |
+| `q` | Search Criteria using Query String Syntax. See [Query Syntax](/logs/references/query-syntax) for information of how to build the queries. |
+| `page` | The zero-based page number. |
+| `per_page` | The number of entries per page. |
+| `sort` | The field to use for sorting. Use `field:order`, where `order` is `1` for ascending and `-1` for descending. For example `date:-1`. |
+| `fields:` | A comma-separated field list to include or exclude (depending on `include_fields`) from the result. Leave empty to retrieve all fields. |
+| `include_fields` | `true` if the fields specified are to be included in the result, `false` otherwise. Defaults to `true`. |
+
+For the list of fields that can be used in the search query and the `fields` and `sort` parameters, see [Query Syntax: Searcheable fields](logs/references/query-syntax#searchable-fields).
+
+## Limitations
+
+Besides the limitation of 100 logs per request to retrieve logs, you may only paginate through up to 1,000 search results.
+
+If you get the error `414 Request-URI Too Large` this means that your query string is larger than the supported length. In this case, refine your search.
+
+::: panel Private Cloud Users
+For Private Cloud users searching tenant logs, note that only the following fields are searchable at this time: 
+
+* `user`
+* `connection`
+* `application`
+* `type`
+* `ip`
+
+Use double quotes for exact searches (e.g., `application:"test"` will search for all log entries specific to the application named `test`, but `application:test` will search log entries for applications with test in their name.
+:::
+
+## Other log endpoints
+
+As an alternative or complement to retrieving logs by checkpoint or search criteria using the [/api/v2/logs](/api/v2#!/Logs/get_logs) endpoint, you can also use the following endpoints to look for logs:
+
+* [/api/v2/logs/{id}](/api/v2#!/Logs/get_logs_by_id): Retrieves the single log entry associated with the provided log id.
+* [/api/v2/users/{user_id}/logs](/api/v2#!/Users/get_logs_by_user): Retrieves log events for a specific user id.
+
+## Keep reading
+
+* [Administrator and Developer Log Usage Examples](/logs/concepts/logs-admins-devs)
+* [Log Data Retention](/logs/references/log-data-retention)
+* [Log Event Type Codes](/logs/references/log-event-type-codes)
+* [Log Search Query Syntax](/logs/references/query-syntax)
+* [View Log Data in the Dashboard](/logs/guides/view-log-data-dashboard)
+* [View Anomaly Detection Events](/anomaly-detection/guides/use-tenant-data-for-anomaly-detection)
+* [Log Event Filters](/logs/references/log-event-filters)
+* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge)
+* [GDPR: Data Minimization](/compliance/gdpr/features-aiding-compliance/data-minimization)
\ No newline at end of file
diff --git a/ja-jp/articles/logs/guides/view-log-data-dashboard.md b/ja-jp/articles/logs/guides/view-log-data-dashboard.md
new file mode 100644
index 0000000000..fc0cbcaa41
--- /dev/null
+++ b/ja-jp/articles/logs/guides/view-log-data-dashboard.md
@@ -0,0 +1,32 @@
+---
+description: Learn how to view log data in the Auth0 Dashboard for all events that occur including user authentication and administrative actions such as adding and updating applications, connections, and rules.
+topics:
+  - logs
+contentType: how-to
+useCase:
+  - analyze-logs
+  - integrate-analytics
+---
+# View Log Data in the Dashboard
+
+The **Logs** page of the [Dashboard](${manage_url}/#/logs) displays all events that occur, including user authentication and administrative actions such as adding/updating Applications, Connections, and Rules.
+
+![Log Search](/media/articles/logs/dashboard-logs.png)
+
+Please note that administrative actions will show up in the logs as `API Operation` events.
+
+## Event type filters
+
+You can choose a [filter](/logs/references/log-event-filters) for log error, warning, and success events. For example, you can choose the **Deprecation Notice** warning to filter logs related to deprecation warnings.
+
+![Log Event Filter](/media/articles/logs/log-event-filter.png)
+
+## Keep reading
+
+* [Administrator and Developer Log Usage Examples](/logs/concepts/logs-admins-devs)
+* [Log Data Retention](/logs/references/log-data-retention)
+* [Log Event Type Codes](/logs/references/log-event-type-codes)
+* [Log Search Query Syntax](/logs/references/query-syntax)
+* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api)
+* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge)
+* [GDPR: Data Minimization](/compliance/gdpr/features-aiding-compliance/data-minimization)
\ No newline at end of file
diff --git a/ja-jp/articles/logs/index.md b/ja-jp/articles/logs/index.md
new file mode 100644
index 0000000000..b8a85708f2
--- /dev/null
+++ b/ja-jp/articles/logs/index.md
@@ -0,0 +1,29 @@
+---
+description: Understand how Auth0 logs work.
+url: /logs
+classes: topic-page
+topics:
+  - logs
+contentType: index
+useCase:
+  - analyze-logs
+  - integrate-analytics
+---
+# Logs
+
+Using the [Dashboard](${manage_url}/#/logs) or the [Management API logs endpoint](/api/v2#!/Logs/get_logs), you can pull log data on actions performed by administrators using the Dashboard, operations performed via the Management API, and authentications made by your users.
+
+::: warning
+Auth0 does not provide real-time logs for your tenant. While we do our best to index events as they arrive, you may see some delays.
+:::
+
+<%= include('../_includes/_topic-links', { links: [
+  'logs/streams',
+  'logs/references/log-data-retention',
+  'logs/guides/view-log-data-dashboard',
+  'logs/references/log-event-filters',
+  'logs/guides/retrieve-logs-mgmt-api',
+  'logs/references/log-event-type-codes',
+  'logs/references/query-syntax',
+  'logs/concepts/logs-admins-devs'
+] }) %>
diff --git a/ja-jp/articles/logs/references/log-data-retention.md b/ja-jp/articles/logs/references/log-data-retention.md
new file mode 100644
index 0000000000..4ea7b2c72d
--- /dev/null
+++ b/ja-jp/articles/logs/references/log-data-retention.md
@@ -0,0 +1,58 @@
+---
+title: Log Data Retention
+description: Describes how long log data is stored depending on your Auth0 plan.
+topics:
+  - logs
+  - log-data
+contentType:
+  - reference
+useCase:
+  - manage-logs
+---
+# Log Data Retention
+
+Auth0 provides event logging capability and you can scan logs to identify event anomalies. Standard log retention period for Auth0 logs is determined by subscription level with the shortest period being 2 days and the longest period being only 30 days. Leveraging Auth0 support for integrating with external logging services allows you to retain logs outside of this timeframe, and will also provide for log aggregation across your organization.
+
+To understand how you will use the Auth0 logs in your situation, review the log data retention period for your subscription level.
+
+Plan | Log Retention
+-----|--------------
+Free | 2 days
+Developer | 2 days
+Developer Pro | 10 days
+Enterprise | 30 days
+
+You can implement an Auth0 log data export extension to send log data to an external log analytics service. For example, you can use log files for troubleshooting and detecting intermittent errors that may be hard to find with quality assurance testing. You may also want log data in case forensic data is ever needed for security purposes. Log data can also provide comprehensive analytics to help you see patterns in usage trends and anomaly detection triggers.
+
+Auth0 extensions support following third-party services:
+
+- [Application Insights](/extensions/application-insight)
+- [AWS Cloudwatch](/extensions/cloudwatch)
+- [Azure Blob Storage](/extensions/azure-blob-storage)
+- [Logentries](/extensions/logentries)
+- [Loggly](/extensions/loggly)
+- [Logstash](/extensions/logstash)
+- [Mixpanel](/extensions/mixpanel)
+- [Papertrail](/extensions/papertrail)
+- [Sumo Logic](/extensions/sumologic)
+- [Splunk](/extensions/splunk)
+
+You can also export logs to the following services using Auth0 Rules:
+
+* [Keen](/monitoring/guides/send-events-to-keenio)
+* [Segment](/monitoring/guides/send-events-to-segment)
+* [Splunk](/monitoring/guides/send-events-to-splunk)
+
+## Rate limits exceeded and other errors
+
+Auth0 provides a unique error code for errors reported when the [rate limit is exceeded](/policies/rate-limits#exceeding-the-rate-limit). You can set up automatic scanning of logs to check for rate limit errors so you can proactively address activity that hits rate limits before it causes too much trouble for your users. Auth0 also publishes error codes for other types of errors, and you can scan logs for [authentication errors](/libraries/error-messages) as well as errors from Auth0 Management API calls. (Management API error codes are shown below each call in the [Management API Explorer](/api/management/v2)).
+
+## Keep reading
+
+* [Administrator and Developer Log Usage Examples](/logs/concepts/logs-admins-devs)
+* [View Log Data in the Dashboard](/logs/guides/view-log-data-dashboard)
+* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api)
+* [Log Event Type Codes](/logs/references/log-event-type-codes)
+* [Log Search Query Syntax](/logs/references/query-syntax)
+* [Log Event Filters](/logs/references/log-event-filters)
+* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge)
\ No newline at end of file
diff --git a/ja-jp/articles/logs/references/log-event-filters.md b/ja-jp/articles/logs/references/log-event-filters.md
new file mode 100644
index 0000000000..6faa84fbf8
--- /dev/null
+++ b/ja-jp/articles/logs/references/log-event-filters.md
@@ -0,0 +1,148 @@
+---
+title: Log Event Filters
+description: Lists the log filters for errors, warnings, and success events. 
+topics:
+  - logs
+  - log-data
+  - log-filter
+contentType:
+  - reference
+useCase:
+  - manage-logs
+  - filter-log-events
+---
+# Log Event Filters
+
+You can filter logs for errors, warnings, and success events in the [Dashboard](${manage_url}/#/logs) when you click the **Filter** down arrow. 
+
+## Error event filters
+
+| Filter | Description |
+| -- | -- |
+| Block Account | IP blocked for >10 failed attempts to login to single account |
+| Blocked IP Address | IP blocked for >100 failed login attempts or >50 signup attempts |
+| Breached password | Attempted login with a leaked password |
+| Connector Offline | AD/LDAP Connector is offline |
+| Device Confirmation Canceled by User | User did not confirm device |
+| Error sending MFA Push Notification | Push notification for MFA failed |
+| Error sending MFA SMS | SMS for MFA failed |
+| Failed API Operation | Operation on API failed |
+| Failed Change Email | Failed to change user email |
+| Failed Change Password | Failed to change user password |
+| Failed Change Password Request | Change password request failed |
+| Failed Change Phone Number | Failed to change user phone number |
+| Failed Change Username | Failed to change username |
+| Failed Connector Provisioning | Failed to provision a AD/LDAP connector |
+| Failed Delegation | Failed to generate delegation token |
+| Failed Exchange | Token Exchange |
+| Failed Exchange | Native Socal Login |
+| Failed Exchange | Authorization Code for Access Token |
+| Failed Exchange | Client Credentials for Access Token |
+| Failed Exchange | Password for Access Token |
+| Failed Exchange | Refresh Token for Access Token |
+| Failed Exchange | Password and OOB Challenge for Access Token |
+| Failed Exchange | Password and OTP Challenge for Access Token |
+| Failed Exchange | Password and MFA Recovery code for Access Token |
+| Failed Exchange | Device Code for Access Token |
+| Failed Login | User failed to login |
+| Failed Login (invalid email/username) | User failed to login due to invalid username |
+| Failed Login (wrong password) | User failed to login due to invalid password |
+| Failed Logout | User logout failed |
+| Failed Post Change Password Hook | Post-change password hook failed |
+| Failed Post User Registration Hook | Post user registration hook failed |
+| Failed Sending Notification | Failed to send email notification |
+| Failed Signup | Sign up failed |
+| Failed Silent Auth | Silent authentication failed |
+| Failed User Deletion | User deletion failed |
+| Failed Verification Email | Failed to send verification email |
+| Failed Verification Email Request | Failed to process verification email request |
+| Failed CORS | Origin is not in the Allowed Origins list for the specified application |
+| Failed by Connector | AD/LDAP Connector Failure |
+| Failed cross origin authentication | Cross-origin authentication failed |
+| Failed device activation | Failed to activate device |
+| Failed device authorization request | Device authorization request failed |
+| MFA Enrollment start failed | Multi-factor authentication enroll failed |
+| OTP Auth failed | One-time password authentication failed |
+| OTP Auth rejected | One-time password authentication rejected |
+| Rate Limit on API | Maximum number of requests to the Authentication API in given time has been reached |
+| Recovery failed | Multi-factor recovery code failed |
+| Second factor email failed | Email for MFA failed |
+| Too Many Calls to /delegation | Rate limt exceeded to /delegation endpoint |
+| Too Many Calls to /userinfo | Rate limit exceeded to /userinfo endpoint |
+| Too Many Invalid Device Codes | Rate limit exceeded for invalid device codes |
+
+## Warning event filters 
+
+| Filter | Description |
+| -- | -- |
+| Deprecation Notice | Feature is deprecated |
+| Too many failures | Multi-factor OTP has failed too many times |
+| Too many failures | Mutli-factor recovery code has failed too many times |
+| Users import | Failed to import users |
+| Warning During Login | Warnings during login |
+
+## Success event filters 
+
+| Filter | Description |
+| -- | -- |
+| API Operation | API operation completed successfully |
+| Account unblocked | User block setup by anomay detection has been released |
+| Auth0 OS Update Ended | Auth0 OS update ended |
+| Auth0 OS Update Started | Auth0 OS update started |
+| Auth0 Update Ended | Auth0 update ended |
+| Auth0 Update Launched | New version of Auth0 released |
+| Auth0 Update Started | Auth0 update started |
+| Code Sent | Passwordess login code has been sent |
+| Code/Link Sent | Passwordless lgoin code/link has been sent |
+| Configuration read | PSaaS configuration has been read |
+| Configuration status checked | PSaaS configuration's status has been checked |
+| Configuration updated | PSaaS configuration has been updated |
+| Connector Online | AD/LDAP Connector is online and working |
+| Enroll started | Multi-factor authentication enroll has started |
+| MFA enrollment complete | Multi-factor authentication enroll has completed |
+| MFA settings update | Mutli-factor tenant settings updated |
+| Module switch | Multi-factor module switched |
+| OTP Auth Succeed | One-time password authentication success |
+| Push notification sent | Push notification for MFA successfully sent | 
+| Recovery succeed | Multi-factor recovery code succeeded authorization |
+| SMS Sent | SMS for MFA sent successfully sent |
+| Second factor email sent | Email for MFA successfully sent |
+| Second factor started | Second factor authentication event started for MFA |
+| Success Change Email | Email changed successfully |
+| Success Change Password | Password changed successfully |
+| Success Change Password Request | Change password request succeeded |
+| Success Change Phone Number | Phone number changed successfully |
+| Success Change Username | Username changed successfully |
+| Success Delegation | Delegation token generated successfully |
+| Success Exchange | Authorization Code for Access Token |
+| Success Exchange | Client Credentials for Access Token |
+| Success Exchange | Password for Access Token |
+| Success Exchange | Refresh Token for Access Token |
+| Success Exchange | Token Exchange |
+| Success Exchange | Native Social Login |
+| Success Exchange | Password and OOB Challenge for Access Token |
+| Success Exchange | Password and OTP Challenge for Access Token |
+| Success Exchange | Password and MFA Recovery code for Access Token |
+| Success Exchange | Device Code for Access Token |
+| Success Login | Successful Login |
+| Success Logout | User successfully logged out |
+| Success Post Change Password Hook | Post-change password hook ran successfully |
+| Success Signup | Successful signup |
+| Success Silent Auth | Successful silent authentication |
+| Success Verification Email | Successful verification email |
+| Success Verification Email Request | Successful verification email request |
+| Success cross origin authentication | Successful cross-origin authentication | 
+| Successful User Deletion | User successfully deleted |
+| Unenroll device account | Device used for second factor authentication has been unenrolled |
+| Update device account | Device used for second factor authentication has been updated |
+| User delete | Deleted multi-factor user account |
+| Users import | Successfully imported users |
+
+## Keep reading
+
+* [Administrator and Developer Log Usage Examples](/logs/concepts/logs-admins-devs)
+* [View Log Data in the Dashboard](/logs/guides/view-log-data-dashboard)
+* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api)
+* [Log Event Type Codes](/logs/references/log-event-type-codes)
+* [Log Search Query Syntax](/logs/references/query-syntax)
+* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge)
\ No newline at end of file
diff --git a/ja-jp/articles/logs/references/log-event-type-codes.md b/ja-jp/articles/logs/references/log-event-type-codes.md
new file mode 100644
index 0000000000..e7496892b8
--- /dev/null
+++ b/ja-jp/articles/logs/references/log-event-type-codes.md
@@ -0,0 +1,132 @@
+---
+title: Log Event Type Codes
+description: Lists the event codes associated with log events. 
+topics:
+  - logs
+  - log-data
+contentType:
+  - reference
+useCase:
+  - manage-logs
+---
+# Log Event Type Codes
+
+The following table lists the codes associated with the each log event.
+
+| **Event Code** | **Event** | **Event Description** | **Additional Info** |
+| --- | --- | --- | --- |
+| `api_limit` | Rate Limit on the Authentication API | The maximum number of requests to the Authentication API in given time has reached. | [Rate Limit Policy](/policies/rate-limits) |
+| `cls` | Code/Link Sent | Passwordless login code/link has been sent | [Passwordless](/connections/passwordless) |
+| `coff` | Connector Offline | AD/LDAP Connector is offline | [Active Directory/LDAP Connector](/connector) |
+| `con` | Connector Online | AD/LDAP Connector is online and working | [Active Directory/LDAP Connector](/connector) |
+| `cs` | Code Sent | Passwordless login code has been sent | [Passwordless](/connections/passwordless) |
+| `depnote` | Deprecation Notice | | |
+| `du` | Deleted User | User has been deleted. | [User Profile](/users/concepts/overview-user-profile) |
+| `f` | Failed Login | | |
+| `fc` | Failed by Connector | | [Active Directory/LDAP Connector](/connector) |
+| `fce` | Failed Change Email | Failed to change user email | [User Profile](/users/concepts/overview-user-profile) |
+| `fco` | Failed by CORS | Origin is not in the Allowed Origins list for the specified application | [Applications](/dashboard/reference/settings-application) |
+| `fcoa` | Failed cross-origin authentication | | |
+| `fcp` | Failed Change Password | | [Changing a User's Password](/connections/database/password-change) |
+| `fcph` | Failed Post Change Password Hook | | |
+| `fcpn` | Failed Change Phone Number | | [User Profile](/users/concepts/overview-user-profile) |
+| `fcpr` | Failed Change Password Request | | [Changing a User's Password](/connections/database/password-change) |
+| `fcpro` | Failed Connector Provisioning | Failed to provision a AD/LDAP connector | [Active Directory/LDAP Connector](/connector) |
+| `fcu` | Failed Change Username | Failed to change username | [User Profile](/users/concepts/overview-user-profile) |
+| `fd` | Failed Delegation | Failed to generate delegation token | [Delegation Tokens](/tokens/delegation) |	
+| `fdeac`   | Failed Device Activation | Failed to activate device. | [Device Authorization Flow](/flows/concepts/device-auth) |
+| `fdeaz`    | Failed Device Authorization Request | Device authorization request failed. | [Device Authorization Flow](/flows/concepts/device-auth) |
+| `fdecc`    | User Canceled Device Confirmation | User did not confirm device. | [Device Authorization Flow](/flows/concepts/device-auth) |
+| `fdu` | Failed User Deletion | | [User Profile](/users/concepts/overview-user-profile) |
+| `feacft` | Failed Exchange | Failed to exchange authorization code for Access Token | [Call API Using the Authorization Code Flow](/flows/guides/auth-code/call-api-auth-code)
+| `feccft` | Failed Exchange | Failed exchange of Access Token for a Client Credentials Grant | [Asking for Access Tokens for a Client Credentials Grant](/api-auth/config/asking-for-access-tokens) |
+| `fede`    | Failed Exchange | Failed to exchange Device Code for Access Token | [Device Authorization Flow](/flows/concepts/device-auth) |
+| `fens` | Failed Exchange | Failed exchange for Native Social Login | |
+| `feoobft` | Failed Exchange | Failed exchange of Password and OOB Challenge for Access Token | |
+| `feotpft` | Failed Exchange | Failed exchange of Password and OTP Challenge for Access Token | |
+| `fepft` | Failed Exchange | Failed exchange of Password for Access Token | |
+| `fercft` | Failed Exchange | Failed Exchange of Password and MFA Recovery code for Access Token | |
+| `fertft` | Failed Exchange | Failed Exchange of Refresh Token for Access Token | |
+| `ferrt` | Failed Exchange | Failed Exchange of Rotating Refresh Token | |
+| `flo` | Failed Logout | User logout failed | [Logout](/logout) |
+| `fn` | Failed Sending Notification | Failed to send email notification | [Emails](/email) |
+| `fp` | Failed Login (Incorrect Password) | | |
+| `fs` | Failed Signup | | |
+| `fsa` | Failed Silent Auth | | |
+| `fu` | Failed Login (Invalid Email/Username) | | |
+| `fui` | Failed users import | Failed to import users | [User Import/Export](/extensions/user-import-export) |
+| `fv` | Failed Verification Email | Failed to send verification email | [Verification Email](/email/custom#verification-email) |
+| `fvr` | Failed Verification Email Request | Failed to process verification email request | [Verification Email](/email/custom#verification-email) |
+| `gd_auth_failed` | MFA Auth failed | Multi-factor authentication failed. This could happen due to a wrong code entered for SMS/Voice/Email/TOTP factors, or a system failure.  | [Multi-factor Authentication](/mfa) |
+| `gd_auth_rejected` | MFA Auth rejected | A user rejected a Multi-factor authentication request via push-notification. | [Multi-factor Authentication](/mfa) |
+| `gd_auth_succeed` | MFA Auth success | Multi-factor authentication success. | [Multi-factor Authentication](/mfa) |
+| `gd_enrollment_complete` | MFA enrollment complete | A first time MFA user has successfully enrolled using one of the factors.| |
+| `gd_otp_rate_limit_exceed` | Too many failures | A user, during enrollment or authentication, enters an incorrect code more than the maximum allowed number of times. Ex: A user enrolling in SMS enters the 6-digit code wrong more than 10 times in a row.| |
+| `gd_recovery_failed` | Recovery failed | A user enters a wrong recovery code when attempting to authenticate. | [Multi-factor Authentication](/mfa) |
+| `gd_recovery_rate_limit_exceed` | Too many failures | A user enters a wrong recovery code too many times. | [Multi-factor Authentication](/mfa) |
+| `gd_recovery_succeed` | Recovery success | A user successfully authenticates with a recovery code. | [Multi-factor Authentication](/mfa) |
+| `gd_send_pn` | Push notification sent | Push notification for MFA sent successfully sent. | [MFA with Push Notifications](/mfa/concepts/mfa-factors#push-notifications) |
+| `gd_send_sms` | SMS sent | SMS for MFA successfully sent. | [Using SMS for MFA](/mfa/concepts/mfa-factors#sms-notifications) |
+| `gd_send_sms_failure` | SMS sent failures | Attempt to send SMS for MFA failed. | [Using SMS for MFA](/mfa/concepts/mfa-factors#sms-notifications) |
+| `gd_send_voice` | Voice call made | Voice call for MFA successfully made. | [Using Voice for MFA](/mfa/concepts/mfa-factors#voice-notifications) |
+| `gd_send_voice_failure` | Voice call failure | Attempt to make Voice call for MFA failed. | [Using Voice for MFA](/mfa/concepts/mfa-factors#voice-notifications) |
+| `gd_start_auth` | Second factor started | Second factor authentication event started for MFA. | [Multi-factor Authentication](/mfa) |
+| `gd_start_enroll` | Enroll started | Multi-factor authentication enroll has started. | [Multi-factor Authentication](/mfa) |
+| `gd_tenant_update` | Guardian tenant update | | [Hosted MFA Page](/universal-login/multifactor-authentication) |
+| `gd_unenroll` | Unenroll device account | Device used for second factor authentication has been unenrolled. | [Multi-factor Authentication](/mfa) |
+| `gd_update_device_account` | Update device account | Device used for second factor authentication has been updated. | [Multi-factor Authentication](/mfa) |
+| `limit_delegation` | Too Many Calls to /delegation | Rate limit exceeded to `/delegation` endpoint | [API Rate Limit Policy](/policies/rate-limits) |
+| `limit_mu` | Blocked IP Address | An IP address is blocked with 100 failed login attempts using different usernames, all with incorrect passwords in 24 hours, or 50 sign-up attempts per minute from the same IP address. | [Anomaly Detection](/anomaly-detection) |
+| `limit_wc` | Blocked Account | An IP address is blocked with 10 failed login attempts into a single account from the same IP address. | [Anomaly Detection](/anomaly-detection) |
+| `mfar` | MFA Required | A user has been prompted for multi-factor authentication. In the case of Adaptive MFA, details regarding the risk assessment are included. | Available in only [Resource Owner Password Flow](/flows/resource-owner-password-flow). |
+| `pwd_leak` | Breached password | Someone behind the IP address: `ip` attempted to login with a leaked password. | [Anomaly Detection](/anomaly-detection) |
+| `s` | Success Login | Successful login event. | |
+| `sapi` | Success API Operation | | |
+| `sce` | Success Change Email | | [Emails in Auth0](/email) |
+| `scoa` | Success cross-origin authentication | | |
+| `scp` | Success Change Password | | |
+| `scph` | Success Post Change Password Hook | | |
+| `scpn` | Success Change Phone Number | | |
+| `scpr` | Success Change Password Request | | |
+| `scu` | Success Change Username | | |
+| `sd` | Success Delegation | | [Delegation Tokens](/tokens/delegation) |
+| `sdu` | Success User Deletion | User successfully deleted | [User Profile](/users/concepts/overview-user-profile) |
+| `seacft` | Success Exchange | Successful exchange of authorization code for Access Token | [Call API Using the Authorization Code Flow](/flows/guides/auth-code/call-api-auth-code) |
+| `seccft` | Success Exchange | Successful exchange of Access Token for a Client Credentials Grant | [Asking for Access Tokens for a Client Credentials Grant](/api-auth/config/asking-for-access-tokens) |
+| `sede`     | Success Exchange | Successful exchange of device code for Access Token | [Device Authorization Flow](/flows/concepts/device-auth) |
+| `sens` | Success Exchange | Native Social Login | |
+| `seoobft` | Success Exchange | Successful exchange of Password and OOB Challenge for Access Token | |
+| `seotpft` | Success Exchange | Successful exchange of Password and OTP Challenge for Access Token | |
+| `sepft` | Success Exchange | Successful exchange of Password for Access Token | |
+| `sercft` | Success Exchange | Successful exchange of Password and MFA Recovery code for Access Token | |
+| `sertft` | Success Exchange | Successful exchange of Refresh Token for Access Token | |
+| `slo` | Success Logout | User successfully logged out | [Logout](/logout) |
+| `ss` | Success Signup | | |
+| `ssa` | Success Silent Auth | | |
+| `sui` | Success users import | Successfully imported users | [User Import/Export](/extensions/user-import-export) |
+| `sv` | Success Verification Email | | |
+| `svr` | Success Verification Email Request | | |
+| `ublkdu` | User login block released | User block setup by anomaly detection has been released | |
+| `w` | Warnings During Login | | |
+
+# Managed Private Cloud Only
+
+These events are only generated in the [Managed Private Cloud](https://auth0.com/docs/private-cloud/managed-private-cloud) deployment model of Auth0.
+
+| **Event Code** | **Event** | **Event Description** | **Additional Info** |
+| --- | --- | --- | --- |
+| `admin_update_launch` | Auth0 Update Launched | |
+| `sys_os_update_end` | Auth0 OS Update Ended | | |
+| `sys_os_update_start` | Auth0 OS Update Started | | |
+| `sys_update_end` | Auth0 Update Ended | | |
+| `sys_update_start` | Auth0 Update Started | | |
+
+## Keep reading
+
+* [Administrator and Developer Log Usage Examples](/logs/concepts/logs-admins-devs)
+* [View Log Data in the Dashboard](/logs/guides/view-log-data-dashboard)
+* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api)
+* [Anomaly Detection](/anomaly-detection)
+* [Log Search Query Syntax](/logs/references/query-syntax)
+* [Log Event Filters](/logs/references/log-event-filters)
+* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge)
diff --git a/ja-jp/articles/logs/references/query-syntax.md b/ja-jp/articles/logs/references/query-syntax.md
new file mode 100644
index 0000000000..c8d5bfe1cb
--- /dev/null
+++ b/ja-jp/articles/logs/references/query-syntax.md
@@ -0,0 +1,129 @@
+---
+title: Log Search Query Syntax
+description: Describes search query syntax using a subset of the Lucene query syntax to refine Auth0 log searches.
+toc: true
+topics:
+  - logs
+  - log-management
+  - search
+  - query-syntax
+contentType:
+  - reference
+useCase:
+  - manage-logs
+---
+# Log Search Query Syntax
+
+When searching for logs, you can create queries using a subset of [Lucene query syntax](http://www.lucenetutorial.com/lucene-query-syntax.html) to refine your search.
+
+The query string is parsed into a series of terms and operators:
+
+* A term can be a single word such as `jane` or `smith`.
+* A term can be a phrase surrounded by double quotes (`"customer log"`), which will match all words in the phrase in the same order.
+* A term without a field name will only match [these selected fields](/logs/query-syntax#fields-searchable-against-bare-terms) fields.
+* Multiple terms can be grouped together with parentheses to form sub-queries.
+* All search fields are case sensitive.
+* Operators (`AND`, `OR`, `NOT`) work on all searchable fields.
+
+## Searchable fields
+
+The following list of fields are searchable and case sensitive:
+
+* `log_id`: the id of the log event
+* `date`: The moment when the event occurred.
+* `connection`: The connection name related to the event.
+* `connection_id`: The connection id related to the event.
+* `client_id`: The client id related to the event
+* `client_name`: The name of the client related to the event.
+* `ip`: The IP address from where the request that caused the log entry originated.
+* `user_id`: The user id related to the event.
+* `user_name`: The user name related to the event.
+* `description`: The description of the event.
+* `user_agent`: The user agent that is related to the event.
+* `type`: One of the [possible event types](/logs#log-data-event-listing).
+* `strategy`: The connection strategy related to the event.
+* `strategy_type`: The connection strategy type related to the event.
+* `hostname`: the hostname that is being used for the authentication flow.
+
+## Fields searchable against bare terms
+
+If a search term is entered without a field name, it will only be searched against the following fields:
+
+* `user_name`
+* `connection`
+* `client_name`
+* `type`
+* `ip`
+* `log_id`
+* `description`
+
+## Exact matching
+
+To find exact matches, use double quotes: `description:"Username invalid"`.
+
+For example, to find logs with the description `Username invalid`, use `q=description:"Username invalid"`:
+
+## Wildcards
+
+Wildcard searches can be run on terms using the asterisk character (`*`) to replace zero or more characters: `user_name:john*`. They can be used for prefix matching, for example `user_name:j*`. For other uses of wildcards (e.g. suffix matching), literals must have 3 characters or more. For example, `name:*usa` is allowed, but `name:*sa` is not.
+
+The question mark character (`?`), is currently not supported.
+
+For example, to find all logs for users whose usernames start with `john`, use `q=user_name:john*`:
+
+## Ranges
+
+You can use ranges in your log search queries. For inclusive ranges use square brackets: `[min TO max]`, and for exclusive ranges use curly brackets: `{min TO max}`.
+
+Curly and square brackets can be combined in the same range expression. You can also use wildcards within ranges.
+
+As an example, to find all logs from December 18, 2018 until the present, use `q=date:[2018-12-18 TO *]`.
+If you'd like to search logs from the beginning of your retention period until, but not including, December 19, 2018, use `q=date:[* TO 2018-12-19}`.
+
+## Example queries
+
+Below are some examples to show the kinds of queries you can make with the Management API.
+
+Use Case | Query
+---------|------
+Search all logs with connections that contains "Pass" | `connection:*pass*`
+Search all logs for users with a user name that contains "fred" | `user_name:*fred*`
+Search all logs with user id's matching exactly "123" | `user_id:"123"`
+Search for all logs with a type starting with "s" | `type:s*`
+Search for user names that start with "jane" and end with "smith" | `user_name:jane*smith`
+Search for all logs in December 2018 | `date:[2018-12 TO 2018-01-01}`
+Search for all logs from December 10, 2018 forward | `date:[2018-12-10 TO *]`
+Search for all logs from January 1, 2019 at 1AM, until, but not including January 1, 2019 at 12:23:45 | `date:[2019-01-01T01:00:00 TO 2019-01-01T12:23:45}`
+
+## Limitations
+
+* If you get the error `414 Request-URI Too Large` this means that your query string is larger than the supported length. In this case, refine your search.
+* Log fields are not tokenized , so `description:rule` will not match a description with value `Create a rule` nor `Update a rule`. Instead, use `description:*rule`. See [wildcards](#wildcards) and [exact matching](#exact-matching).
+* The `.raw` field extension is not supported. Fields match the whole value that is provided and are not tokenized.
+* To search for a specific value nested in the `details` field, use the path to the field (i.e., `details.request.channel:"https://manage.auth0.com/"`). Bare searches like `details:"https://manage.auth0.com/"` do not work.
+
+## Pagination
+
+When calling the [GET /api/v2/logs](/api/v2#!/Logs/get_logs) or [GET /api/v2/users/{user_id}/logs](/api/v2#!/Users/get_logs_by_user) endpoints using the `include_totals` parameter, the result is a JSON object containing a summary of the results **and** the requested logs. The JSON object looks something like:
+
+```js
+{
+  "length": 5,
+  "limit": 5,
+  "logs": [...],
+  "start": 0,
+  "total": 5
+}
+```
+
+When searching for logs, the `totals` field tells you how many logs are returned in the page (similar to what the `length` field returns). 
+
+## Keep reading
+
+* [Administrator and Developer Log Usage Examples](/logs/concepts/logs-admins-devs)
+* [View Log Data in the Dashboard](/logs/guides/view-log-data-dashboard)
+* [Retrieve Logs Using the Management API](/logs/guides/retrieve-logs-mgmt-api)
+* [View Anomaly Detection Events](/anomaly-detection/guides/use-tenant-data-for-anomaly-detection)
+* [Log Event Type Codes](/logs/references/log-event-type-codes)
+* [Log Event Filters](/logs/references/log-event-filters)
+* [Integrate AWS EventBridge with Auth0](/integrations/aws-eventbridge)
\ No newline at end of file
diff --git a/ja-jp/articles/logs/streams/amazon-eventbridge.md b/ja-jp/articles/logs/streams/amazon-eventbridge.md
new file mode 100644
index 0000000000..7c9aa10283
--- /dev/null
+++ b/ja-jp/articles/logs/streams/amazon-eventbridge.md
@@ -0,0 +1,86 @@
+---
+title: Amazon EventBridge Log Streams
+description: Learn how to create an event-driven workflow using Amazon EventBridge to send your tenant logs to the targets of your choice, such as AWS EC2 instances, Lambda functions, Kinesis streams, and ECS tasks.
+toc: true
+topics:
+ - integrations
+ - logs
+ - streams
+ - event-streams
+ - aws
+ - eventbridge
+ - amazon
+contentType: how-to
+---
+# Amazon EventBridge Log Streams
+
+Amazon EventBridge is a serverless event bus that acts as an intermediary allowing you to send data from your applications to AWS services. You can create an event-driven workflow using EventBridge to send your Auth0 tenant logs to the targets of your choice (e.g., AWS EC2 instances, Lambda functions, Kinesis streams, and ECS tasks).
+
+## Steps
+
+To send Auth0 events to Amazon EventBridge, you will need to:
+
+1. Set up a partner event source (in this case, this is Auth0)
+2. Set up a partner event bus that matches incoming events with the routes to which they should be targeted
+3. Set up rules to route incoming events to your choice of AWS service
+4. Test the integration
+
+You can send events from Auth0 to AWS once you have [matched your partner event source to the partner event bus](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-partner-event-bus.html).
+
+### Set up Auth0 as the partner event source
+
+First, you will need to set up Auth0 for use as the event source in the [Dashboard](${manage_url}).
+
+1. Log in to the [Auth0 Dashboard](${manage_url}).
+
+2. Navigate to **Logs > Streams**.
+
+3. Click **+ Create Stream**.
+
+4. Select **Amazon EventBridge**, and enter a unique name for your new Amazon EventBridge Event Stream.
+
+5. Create the Event Source by providing your **AWS Account ID** and **AWS Region**. Note that the region you select must match the region in which your Amazon EventBridge resides.
+
+6. Click **Save**. Auth0 provides you with an **Event Source Name**. Make sure to save your **Event Source Name** value because you will be providing it to AWS at a later point to complete the integration.
+
+### Set up event bus in AWS
+
+1. Go to the [Amazon EventBridge partners tab](https://console.aws.amazon.com/events/home?region=us-east-1#/partners) in your AWS account, and make sure you are in the **AWS Region** where the event source was created.
+
+2. Paste the **Event Source Name** in the event source search box to find the newly-created Event Source, and click on it to associate it with an Event Bus.
+**Note**: The Event Source will remain in pending state until it gets associated with an Event Bus, and all the events sent to that Event Source will be dropped.
+
+3. Once you click on the Event Source, click **Associate with Event Bus**.
+
+4. Name the Event Bus the same name as the Event Source. At this point, you can specify permissions for this Event Bus or simply associate it.
+
+### Create EventBridge rules
+
+At this point, the events that you send are available on your Event Bus. However, before you can use the data you send to AWS services, you must [create rules](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-event-bus.html) that map those events to specific targets.
+
+Amazon EventBridge uses rules, which are definitions specifying how you want incoming events routed to the desired targets. Targets are the services, such as EC2 instances, Lambda functions, Kinesis streams, or ECS tasks, that process the event-driven data that they receive. Data received by targets are JSON-formatted.
+
+A single rule can route to one or more targets (if there are more than one, AWS processes all in parallel).
+
+To create a rule:
+
+1. Go to the [EventBridge page](https://console.aws.amazon.com/events/home?region=us-east-1#/), and click **Create rule**.
+
+2. Provide the name of the Event Bus, and specify your targets.
+
+### Test integration
+
+As soon as Auth0 writes the next tenant log, you should see a copy of the log Auth0 has written in JSON format at the target you defined in your EventBridge rule.
+
+## Delivery attempts and retries
+
+Auth0 events are delivered to AWS via a streaming mechanism that sends each event as it is triggered in our system. If EventBridge is unable to receive the event, we will retry up to three times to deliver the event; otherwise, we will log the failure, and you will see the failure in the **Health** tab for your log stream.
+
+## More on Log Streams
+
+::: next-steps
+* [HTTP Event Log Streams](/logs/streams/http-event)
+* [Example: Stream Auth0 Log Events to Slack](/logs/streams/http-event-to-slack)
+* [Datadog Event Log Streams](/logs/streams/datadog)
+* [Azure Event Grid Log Streams](/logs/streams/azure-event-grid)
+:::
diff --git a/ja-jp/articles/logs/streams/azure-event-grid.md b/ja-jp/articles/logs/streams/azure-event-grid.md
new file mode 100644
index 0000000000..ae1f8b63aa
--- /dev/null
+++ b/ja-jp/articles/logs/streams/azure-event-grid.md
@@ -0,0 +1,113 @@
+---
+title: Azure Event Grid Log Streams
+description: Learn how to create an event-driven workflow using Azure Event Grid and send your tenant logs anywhere within the Azure ecosystem.
+toc: false
+topics:
+ - logs
+ - streams
+ - event-streams
+contentType: how-to
+---
+
+# Integrate Azure Event Grid with Auth0
+
+Azure Event Grid is a serverless event bus that lets you send event data from any source to any destination.
+
+You can create event-driven workflows using Event Grid to send your Auth0 tenant logs to targets, such as Azure Functions, Event Hubs, Sentinel, and Logic Apps.
+
+For a full list of the event type codes that Auth0 supports, see [Log Event Type Codes](/logs/references/log-event-type-codes).
+
+## Send events from Auth0 to Azure Event Grid
+
+To send Auth0 events to Azure, you must:
+
+1. Enable the Event Grid resource provider.
+2. Set up an event source (in this case, this is Auth0).
+3. Set up an event handler, which is the app or service where the event will be sent.
+
+To learn more, see [Microsoft's Concepts in Azure Event Grid](https://docs.microsoft.com/en-us/azure/event-grid/concepts).
+
+### Enable Event Grid resource provider
+
+If you haven’t previously used Event Grid, you will need to register the Event Grid resource provider. If you've used Event Grid before, skip to the next section.
+
+In your Azure portal:
+
+1. Select Subscriptions.
+2. Select the subscription you’re using for Event Grid.
+3. On the left menu, under **Settings**, select Resource providers.
+4. Find `Microsoft.EventGrid`.
+5. Select **Register**.
+6. Refresh to make sure the status changes to `Registered`.
+
+### Set up an Auth0 event source
+
+Use the Auth0 Dashboard to set up Auth0 for use as an event source.
+
+1. Log in to the [Auth0 Dashboard](${manage_url}).
+2. Navigate to **Logs > Streams**.
+3. Click **+ Create Stream**.
+4. Select **Azure Event Grid**, and enter a unique name for your new stream.
+5. On the next screen, provide the following settings for your Event Grid stream:
+
+| Setting | Description |
+|---------|-------------|
+| Name | A unique display name to distinguish this integration from other integrations. |
+| Azure Subscription ID | The unique alphanumeric string that identifies your Azure subscription. |
+| Azure Region | The region in which your Azure subscription is hosted. |
+| Resource Group name | The name of the Azure resource group, which allows you to manage all Azure assets within one subscription. |
+
+6. Click **Save**.
+
+#### Activate your Auth0 Partner Topic in Azure
+
+Activating the Auth0 topic in Azure allows events to flow from Auth0 to Azure.
+
+1. Log in to the [Azure Portal](https://portal.azure.com/).
+2. Search `Partner Topics` at the top, and click `Event Grid Partner Topics` under services.
+3. Click on the topic that matches the stream you created in your Auth0 Dashboard.
+4. Confirm that the `Source` field matches your Auth0 account.
+5. Click **Activate**.
+
+#### Subscribe to your Partner Topic
+
+Subscribe to an Event Grid partner topic to tell Event Grid which events to send to your event handler.
+
+1. On the Event Grid partner topic Overview page, select **+ Event Subscription** on the toolbar.
+2. On the Create Event Subscription page:
+    1. Enter a name for the event subscription.
+    2. Select your desired Azure service or WebHook for the Endpoint type.
+    3. Follow the instructions for the particular service.
+    4. Back on the Create Event Subscription page, select Create.
+
+To send events to your topic, please follow the instructions in this article.
+
+### Set up an event handler
+
+Go to your Azure subscription and spin up a service that is supported as an event handler. For a full list of supported event handlers, see [Microsoft's Event Handlers in Azure Event Grid](https://docs.microsoft.com/en-us/azure/event-grid/event-handlers).
+
+## Testing
+
+At this point, your Event Grid workflow should be complete.
+
+### Verify the integration
+
+To verify that the integration is working as expected:
+
+1. Log in to the [Auth0 Dashboard](${manage_url}).
+2. Navigate to **Logs > Streams**.
+3. Click on your Event Grid stream.
+4. Once on the stream, click the **Health** tab. The stream should be active and as long as you don't see any errors, the stream is working.
+
+## Delivery attempts and retries
+
+Auth0 events are delivered to your server via a streaming mechanism that sends each event as it is triggered. If your server is unable to receive the event, Auth0 will try to redeliver it up to three times. If still unsuccessful, Auth0 will log the failure to deliver, and you will be able see these failures in the Health tab for your log stream.
+
+## More on Log Streams
+
+::: next-steps
+* [HTTP Event Log Streams](/logs/streams/http-event)
+* [Example: Stream Auth0 Log Events to Slack](/logs/streams/http-event-to-slack)
+* [Amazon EventBridge Log Streams](/logs/streams/amazon-eventbridge)
+* [Datadog Event Log Streams](/logs/streams/datadog)
+:::
diff --git a/ja-jp/articles/logs/streams/datadog.md b/ja-jp/articles/logs/streams/datadog.md
new file mode 100644
index 0000000000..6cac684506
--- /dev/null
+++ b/ja-jp/articles/logs/streams/datadog.md
@@ -0,0 +1,96 @@
+---
+title: Datadog Log Streams
+description: Learn how to export your log events in near real-time to Datadog.
+toc: false
+topics:
+ - logs
+ - streams
+ - event-streams
+contentType: how-to
+---
+
+# Datadog Log Streams
+
+Datadog is a monitoring platform for cloud applications. It brings together data from servers, containers, databases, and third-party services to make your stack entirely observable. You can use it to create monitoring, alerting, and analysis dashboards for Auth0 tenants.
+
+## Prerequisites
+
+To send Auth0 events to Datadog, you will need:
+
+* a `Log Management` plan with Datadog. See [Datadog plans](https://www.datadoghq.com/pricing/).
+* a Datadog API Key. See below.
+* your Datadog dashboard region.
+
+## Steps
+
+To send Auth0 events to Datadog, you will need to:
+
+1. Copy your API Key from Datadog
+2. Set up an Event Stream in Auth0
+
+### Copy API Key from Datadog
+
+1. Log in to the Datadog dashboard.
+2. Navigate to **Integrations** > **APIs**.
+![Integrations Dashboard](/media/articles/logs/datadog/tutorial-1.png)
+3. Expand the API Keys section, and copy the API Key that you would like to use.
+![API Keys Section](/media/articles/logs/datadog/tutorial-2.png)
+
+### Set up Event Stream in Auth0
+
+1. Log in to the [Auth0 Dashboard](${manage_url}).
+2. Navigate to **Logs > Streams**.
+3. Click **+ Create Stream**.
+4. Select **Datadog**, and enter a unique name for your new Datadog Event Stream.
+5. On the next screen, provide the following settings for your Datadog Event Stream:
+
+| Setting | Description |
+|---------|-------------|
+| API Key | The Datadog API key you copied from the Datadog dashboard. |
+| Region  | If you are in the Datadog EU site (app.datadoghq.eu), the `Region` should be `EU`; otherwise, it should be `US`. |
+
+![Datadog Settings Form](/media/articles/logs/datadog/tutorial-3.png)
+
+6. Click **Save**.
+7. You're done! When Auth0 writes the next log event, you'll receive a copy of that log event in Datadog with the `source` and `service` set to `auth0`.
+
+### View logs in Datadog
+
+1. Navigate to **Logs** > **Livetail**.
+2. See Auth0 logs by setting the `source` to `auth0`.
+![Datadog Logs Dashboard](/media/articles/logs/datadog/tutorial-4.png)
+
+## Delivery attempts and retries
+
+Auth0 events are delivered to your server via a streaming mechanism that sends each event as it is triggered. If your server is unable to receive the event, Auth0 will retry delivering it up to three times. If still unsuccessful, Auth0 will log the failure, and you will see these failure in the **Health** tab for your log stream.
+
+## Enhancement to log data
+
+One of the unique values of Datadog as a monitoring tool, specifically when it comes to integrations, is the data enhancement they provide to ensure customers can rely on receiving specific data fields regardless of the system with which they are integrating. As part of this Auth0 Log Streaming integration, Datadog has enhanced our data. The following new fields can be found in our logs when using the Log Streaming integration with Datadog:
+
+| Fields | Auth0 attribute |
+|---------|-------------|
+| Official Log date | `data.date` |
+| `network.client.ip` | `data.ip` |
+| `network.client.geoip` |	`data.ip` (parsed) |
+| `http.useragent` |	`data.user_agent` |
+| `http.useragent_details` |	`data.user_agent` (parsed) |
+| `usr.id` |	`data.user_name` |
+| `usr.name` |	`data.user_name` |
+| `usr.email` |	`data.details.request.auth.user.email` (when available) |
+| `data.type` | `evt.name` |
+| `message` |	Event description (For a list of descriptions, see [Log Event Type Codes](/logs/references/log-event-type-codes).) |
+
+To learn more about Datadog transformations, see:
+
+* For US: [Datadog US Log Pipelines](https://app.datadoghq.com/logs/pipelines)
+* For EU: [Datadog EU Log Pipelines](https://app.datadoghq.EU/logs/pipelines)
+
+## More on Log Streams
+
+::: next-steps
+* [HTTP Event Log Streams](/logs/streams/http-event)
+* [Example: Stream Auth0 Log Events to Slack](/logs/streams/http-event-to-slack)
+* [Amazon EventBridge Log Streams](/logs/streams/amazon-eventbridge)
+* [Azure Event Grid Log Streams](/logs/streams/azure-event-grid)
+:::
diff --git a/ja-jp/articles/logs/streams/http-event-to-slack.md b/ja-jp/articles/logs/streams/http-event-to-slack.md
new file mode 100644
index 0000000000..2b245b2d37
--- /dev/null
+++ b/ja-jp/articles/logs/streams/http-event-to-slack.md
@@ -0,0 +1,188 @@
+---
+title: Stream Auth0 Log Events to Slack
+description: Use the HTTP Event Log Streams to send failed events to Slack.
+toc: false
+topics:
+  - logs
+  - streams
+  - event-streams
+  - http-event
+  - Slack
+contentType: how-to
+---
+
+# Send Auth0 Failed Log Events to Slack
+
+This guide explains how to use [Auth0 Log Streaming](/logs/streams) to send specific logged events to Slack. The events sent in this guide include all failures (e.g., logins, signups, token exchange) and limits (e.g., rate limits, anomaly detection).
+
+Using this guide, you will build the following:
+
+![Stream Auth0 Log Events to Slack](/media/articles/logs/log-stream-to-slack-diagram.png)
+
+1. Application 1 and 2 both redirect to Auth0 to log in
+2. The login for Application 2 succeeds, but the login for Application 1 fails; both events create a distinct log record
+3. Both applications receive a response from Auth0
+4. These log events are sent together in a JSON payload to the custom webhook
+5. The webhook filters out the successful event
+6. The webhook sends the failed event to Slack
+
+To learn how to adjust the filter used here for different scenarios, see our [Log Event Type Codes](/logs/references/log-event-type-codes) reference.
+
+## What is Slack
+
+Slack is a business communication platform that can be extended using custom applications. Many companies, including Auth0, use Slack for general team communication as well as a notification platform.
+
+## Get started with Slack
+
+Go to [Slack API Applications](https://api.slack.com/apps), and log in to your Slack account. Follow instructions in the [Incoming Webhooks for Slack](https://slack.com/help/articles/115005265063-Incoming-Webhooks-for-Slack) guide to create a Slack endpoint that will accept the failed log events. Make sure to leave your browser tab open or copy the URL provided as you'll need that later in this guide.
+
+## Deploy the webhook
+
+You'll build a simple Express API that provides a single `/api/logs` route accepting POST requests. When any log event happens, it will be sent to this endpoint. If the request is formatted properly, the log events for failures will be parsed and sent to Slack.
+
+ Start with a simple Express application:
+
+```js
+// app.js
+require("dotenv").config();
+
+const express = require("express");
+const http = require("http");
+
+const app = express();
+app.use(express.json());
+
+app.post("/api/logs", require("./api/logs"));
+
+const port = process.env.PORT || 3000;
+http.createServer(app).listen(port, () => {
+  console.log(`Listening on port <%= "${port}" %>`);
+});
+```
+
+Then add the endpoint middleware:
+
+```js
+// api/logs/index.js
+const got = require("got");
+
+module.exports = async (req, res, next) => {
+  const { body, headers } = req;
+
+  if (!body || !Array.isArray(body)) {
+    return res.sendStatus(400);
+  }
+
+  if (headers.authorization !== process.env.AUTH0_LOG_STREAM_TOKEN) {
+    return res.sendStatus(401);
+  }
+
+  const failedLogs = body.filter((log) => {
+    return "f" === log.data.type[0] || /limit/.test(log.data.type);
+  });
+
+  if (failedLogs.length === 0) {
+    return res.sendStatus(204);
+  }
+
+  const reqUrl = process.env.SLACK_WEBHOOK_URL;
+  const reqOpts = {
+    json: {
+      attachments: failedLogs.map((log) => {
+        return {
+          pretext: "*Auth0 log alert*",
+          title: `<%= " ${log.data.description}" %> [type: <%= "${log.data.type}" %>]`,
+          color: "#ff0000",
+          title_link: `https://manage.auth0.com/#/logs/<%= "${log.data.log_id}" %>`
+        };
+      }),
+    },
+  };
+
+  try {
+    const slackResponse = await got.post(reqUrl, reqOpts);
+    res.status(slackResponse.statusCode);
+    return res.end(slackResponse.body);
+  } catch (error) {
+    next(error);
+  }
+};
+```
+
+Finally, add the NPM package file:
+
+```json
+// package.json
+{
+  "dependencies": {
+    "dotenv": "^8.2.0",
+    "express": "^4.17.1",
+    "got": "^10.7.0"
+  },
+  "scripts": {
+    "start": "node app.js",
+  }
+}
+```
+
+To configure this application, you'll also need the following environment variables:
+
+- `SLACK_WEBHOOK_URL`: The URL provided by Slack for your incoming webhook application.
+- `AUTH0_LOG_STREAM_TOKEN`: Optional, but recommended. A long, random string used to protect the endpoint from unauthorized requests. You will use this value in the Auth0 configuration steps below as well.
+
+If you are testing this locally or hosting this endpoint yourself, these can be saved in a `.env` file in the application's root directory. For hosting providers like Heroku, Dokku, and similar, consult the platform's documentation for the correct way to deploy these.
+
+Once configured locally or deployed to your host, you can test the endpoint and its connection to Slack with the following:
+
+```bash
+npm install # If running yourself
+added XX packages from XX contributors in XX.XXs
+
+npm start # If running yourself 
+Listening on port 3000
+
+# Replace the Authorization header below
+curl \
+  --header "Authorization: AUTH0_LOG_STREAM_TOKEN_VALUE" \
+  --header "Content-Type: application/json" \
+  --request POST \
+  --data '[{"data": {"type": "f", "description": "Test failure", "client_id": "TestClientId", "client_name": "Test Client Name", "log_id": "abc1234567890"}}]' \
+  http://localhost:3000/api/logs
+ok
+```
+
+The `ok` above signals that the request was accepted and processed correctly. In Slack, you should see the following message in the channel you configured:
+
+![Stream Auth0 Log Events to Slack](/media/articles/logs/log-stream-to-slack-message.png)
+
+## Configure an Auth0 log stream
+
+The final step is to configure Auth0 to send log events to this webhook using an HTTP event stream.
+
+To create a new stream poinint to your deployed Express application, follow the instructions in [HTTP Event](/logs/streams/http-event). Use the following field values:
+
+- **Payload URL**: URL to your deployed webhook like `https://[host domain]/api/logs`
+- **Authorization Token**: Value configured above
+- **Content Type**: Use "application/json"
+- **Content Format**: Use "JSON Array"
+
+Once this is saved, your log stream is ready to use. To test, you'll need to trigger a failing log event. The simplest way to do that is to attempt to log in with an incorrect email or password. If the stream is configured correctly, you should see a Slack message saying:
+
+`Wrong email or password. [type: fu]`
+
+## Troubleshoot
+
+If you're not seeing the Slack message appear after several seconds, you'll need to walk down the same path a log event would:
+
+1. Check the Dashboard **Logs > Search** screen to make sure the record is there.
+2. Check the **Health** tab for the stream ([delivery attempts and retries](/logs/streams/http-event#delivery-attempts-and-retries)).
+3. If the webhook delivery is succeeding, check the logs for your deployed application.
+
+## More on Log Streams
+
+::: next-steps
+* [HTTP Event Log Streams](/logs/streams/http-event)
+* [Amazon EventBridge Log Streams](/logs/streams/amazon-eventbridge)
+* [Datadog Event Log Streams](/logs/streams/datadog)
+* [Azure Event Grid Log Streams](/logs/streams/azure-event-grid)
+:::
diff --git a/ja-jp/articles/logs/streams/http-event.md b/ja-jp/articles/logs/streams/http-event.md
new file mode 100644
index 0000000000..a12963907c
--- /dev/null
+++ b/ja-jp/articles/logs/streams/http-event.md
@@ -0,0 +1,52 @@
+---
+title: HTTP Event Log Streams
+description: HTTP Event Log Streams let you export your events in near real-time to your own server.
+toc: false
+topics:
+ - logs
+ - streams
+ - event-streams
+ - http-event
+contentType: how-to
+---
+
+# HTTP Event Log Streams
+
+HTTP Event Log Streams let you export your log events to the server or target of your choice. When Auth0 creates a log entry for your tenant, a copy is automatically sent to a given URL via an HTTP POST request.
+
+If you use Amazon Web Services, Auth0 also offers an [AWS EventBridge integration](/logs/streams/amazon-eventbridge).
+
+See our example [HTTP Event Log Stream example using Slack](/logs/streams/http-event-to-slack).
+
+## Create an HTTP Event Stream
+
+1. Log in to the [Auth0 Dashboard](${manage_url}).
+2. Navigate to **Logs > Streams**.
+3. Click **+ Create Stream**.
+4. Select **Custom Webhook** and enter a unique name for your new HTTP Event Stream.
+5. On the next screen, provide the following settings for your HTTP Event Stream:
+
+| Setting | Description |
+|---------|-------------|
+| Name | A unique display name to distinguish this integration from other integrations |
+| Payload URL | The URL where the event payloads are sent as HTTP POST requests. |
+| Authorization Token | (Optional) Set in the Authorization header of the request if provided. |
+| Content Type | The media type of the payload that will be delivered to the webhook. |
+
+![Create a new HTTP Event Log Stream](/media/articles/logs/http-event-stream.png)
+
+6. Click **Save**.
+7. You're done! Now when Auth0 writes the next tenant log, you'll receive a copy of that log event as a POST request at the `Payload URL` you provided.
+
+## Delivery attempts and retries
+
+Auth0 events are delivered to your server via a streaming mechanism that sends each event as it is triggered in our system. If your server is unable to receive the event, we will retry up to three times to deliver the event; otherwise, we will log the failure to deliver in our system, and you will be able see these failures in the Health tab for your log stream.
+
+## More on Log Streams
+
+::: next-steps
+* [Example: Stream Auth0 Log Events to Slack](/logs/streams/http-event-to-slack)
+* [Amazon EventBridge Log Streams](/logs/streams/amazon-eventbridge)
+* [Datadog Event Log Streams](/logs/streams/datadog)
+* [Azure Event Grid Log Streams](/logs/streams/azure-event-grid)
+:::
diff --git a/ja-jp/articles/logs/streams/index.md b/ja-jp/articles/logs/streams/index.md
new file mode 100644
index 0000000000..73403ee075
--- /dev/null
+++ b/ja-jp/articles/logs/streams/index.md
@@ -0,0 +1,52 @@
+---
+title: Log Streams
+description: Learn about using Log Streams to export your log events in near real-time.
+classes: topic-page
+toc: false
+topics:
+ - logs
+ - streams
+ - event-streams
+contentType: index
+---
+
+# Log Streams
+
+Log Streams let you export your log events to a target of your choice given URL or one of our integrations. With Log Streams you can:
+
+* export logs to a tool or service you already use
+* react to events, such as changed passwords or new registrations, with your own business logic by sending log events to custom webhooks
+* send events to Amazon EventBridge or Azure Event Grid
+
+## Log Stream Health
+
+You can troubleshoot potential issues with your stream by looking in the `Health` tab.
+
+1. Log in to the [Auth0 Dashboard](${manage_url}).
+2. Navigate to **Logs > Streams**.
+3. Click on a stream.
+4. Select the **Health** tab.
+
+## Log Stream Status
+
+| Status | Description |
+|---------|-------------|
+| Active  | Your stream is enabled with us, and we will attempt to deliver the next log events. |
+| Paused  | You have requested that we stop delivery attempts for the stream. You may click the `Resume Stream` option at any time to change the status back to `Active`. |
+| Disabled | We have disabled your stream because of successive errors. You may click the `Restart Stream` option at any time to change the status back to `Active` and re-attempt delivery for this stream. |
+
+![Pause a Stream](/media/articles/logs/health/pause-a-stream.png)
+
+## Delivery Errors
+
+To help diagnose issues with your stream, you can see the last ten errors we encountered while attempting to deliver logs to your stream within the last 5 days.
+
+![Stream Errors](/media/articles/logs/health/health-errors.png)
+
+<%= include('../../_includes/_topic-links', { links: [
+  'logs/streams/http-event',
+  'logs/streams/http-event-to-slack',
+  'logs/streams/amazon-eventbridge',
+  'logs/streams/datadog',
+  'logs/streams/azure-event-grid'
+] }) %>
diff --git a/ja-jp/articles/mfa/_includes/_authenticator-before-start.md b/ja-jp/articles/mfa/_includes/_authenticator-before-start.md
new file mode 100644
index 0000000000..89d496c5ea
--- /dev/null
+++ b/ja-jp/articles/mfa/_includes/_authenticator-before-start.md
@@ -0,0 +1,3 @@
+## Prerequisite
+
+Before you can use the MFA APIs, you'll need to enable the MFA grant type for your application. You can enable the MFA grant by going to [Applications > Your Application > Advanced Settings > Grant Types](${manage_url}/#/applications) and selecting MFA.
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/_includes/_configure-sns.md b/ja-jp/articles/mfa/_includes/_configure-sns.md
new file mode 100644
index 0000000000..75d826d044
--- /dev/null
+++ b/ja-jp/articles/mfa/_includes/_configure-sns.md
@@ -0,0 +1,3 @@
+## Configure SNS for native apps
+
+For your native application to receive push notifications from Guardian, you will need to override the default SNS settings. See [Configure Push Notifications for MFA](/mfa/guides/configure-push) for details.
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/_includes/_enable-push-notifications.md b/ja-jp/articles/mfa/_includes/_enable-push-notifications.md
new file mode 100644
index 0000000000..82be4f2aea
--- /dev/null
+++ b/ja-jp/articles/mfa/_includes/_enable-push-notifications.md
@@ -0,0 +1,7 @@
+## Enable Guardian push notifications
+
+1. To enable Guardian push notifications for your users, go to the [Multi-factor Auth](${manage_url}/#/guardian) section of the Dashboard. 
+
+2. Toggle the **Push Notification** slider to enable it.
+
+![Enable Push Notifications](/media/articles/mfa/mfa-dashboard.png)
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/_includes/_get_mfa_token.md b/ja-jp/articles/mfa/_includes/_get_mfa_token.md
new file mode 100644
index 0000000000..eda25ae672
--- /dev/null
+++ b/ja-jp/articles/mfa/_includes/_get_mfa_token.md
@@ -0,0 +1,5 @@
+Depending on when you are triggering enrollment, you can obtain an access token for using the MFA API in different ways: 
+
+- If you are enrolling during authentication, check [Authenticate With Resource Owner Password Grant and MFA](/mfa/guides/mfa-api/authenticate).
+
+- If you want to let the user enroll a factor at any moment, check [Managing MFA Enrollments](/mfa/guides/mfa-api/manage).
diff --git a/ja-jp/articles/mfa/_includes/_get_mfa_token_challenge.md b/ja-jp/articles/mfa/_includes/_get_mfa_token_challenge.md
new file mode 100644
index 0000000000..b0d61e66c7
--- /dev/null
+++ b/ja-jp/articles/mfa/_includes/_get_mfa_token_challenge.md
@@ -0,0 +1 @@
+Get an MFA token following the steps described in the [Authenticate With Resource Owner Password Grant and MFA](/mfa/guides/mfa-api/authenticate) document.
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/_includes/_recovery_codes.md b/ja-jp/articles/mfa/_includes/_recovery_codes.md
new file mode 100644
index 0000000000..e5f6ab8dc8
--- /dev/null
+++ b/ja-jp/articles/mfa/_includes/_recovery_codes.md
@@ -0,0 +1 @@
+If this is the first time the user is associating an authenticator, you'll notice the response includes `recovery_codes`. Recovery codes are used to access the user's account in the event that they lose access to the account or device used for their second factor authentication. These are one-time usable codes, and new ones are generated as necessary.
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/_includes/_request_association.md b/ja-jp/articles/mfa/_includes/_request_association.md
new file mode 100644
index 0000000000..7d7ce5babc
--- /dev/null
+++ b/ja-jp/articles/mfa/_includes/_request_association.md
@@ -0,0 +1 @@
+Make a `POST` request to the `/mfa/associate` endpoint to enroll the user's authenticator. The Bearer Token required by this endpoint is the MFA token obtained in the previous step.
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/_includes/_successful_challenge.md b/ja-jp/articles/mfa/_includes/_successful_challenge.md
new file mode 100644
index 0000000000..c68b5367db
--- /dev/null
+++ b/ja-jp/articles/mfa/_includes/_successful_challenge.md
@@ -0,0 +1,11 @@
+If the call was successful, you'll receive a response in the below format, containing the Access Token:
+
+```
+{
+  "id_token": "eyJ...i",
+  "access_token": "eyJ...i",
+  "expires_in": 600,
+  "scope": "openid profile",
+  "token_type": "Bearer"
+}
+```
diff --git a/ja-jp/articles/mfa/_includes/_successful_confirmation.md b/ja-jp/articles/mfa/_includes/_successful_confirmation.md
new file mode 100644
index 0000000000..1159ca96d2
--- /dev/null
+++ b/ja-jp/articles/mfa/_includes/_successful_confirmation.md
@@ -0,0 +1,15 @@
+If the call was successful, you'll receive a response in the below format, containing the Access Token:
+
+```
+{
+  "id_token": "eyJ...i",
+  "access_token": "eyJ...i",
+  "expires_in": 600,
+  "scope": "openid profile",
+  "token_type": "Bearer"
+}
+```
+
+At this point, the authenticator is fully associated and ready to be used, and you have the authentication tokens for the user.
+
+You can check at any point to verify whether an authenticator has been confirmed by calling the [`mfa/authenticators` endpoint](/mfa/guides/mfa-api/manage#list-authenticators). If the authenticator is confirmed, the value returned for `active` is `true`.
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/_includes/_test-setup.md b/ja-jp/articles/mfa/_includes/_test-setup.md
new file mode 100644
index 0000000000..ea25a2a065
--- /dev/null
+++ b/ja-jp/articles/mfa/_includes/_test-setup.md
@@ -0,0 +1,3 @@
+::: warning
+The following steps will add text-message-based multi-factor to the login flow for the tenant in which you're working. We **highly** recommend testing this setup on a [staging or development server](/dev-lifecycle/setting-up-env) before making the changes to your production login flow.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/concepts/guardian.md b/ja-jp/articles/mfa/concepts/guardian.md
new file mode 100644
index 0000000000..65d97d5a10
--- /dev/null
+++ b/ja-jp/articles/mfa/concepts/guardian.md
@@ -0,0 +1,96 @@
+---
+title: Auth0 Guardian
+description: Understand how Guardian works and how Guardian SDK helps you build your own authenticator and Guardian-like applications.
+topics:
+  - mfa
+  - guardian
+  - android
+  - iOS
+contentType:
+  - concept
+useCase:
+  - customize-mfa
+---
+# Auth0 Guardian
+
+Auth0 multi-factor authentication (MFA) supports these authentication factors:
+
+* One-time password (OTP)
+* SMS
+* Voice
+* Push
+* Duo
+* Email
+
+Auth0 Guardian is a mobile app that can deliver push notifications to a user’s pre-registered device - typically a mobile phone or tablet - from which a user can immediately allow or deny account access via the press of a button. It can also generate one-time passwords if that factor is preferred.
+
+The push factor is offered with the Guardian mobile app, available for both iOS and Android. In addition, the technology is also available as whitelabelled Guardian SDK which can be used in custom mobile applications to act as second factor push responder. 
+
+Auth0 Guardian is available on ([Google Play](https://play.google.com/store/apps/details?id=com.auth0.guardian) and the [App Store](https://itunes.apple.com/us/app/auth0-guardian/id1093447833?mt=8)).
+
+::: note
+See the documentation for [Apple Push Notification service (APNs)](https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/APNSOverview.html) for details on setting up APNs. 
+:::
+
+## How it works
+
+Instead of integrating with each vendor-specific push notification service, Auth0 push notification is implemented using AWS Simple Notification Service (SNS) which handles the vendor specific integration. 
+
+![Guardian Functionality](/media/articles/mfa/guardian-functionality.png)
+
+## Guardian and push notifications
+
+When enabling push, end-users will need to have Auth0 Guardian or a custom application built with the Guardian SDK installed in their device. The app is sent push notifications when the user attempts to authenticate, and the user must respond to it in order to login, ensuring that they not only know their login information but also possess the device set up for MFA.
+
+End users will be prompted to download Auth0 Guardian when trying to sign up or log in to your application. Once they indicate that they have successfully downloaded the app, a QR code will appear on screen. They will have a short amount of time in which to scan the code with the designated app. Once this is done, they should see a confirmation screen.
+
+Once this is all set up, when the user attempts to authenticate as normal, their device will receive a push notification via the app, and once they approve the request, they will be logged in.
+
+
      Guardian Push
      
+
+## Guardian and One-Time Passwords
+
+![MFA OTP Signup](/media/articles/mfa/mfa-otp-setup.png)
+
+Upon signup, they can scan a code and set up the app, upon which it will begin generating one-time codes. 
+
+Afterwards, when logging in to the app, the user can simply check the authenticator app for the current one-time code:
+
+
      Google Authenticator OTP
      
+
+And enter the code at the prompt:
+
+![MFA OTP Login](/media/articles/mfa/mfa-otp-login.png)
+
+Your users will need to have an OTP Authenticator app installed in their mobile devices.
+
+## Guardian SDKs
+
+You can [install the Guardian SDK](/mfa/guides/guardian/install-guardian-sdk), available for [iOS](/mfa/guides/guardian/configure-guardian-ios) and [Android](/mfa/guides/guardian/configure-guardian-android) to build your own whitelabel multi-factor authentication application with complete control over the branding and look-and-feel.
+
+With the Guardian SDK, you can build your own custom mobile applications that works like Guardian or integrate some Guardian functionalities, such as receiving push notifications in your existing mobile applications.
+
+A typical scenario could be for a banking app. You can use the Guardian SDK in your existing mobile app to receive and confirm push notifications when someone performs an ATM transaction.
+
+See [auth0-guardian.js](https://github.com/auth0/auth0-guardian.js) for more information.
+
+## Migration to Firebase Cloud Messaging
+
+Auth0’s Guardian SDKs for iOS and Android help you create custom mobile apps with Guardian functionality, providing secure access to multi-factor authentication (MFA) with push notifications. 
+
+The [Android SDK](/mfa/guides/guardian/guardian-android-sdk) library was built to send push notifications using Google Cloud Messaging, which [Google deprecated](https://firebase.googleblog.com/2018/04/time-to-upgrade-from-gcm-to-fcm.html) and replaced with Firebase Cloud Messaging. Google Cloud Messaging will stop working on April 11th 2019. **Note that existing applications should [keep working as-is](https://aws.amazon.com/blogs/messaging-and-targeting/the-end-of-google-cloud-messaging-and-what-it-means-for-your-apps/)**.
+
+You can learn more about how to migrate from GCM to FCM by following [Google’s documentation](https://developers.google.com/cloud-messaging/android/android-migrate-fcm).
+
+The main difference between sending notifications to GCM and to FCM is the payload received in the notification. While it was previously possible for customers using the Android SDK to adapt the payload received before calling the SDK method, we have upgraded the library to accept the new payload, making it simpler to adopt FCM. 
+
+The Guardian Android SDK 0.4.0 version is available in Maven Central and includes this change. The sample application was also upgraded, so it can be tested by providing the google-services.json file and a guardian-url. 
+
+## Keep reading
+
+* [Configure Push Notifications for MFA](/mfa/guides/configure-push)
+* [Create Custom Enrollment Tickets](/mfa/guides/guardian/create-enrollment-ticket)
+* [Guardian Error Code Reference](/mfa/references/guardian-error-code-reference)
+* [Auth0 Management API](/api/management/v2)
+* [Getting Started with Apple Push Notification Service](https://docs.aws.amazon.com/sns/latest/dg/mobile-push-apns.html)
+* [Getting Started with Firebase Cloud Messaging for Android](https://docs.aws.amazon.com/sns/latest/dg/sns-mobile-application-as-subscriber.html)
diff --git a/ja-jp/articles/mfa/concepts/mfa-api.md b/ja-jp/articles/mfa/concepts/mfa-api.md
new file mode 100644
index 0000000000..6154ac2805
--- /dev/null
+++ b/ja-jp/articles/mfa/concepts/mfa-api.md
@@ -0,0 +1,31 @@
+---
+title: Multi-factor Authentication API
+description: Overview of available multi-factor authentication APIs
+topics:
+  - mfa
+  - mfa-api
+contentType:
+  - index
+useCase:
+  - customize-mfa
+---
+# Multi-factor Authentication API
+
+Auth0 provides a built-in Multi-factor Authentication (MFA) enrollment and authentication flow using [Universal Login](/universal-login).
+
+You will need to use the MFA API in the following scenarios:
+
+- If you are [authenticating users with the Resource Owner Password Grant](/mfa/guides/mfa-api/authenticate).
+
+- If you want to build an interface to let users [manage their authentication factors](/mfa/guides/mfa-api/manage).
+
+<%= include('../_includes/_authenticator-before-start') %>
+
+## Limitations
+
+The MFA API is designed to work with SMS, Push via Guardian, Email, and OTP factors. It does not currently support enrolling with Duo or with the legacy 'google-authenticator' factor (Google Authenticator can still be enrolled using the OTP factor).
+
+## Keep reading
+
+* [Authenticate With Resource Owner Password Grant and MFA](/mfa/guides/mfa-api/authenticate)
+* [Manage Authenticator Factors using the MFA API](/mfa/guides/mfa-api/manage)
diff --git a/ja-jp/articles/mfa/concepts/mfa-developer-resources.md b/ja-jp/articles/mfa/concepts/mfa-developer-resources.md
new file mode 100644
index 0000000000..735ce8aee0
--- /dev/null
+++ b/ja-jp/articles/mfa/concepts/mfa-developer-resources.md
@@ -0,0 +1,35 @@
+---
+description: Learn about developer resources such as the Auth0 MFA API and the Guardian SDKs for MFA.
+topics:
+  - mfa
+  - guardian
+contentType:
+  - index
+useCase:
+  - customize-mfa
+---
+# Developer Resources for Multi-factor Authentication
+
+Using Auth0 SDKs, you can customize your users' multi-factor authentication (MFA) experience and even build applications on top of our multi-factor capabilities.
+
+## MFA API
+
+[MFA API](/mfa/concepts/mfa-api) endpoints allow you to enforce MFA when users interact with [the Token endpoints](/api/authentication#get-token), as well enroll and manage MFA factors.
+
+## Customize the multi-factor authentication page
+
+Use the following client libraries to customize the look-and-feel of the MFA page so it matches your organization.
+
+* [Client library for Auth0 MFA](https://github.com/auth0/auth0-guardian.js)
+* [Creating a Custom MFA Widget](https://github.com/auth0/auth0-guardian.js/tree/master/example)
+
+## Manage enrollments
+
+You can [customise the enrollment](/mfa/guides/guardian/create-enrollment-ticket) process for your users.
+
+## Build custom mobile applications
+
+Build custom _white-label_ Guardian-like applications, or add multi-factor functionality into your applications.
+
+* [Guardian for Android](/mfa/guides/guardian/guardian-android-sdk)
+* [Guardian for iOS](/mfa/guides/guardian/guardian-ios-sdk)
diff --git a/ja-jp/articles/mfa/concepts/mfa-factors.md b/ja-jp/articles/mfa/concepts/mfa-factors.md
new file mode 100644
index 0000000000..26141b8f56
--- /dev/null
+++ b/ja-jp/articles/mfa/concepts/mfa-factors.md
@@ -0,0 +1,77 @@
+---
+description: Understand how MFA works in Auth0, the authentication factors, policies and use cases.
+toc: true 
+topics:
+    - mfa
+contentType:
+  - concept
+useCase:
+  - customize-mfa
+---
+# Multi-factor Authentication Factors
+
+Auth0 supports a number of different options when it comes to enabling MFA for protecting user account access. An MFA workflow is typically provided via a separate application that runs on a mobile or tablet device. 
+
+If you don’t want your customers to have to download a separate application, Auth0 also provides an [SDK](/mfa/guides/guardian/install-guardian-sdk) that you can use to build a second factor workflow in your existing mobile device app.
+
+On the [Dashboard > Multifactor Auth](${manage_url}/#/mfa) page, you can select the factors to use for MFA for your tenant. 
+
+![MFA Dashboard Page](/media/articles/mfa/mfa-dashboard.png)
+
+Auth0 supports the following factors for implementing MFA. You must enable at least one to use MFA, but you can choose to enable and make available more than one factor if you wish. Available factors are dependent on your subscription plan.
+
+## Push notifications
+
+Send users push notifications to a their pre-registered devices - typically a mobile phone or tablet - from which a user can immediately allow or deny account access via the simple press of a button. Push factor is offered with the [Guardian](/mfa/concepts/guardian) mobile app, available for both [iOS](/mfa/guides/guardian/guardian-ios-sdk) and [Android](/mfa/guides/guardian/guardian-android-sdk). 
+
+## SMS notifications
+
+[Send users a one-time code over SMS](/mfa/guides/configure-phone) which the user is then prompted to enter before they can finish authenticating.
+
+## Voice notifications
+
+[Deliver users a one-time code through a voice call](/mfa/guides/configure-phone) which the user is then prompted to enter before they can finish authenticating.
+
+## One-Time passwords
+
+[One-Time Password (OTP)](/mfa/guides/configure-otp) allows you to use an Authenticator application in your personal device - such as Google Authenticator - that will generate a one-time password which changes over time and which can be entered as the second factor to validate a user’s account.
+
+## Email notifications
+
+You can [use email](/mfa/guides/configure-email) when you want to provide users a way to perform MFA when they don't have their phone to receive an SMS or push notification.
+
+## Duo Security
+
+[Duo](/mfa/guides/configure-cisco-duo) is a multi-faceted provider and can only be used if it's the only factor available for the user. Use your Duo account to manage MFA with Auth0. 
+
+## Policies
+
+Policies determine when a user will be prompted to complete additional steps to prove they own a particular account. Use policies to define your own level of acceptable risk. You can choose between **Never** and **Always**. 
+
+You can achieve more refined multifactor configurations (such as per application, per user, etc.) by using [Rules](/rules/references/use-cases#multi-factor-authentication). 
+
+::: note
+Rules affecting MFA take precedence over the policy configuration in the Dashboard.
+:::
+
+## MFA use cases
+
+There are different ways to manage MFA depending on your environment: 
+
+* B2B: Your customers manage MFA factors for their users.
+* B2C: End users manage their own MFA factors via the My MFA Settings Page.
+* B2E: You manage MFA factors for your users.
+
+To learn about the API endpoints you can use to build a user interface that allows users to manage MFA factors, see [Manage Authenticator Factors using the MFA API](/mfa/guides/mfa-api/manage).
+
+Applications that allow access to different types of resources can require users to authenticate with a stronger authentication mechanism to access sensitive resources. For details, see [Step-Up Authentication](/mfa/concepts/step-up-authentication). 
+
+You can configure a rule in **Dashboard > Rules** to define the conditions that will trigger additional authentication challenges. Use rules to force MFA for users of certain applications, or for users with particular user metadata or IP ranges, among other triggers.
+
+Add contextual MFA which allows you to define arbitrary conditions that will trigger additional authentication challenges to your customers for increased security, for example, geographic location (geo-fencing), address or type of network used (IP filtering), time of day, day of the week or change in the location or device being used to log in.
+
+## Keep reading
+
+* [Enable MFA](/mfa/guides/enable-mfa)
+* [Configure Push Notifications for MFA](/mfa/guides/configure-push)
+* [Developer Resources for Multi-factor Authentication](/mfa/concepts/mfa-developer-resources)
diff --git a/ja-jp/articles/mfa/concepts/step-up-authentication.md b/ja-jp/articles/mfa/concepts/step-up-authentication.md
new file mode 100644
index 0000000000..ce09fe0084
--- /dev/null
+++ b/ja-jp/articles/mfa/concepts/step-up-authentication.md
@@ -0,0 +1,57 @@
+---
+description: Understand how step-up authentication works for APIs and web apps to verify that the user has logged in using MFA and if not, require the user to step-up to access certain resources. 
+topics:
+  - mfa
+  - step-up-authentication
+contentType:
+  - concept
+useCase:
+  - customize-mfa
+---
+# Step-up Authentication
+
+With step-up authentication, applications that allow access to different types of resources can require users to authenticate with a stronger authentication mechanism to access sensitive resources.
+
+For example, Fabrikam's Intranet requires users to authenticate with their username and password to access customer data. However, a request for access to employee data (which may contain sensitive salary information) triggers a stronger authentication mechanism like multi-factor authentication (MFA).
+
+You can add step-up authentication to your app with Auth0's extensible multi-factor authentication support. Your app can verify that the user has logged in using multi-factor authentication (MFA) and, if not, require the user to step-up to access certain resources.
+
+![Step-up flow](/media/articles/mfa/step-up-flow.png)
+
+## Step-up Authentication for APIs
+
+When your audience is an API, you can implement step-up authentication with Auth0 using scopes, Access Tokens and [Rules](/rules/references/use-cases#multi-factor-authentication).
+
+::: note
+An Access Token is a credential you can use to access an API. The actions that you can perform to that API are defined by the scopes your Access Token includes. The rules are JavaScript functions you can use to run custom logic when a user authenticates.
+:::
+
+You can use a rule to trigger the step-up authentication mechanism (for example, prompt MFA) whenever the user requests scopes that map to sensitive resources.
+
+This is best explained with an example.
+
+A user signs into Fabrikam's web app. The standard login gives to this user the ability to interact with their API and fetch the users account list. This means that the Access Token that the application receives after the user authentication contains a scope like `read:accounts`.
+
+Now the user wishes to transfer funds from one account to another, which is deemed a high-value transaction. In order to perform this action, the API requires the scope `transfer:funds`.
+
+The Access Token that the user currently has does not include this scope and the application knows it since it knows the set of scopes it requested in the initial authentication call.
+
+The solution is that the application performs another authentication call, but this time it requests the required scope. The browser redirects to Auth0 and a rule is used to challenge the user to authenticate with MFA since a high-value scope was requested.
+
+Once the user successfully authenticates with MFA, a new Access Token which includes the high-value scope is generated and sent. The application will pass the Access Token to the API which will discard it after verification, thereby treating it like a single-use token.
+
+For details and sample code, see [Step-up Authentication for APIs](/mfa/guides/configure-step-up-apis).
+
+## Step-up Authentication for Web Apps
+
+If it is a web app that verifies the authentication level, and not an API, then you do not have an Access Token. In this case you can check if a user has logged in with MFA by reviewing the contents of their [ID Token](/tokens/concepts/id-tokens). You can then configure your application to deny access to pages with sensitive information if the ID Token indicates that the user did not log in with MFA, and use a rule to trigger the step-up authentication mechanism (for example, prompt MFA).
+
+For example, you might have an employee app that authenticates users with username and password, but if a user wants to access salary information, they have to provide a second factor, using for example a mobile push notification.
+
+You can implement this by checking the ID Token when the user tries to access that screen. If the claims show that the user has authenticated with MFA already then display the sensitive information. Otherwise, trigger authentication again, and using a rule, prompt the user to authenticate with MFA.
+
+For details and sample code, see [Step-up Authentication for Web Apps](/mfa/guides/configure-step-up-web-apps).
+
+## Keep reading
+
+* [Authentication policy definitions](http://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html#rfc.section.4)
diff --git a/ja-jp/articles/mfa/guides/a.json b/ja-jp/articles/mfa/guides/a.json
new file mode 100644
index 0000000000..c7a8387871
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/a.json
@@ -0,0 +1 @@
+{ "message_types": ["sms", "voice"] }
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/guides/configure-cisco-duo.md b/ja-jp/articles/mfa/guides/configure-cisco-duo.md
new file mode 100644
index 0000000000..a47cc6ee98
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/configure-cisco-duo.md
@@ -0,0 +1,52 @@
+---
+description: Learn how to configure Cisco Duo for MFA.
+topics:
+  - mfa
+  - duo
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Configure Cisco Duo for MFA
+
+Cisco Duo is a multi-faceted authentication provider and can only be used on your Auth0 tenant if all other factors are disabled. 
+
+## Administrative setup
+
+Your Duo account can be configured to support push notifications, SMS, OTP, phone callback, and more. See the [Duo documentation](https://duo.com/docs) for more details on Duo setup. 
+
+::: note
+Create an integration in Duo Security of type **Web SDK** and use those credentials to fill in the Duo settings in the Auth0 Dashboard as noted below.
+:::
+
+When enabling Duo in the Dashboard, you will need to click on the Duo factor and fill in a few settings fields in order to link your Duo account to Auth0.
+
+![MFA Duo Settings](/media/articles/mfa/duo-settings.png)
+
+::: warning
+If other factors are enabled alongside Duo, Duo will be unavailable. Duo is only available to end users when it is the **sole** factor enabled.
+:::
+
+## MFA sessions
+
+Duo does not provide an option for "Remember Me" behavior, so a 30-day MFA session is hard-coded to remember a logged-in user and not prompt them every time they log in. If you wish to force end-users to log in with Duo every time, you may implement this functionality by creating a rule with `allowRememberBrowser: false` instead.
+
+```js
+function (user, context, callback) {
+  context.multifactor = {
+    provider: 'any',
+    allowRememberBrowser: false
+  };
+
+  callback(null, user, context);
+}
+```
+
+## End user experience
+
+The user will see a prompt for the second factor with Duo, listing the options you have enabled in your Duo account.
+
+![Duo Login](/media/articles/mfa/duo-login.png)
+
+Your end users can download Duo from [Google Play](https://play.google.com/store/apps/details?id=com.duosecurity.duomobile) or from the [App Store](https://itunes.apple.com/us/app/duo-mobile/id422663827?mt=8) for use as a second factor.
diff --git a/ja-jp/articles/mfa/guides/configure-email.md b/ja-jp/articles/mfa/guides/configure-email.md
new file mode 100644
index 0000000000..0b8c75500f
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/configure-email.md
@@ -0,0 +1,43 @@
+---
+description: Learn how to configure email as an MFA factor for users who don't have their primary factor available. 
+topics:
+  - mfa
+  - email
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Configure Email Notifications for MFA
+
+Using email as an MFA factor is useful when you want to provide users a way to perform MFA when they don't have their primary factor available (e.g. they don't have their phone to receive an SMS or push notification). 
+
+You can only enable email as an MFA factor if there is already another factor enabled. Email will only be functional as a factor from Universal Login when you have the [New Universal Login Experience](/universal-login/new) enabled.
+
+Once Email MFA is enabled user will be prompted to complete MFA with the other enabled factor. If they have a **verified email** they will be given the option to select Email, and get an one time code in their email which they can then enter to complete MFA.
+
+Users do not need to explicitly enroll with email MFA. They will get be able to use it when they have a verified email. This happens when they completed the email verification flow, when the updated the email_verified field using the Management API, or when they logged-in with a connection that provides verified emails (e.g. Google).
+
+Note that Email is not true multi-factor authentication (MFA) as it does not represent a different factor than the password. It does not represent 'something I have' or 'something I am', but rather just another 'something I know' (the email password). It is also weaker than other factors, in that it's only as secure as the email itself (e.g. is it encrypted end-to-end?).
+
+## End-user experience
+
+After the login step, users will be prompted with the most secure enabled factor. If they select 'Try another method', and then pick Email, they will be sent an email with a six-digit code that they will need to enter to complete the authentication flow.
+
+![Email End User 1](/media/articles/mfa/mfa-email.png)
+
+## Using the MFA API
+
+You can explicitly enroll an email for MFA [using the MFA API](/mfa/guides/mfa-api/email). If users have a verified email and one or more explicitly enrolled emails, they'll be able to select which email they want to use to complete MFA when logging-in using Universal Login.
+
+## Administrative setup
+
+In order to set up Email, you need to enable the Email factor in the Dashboard. You will only be able to enable it if there is another factor enabled. 
+
+![MFA Email Settings](/media/articles/mfa/email-settings.png)
+
+[Auth0 provides a test email provider](/email) but it only allows a limited amount of emails, so you should [configure your own email provider](/email/providers).
+
+## Keep reading
+
+* [Enroll and Challenge Email Authenticators using the MFA API](/mfa/guides/mfa-api/email)
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/guides/configure-otp.md b/ja-jp/articles/mfa/guides/configure-otp.md
new file mode 100644
index 0000000000..2ac05eb434
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/configure-otp.md
@@ -0,0 +1,36 @@
+---
+description: Learn how to configure time-based one time passwords for MFA.
+topics:
+  - mfa
+  - duo
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Configure One Time Passwords for MFA
+
+To use one time passwords as an authentication factor, users need an Authenticator app such as:
+
+* Authy ([Google Play](https://play.google.com/store/apps/details?id=com.authy.authy) / [App Store](https://itunes.apple.com/us/app/authy/id494168017)).
+* Google Authenticator ([Google Play](https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2) / [App Store](https://itunes.apple.com/us/app/google-authenticator/id388497605)).
+* Auth0 Guardian ([Google Play](https://play.google.com/store/apps/details?id=com.auth0.guardian) / [App Store](https://itunes.apple.com/us/app/auth0-guardian/id1093447833)).
+* Microsoft Authenticator ([Google Play](https://play.google.com/store/apps/details?id=com.azure.authenticator) / [App Store](https://itunes.apple.com/us/app/microsoft-authenticator/id983156458)).
+
+![MFA OTP Signup](/media/articles/mfa/mfa-otp-setup.png)
+
+Upon signup, they can scan a code and set up the app, upon which it will begin generating one-time codes. 
+
+Afterwards, when logging in to the app, the user can simply check the authenticator app for the current one-time code:
+
+
      Google Authenticator OTP
      
+
+And enter the code at the prompt:
+
+![MFA OTP Login](/media/articles/mfa/mfa-otp-login.png)
+
+Your users will need to have an OTP Authenticator app installed in their mobile devices.
+
+## Keep reading
+
+* [Enroll and Challenge OTP Authenticators using the MFA API](/mfa/guides/mfa-api/otp)
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/guides/configure-phone.md b/ja-jp/articles/mfa/guides/configure-phone.md
new file mode 100644
index 0000000000..9b37a8fdd1
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/configure-phone.md
@@ -0,0 +1,128 @@
+---
+title: Configure SMS and Voice Notifications for MFA
+description: Learn how to configure SMS and Voice notifications for MFA.
+topics:
+  - mfa
+  - twilio
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Configure SMS and Voice Notifications for MFA
+
+If you use SMS or Voice as an authentication factor, when an end user attempts to authenticate with your application, they are sent a code via SMS or Voice, which they will have to enter to complete the transaction. This implies that they both know their login credentials and are in possession of the phone number that they have registered for Multi-factor Authentication (MFA) use.
+
+You can configure this factor to send messages through SMS, Voice, or to let the end users choose how they want the code to be delivered.
+
+::: warning
+- Using Voice as an MFA factor is currently a Beta feature. It should not be used in production environments.
+- Voice as an MFA factor is not available when using the [Classic Universal Login Experience](/universal-login/classic).
+::: 
+
+## End user experience - Voice and SMS
+
+When Voice and SMS are enabled, users are given the option to enroll by getting the code sent by SMS or Voice:
+
+![Voice and SMS - End User](/media/articles/mfa/mfa-sms-voice.png)
+
+When only SMS is enabled, the flow is simpler:
+
+![SMS - End User](/media/articles/mfa/mfa-sms.png)
+
+After users are enrolled, the next time they authenticate they will get the Voice or SMS message in their registered phone. 
+
+## Administrative setup
+
+![MFA Phone Message Settings](/media/articles/mfa/mfa-phone-settings.png)
+
+### Message Delivery Provider and Method
+
+To allow users to authenticate with SMS or Voice, you must enable the Phone factor and select your preferred delivery method:
+
+* **Auth0**: Sends the messages using Auth0's internally-configured SMS delivery provider. It can be used for evaluation and testing purposes, and there is a maximum of 100 messages per tenant during the entire tenant lifetime. New codes are not received after reaching the 100 message limit. You can't use this provider to send Voice messages.
+
+* **Twilio**: Sends the messages using the [Twilio Programmable SMS API](https://www.twilio.com/sms) for SMS or [Twilio Programmable Voice API](https://www.twilio.com/voice) for Voice. You will need to provide [your own Twilio credentials](#twilio-configuration). Make sure you use Twilio  **Live Credentials**, not the **Test Credentials**. The test credentials are not meant to be used to send messages in a production environment.
+
+* **Custom**: Sends the messages by invoking the [Send Phone Message Hook](/hooks/extensibility-points/send-phone-message).
+
+You can also choose if you want to give users the option of getting text messages, voice calls, or both.
+
+### Twilio configuration
+
+If you choose to deliver SMS via Twilio, follow these steps to configure your SMS factor.
+
+![MFA Phone Settings](/media/articles/mfa/mfa-phone-twilio.png)
+
+1. Open an account with Twilio. You will need a [Twilio Account SID](https://www.twilio.com/help/faq/twilio-basics/what-is-an-application-sid) and a [Twilio Auth Token](https://www.twilio.com/help/faq/twilio-basics/what-is-the-auth-token-and-how-can-i-change-it). These are the Twilio API credentials that Auth0 will use to send messages to your users.
+
+  You may also need to enable permissions for your geographic region for [SMS](https://support.twilio.com/hc/en-us/articles/223181108-How-International-SMS-Permissions-work) and [Voice](https://www.twilio.com/console/voice/calls/geo-permissions). If you use Voice, your account needs to have a Twilio phone number enabled to make Voice calls. This can be an external phone number [verified with Twilio](https://support.twilio.com/hc/en-us/articles/223180048-Adding-a-Verified-Phone-Number-or-Caller-ID-with-Twilio) or you can purchase and set up a Twilio Phone Number from within your account.
+
+2. Configure the connection. Enter your **Twilio Account SID** and **Twilio Auth Token** in the appropriate fields.
+
+3. Choose your **SMS Source**.
+
+  * If you choose **Use From**, you will need to enter the **From** phone number that users will see as the sender. You may also configure this in Twilio. 
+
+  * If you choose **Use Messaging Services**, you will need to enter a [Messaging Service SID](https://www.twilio.com/docs/sms/services/services-send-messages).
+
+  If you are using Voice, you always need to configure 'From' even if you are using 'Messaging Services' for SMS. Make sure the phone number is configured to send both SMS and Voice messages.
+
+5. Click **Save**.
+
+### Custom Phone Messaging providers
+
+Phone Messaging providers not currently integrated with Auth0 can be implemented by using the [Send Phone Message](/hooks/extensibility-points/send-phone-message) Hook. To learn how to do this in your MFA flow, check the examples for different providers below:
+
+* [Amazon SNS](/mfa/send-phone-message-hook-amazon-sns)
+* [Twilio](/mfa/send-phone-message-hook-twilio)
+* [Infobip](/mfa/send-phone-message-hook-infobip)
+* [TeleSign](/mfa/send-phone-message-hook-telesign)
+* [Vonage](/mfa/send-phone-message-hook-vonage)
+* [Esendex](/mfa/send-phone-message-hook-esendex)
+* [Mitto](/mfa/send-phone-message-hook-mitto)
+
+## Custom SMS or Voice Notification Templates
+
+Optionally, you can [customize your SMS or Voice notification templates](/mfa/guides/customize-phone-messages).
+
+## Using the Management API to configure Voice or SMS
+
+You can use the Management API to configure which Message Delivery Methods are enabled by using the `/api/v2/guardian/factors/phone/message-types` endpoint. 
+
+The `messages_types` parameter is an array that can have `["sms"]`, `["voice"]`, or `["sms", "voice"]`. You need a [Management API Token](/api/management/v2/tokens) with the `update:guardian_factors` scope as a Bearer Token to call the API:
+
+ ```har
+  {
+      "method": "PUT",
+      "url": "https://${account.namespace}/api/v2/guardian/factors/phone/message-types",
+      "headers": [
+        { "name": "Content-Type", "value": "application/json" },
+   	    { "name": "Authorization", "value": "Bearer MGMT_API_ACCESS_TOKEN" }
+      ],
+      "postData": {
+          "mimeType": "application/json",
+          "text": "{ \"message_types\": [\"sms\", \"voice\"] }"
+      }
+  }
+```
+
+## Security Considerations
+
+When using any phone messaging provider, you need to be aware that attackers abusing the signup flow could cause you financial damage.
+
+Auth0 will limit a single user to sending up to 10 SMS or voice messages per hour. To further protect your account, you can consider:
+
+- Enabling [Brute Force Protection](/anomaly-detection/references/brute-force-protection-triggers-actions#100-failed-login-attempts-or-50-sign-up-attempts). Auth0 will block an IP if it attempts to do more than 50 signup requests per minute.
+
+- Enable [Log Streaming](/logs/streams) and create alerts using your favorite monitoring tool, when you see spikes in the number of `gd_send_voice` or `gd_send_voice_failure` [log events](/logs/references/log-event-type-codes).
+
+Phone Messaging providers have additional protections. If you are using Twilio, make sure you read the [Anti-Fraud Developer Guide](https://www.twilio.com/docs/usage/anti-fraud-developer-guide). We recommend that you consider the following options:
+
+- Limit the countries that you will send messages for [SMS](https://support.twilio.com/hc/en-us/articles/223181108-How-International-SMS-Permissions-work) and [Voice](https://support.twilio.com/hc/en-us/articles/223180228-International-Voice-Dialing-Geographic-Permissions-Geo-Permissions-and-How-They-Work). This is particularly useful if there are countries with a higher risk of [toll fraud](https://www.twilio.com/learn/voice-and-video/toll-fraud) or more expensive calling rates in which you do not typically do business.
+
+- Enable Twilio [usage triggers](https://support.twilio.com/hc/en-us/articles/223132387-Protect-your-Twilio-project-from-Fraud-with-Usage-Triggers) to protect your account against fraud and coding mistakes.
+
+## Keep Reading
+
+* [Enroll and Challenge SMS and Voice Authenticators using the MFA API](/mfa/guides/mfa-api/phone)
diff --git a/ja-jp/articles/mfa/guides/configure-push.md b/ja-jp/articles/mfa/guides/configure-push.md
new file mode 100644
index 0000000000..4bed2fc849
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/configure-push.md
@@ -0,0 +1,42 @@
+---
+description: Learn how to configure push notification using Guardian SDKs for multi-factor authentication.
+topics:
+  - mfa
+  - guardian-sdk
+  - push
+contentType:
+  - how-to
+useCase:
+  - configure-push-notifications
+---
+# Configure Push Notifications for MFA
+
+Use a custom app built using the Guardian SDKs for [iOS](/mfa/guides/guardian/guardian-ios-sdk) and [Android](/mfa/guides/guardian/guardian-android-sdk) that relies on vendor-specific push notification services. 
+
+1. [Create an SNS Platform Application](https://console.aws.amazon.com/sns/v3/home?region=us-east-1#/mobile/push-notifications/platform-applications) using AWS Management console and note it’s ARN.
+
+2. Create an AWS Access Key authorized to create Platform application endpoints. Guardian automatically creates a platform application endpoint with appropriate device token as part of a successful enrollment. 
+
+3. To receive push notifications from Guardian, it's necessary to override Guardian's default SNS settings.
+
+    Go to the [Multi-factor Authentication](${manage_url}/#/guardian) section of the Dashboard.
+
+4. Toggle **Custom App** option in the **Push via Auth0 Guardian** section and set your AWS Access Key and ARN from the AWS Management Console. 
+
+    Name | Description
+    -----|------------
+    AWS Access Key Id | Your AWS Access Key ID.
+    AWS Secret Access Key | Your AWS Secret Access Key.
+    AWS Region | Your AWS application's region.
+    APNS ARN | The Amazon Resource Name for your [Apple Push Notification Service](http://docs.aws.amazon.com/sns/latest/dg/mobile-push-apns.html).
+    GCM ARN | The Amazon Resource Name for your [Firebase Cloud Messaging Service](https://docs.aws.amazon.com/sns/latest/dg/sns-mobile-application-as-subscriber.html).
+
+5. Click **SAVE**. 
+
+## Keep reading
+
+* [Guardian iOS SDK](/mfa/guides/guardian/guardian-ios-sdk)
+* [Guardian Android SDK](/mfa/guides/guardian/guardian-android-sdk)
+* [Create Custom Enrollment Tickets](/mfa/guides/guardian/create-enrollment-ticket)
+* [Guardian Error Code Reference](/mfa/references/guardian-error-code-reference)
+* [Enroll and Challenge Push Authenticators using the MFA API](/mfa/guides/mfa-api/push)
diff --git a/ja-jp/articles/mfa/guides/configure-step-up-apis.md b/ja-jp/articles/mfa/guides/configure-step-up-apis.md
new file mode 100644
index 0000000000..8b5357dc01
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/configure-step-up-apis.md
@@ -0,0 +1,217 @@
+---
+title: Configure Step-up Authentication for APIs
+description: Learn how an API can check if a user has logged in with Multi-factor Authentication by examining their Access Token.
+topics:
+  - mfa
+  - step-up-authentication
+  - apis
+contentType:
+  - how-to
+  - concept
+useCase:
+  - customize-mfa
+---
+# Configure Step-up Authentication for APIs
+
+With step-up authentication, applications that allow access to different types of resources can require users to authenticate with a stronger mechanism to access sensitive information or perform certain transactions.
+
+For instance, a user of a bankin app may be allowed to transfer money between accounts only after they have confirmed their identity using multi-factor authentication (MFA).
+
+When your audience is an API, you can implement step-up authentication with Auth0 using scopes, Access Tokens, and [Rules](/rules/references/use-cases#multi-factor-authentication). 
+
+## How it works
+
+When an application wants to access an API's protected resources, it must provide an Access Token. The resources that it will have access to depend on the permissions that are included in the Access Token. These permissions are defined as **scopes**. 
+
+For example, a banking API may accept two different levels of authorization: view account balance (scope `view:balance`) or transfer funds (scope `transfer:funds`). When an application asks the API to retrieve the user's balance, then the Access Token should contain the `view:balance` scope. To transfer money to another account, the Access Token should contain the `transfer:funds` scope.
+
+The flow for this example:
+
+1. The user logs in to the application using username/password authentication. The standard login gives this user the ability to interact with the API and fetch their balance. This means that the Access Token that the app receives after the user authenticates contains the `view:balance` scope.
+2. The application sends a request to the API to retrieve the balance, using the Access Token as credentials.
+3. The API validates the token and sends the balance info to the application, so the user can view it.
+4. Now the user wishes to transfer funds from one account to another, which is deemed a high-value transaction that requires the `transfer:funds` scope. The application sends a request to the API using the same Access Token.
+5. The API validates the token and denies access because the token is missing the required `transfer:funds` scope.
+6. The application redirects to Auth0, where a rule is used to challenge the user to authenticate with MFA since a high-value scope was requested. Once the user successfully authenticates with MFA, a new Access Token that includes the correct scope is generated and sent to the application as part of the response.
+7. The application sends another transfer funds request using the new Access Token, which includes the `transfer:funds` scope this time.
+8. The API validates the token, discards it (thereby treating it like a single-use token), and proceeds with the operation.
+
+## Validate Access Tokens
+
+Besides checking the scope, the API must perform additional validation on the Access Token. It must also:
+
+* verify the token's signature, which is used to verify that the sender of the token is who it says it is and to ensure that the message wasn't changed along the way. 
+
+* validate the standard claims: 
+
+    | Claim | Description |
+    | --- | --- |
+    | `exp` | Token expiration |
+    | `iss` | Token issuer |
+    | `aud` | Intended recipient of the token |
+
+For more information, see [Validate an Access Token: Custom API Access Tokens](/tokens/guides/validate-access-tokens#custom-api-access-tokens).
+
+## Sample scenario
+
+In the following scenario, we will learn how to implement the flow described above.
+
+For this example, we assume that we have already done the following:
+
+- [Registered an application](/applications). For this example, we'll use a single-page web app.
+- [Created a database connection](${manage_url}/#/connections/database).
+- [Registered the API](/apis#how-to-configure-an-api-in-auth0). During this process, we should create two scopes: `view:balance` and `transfer:funds`.
+- [Enabled Multi-factor Authentication](/mfa). For this example, we'll use push notifications.
+
+1. Create a rule that challenges the user to authenticate with MFA when the `transfer:funds` scope is requested. Navigate to [Rules](${manage_url}/#/rules), and create a rule that contains the following content:
+
+    ```js
+    function(user, context, callback) {
+
+      var CLIENTS_WITH_MFA = ['${account.clientId}'];
+      // run only for the specified clients
+      if (CLIENTS_WITH_MFA.indexOf(context.clientID) !== -1) {
+        // ask for MFA only if scope transfer:funds was requested
+        if (context.request.query.scope.indexOf('transfer:funds') > -1) {
+          context.multifactor = {
+            provider: 'any',
+            allowRememberBrowser: false
+          };
+        }
+      }
+
+      callback(null, user, context);
+    }
+    ```
+
+    - The `CLIENTS_WITH_MFA` variable holds the Client IDs of all the applications you want to use this rule. (You can remove this (and the `if` statement that follows) if you don't need it.)
+
+    - The `context.request.query.scope` property contains all the scopes for which the authentication request asked. If it includes the value `transfer:funds`, then we ask for MFA by setting the `context.multifactor` property to the appropriate value. In this case, we are asking for MFA using [Push](/mfa/concepts/mfa-factors#push-notifications).
+
+2. Configure the app to send the appropriate authentication request to the API, depending on whether the user is attempting to perform the high-value transaction of transferring funds. Notice that the only difference between the two authentication requests (with or without MFA) is the scope.
+
+
      
+  
      
+    
+  
      
+  
      
+    
      
+      
      +        
+        https://${account.namespace}/authorize?
+        audience=https://my-banking-api&
+        scope=openid%20view:balance&
+        response_type=id_token%20token&
+        client_id=${account.clientId}&
+        redirect_uri=${account.callback}&
+        nonce=NONCE&
+        state=OPAQUE_VALUE
+        
+      
      
+    
      
+    
      
+      
      +        
+        https://${account.namespace}/authorize?
+        audience=https://my-banking-api&
+        scope=openid%20view:balance%20transfer:funds&
+        response_type=id_token%20token&
+        client_id=${account.clientId}&
+        redirect_uri=${account.callback}&
+        nonce=NONCE&
+        state=OPAQUE_VALUE
+        
+      
      
+    
      
+  
      
+
      
+
+| Parameter | Setting |
+| --- | --- |
+| `audience` | Set to the **Identifier** of your API (find it at [API Settings](${manage_url}/#/apis/)). We set ours to `https://my-banking-api`. |
+| `response_type` | Set to `id_token token` so we get both an ID Token and an Access Token in the response. |
+| `client_id` | Set to the Client ID of your application (find it at [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)). |
+| `redirect_uri` | Set to a URL in your application that Auth0 should redirect back to after authentication (find it at [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)). |
+| `nonce` | Set to a secure string value which will be included in the response from Auth0. This is [used to prevent token replay attacks](/api-auth/tutorials/nonce) and is required for `response_type=id_token token`. |
+| `state` | Set to an opaque value that Auth0 includes when redirecting back to the application. This value must be used by the application to [prevent CSRF attacks](/protocols/oauth2/oauth-state). |
+
+3. Configure the API to validate the incoming token according to the steps described in the [Validate Access Tokens](#validate-access-tokens) section and check the authorized permissions. 
+
+    In this scenario, we will configure two endpoints for our API:
+
+    - `GET /balance`: to retrieve the current balance
+    - `POST /transfer`: to transfer funds
+
+    We will use `Node.js` and a number of modules:
+
+    - [express](https://expressjs.com/): adds the Express web application framework.
+    - [jwks-rsa](https://github.com/auth0/node-jwks-rsa): retrieves RSA signing keys from a **JWKS** (JSON Web Key Set) endpoint. Using `expressJwtSecret`, we can generate a secret provider that will issue the right signing key to `express-jwt` based on the `kid` in the JWT header.
+    - [express-jwt](https://github.com/auth0/express-jwt): lets you authenticate HTTP requests using JWT tokens in your Node.js applications. It provides several functions that make working with JWTs easier.
+    - [express-jwt-authz](https://github.com/auth0/express-jwt-authz): checks if the Access Token contains a specific scope.
+
+    Start with installing the dependencies:
+
+    `npm install express express-jwt jwks-rsa express-jwt-authz --save`
+
+    Next, define the API endpoints, create a middleware function to validate the Access Token, and secure the endpoints using that middleware. The code in your `server.js` file should look like the following sample script:
+
+    ```js
+    // set dependencies
+    const express = require('express');
+    const app = express();
+    const jwt = require('express-jwt');
+    const jwksRsa = require('jwks-rsa');
+    const jwtAuthz = require('express-jwt-authz');
+
+    // Create middleware for checking the JWT
+    const checkJwt = jwt({
+      // Dynamically provide a signing key based on the kid in the header and the signing keys provided by the JWKS endpoint
+      secret: jwksRsa.expressJwtSecret({
+        cache: true,
+        rateLimit: true,
+        jwksRequestsPerMinute: 5,
+        jwksUri: `https://${account.namespace}/.well-known/jwks.json`
+      }),
+
+      // Validate the audience and the issuer
+      audience: 'https://my-banking-api', // replace with your API's audience, available at Dashboard > APIs
+      issuer: 'https://${account.namespace}/',
+      algorithms: [ 'RS256' ] // we are using RS256 to sign our tokens
+    });
+
+    // create retrieve balance endpoint
+    app.get('/balance', checkJwt, jwtAuthz(['view:balance']), function (req, res) {
+      // code that retrieves the user's balance and sends it back to the calling app
+      res.status(201).send({message: "This is the GET /balance endpoint"});
+    });
+
+
+    // create transfer funds endpoint
+    app.post('/transfer', checkJwt, jwtAuthz(['transfer:funds']), function (req, res) {
+      // code that transfers funds from one account to another
+      res.status(201).send({message: "This is the POST /transfer endpoint"});
+    });
+
+    // launch the API Server at localhost:8080
+    app.listen(8080);
+    console.log('Listening on http://localhost:8080');
+    ```
+
+    Each time the API receives a request the following happens:
+
+    1. The endpoint calls the `checkJwt` middleware.
+    2. `express-jwt` decodes the token and passes the request, the header, and the payload to `jwksRsa.expressJwtSecret`.
+    3. `jwks-rsa` downloads all signing keys from the JWKS endpoint and checks if one of the signing keys matches the `kid` in the header of the Access Token. If none of the signing keys match the incoming `kid`, an error is thrown. If there is a match, we pass the right signing key to `express-jwt`.
+    4. `express-jwt` continues its own logic to validate the signature of the token, the expiration, audience, and the issuer.
+    5. `jwtAuthz` checks if the scope that the endpoint requires is part of the Access Token.
+
+## Keep reading
+
+* [Access Tokens](/tokens/concepts/access-tokens)
+* [Rules Uses Cases](/rules/references/use-cases#multi-factor-authentication)
+* [Scopes](/scopes)
+* [Validate Access Tokens](/tokens/guides/validate-access-tokens)
+* [Step-up Authentication for Web Apps](/mfa/guides/configure-step-up-for-web-apps)
diff --git a/ja-jp/articles/mfa/guides/configure-step-up-web-apps.md b/ja-jp/articles/mfa/guides/configure-step-up-web-apps.md
new file mode 100644
index 0000000000..af00fbc2ed
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/configure-step-up-web-apps.md
@@ -0,0 +1,167 @@
+---
+title: Configure Step-up Authentication for Web Apps
+description: Learn how to check if a user has logged in your web app with Multi-factor Authentication by examining their ID Token.
+topics:
+  - mfa
+  - step-up-authentication
+  - web-apps
+contentType:
+  - how-to
+  - concept
+useCase:
+  - customize-mfa
+---
+# Configure Step-up Authentication for Web Apps
+
+With step-up authentication, applications that allow access to different types of resources can require users to authenticate with a stronger mechanism to access sensitive information or perform certain transactions.
+
+For instance, a user may be allowed to access views with sensitive data or reset their password only after confirming their identity using multi-factor authentication (MFA).
+
+To accomplish step-up authentication for your web app, you will create a rule that challenges the user to authenticate with MFA when the web app asks for it, check the ID Token claims for MFA if the user tries to access a restricted page, and then challenge the user if MFA is not included in the claim. 
+
+## How it works
+
+When a user logs in, you retrieve an [ID Token](/tokens/concepts/id-tokens), which is a JSON Web Token (JWT) that contains information relevant to the user's session in the form of claims. For this scenario, the relevant claim is `amr`, which indicates the authentication method used during login; it **must** be present in the ID Token's payload and **must** contain the value `mfa`. Because it can contain claims other than `mfa`, when validating you must both test for its existence and examine its contents for a value of `mfa`.
+
+::: panel Authentication Methods Reference
+The `amr` claim is a JSON array of strings that indicates the authentication method used during login. Its values may include any of the pre-defined [Authentication Method Reference Values](https://tools.ietf.org/html/rfc8176). For example, the `amr` claim may contains the pre-defined value `mfa`, which indicates that the user has authenticated using MFA. 
+:::
+
+If a user attempts to access a restricted page and the token shows that the user has **not** authenticated with MFA, then you can retrigger authentication, which you have configured to trigger MFA using a rule. Once the user provides the second factor, a new ID Token that contains the `amr` claim is generated and sent to the app.
+
+## Validate ID Tokens for MFA
+
+1. Retrieve the ID Token.
+2. Verify the token's signature, which is used to verify that the sender of the token is who it says it is and to ensure that the message wasn't changed along the way.
+3. Validate the following claims: 
+
+    | Claim | Description |
+    | --- | --- |
+    | `exp` | Token expiration |
+    | `iss` | Token issuer |
+    | `aud` | Intended recipient of the token |
+    | `amr` | If `amr` does not exist in the payload or does not contain the value `mfa`, the user did not log in with MFA. If `amr` exists in the payload and contains the value `mfa`, then the user did log in with MFA. |
+
+    In the example below, you can compare the potential values included in an ID Token's payload when a user has authenticated with MFA versus when they have not.
+
+
      
+  
      
+    
+  
      
+  
      
+    
      
+      
      +        
+{
+    "iss": "https://${account.namespace}/",
+    "sub": "auth0|1a2b3c4d5e6f7g8h9i",
+    "aud": "${account.clientId}",
+    "iat": 1522838054,
+    "exp": 1522874054,
+    "acr": "http://schemas.openid.net/pape/policies/2007/06/multi-factor",
+    "amr": [
+        "mfa"
+    ]
+}
+        
+      
      
+    
      
+    
      
+      
      +        
+{
+    "iss": "https://${account.namespace}/",
+    "sub": "auth0|1a2b3c4d5e6f7g8h9i",
+    "aud": "${account.clientId}",
+    "iat": 1522838054,
+    "exp": 1522874054
+}
+        
+      
      
+    
      
+  
      
+
      
+
+## Sample scenario
+
+In the following scenario, a web app authenticates users with username and password. When users want to access a specific screen with sensitive information, such as salary data, they must authenticate with another factor, such as Guardian push notifications.
+
+For this example, we assume that we have already done the following:
+
+- [Registered an application](/applications). For this example, we'll use a regular web app.
+- [Created a database connection](${manage_url}/#/connections/database).
+- [Enabled Multi-factor Authentication](/mfa/guides/enable-mfa) using push notifications.
+
+1. Create a rule that challenges the user to authenticate with MFA when the web app requests it. Navigate to [Rules](${manage_url}/#/rules), and create a rule that contains the following content:
+
+    ```js
+    function(user, context, callback) {
+
+      var CLIENTS_WITH_MFA = ['${account.clientId}'];
+      // run only for the specified clients
+      if (CLIENTS_WITH_MFA.indexOf(context.clientID) !== -1) {
+        // ask for MFA only if the web app said so in the authentication request
+        if (context.request.query.acr_values === 'http://schemas.openid.net/pape/policies/2007/06/multi-factor'){
+          context.multifactor = {
+            provider: 'any',
+            allowRememberBrowser: false
+          };
+        }
+      }
+
+      callback(null, user, context);
+    }
+    ```
+
+    - The `CLIENTS_WITH_MFA` variable holds the Client IDs of all the applications you want to use this rule. (You can remove this (and the `if` statement that follows) if you don't need it.)
+
+    - The `context.request.query.acr_values` property contains the context class that the Authorization Server is being requested to use when processing requests from the application. It only exists when the application includes it in the authentication request. In this example, our web app will include it in the authentication request, but only when a user who has not already authenticated ith MFA tries to access salary information. When our web app includes it, it will set a value of `http://schemas.openid.net/pape/policies/2007/06/multi-factor`, which indicates that we want the Authorization Server to require MFA, and the `context.multifactor` property value that we set in our code will specify MFA via [Push notification](/mfa/concepts/mfa-factors#push-notifications).
+
+2. Configure the app to check that the user has authenticated using MFA when a user tries to acces the restricted salary information page. (When a user has authenticated with MFA, the ID Token claims contain the `amr` claim with a value of `mfa`). If the user has already authenticated with MFA, then the web app will display the restricted page; otherwise, the web app will send a new authentication request that includes the `acr_values` parameter with a value of `http://schemas.openid.net/pape/policies/2007/06/multi-factor`, which will trigger our rule. 
+
+    The web app in this scenario uses the [Authorization Code Flow](/flows/concepts/auth-code) to authenticate, so the request is as follows:
+
+    ```text
+    https://${account.namespace}/authorize?
+        audience=https://${account.namespace}/userinfo&
+        scope=openid&
+        response_type=code&
+        client_id=${account.clientId}&
+        redirect_uri=${account.callback}&
+        state=YOUR_OPAQUE_VALUE&
+        acr_values=http://schemas.openid.net/pape/policies/2007/06/multi-factor
+    ```
+
+    Once the user authenticates with MFA, the web app receives the authorization code, which must be exchanged for the new ID Token, which should now contain the `amr` claim with a value of `mfa`. To learn how to exchange the code for an ID Token, see [Add Login Using the Authorization Code Flow: Request Tokens](/flows/guides/auth-code/add-login-auth-code#request-tokens). 
+
+3. Validate the incoming ID Token using the steps described in the [Validate ID Tokens for MFA](#validate-id-tokens-for-mfa) section. In this scenario, we perform these validations using the [JSON Web Token Sample Code](https://github.com/auth0/node-jsonwebtoken), which verifies the token's signature (`jwt.verify`), decodes the token, checks whether the payload contains `amr`, and if so, logs the results in the console.
+
+    ```js
+    const AUTH0_CLIENT_SECRET = '${account.clientSecret}';
+    const jwt = require('jsonwebtoken')
+
+    jwt.verify(id_token, AUTH0_CLIENT_SECRET, { algorithms: ['HS256'] }, function(err, decoded) {
+      if (err) {
+        console.log('invalid token');
+        return;
+      }
+
+      if (Array.isArray(decoded.amr) && decoded.amr.indexOf('mfa') >= 0) {
+        console.log('You used mfa');
+        return;
+      }
+
+      console.log('you are not using mfa');
+    });
+    ```
+
+## Keep reading
+
+* [ID Tokens](/tokens/concepts/id-tokens)
+* [Rules Use Cases](/rules/references/use-cases#multi-factor-authentication)
+* [JSON Web Tokens](/tokens/concepts/jwts)
+* [OpenID Connect (OIDC) specification](http://openid.net/specs/openid-connect-core-1_0.html)
+* [Configure Step-up Authentication for APIs](/mfa/guides/configure-step-up-apis)
diff --git a/ja-jp/articles/mfa/guides/customize-mfa-universal-login.md b/ja-jp/articles/mfa/guides/customize-mfa-universal-login.md
new file mode 100644
index 0000000000..876b69c42d
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/customize-mfa-universal-login.md
@@ -0,0 +1,174 @@
+---
+description: Learn how to customize MFA pages with Universal Login branding options.
+topics:
+  - mfa
+  - custom-mfa
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Customize Multi-Factor Authentication
+
+::: note
+These customizations do not apply to Duo, which has its own UI.
+:::
+
+The multi-factor authentication pages that appear to your users can be customized by adjusting the Universal Login branding options in the [Universal Login Settings](${manage_url}/#/login_settings) section.
+
+If you need further customization, you can also customize [the full HTML content](/universal-login/multifactor-authentication#customize-the-html-for-the-mfa-page) to reflect your organization's particular UX requirements. 
+
+With the New Universal Login Experience, MFA is presented even more simply to the user. Once they have entered their credentials to log in, they are presented with the MFA screen. If they have no MFA factor enrolled, they will be asked to enroll, and if they do, they will be asked to present their MFA credential.
+
+![MFA with New UL](/media/articles/universal-login/new-ul-mfa1.png)
+
+Note that in addition to complying with the requested factor, a user can also click the link at the bottom and be taken to a screen which presents all available MFA factors for this application, and select another to enroll or use.
+
+![MFA with New UL - Select a Factor](/media/articles/universal-login/new-ul-mfa2.png)
+
+## Customize via Rules
+
+If you need to customize the multi-factor experience you are offering to your users, you may do so via custom rules configurations for multi-factor authentication. This might be needed, for example, if you wish to trigger MFA for only specific applications, or for specific users based on user metadata or on IP addresses.
+
+## MFA API
+
+Additionally, the [MFA API](/mfa/concepts/mfa-api) is available for other customized MFA requirements.
+
+You can configure a [rule](/rules/references/use-cases#multi-factor-authentication) in  [Dashboard > Rules](${manage_url}/#/rules) for custom multi-factor authentication (MFA) processes, which allow you to define the conditions that will trigger additional authentication challenges. Rules can be used to force MFA for users of certain applications, or for users with particular user metadata or IP ranges, among other triggers.
+
+::: note
+The MFA settings defined in rules will always take precedence over the toggles in the Multi-factor Auth section of the Dashboard.
+:::
+
+## `provider` setting
+
+The `provider` setting is a way to specify whether to force MFA, and which factor to you use. The behavior is different depending if you use the Classic or the New Universal Login experience:
+
+| Provider             | Classic Experience      | New Experience          |
+|----------------------|:-----------------------:|------------------------:|
+| any                  |  Push, SMS or OTP using | Push, SMS, Voice, OTP or Email |
+| guardian             |  Push, SMS or OTP using | Push, SMS, OTP or Email |
+| google-authenticator |  Google Authenticator   | Push, SMS, OTP or Email |
+| duo                  |  Duo                    | Duo                     |
+
+If you are using the New Experience you can get the behavior of the Classic experience if you enable customization of the MFA login page.
+
+The `guardian` and `google-authenticator` options are legacy settings that are kept for backwards compatibility reasons, and should not be used moving forward. We recommend using `any`.  The 'google-authenticator' option does not let users enroll a recovery code.
+
+Setting the `provider` to a specific option manually will override the enabled/disabled toggles in the Dashboard. The following rule will prompt the user to enroll for Duo even if other factor are enabled in the Dashboard:
+
+```js
+function (user, context, callback) {
+
+  // Forcing the provider to Duo programmatically
+  context.multifactor = {
+    provider: 'duo'
+  };
+
+  callback(null, user, context);
+}
+```
+
+## Implement contextual MFA
+
+The exact requirements for configuring Contextual MFA will vary. Below are sample snippets you might consider using as you customize your specific solution.
+
+### Customize MFA for select users
+
+You may customize MFA to run only for users who are authenticating against specific applications in your tenant, or only for users who are marked to use MFA. To enable this behavior you need to have the "Always require Multi-factor Authentication" toggle turned off, and enable MFA using a rule for specific users or applications.
+
+```js
+function (user, context, callback) {
+
+  //var CLIENTS_WITH_MFA = ['REPLACE_WITH_YOUR_CLIENT_ID'];
+  // run only for the specified applications
+  // if (CLIENTS_WITH_MFA.indexOf(context.clientID) !== -1) {
+    // uncomment the following if clause in case you want to request a second factor only from user's that have user_metadata.use_mfa === true
+    // if (user.user_metadata && user.user_metadata.use_mfa){
+      context.multifactor = {
+        provider: 'any',
+        allowRememberBrowser: false
+      };
+    // }
+  //}
+
+  callback(null, user, context);
+}
+```
+
+If you choose to selectively apply MFA, you will need the appropriate `clientID` values, and the code will be executed as part of a [Rule](/rules) whenever a user logs in.
+
+More specifically, you will uncomment and populate the following line of the rule template above with the appropriate client IDs:
+
+`var CLIENTS_WITH_MFA = ['REPLACE_WITH_CLIENT_ID'];`
+
+By setting `allowRememberBrowser: false`, the user will always be prompted for MFA when they login. This prevents the browser cookie from saving the credentials and helps make logins more secure, especially from untrusted machines. 
+
+### Change authentication request frequency
+
+In some scenarios you may want to avoid prompting the user for MFA each time they log in from the same browser. The default behavior is:
+
+- The user will be prompted for MFA every 30 days when `provider` is set to `google-authenticator` or `duo`
+- The user will be able to decide if they want to skip MFA for the next 30 days when `provider` is set to other values.
+
+You can alter that behavior by using the `allowRememberBrowser` property:
+
+```JS
+function (user, context, callback) {
+
+  if (conditionIsMet()){
+    context.multifactor = {
+      allowRememberBrowser: false,
+      provider: 'any'
+    };
+  }
+
+  callback(null, user, context);
+}
+```
+
+Depending on the property value the behavior will be as follows:
+
+- `true`: when `provider` is set to `google-authenticator` or `duo`, the user will be prompted for MFA once every 30 days. For other provider values, the user will be able to decide if they want to skip MFA for the next 30 days.
+- `false`: the user will be prompted for MFA each time they authenticate.
+
+::: note
+These time values are for active users. If a user is inactive for a period of seven days or more, their cookie will expire anyway, and they will be prompted for MFA on their next login attempt, even if `allowRememberBrowser` is `true` and it has not been thirty days since their last MFA prompt.
+:::
+
+In order to let the user skip MFA, a cookie will be stored in the user's browser. If the user has the cookie set but you still want the user to perform MFA, you have these options:
+
+- Set `allowRememberBrowser` to `false`
+- Set `acr_values` to `http://schemas.openid.net/pape/policies/2007/06/multi-factor` when calling the `/authorize` endpoint.
+
+If you want to require a specific user to be prompted for MFA during their next log in, you can call the [Invalidate Remember Browser API endpoint](https://auth0.com/docs/api/management/v2#!/Users/post_invalidate_remember_browser). This is useful for situations where the user loses a trusted device.
+
+### Customize MFA for users outside the network
+
+Assuming that access to the specified network of internal IP addresses is well controlled, you can also have Auth0 request MFA from only users whose requests originate from outside the corporate network:
+
+```js
+function (user, context, callback) {
+  var ipaddr = require('ipaddr.js');
+  var corp_network = "192.168.1.134/26";
+
+  var current_ip = ipaddr.parse(context.request.ip);
+  if (!current_ip.match(ipaddr.parseCIDR(corp_network))) {
+    context.multifactor = {
+        provider: 'any',
+        allowRememberBrowser: false
+    };
+  }
+
+  callback(null, user, context);
+}
+```
+
+## Customize MFA with social connections
+
+If you are using MFA after an authentication with one or more social providers, you need to use your own application `ID` and `Secret` in the connection to the provider's site in place of the default Auth0 development credentials. For instructions on how to get the credentials for each social provider, select your particular from the list at: [Identity Providers](/identityproviders). In production usage, you should always use your own credentials instead of [Auth0 devkeys](/connections/social/devkeys).
+
+## Keep reading
+
+* [Resource Owner](/mfa/guides/mfa-api/multifactor-resource-owner-password)
+* [Configure Silent Authentication](/api-auth/tutorials/silent-authentication)
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/guides/customize-phone-messages.md b/ja-jp/articles/mfa/guides/customize-phone-messages.md
new file mode 100644
index 0000000000..a33701d54b
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/customize-phone-messages.md
@@ -0,0 +1,54 @@
+---
+description: Customize SMS or Voice Messages
+topics:
+  - mfa
+  - guardian
+  - sms
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Customize SMS or Voice Messages
+
+To customize the SMS or Voice messages sent by Auth0 during enrollment or verification, do the following:
+
+First, go to the [Multi-factor Auth page](${manage_url}/#/mfa), then click on the **Phone** box to configure your Phone Messaging settings.
+
+![MFA Phone Settings](/media/articles/mfa/mfa-phone-templates.png)
+
+You have two fields to customize your messages:
+
+* **Enrollment Template**: the message sent by Auth0 during enrollment.
+* **Verification Template**: the message sent by Auth0 during authentication.
+
+[Liquid](https://github.com/Shopify/liquid/wiki/Liquid-for-Designers) syntax is the supported templating engine to use when accessing user attributes in SMS templates. The following attributes are available:
+
+* `message_type`: Can be "sms" or "voice", and can be used to indicate which kind of message is being sent.
+* `code`: The Enrollment/Verification code. When sending voice messages, this variable will have the value with dots between the digits (e.g. ‘1.2.3.4.5.6’), so it can be pronounced as independent digits by voice messaging providers.
+* `locale`: When using the New Universal Login experience or the MFA API, it will have the the [language selected for the login flow](/universal-login/i18n). 
+* `requestInfo.lang`: The browser Accept-Language header (ie, `es-AR,es;q=0.8`,`en-US,en`, and so on.). It can be used for localization when using the Classic Login Experience.
+* `tenant.friendlyName`: The **Friendly Name** set in [Tenant Settings](${manage_url}/#/tenant).
+* `pause`: A special variable that can be used when you want to make a pause during a voice message.
+
+## Examples
+
+```
+{% if message_type == "voice" %}
+  {% if locale contains "fr" %}
+  Bonjour, vous avez demandé à recevoir un code de vérification pour vous enregister avec {{tenant.friendly_name}}. Votre code est: {{pause}} {{code}}. Je répète, votre code est: {{pause}}{{code}}.
+  {% elsif locale contains "es" %}
+  Usted ha requerido un código de verificación para inscribirse con {{tenant.friendly_name}}. Su código es: {{pause}}{{code}}. Repito, su código es: {{pause}}{{code}}.
+  {% else %}
+  Hello, you requested a verification code to enroll with {{tenant.friendly_name}}. Your code is: {{pause}}{{code}}. I repeat, your code is: {{pause}}{{code}}.
+  {% endif %}
+{% else %}
+  {% if locale contains "fr" %}
+  {{code}} est votre code de vérification pour vous enregistrer avec {{tenant.friendly_name}}.
+  {% elsif locale contains "es" %}
+  {{code}} es su código para inscribirse con {{tenant.friendly_name}}.
+  {% else %}
+  {{code}} is your verification code to enroll with {{tenant.friendly_name}}.
+  {% endif %}
+{% endif %}
+```
diff --git a/ja-jp/articles/mfa/guides/enable-mfa.md b/ja-jp/articles/mfa/guides/enable-mfa.md
new file mode 100644
index 0000000000..fc86a9e176
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/enable-mfa.md
@@ -0,0 +1,40 @@
+---
+description: Learn how to enable MFA in the Dashboard.
+topics:
+  - mfa
+contentType:
+  - how-to
+useCase:
+  - enable-mfa-dashboard
+---
+# Enable Multi-Factor Authentication
+
+To enable MFA, you toggle on the factors (such as push notifications or SMS) you choose to enable in the Dashboard on your tenant. Next, you perform any further setup required to configure that factor, and last, you choose whether you wish to force MFA for all users or not. 
+
+You can also customize your MFA flow with Auth0 [Rules](/rules/references/use-cases#multi-factor-authentication), to allow MFA to only be required in specific circumstances or force a particular factor to be used.
+
+1. To enable the factors you require, go to [Dashboard > Multifactor Auth](${manage_url}/#/mfa). Here you will find a series of toggles for the MFA factors supported by Auth0. 
+
+![MFA Dashboard Page](/media/articles/mfa/mfa-dashboard.png)
+
+Any or all of these factors can be enabled simultaneously. When logging in the first time, the user will be shown the most secure factor available, but will be allowed to choose another factor to use if you have more than one factor enabled in the Dashboard. The Phone messaging and the Duo factors require further setup. You will have to click on the factor and fill in a few further settings before continuing.
+
+::: note
+Duo will only be available to end-users as a factor if it is the only factor that is enabled.
+:::
+
+2. Under **Policies**, next to **Require Multi-factor Auth**, choose **Always** or **Never**. If set to **Always**, users will be able to use any of the factors enabled in the Dashboard.
+
+3. Click **Save**.
+
+4. Configure your [factors](/mfa/concepts/mfa-factors). 
+
+## Keep reading
+
+* [Configure Push Notifications for MFA](/mfa/guides/configure-push)
+* [Configure One Time Passwords for MFA](/mfa/guides/configure-otp)
+* [Configure SMS or Voice Notifications for MFA](/mfa/guides/configure-phone)
+* [Configure Email Notifications for MFA](/mfa/guides/configure-email)
+* [Configure Cisco Duo](/mfa/guides/configure-cisco-duo)
+* [Customize SMS or Voice Messages](/mfa/guides/customize-phone-messages)
+* [Customize Multi-factor Authentication](/mfa/guides/customize-mfa-universal-login)
diff --git a/ja-jp/articles/mfa/guides/guardian/create-enrollment-ticket.md b/ja-jp/articles/mfa/guides/guardian/create-enrollment-ticket.md
new file mode 100644
index 0000000000..f50d2e5fef
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/guardian/create-enrollment-ticket.md
@@ -0,0 +1,134 @@
+---
+description: Learn how to create an enrollment ticket from the MFA API.
+topics:
+  - mfa
+  - step-up-authentication
+  - api
+  - custom-enrollment
+  - tickets
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Create Custom Enrollment Tickets
+
+It is also possible to manage users' enrollments by creating _enrollment tickets_ via the [post_ticket API](/api/management/v2#!/Guardian/post_ticket).
+
+This API will return an _enrollment ticket_ containing a `ticket_id` and a `ticket_url`, which can be used to enroll a user.
+
+The `ticket_url` can be delivered to the user (for instance, via email) and used to kick off the enrollment process.
+
+Alternatively, the ticket can be leveraged inside the [MFA Page](${manage_url}/#/mfa_page) to customize the Auth0 MFA widget's appearance:
+
+```html
+
+
+
+  2nd Factor Authentication
+  
+  
+  
+
+
+
+
+  
      
+    
      
+      
      Welcome! {{ userData.email }} enroll your device
      
+      
      
+
+        
+        
      
+      
      
+    
      
+  
      
+
+  
+
+  
+
+
+```
+
+This custom page displays the Auth0 MFA widget in both enrollment and standard multi-factor authentication (MFA) login scenarios. You can use the ticket variable to check which scenario is in use and control the content accordingly.
+
+For example, the following code displays a different message depending on whether the user is enrolling or authenticating:
+
+```html
+{% if ticket %}
+
      Welcome, {{ userData.email }}, enroll your device below
      
+{% else %}
+
      Welcome back, {{ userData.email }}, authenticate below
      
+{% endif %}
+````
+
+::: note
+The conditional logic around the existence of the `ticket` variable is also used in the initialization of the `Auth0MFAWidget` above.
+:::
+
+## Keep reading
+
+* [MFA Widget Reference](/mfa/references/mfa-widget-reference)
\ No newline at end of file
diff --git a/ja-jp/articles/mfa/guides/guardian/guardian-android-sdk.md b/ja-jp/articles/mfa/guides/guardian/guardian-android-sdk.md
new file mode 100644
index 0000000000..48f60e38c5
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/guardian/guardian-android-sdk.md
@@ -0,0 +1,162 @@
+---
+title: Guardian for Android SDK
+description: Learn how to install, use and configure options for the Guardian for Android SDK. 
+topics:
+  - mfa
+  - guardian
+  - android
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Guardian for Android SDK
+
+The [Guardian for Android SDK](https://github.com/auth0/Guardian.Android) helps you create Android apps with Guardian functionality, providing secure access to multi-factor authentication (MFA) with push notifications. With this toolkit you can build your own customized version of the Guardian application that matches the look and feel of your organization.
+
+## Requirements
+
+Android API level 15+ is required in order to use the Guardian Android SDK.
+
+## Install Guardian Android SDK
+
+Guardian is available both in [Maven Central](http://search.maven.org) and [JCenter](https://bintray.com/bintray/jcenter). 
+
+1. To start using *Guardian* add these lines to your `build.gradle` dependencies file:
+
+    ```gradle
+    implementation 'com.auth0.android:guardian:0.4.0'
+    ```
+
+::: note
+You can check for the latest version on the repository [Releases](https://github.com/auth0/GuardianSDK.Android/releases) tab, in [Maven](http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22com.auth0.android%22%20AND%20a%3A%22guardian%22), or in [JCenter](https://bintray.com/auth0/android/Guardian.Android).
+:::
+
+2. After adding your Gradle dependency, make sure to remember to sync your project with Gradle files.
+
+<%= include('../../_includes/_enable-push-notifications') %>
+
+<%= include('../../_includes/_configure-sns') %>
+
+## Use the SDK
+
+Guardian is the core of the SDK. You'll need to create an instance of this class for your specific tenant/url.
+
+```java
+Uri url = Uri.parse("https://tenant.guardian.auth0.com/");
+
+Guardian guardian = new Guardian.Builder()
+    .url(url)
+    .build();
+```
+
+or
+
+```java
+String domain = "tenant.guardian.auth0.com";
+
+Guardian guardian = new Guardian.Builder()
+    .domain(domain)
+    .build();
+```
+
+### Enroll
+
+The link between the second factor (an instance of your app on a device) and an Auth0 account is referred to as an enrollment.
+
+You can create an enrollment using the `Guardian.enroll` function, but first you'll have to create a new pair of RSA keys for it. The private key will be used to sign the requests to allow or reject a login. The public key will be sent during the enroll process so the server can later verify the request's signature.
+
+```java
+KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance("RSA");
+keyPairGenerator.initialize(2048); // you MUST use at least 2048 bit keys
+KeyPair keyPair = keyPairGenerator.generateKeyPair();
+```
+
+Next, obtain the enrollment information by scanning the Guardian QR code, and use it to enroll the account:
+
+```java
+Uri enrollmentUriFromQr = ...; // the URI obtained from a Guardian QR code
+
+CurrentDevice device = new CurrentDevice(context, "fcmToken", "deviceName");
+
+Enrollment enrollment = guardian
+    .enroll(enrollmentUriFromQr, device, keyPair)
+    .execute();
+```
+
+Alternatively, you can execute the request in a background thread:
+
+```java
+guardian
+    .enroll(enrollmentUriFromQr, device, keyPair)
+    .start(new Callback {
+        @Override
+        void onSuccess(Enrollment enrollment) {
+            // we have the enrollment data
+        }
+
+        @Override
+        void onFailure(Throwable exception) {
+            // something failed
+        }
+    });
+```
+
+The `deviceName` and `fcmToken` are data that you must provide:
+
+- The `deviceName` is the name that you want for the enrollment. It will be displayed to the user when the second factor is required.
+- The `fcmToken` is the token for Firebase Cloud Messaging push notification service. See the [docs](https://firebase.google.com/docs/cloud-messaging/android/client#sample-register) for more information about the FCM token.
+
+### Unenroll
+
+To disable multi-factor authentication you can delete the enrollment:
+
+```java
+guardian
+    .delete(enrollment)
+    .execute(); // or start(new Callback<> ...)
+```
+
+### Allow a login request
+
+Once you have the enrollment in place, you'll receive a FCM push notification every time the user needs multi-factor authentication.
+
+Guardian provides a method to parse the `Map` data inside the [RemoteMessage](https://firebase.google.com/docs/reference/android/com/google/firebase/messaging/RemoteMessage) received from FCM and return a `Notification` instance ready to be used.
+
+```java
+// at the FCM listener you receive a RemoteMessage
+@Override
+public void onMessageReceived(RemoteMessage message) {
+    Notification notification = Guardian.parseNotification(message.getData());
+    if (notification != null) {
+        // you received a Guardian notification, handle it
+        handleGuardianNotification(notification);
+        return;
+    }
+
+    /* handle other push notifications you might be using ... */
+}
+```
+
+Once you have the notification instance, you can approve the authentication request by using the `allow` method. You'll also need the enrollment that you obtained previously. If there are multiple enrollments, be sure to use the one that has the same `id` as the notification (the `enrollmentId` property).
+
+```java
+guardian
+    .allow(notification, enrollment)
+    .execute(); // or start(new Callback<> ...)
+```
+
+### Reject a login request
+
+To deny an authentication request, use `reject` instead. You can also add an optional reason for the rejection, which will be available in the guardian logs.
+
+```java
+guardian
+    .reject(notification, enrollment) // or reject(notification, enrollment, reason)
+    .execute(); // or start(new Callback<> ...)
+```
+
+## Keep reading
+
+* [Getting Started with Google Cloud Messaging for Android](https://docs.aws.amazon.com/sns/latest/dg/mobile-push-gcm.html)
+* 
diff --git a/ja-jp/articles/mfa/guides/guardian/guardian-ios-sdk.md b/ja-jp/articles/mfa/guides/guardian/guardian-ios-sdk.md
new file mode 100644
index 0000000000..125aa8a0c3
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/guardian/guardian-ios-sdk.md
@@ -0,0 +1,187 @@
+---
+title: Guardian for iOS SDK
+description: Learn how to install, use and configure options for the Guardian for iOS SDK. 
+topics:
+  - mfa
+  - guardian
+  - ios
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Guardian for iOS SDK
+
+The [Guardian for iOS Software Development Kit](https://github.com/auth0/GuardianSDK.iOS) helps you create iOS apps with Guardian functionality, providing secure access to multi-factor authentication (MFA) with push notifications. With this toolkit you can build your own customized version of the Guardian application that matches the look and feel of your organization.
+
+For more general information on MFA, see [multi-factor authentication](/mfa).
+
+## Requirements
+
+The Guardian iOS SDK requires iOS 9.3+ and Swift 3.
+
+## Install Guardian iOS SDK
+
+### CocoaPods
+
+Guardian.swift is available through [CocoaPods](http://cocoapods.org).
+To install it, simply add the following line to your Podfile:
+
+```ruby
+pod "Guardian"
+```
+
+### Carthage
+
+In your Cartfile add this line
+
+```
+github "auth0/Guardian.swift"
+```
+
+<%= include('../../_includes/_enable-push-notifications') %>
+
+<%= include('../../_includes/_configure-sns') %>
+
+## Using the SDK
+
+`Guardian` is the core of the SDK. To get things going you'll have to import the library:
+
+```swift
+import Guardian
+```
+
+Then you'll need the Auth0 Guarduan domain for your account:
+
+```swift
+let domain = "{YOUR_ACCOUNT_NAME}.guardian.auth0.com"
+```
+
+### Enroll
+
+An enrollment is a link between the second factor and an Auth0 account. When an account is enrolled you'll need it to provide the second factor required to verify the identity.
+
+For an enrollment you need the following things, besides your Guardian Domain:
+
+- Enrollment Uri: The value encoded in the QR Code scanned from Guardian Web Widget or in your enrollment ticket sent to you, for example, by email.
+- APNS Token: Apple APNS token for the device and **MUST** be a `String`containing the 64 bytes (expressed in hexadecimal format)
+- Key Pair: A RSA (Private/Public) key pair used to assert your identity with Auth0 Guardian
+
+::: note
+In case your app is not yet using push notifications or you're not familiar with it, you should check their [docs](https://developer.apple.com/go/?id=push-notifications).
+:::
+
+After your have all of them, you can enroll your device:
+
+```swift
+Guardian
+        .enroll(forDomain: "{YOUR_GUARDIAN_DOMAIN}",
+                usingUri: "{ENROLLMENT_URI}",
+                notificationToken: "{APNS_TOKEN}",
+                keyPair: keyPair)
+        .start { result in
+            switch result {
+            case .success(let enrollment):
+                // success, we have the enrollment data available
+            case .failure(let cause):
+                // something failed, check cause to see what went wrong
+            }
+        }
+```
+
+On success you'll obtain the enrollment information, that should be secured stored in your application. This information includes the enrollment identifier, and the token for Guardian API associated to your device for updating or deleting your enrollment.
+
+#### RSA key pair
+
+Guardian.swift provides a convenience class to generate an RSA key pair and store it in iOS Keychain.
+
+```swift
+let rsaKeyPair = RSAKeyPair.new(
+    usingPublicTag: "com.auth0.guardian.enroll.public",
+    privateTag: "com.auth0.guardian.enroll.private"
+    )
+```
+
+::: note
+The tags should be unique since it's the identifier of each key inside iOS Keychain.
+:::
+
+::: note
+Since the keys are already secured stored inside iOS Keychain, you olny need to store the identifiers
+:::
+
+### Allow a login request
+
+Once you have the enrollment in place, you will receive a push notification every time the user has to validate their identity with MFA.
+
+Guardian provides a method to parse the data received from APNs and return a `Notification` instance ready to be used.
+
+```swift
+if let notification = Guardian.notification(from: notificationPayload) {
+    // we have received a Guardian push notification
+}
+```
+
+Once you have the notification instance, you can easily allow the authentication request by using
+the `allow` method. You'll also need the enrollment that you obtained previously.
+In case you have more than one enrollment, you'll have to find the one that has the same `id` as the
+notification (the `enrollmentId` property).
+
+```swift
+Guardian
+        .authentication(forDomain: "{YOUR_GUARDIAN_DOMAIN}", andEnrollment: enrollment)
+        .allow(notification: notification)
+        .start { result in
+            switch result {
+            case .success:
+                // the auth request was successfully allowed
+            case .failure(let cause):
+                // something failed, check cause to see what went wrong
+            }
+        }
+```
+
+### Reject a login request
+
+To deny an authentication request call `reject` instead. You can also send an optional reject reason if
+you want. The reject reason will be available in the guardian logs.
+
+```swift
+Guardian
+        .authentication(forDomain: "{YOUR_GUARDIAN_DOMAIN}", andEnrollment: enrollment)
+        .reject(notification: notification)
+        // or reject(notification: notification, withReason: "hacked")
+        .start { result in
+            switch result {
+            case .success:
+                // the auth request was successfully rejected
+            case .failure(let cause):
+                // something failed, check cause to see what went wrong
+            }
+        }
+```
+
+### Unenroll
+
+If you want to delete an enrollment -for example if you want to disable MFA- you can make the
+following request:
+
+```swift
+Guardian
+        .api(forDomain: "{YOUR_GUARDIAN_DOMAIN}")
+        .device(forEnrollmentId: "{USER_ENROLLMENT_ID}", token: "{ENROLLMENT_DEVICE_TOKEN}")
+        .delete()
+        .start { result in
+            switch result {
+            case .success:
+                // success, the enrollment was deleted
+            case .failure(let cause):
+                // something failed, check cause to see what went wrong
+            }
+        }
+```
+
+## Keep reading
+
+* [Configure Push Notifications for MFA](/mfa/guides/configure-push)
+* [Getting Started with Apple Push Notification Service](https://docs.aws.amazon.com/sns/latest/dg/mobile-push-apns.html)
diff --git a/ja-jp/articles/mfa/guides/guardian/install-guardian-sdk.md b/ja-jp/articles/mfa/guides/guardian/install-guardian-sdk.md
new file mode 100644
index 0000000000..a1fe64bcfc
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/guardian/install-guardian-sdk.md
@@ -0,0 +1,221 @@
+---
+description: Learn how to install, use and configure options for the Guardian SDKs. 
+topics:
+  - mfa
+  - guardian
+  - ios
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Install Guardian SDK
+
+The Guardian SDK provides a UI-less client for Guardian.
+
+```text
+npm install auth0-guardian-js
+```
+
+## Source files
+
+* [Full Version](https://cdn.auth0.com/js/guardian-js/1.3.3/guardian-js.js)
+* [Minified Version](https://cdn.auth0.com/js/guardian-js/1.3.3/guardian-js.min.js)
+
+## Configure Guardian
+
+```js
+var auth0GuardianJS = require('auth0-guardian-js')({
+	// For US tenants: https://{name}.guardian.auth0.com
+ 	// For AU tenants: https://{name}.au.guardian.auth0.com
+ 	// For EU tenants: https://{name}.eu.guardian.auth0.com
+	serviceUrl: "https://{{ userData.tenant }}.guardian.auth0.com",
+	requestToken: "{{ requestToken }}", // or ticket: "{{ ticket }}" - see below
+
+	issuer: {
+		// The issuer name to show in OTP Generator apps
+		label: "{{ userData.tenantFriendlyName }}",
+		name: "{{ userData.tenant }}",
+	},
+
+	// The account label to show in OTP Generator apps
+	accountLabel: "{{ userData.friendlyUserId }}",
+
+	// Optional, for debugging purpose only,
+	// ID that allows to associate a group of requests
+	// together as belonging to the same "transaction" (in a wide sense)
+	globalTrackingId: "{{ globalTrackingId }}"
+});
+```
+
+Use of `requestToken` or `ticket` depends on the authentication method. Ticket corresponds to a previously generated [enrollment ticket](/mfa/guides/guardian/create-enrollment-ticket).
+
+## Enroll devices
+
+Enrolling devices consists of the following steps:
+
+1. Start the transaction.
+2. (optional) Chck if the user is already enrolled. You cannot enroll twice.
+3. Send the information needed to enroll.
+4. Confirm enrollment.
+5. Show recovery code.
+
+Some steps can be omitted depending on the method, we provide the same interface for all methods so you can write uniform code. Some of the methods end up completing the authentication, whereas some others need an extra authentication step. You can know that by listening to the `enrollment-complete` event. 
+
+```js
+function enroll(transaction, method) {
+	if (transaction.isEnrolled()) {
+		console.log('You are already enrolled');
+		return;
+	}
+
+	var enrollData = {};
+
+	if (method === 'sms') {
+		enrollData.phoneNumber = prompt('Phone number'); // Collect phone number
+	}
+
+	return transaction.enroll(method, enrollData, function (err, otpEnrollment) {
+		if (err) {
+			console.error(err);
+			return;
+		}
+
+		var uri = otpEnrollment.getUri();
+		if (uri) {
+			showQR(uri);
+		}
+
+		var confirmData = {};
+		if (method === 'otp' || method === 'sms') {
+			confirmData.otpCode = prompt('Otp code'); // Collect verification otp
+		}
+
+		otpEnrollment.confirm(confirmData);
+	});
+}
+
+auth0GuardianJS.start(function(err, transaction) {
+	if (err) {
+		console.error(err);
+		return;
+	}
+
+	transaction.on('error', function(error) {
+		console.error(error);
+	});
+
+	transaction.on('timeout', function() {
+		console.log('Timeout');
+	});
+
+	transaction.on('enrollment-complete', function(payload) {
+		if (payload.recoveryCode) {
+			alert('Recovery code is ' + payload.recoveryCode);
+		}
+
+		if (payload.authRequired) {
+			showAuthenticationFor(transaction, payload.enrollment);
+			return;
+		}
+	});
+
+	transaction.on('auth-response', function(payload) {
+		if (payload.recoveryCode) {
+			alert('The new recovery code is ' + payload.recoveryCode);
+		}
+
+		if (!payload.accepted) {
+			alert('Authentication has been rejected');
+			return;
+		}
+
+		auth0GuardianJS.formPostHelper('{{ postActionURL }}', { signature: payload.signature });
+	});
+
+	var availableEnrollmentMethods = transaction.getAvailableEnrollmentMethods();
+
+	method = prompt('What method do you want to use, select one of '
+		+ availableEnrollmentMethods.join(', '));
+
+	enroll(transaction, method) // For sms
+});
+```
+
+## Authenticate
+
+To authenticate with a method you need to execute the following steps:
+
+1. Start the transaction.
+2. (optional) Check if the user is already enrolled. You need to be enrolled to authenticate.
+3. Request the auth (the push notification / sms). Request is a noop for OTP.
+4. Verify the otp (`.verify` is a noop for push)
+
+Some steps can be omitted depending on the method, we provide the same interface for all methods so you can write uniform code. After the factor is verified or the push accepted you will receive an `auth-response` event with the payload to send to the server, you can use the `auth0GuardianJS.formPostHelper('{{ postActionURL }}', payload)` to post back the message to the server.
+
+You may also receive `auth-rejected` if the push notification was received.
+
+```js
+function authenticate(method) {
+	auth0GuardianJS.start(function (err, transaction) {
+		if (err) {
+			console.error(err);
+			return;
+		}
+
+		if (!transaction.isEnrolled()) {
+			console.log('You are not enrolled');
+			return;
+		}
+
+		transaction.on('error', function(error) {
+			console.error(error);
+		});
+
+		transaction.on('timeout', function() {
+			console.log('Timeout');
+		});
+
+		transaction.on('auth-response', function(payload) {
+			if (payload.recoveryCode) {
+				alert('The new recovery code is ' + payload.recoveryCode);
+			}
+
+			if (!payload.accepted) {
+				alert('Authentication has been rejected');
+				return;
+			}
+
+			auth0GuardianJS.formPostHelper('{{ postActionURL }}', { signature: payload.signature });
+		});
+
+		var enrollment = transaction.getEnrollments()[0];
+
+		if (enrollment.getAvailableAuthenticatorTypes().length === 0) {
+			alert('Somethings went wrong, seems that there is no authenticators');
+			return;
+		}
+
+		transaction.requestAuth(enrollment, { method: method } function(err, auth) {
+			if (err) {
+				console.error(err);
+				return;
+			}
+
+			var data = {};
+			if (method === 'sms' || method === 'otp') {
+				data.otpCode = prompt('Otp code');
+			} else if (method === 'recovery-code') {
+				data.recoveryCode = prompt('Recovery code');
+			}
+
+			return auth.verify(data);
+		});
+	});
+}
+```
+
+## Keep reading
+
+* [Full Guardian API](https://github.com/auth0/auth0-guardian.js#full-api)
+* [Guarding SDK Error Code Reference](/mfa/references/guardian-error-code-reference)
diff --git a/ja-jp/articles/mfa/guides/import-user-mfa.md b/ja-jp/articles/mfa/guides/import-user-mfa.md
new file mode 100644
index 0000000000..963de16bd9
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/import-user-mfa.md
@@ -0,0 +1,163 @@
+---
+description: Import MFA enrollments for your existing users.
+topics:
+  - mfa
+contentType:
+  - how-to
+useCase:
+  - import-mfa
+---
+# Import Multi-Factor Authenticators
+
+You can import a user's MFA enrollments with [automatic migration](/users/guides/configure-automatic-migration) and [bulk user imports](/users/guides/bulk-user-imports). The supported enrollment types are:
+
+* Email: for [email](/mfa/concepts/mfa-factors#email-notifications) verification.
+* Phone: for [SMS](/mfa/concepts/mfa-factors#sms-notifications) or [Voice](/mfa/concepts/mfa-factors#voice-notifications) verification.
+* TOTP: for [One-Time Passwords (OTP)](/mfa/concepts/mfa-factors#one-time-passwords) used with authenticator applications, such as Google Authenticator.
+
+Importing MFA enrollments provides a seamless user experience, since users won't have to re-enroll after migration.
+
+::: warning
+Please note that the classic login experience does not support factor selection for users with multiple factors. If you plan to import users with multiple registered factors, consider using the [universal login](/universal-login) experience.
+
+:::
+
+## Schema
+
+The schema applies to MFA factors for both of the aforementioned workflows.
+
+```json
+{
+    "type": "array",
+    "items": {
+        "type": "object",
+        "properties": {
+            "totp": {
+                "type": "object",
+                "properties": {
+                "secret": {
+                    "type": "string",
+                        "pattern": "^[A-Z2-7]+$",
+                        "description": "The OTP secret is used for MFA authentication with Google Authenticator type apps. It must be supplied in un-padded Base32 encoding, such as: JBTWY3DPEHPK3PNP"
+                    },
+                },
+                "additionalProperties": false,
+                "required": ["secret"],
+            },
+            "phone": {
+                "type": "object",
+                "properties": {
+                "value": {
+                    "type": "string",
+                    "pattern": "^\\+[0-9]{1,15}$",
+                    "description": "The phone number for SMS or Voice MFA. The phone number should include a country code and begin with +, such as: +12125550001"
+                },
+                },
+                "additionalProperties": false,
+                "required": ["value"],
+            },
+            "email": {
+                "type": "object",
+                "properties": {
+                    "value": {
+                        "type": "string",
+                        "format": "email",
+                        "description": "The email address for MFA"
+                    },
+                },
+                "additionalProperties": false,
+                "required": ["value"],
+            },
+        },
+        "maxProperties": 1,
+        "additionalProperties": false,
+    },
+    "minItems": 1,
+    "maxItems": 10
+}
+```
+
+## Bulk User Import
+
+To begin, prepare a `users.json` file as described [here](/users/guides/bulk-user-imports). Be sure to include any existing MFA enrollments for each user. Next, start a bulk user import (described in more detail [here](/users/guides/bulk-user-imports#request-bulk-user-import)). You can _update_ the factors of any existing users by enabling the `upsert` option in your initial request.
+
+Once the import job completes, check the response for any errors. If any of the users' MFA factors failed to import, you will see errors such as: 
+
+```json
+{
+  "code": "MFA_FACTORS_FAILED",
+  "message": "Unable to import factors"
+}
+```
+
+When using the `upsert` option, any non-MFA related updates to existing users will have been applied to the user's profile. For example, the following error summary shows the user's `picture` attribute was successfully set to `http://example.org/jdoe.png`, however we were unable to import the provided MFA factors. In cases like this it is safe to retry the import for failed users.
+
+```json
+[
+  {
+    "user": {
+      "email": "antoinette@contoso.com",
+      "picture": "http://example.org/jdoe.png",
+      "mfa_factors": [
+        {
+          "totp": {
+            "secret": "2PRXZWZAYYDAWCD"
+          }
+        },
+        {
+          "phone": {
+            "value": "+15551112233"
+          }
+        },
+        {
+          "email": {
+            "value": "antoinette@antoinette.biz"
+          }
+        }
+      ]
+    },
+    "errors": [
+      {
+        "code": "MFA_FACTORS_FAILED",
+        "message": "Unable to import factors"
+      }
+    ]
+  }
+]
+```
+
+## Automatic Migration
+
+MFA enrollments can also be imported during an [automatic migration](/connections/database/custom-db/overview-custom-db-connections#automatic-migration-scenario). This can be accomplished by providing any existing enrollments in the `mfa_factors` field of the user that is provided to the callback at the end of your custom DB [login script](/connections/database/custom-db/templates/login).
+
+Any failures will appear in your tenant logs as failed logins, and will be distinguishable from other failures by their description: `Unable to import MFA factors`. For instance:
+
+```json
+{
+  "_id": "5e9df3b29ebabe00571c04a7",
+  "date": "2020-04-20T19:10:42.916Z",
+  "type": "fu",
+  "description": "Unable to import MFA factors.",
+  "connection": "Username-Password-Authentication",
+  "connection_id": "con_mMkvaycgzgCS0p0z",
+  "client_id": "aCbTAJNi5HbsjPJtRpSP6BIoLPOrSj2Cgg",
+  "client_name": "All Applications",
+  "ip": "10.12.13.1",
+  "client_ip": null,
+  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36",
+  "details": {
+    "error": {
+      "message": "Unable to import MFA factors."
+    }
+  },
+  "user_name": "test@test.io",
+  "strategy": "auth0",
+  "strategy_type": "database"
+}
+```
+
+## Recovery Codes
+
+Auth0 does not provide a way to import Recovery Codes. When the users's MFA factors are imported, they won't have a recovery code.
+
+If you want to provide users for a recovery code, you can check if they have one enrolled, and if not, use the [recovery code regeneration](/api/management/v2#!/Users/post_recovery_code_regeneration) API endpoint to generate a new one.
diff --git a/ja-jp/articles/mfa/guides/mfa-api/authenticate.md b/ja-jp/articles/mfa/guides/mfa-api/authenticate.md
new file mode 100644
index 0000000000..219932f6e9
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/mfa-api/authenticate.md
@@ -0,0 +1,137 @@
+---
+title: Authenticate With Resource Owner Password Grant and MFA
+description: Authenticate With Resource Owner Password Grant and MFA
+topics:
+  - mfa
+  - mfa-api
+  - mfa-authenticators
+  - otp
+contentType:
+  - how-to
+  - reference
+useCase:
+  - customize-mfa
+---
+# Authenticate With Resource Owner Password Grant and MFA
+
+This guide explains how to use the MFA API to complete the authentication flow using [Resource Owner Password Grant](/api-auth/tutorials/password-grant) when MFA is enabled.
+
+<%= include('../../_includes/_authenticator-before-start') %>
+
+## 1. Authenticate the User
+
+When you use the Resource Owner Password Grant to authenticate, you call the `/oauth/token` endpoint with the user's username/password: 
+
+```har
+{
+"method": "POST",
+"url": "https://${account.namespace}/oauth/token",
+"headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+],
+"postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+    {
+        "name": "grant_type",
+        "value": "password"
+    },
+    {
+        "name": "username",
+        "value": "user@example.com"
+    },
+    {
+        "name": "password",
+        "value": "pwd"
+    },
+    {
+        "name": "client_id",
+        "value": "${account.clientId}"
+    },
+    {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+    },
+    {
+        "name": "audience",
+        "value": "https://someapi.com/api"
+    },
+    {
+        "name": "scope",
+        "value": "openid profile read:sample"
+    }
+    ]
+}
+}
+```
+
+When MFA is enabled, the response will include an `mfa_required` error and a `mfa_token`.
+
+```json
+{
+    "error": "mfa_required",
+    "error_description": "Multifactor authentication required",
+    "mfa_token": "Fe26...Ha"
+}
+```
+
+## 2. Retrieve the Enrolled Authenticators
+
+After getting the error above, you need to find out if the user has an MFA factor enrolled or not. Call [`/mfa/authenticators`](/mfa/guides/mfa-api/manage#list-authenticators) endpoint, using the MFA token obtained in the previous step.
+
+```har
+{
+    "method": "GET",
+	"url": "https://${account.namespace}/mfa/authenticators",
+    "headers": [
+    { "name": "Authorization", "value": "Bearer MFA_TOKEN" },
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ]
+}
+```
+
+You will get an array with the available authenticators. The array will be empty if the user did not enroll any factor.
+
+```json
+[
+    {
+        "id": "recovery-code|dev_O4KYL4FtcLAVRsCl",
+        "authenticator_type": "recovery-code",
+        "active": true
+    },
+    {
+        "id": "email|dev_NU1Ofuw3Cw0XCt5x",
+        "authenticator_type": "oob",
+        "active": true,
+        "oob_channels": "email",
+        "name": "email@address.com"
+    }
+]
+```
+
+## 3. Enroll an MFA Factor
+
+If the user is not enrolled in MFA, use the MFA token obtained earlier, and enroll it using the `/mfa/associate` endpoint. The documents linked below explain how to implement this flow depending on the authentication factor:
+
+- [Enrolling with SMS or Voice](/mfa/guides/mfa-api/phone#enrolling-with-sms-or-voice)
+- [Enrolling with OTP](/mfa/guides/mfa-api/otp#enrolling-with-otp)
+- [Enrolling with Push](/mfa/guides/mfa-api/push#enrolling-with-push)
+- [Enrolling with Email](/mfa/guides/mfa-api/email#enrolling-with-email)
+
+## 4. Challenge the User with MFA
+
+If the user is already enrolled in MFA, you need to challenge the user with one of the existing factors. Use the `authenticator_id` returned by the `/mfa/authenticators` endpoint when calling the `/mfa/challenge` endpoint. 
+
+After the challenge is completed, call `/oauth/token` again to finalize the authentication flow and get the authentication tokens. 
+
+The documents linked below explain how to implement this flow depending on the authentication factor:
+
+- [Challenging with SMS](/mfa/guides/mfa-api/phone#challenging-with-sms-or-voice)
+- [Challenging with OTP](/mfa/guides/mfa-api/otp#challenging-with-otp)
+- [Challenging with Push](/mfa/guides/mfa-api/push#challenging-with-push)
+- [Challenging with Email](/mfa/guides/mfa-api/email#challenging-with-email)
+- [Challenging with Recovery Code](/mfa/guides/mfa-api/recovery-code)
+
+## Keep reading
+
+* [Managing MFA Enrollments](/mfa/guides/mfa-api/manage)
diff --git a/ja-jp/articles/mfa/guides/mfa-api/email.md b/ja-jp/articles/mfa/guides/mfa-api/email.md
new file mode 100644
index 0000000000..4cd4ba8dbb
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/mfa-api/email.md
@@ -0,0 +1,208 @@
+---
+title: Enroll and Challenge Email Authenticators
+description: Build your own MFA flows using email as a factor.
+topics:
+  - mfa
+  - mfa-api
+  - mfa-authenticators
+  - email
+contentType:
+  - how-to
+  - reference
+useCase:
+  - customize-mfa
+---
+# Enroll and Challenge Email Authenticators
+
+Auth0 provides a built-in MFA enrollment and authentication flow using [Universal Login](/universal-login). However, if you want to create your own user interface, you can use the MFA API to accomplish it. 
+
+This guide will explain how to enroll and challenge users with Email using the MFA API. Make sure that Email is [enabled as factor](/mfa/guides/configure-email) in the Dashboard or using the [Management API](/api/management/v2#!/Guardian/put_factors_by_name).
+
+
+::: note
+When Email is enabled as factor, all users with verified emails will be able to use them to complete MFA.
+
+Email authenticators are not supported when using the Classic Universal Login experience.
+:::
+
+<%= include('../../_includes/_authenticator-before-start') %>
+
+## Enrolling with Email
+
+If you want to enable users enroll additional emails, in addition of the verified email in their primary identity, you need to complete the following steps.
+
+### 1. Get the MFA token
+
+<%= include('../../_includes/_get_mfa_token') %>
+
+### 2. Enroll the Authenticator 
+
+To enroll with Email, you need to use the following parameters:
+
+- `authentication_types` = `[oob]`
+- `oob_channels` = `[email]`
+- `email` = `email@address.com`, the user's email address.
+
+  ```har
+  {
+      "method": "POST",
+      "url": "https://${account.namespace}/mfa/associate",
+      "headers": [{
+          "name": "Authorization",
+          "value": "Bearer MFA_TOKEN"
+      }],
+      "postData": {
+          "mimeType": "application/json",
+          "text": "{ \"authenticator_types\": [\"oob\"], \"oob_channels\": [\"email\"], \"email\" : \"email@address.com\" }"
+      }
+  }
+  ```
+
+  If successful, you'll receive a response like this:
+
+  ```json
+  {
+    "authenticator_type": "oob",
+    "binding_method": "prompt",
+    "oob_code" : "Fe26..nWE",
+    "oob_channel": "email",
+    "recovery_codes": [ "N3BGPZZWJ85JLCNPZBDW6QXC" ]
+  }
+  ```
+
+If you get a `User is already enrolled error`, the user already has an MFA factor enrolled. Before associating another factor with the user, you need to challenge the user with the existing factor.
+
+#### Recovery Codes
+
+<%= include('../../_includes/_recovery_codes') %>
+
+### 3. Confirm the email enrollment
+
+The user should receive an email containing the 6-digit code, which they can provide to the application.
+
+To complete enrollment of the email authenticator make a `POST` request to the `oauth/token` endpoint. You need to include the `oob_code` returned in the previous response, and the `binding_code` with the value received in the email message.
+
+```har
+{
+    "method": "POST",
+    "url": "https://${account.namespace}/oauth/token",
+    "postData": {
+        "mimeType": "application/x-www-form-urlencoded",
+        "params": [
+          {
+            "name": "grant_type",
+            "value": "http://auth0.com/oauth/grant-type/mfa-oob"
+          },
+          {
+            "name": "mfa_token",
+            "value": "MFA_TOKEN"
+          },
+          {
+            "name": "oob_code",
+            "value": "OOB_CODE"
+          },
+          {
+            "name": "binding_code",
+            "value": "USER_EMAIL_OTP_CODE"
+          },
+          {
+            "name": "client_id",
+            "value": "${account.clientId}"
+          }
+        ]
+    }
+}
+```
+
+For more information on how to customize the email that users get, check [Customizing Your Emails](/email/templates).
+
+<%= include('../../_includes/_successful_confirmation') %>
+
+## Challenging with Email
+
+To challenge a user with Email, follow the steps detailed below.
+
+### 1. Get the MFA token
+
+<%= include('../../_includes/_get_mfa_token_challenge') %>
+
+### 2. Challenge the user with Email
+
+To challenge the user you first need to obtain the id of the authenticator you want to challenge using the [`/mfa/enrollments`](/mfa/guides/mfa-api/manage#list-authenticators) endpoint.
+
+To trigger an email challenge, `POST` to the to `mfa/challenge` endpoint, using the corresponding `authenticator_id` ID and the `mfa_token`. 
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/mfa/challenge",
+	"postData": {
+		"mimeType": "application/json",
+		"text": "{  \"client_id\": \"YOUR_CLIENT_ID\",  \"client_secret\": \"YOUR_CLIENT_SECRET\",  \"challenge_type\": \"oob\",  \"authenticator_id\": \"email|dev_NU1Ofuw3Cw0XCt5x\", \"mfa_token\": \"MFA_TOKEN\" }"
+	}
+}
+```
+
+### 3. Complete authentication using the received code
+
+If successful, you'll get the following response, and the user will get an email message containing the six-digit code:
+
+```json
+{
+  "challenge_type": "oob",
+  "oob_code": "abcd1234...",
+  "binding_method": "prompt"
+}
+```
+
+Your application needs to prompt the user for the code, and send it as part of the request, in the `binding_code` parameter, in the following call to the `/oauth/token` endpoint:
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "http://auth0.com/oauth/grant-type/mfa-oob"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "CLIENT_SECRET"
+      },
+      {
+        "name": "mfa_token",
+        "value": "MFA_TOKEN"
+      },
+      {
+        "name": "oob_code",
+        "value": "OOB_CODE"
+      },
+      {
+        "name": "binding_code",
+        "value": "USER_EMAIL_OTP_CODE"
+      }
+    ]
+  }
+}
+```
+
+<%= include('../../_includes/_successful_challenge') %>
+
+## Keep Reading
+
+* [Configure Email Notifications for MFA](/mfa/guides/configure-email)
+* [Managing MFA Enrollments](/mfa/guides/mfa-api/manage)
+* [Enroll and Challenge Push Authenticators](/mfa/guides/mfa-api/push)
+* [Enroll and Challenge OTP Authenticators](/mfa/guides/mfa-api/otp)
+* [Enroll and Challenge SMS Authenticators](/mfa/guides/mfa-api/sms)
+* [Challenge a Recovery Code](/mfa/guides/mfa-api/recovery-code)
diff --git a/ja-jp/articles/mfa/guides/mfa-api/manage.md b/ja-jp/articles/mfa/guides/mfa-api/manage.md
new file mode 100644
index 0000000000..128406fe8a
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/mfa-api/manage.md
@@ -0,0 +1,149 @@
+---
+title: Manage Authenticator Factors using the MFA API
+description: Learn how to manage your MFA authenticators
+topics:
+  - mfa
+  - mfa-api
+  - mfa-authenticators
+contentType:
+  - how-to
+  - reference
+useCase:
+  - customize-mfa
+---
+# Manage Authenticator Factors using the MFA API
+
+Auth0 provides several API endpoints to help you manage the authenticators you're using with an application for multi-factor authentication (MFA).
+
+You can use these endpoints to build a complete user interface for letting users manage their authenticator factors. 
+
+<%= include('../../_includes/_authenticator-before-start') %>
+
+## Getting an MFA API Access Token
+
+In order to call the MFA API to manage enrollments, you first need to obtain an Access Token for the MFA API.
+
+If you want to use the MFA API as part of an authentication flow, you can follow the steps detailed in the [Authenticate With Resource Owner Password Grant and MFA](/mfa/guides/mfa-api/authenticate) document.
+
+If you are building a user interface to manage authentication factors, you'll need to obtain a token you can use for the MFA API at any moment, not only during authentication:
+
+* If you are using [Universal Login](/universal-login), redirect to the `/authorize` endpoint, specifying the `https://${account.namespace}/mfa/` audience, before using calling the MFA API.
+* If you are using the Resource Owner Password Grant, you have two options:
+    * Ask for the `https://${account.namespace}/mfa/` audience when logging-in, and use a [Refresh Token](/tokens/concepts/refresh-tokens) to refresh it later.
+    * If you need to list and delete authenticators, ask the user to [authenticate again](/mfa/guides/mfa-api/authenticate) with `/oauth/token`, specifying the `https://${account.namespace}/mfa/` audience. Users will need to complete MFA before being able to list/delete the authentication factors. 
+    * If you only need to list authenticators, ask the user to [authenticate again](/mfa/guides/mfa-api/authenticate) using `/oauth/token`, with username/password. The endpoint will return an `mfa_required` error, and an `mfa_token` you can use to list authenticators. Users will need to provide their password to see their authenticators.
+
+When you request a token for the MFA audience, you can request the following scopes:
+
+* `enroll`: needed to enroll a new authenticator
+* `read:authenticators`: needed to list existing authenticators
+* `remove:authenticators`: needed to delete an authenticator
+
+## List Authenticators
+
+To get the list of the authenticators for a user, you can call the `/mfa/authenticators` endpoint:
+
+```har
+{
+	"method": "GET",
+	"url": "https://${account.namespace}/mfa/authenticators",
+	"headers": [{
+		"name": "Authorization",
+		"value": "Bearer MFA_TOKEN"
+	}]
+}
+```
+
+You should receive information about the authenticator type(s) in the response:
+
+```json
+[
+  {
+    "authenticator_type": "recovery-code",
+    "id": "recovery-code|dev_IsBj5j3H12VAdOIj",
+    "active": true
+  },
+  {
+    "authenticator_type": "otp",
+    "id": "totp|dev_nELLU4PFUiTW6iWs",
+    "active": true,
+  },
+  {
+    "authenticator_type": "oob",
+    "oob_channels": "sms",
+    "id": "sms|dev_sEe99pcpN0xp0yOO",
+    "name": "+1123XXXXX",
+    "active": true
+  }
+]
+```
+
+For the purposes of building an user interface for end users to manage their factors, you should ignore authenticators that have `active` = `false`. Those authenticators are not confirmed by users, so they can't be used to challenge for MFA.
+
+::: note
+- When a user enrolls with Push, Auth0 creates an OTP enrollment. You will see both when listing enrollments.
+- If both SMS and Voice are enabled, when a user enrolls with either SMS or Voice, Auth0 will automatically create two authenticators for the phone number, one for `sms` and another for `voice`. 
+- When Email MFA is enabled, all verified emails will be listed as authenticators.
+- When a user enrolls any factor Auth0 creates a recovery code that will be listed as an authenticator.
+:::
+
+## Enroll Authenticators
+
+The documents below explain how to enroll with different factors:
+
+* [Enrolling with SMS or Voice](/mfa/guides/mfa-api/phone#enrolling-with-sms-or-voice)
+* [Enrolling with OTP](/mfa/guides/mfa-api/otp#enrolling-with-otp)
+* [Enrolling with Push](/mfa/guides/mfa-api/push#enrolling-with-push)
+* [Enrolling with Email](/mfa/guides/mfa-api/email#enrolling-with-email)
+
+You can also [use the Universal Login flow](/mfa/guides/guardian/create-enrollment-ticket) for enrolling users at any moment.
+
+## Delete Authenticators
+
+To delete an associated authenticator, send a `DELETE` request to the `/mfa/authenticators/AUTHENTICATOR_ID` endpoint. You can get the `ID` when listing authenticators.
+
+```har
+{
+	"method": "DELETE",
+	"url": "https://${account.namespace}/mfa/authenticators/AUTHENTICATOR_ID",
+	"headers": [{
+		"name": "Authorization",
+		"value": "Bearer MFA_TOKEN"
+	}]
+}
+```
+
+If the authenticator was deleted, a 204 response is returned.
+
+:::note
+- When you enroll a Push authenticator, Auth0 also enrolls an OTP one. If you delete any of them, the other one will be also deleted.
+- If both SMS and Voice are enabled, when a user enrolls with either SMS or Voice, Auth0 will automatically create two authenticators for the phone number, one for `sms` and another for `voice`.  When you delete one, the other will also be deleted.
+- If Email MFA is enabled, all verified emails will be listed as authenticators, but you can't delete them. You can only delete email authenticators that were enrolled explicitly.
+:::
+
+## Delete a Recovery Code
+
+To delete a Recovery Code, you need to use Management API's `/api/v2/users/USER_ID/recovery-code-regeneration` endpoint. You previously need to get a [Management API Access Token](/api/management/v2/tokens).
+
+```har
+{
+	"method": "DELETE",
+	"url": "https://${account.namespace}/api/v2/users/USER_ID/recovery-code-regeneration",
+	"headers": [{
+		"name": "Authorization",
+		"value": "Bearer MANAGEMENT_API_TOKEN"
+	}]
+}
+```
+
+You will get a new recovery code that the end user will need to capture:
+
+```json
+{
+  "recovery_code": "FA45S1Z87MYARX9RG6EVMAPE"
+}
+```
+
+## Keep reading
+
+* [Authenticate With Resource Owner Password Grant and MFA](/mfa/guides/mfa-api/authenticate)
diff --git a/ja-jp/articles/mfa/guides/mfa-api/multifactor-resource-owner-password.md b/ja-jp/articles/mfa/guides/mfa-api/multifactor-resource-owner-password.md
new file mode 100644
index 0000000000..61398e8c4b
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/mfa-api/multifactor-resource-owner-password.md
@@ -0,0 +1,347 @@
+---
+title: Multi-factor Authentication and Resource Owner Password
+description: How to use Multi-factor Authentication with Resource Owner Password Grant.
+toc: true
+topics:
+  - api-authentication
+  - oidc
+  - mfa
+  - resource-owner-password
+contentType: tutorial
+useCase:
+  - secure-api
+  - call-api
+---
+# Multi-factor Authentication and the Resource Owner Password Grant
+
+Highly-trusted applications can use the [Resource Owner Password Grant](/api-auth/grant/password) to access an API. The flow typically involves prompting the user for username and password as credentials to be submitted to Auth0. In some scenarios, however, stronger authentication may be required. This document outlines using multi-factor authentication (MFA) with the [Resource Owner Password Grant](/api-auth/grant/password).
+
+## Prerequisites
+
+Before you continue, make sure that you've met the following prerequisites:
+
+1. MFA is enabled on the [Auth0 dashboard](${manage_url}). [Duo Security](/mfa/guides/configure-cisco-duo) is __not__ supported as a factor with this flow.
+
+1. An Application is configured to execute the Resource Owner Password Grant (either [password](/api-auth/tutorials/password-grant) or [password-realm](/api-auth/tutorials/password-grant#realm-support) grant types). For details on how to implement this, refer to [Execute the Resource Owner Password Grant](/api-auth/tutorials/password-grant).
+
+1. End users are enrolled in MFA.
+
+## Initiate Multi-factor Authentication
+
+The flow starts by collecting end-user credentials and sending them to Auth0, as described in [Resource Owner Password Grant](/api-auth/grant/password). Both [password](/api-auth/tutorials/password-grant) and [password-realm](/api-auth/tutorials/password-grant#realm-support) flows are available.
+
+1. The user enters their credentials into the Application.
+
+2. The Application forwards the credentials to Auth0.
+
+3. Auth0 validates the credentials and executes any applicable [rules](/rules).
+
+4. If any rule triggers MFA for the current user, an error code of `mfa_required` is returned. The error will additionally contain an `mfa_token` property.
+
+  ```json
+  HTTP/1.1 403 Forbidden
+  Content-Type: application/json
+  {
+    "error": "mfa_required",
+    "error_description": "Multi-factor authentication required",
+    "mfa_token": "eyJ0eXAiOiJKV1QiLCJhbGci....D3QCiQ"
+  }
+  ```
+
+5. The Application will then make a request to the [MFA challenge](/api/authentication#resource-owner-password-and-mfa) endpoint, specifying the challenge types it supports. Valid challenge types are: [OTP](#challenge-type-otp), [OOB with binding method `prompt`](#challenge-type-oob-and-binding-method-prompt), and [OOB with no binding method](#challenge-type-oob-with-no-binding-method). If you already know that `otp` is supported by the end-user and you don't want to request a different factor, you can skip this and the next steps an go directly to [Challenge Type `OTP`](#challenge-type-otp) below.
+
+6. Auth0 sends a response containing the `challenge_type` derived from the types supported by the Application and the specific user. Additionally, extra information, such as `binding_method` may be included to assist in resolving the challenge and displaying the correct UI to the user.
+
+The supported challenge types are:
+
+- `otp`: A one-time password generated by an app setup with a seed or by token generation hardware. This mechanism does not require an extra channel to prove possession of the device; you can get it directly from the app / hardware device.
+
+- `oob`: The proof of possession of the device here is done 'out of band' via a side channel. There are several different channels, including push notification-based authenticators, SMS, and Voice based authenticators. Depending on the channel and the authenticator chosen at enrollment, you may need to provide a `binding_code` used to bind the side channel and the channel used for authentication.
+
+To execute MFA, follow the next steps according to the challenge type you will use:
+
+- [OTP](#challenge-type-otp): for this challenge type, your application must prompt the end-user for an OTP code and continue the flow using the __mfa-otp__ grant type.
+
+- [OOB and binding method `prompt`](#challenge-type-oob-and-binding-method-prompt): the challenge will be sent through a side channel (such as SMS or Voice), and your application will need to prompt the user for the `binding_code` that was included as part of the challenge sent, as well as the `oob_code` received as response to this request to prove possession of the device.
+
+- [OOB with no binding method](#challenge-type-oob-with-no-binding-method): in this case, the proof of possession will be driven entirely in a side channel (such as a push notification-based authenticator). The response will include an `oob_code` that the Application will use to periodically check for the resolution of the transaction. Continue the flow using the __mfa-oob__ grant type.
+
+## Execute Multi-factor Authentication
+
+The following sections cover how to execute MFA based on the challenge type used.
+
+### Challenge Type: `OTP`
+
+![Resource Owner MFA OTP](/media/articles/api-auth/challenge-type-otp.png)
+
+For this type of challenge, the Application must get an one-time password (`otp`) code from a OTP Generator app, such as Google Authenticator or Microsoft Authenticator.
+
+::: note
+If you already know that the user supports OTP, then steps 5 and 6 above of the [Initiate Multi-factor Authentication](#initiate-multifactor-authentication) section are optional.
+:::
+
+7. The Application prompts the end user to enter an OTP code.
+
+8. The end user enters their OTP into the Application.
+
+9. The Application forwards the OTP code to Auth0 using [grant_type=http://auth0.com/oauth/grant-type/mfa-otp](/api/authentication#resource-owner-password) and includes the `mfa_token` obtained in step 4 above.
+
+10. Auth0 validates the provided OTP and returns the Access Token and the Refresh Token.
+
+11. The Application can use the Access Token to call the API on behalf of the end user.
+
+### Challenge Type: `OOB` with Binding Method `prompt`
+
+![Resource Owner MFA OOB Prompt](/media/articles/api-auth/challenge-type-oob-with-binding-method.png)
+
+This challenge type, together with `prompt` binding method, indicates that the challenge will be delivered to the user using a side channel (such as SMS or Voice) and that a `binding_code` is needed to bind the side channel to the one being authenticated. The binding code is sent as part of the challenge message and it is usually an OTP-like code composed of 6 numeric digits.
+
+7. The Application prompts the user for the `binding_code` and stores the `oob_code` from step 6 for future use.
+
+8. The end user receives the challenge on the side channel and enters the `binding_code` into the Application.
+
+9. The Application forwards the `binding_code` to Auth0 using [grant_type=http://auth0.com/oauth/grant-type/mfa-oob](/api/authentication#resource-owner-password) and includes the `mfa_token` (from step 4) and `oob_code` (from step 6).
+
+10. Auth0 validates the `binding_code` and `oob_code` and returns the Access Token and the Refresh Token.
+
+11. The Application can use the Access Token to call the API on behalf of the end user.
+
+### Challenge Type: `OOB` with No Binding Method
+
+![Resource Owner MFA OOB](/media/articles/api-auth/challenge-type-oob-no-binding-method.png)
+
+In this scenario, the challenge will be sent using a side channel, however, there is no need for a `binding_code`. Currently, the only mechanism supported for this scenario is Push Notification with the Guardian Provider.
+
+7. The Application asks the user to accept the delivered challenge and keeps the `oob_code` from step 6 for future use.
+
+8. The Application polls Auth0 using [grant_type=http://auth0.com/oauth/grant-type/mfa-oob](/api/authentication#resource-owner-password) and includes the `mfa_token` (from step 4) and `oob_code` (from step 6).
+
+9. Auth0 validates the provided `oob_code`, the `mfa_token` and returns:
+    - `authorization_pending` error: if the challenge has not been accepted nor rejected.
+    - `slow_down` error: if the polling is too frequent.
+    - an `access_token` and a `refresh_token`: if the challenge has been accepted; polling should be stopped at this point.
+    - `invalid_grant` error: if the challenge has been rejected; polling should be stopped at this point.
+
+10. The Application can use the Access Token to call the API on behalf of the end user.
+
+## Using Recovery Codes
+
+::: note
+This flow is not available when the user uses provider = `google-authenticator` or provider = `duo`.
+:::
+
+![Resource Owner MFA Recovery](/media/articles/api-auth/recovery-code.png)
+
+Some providers support using a recovery code to login in case the enrolled device is not available, or if lack of connectivity prevents receiving an OTP code or push notification.
+
+Using a recovery code is similar to using an OTP code to login. The main difference is that a new recovery code will be generated, and that the application must display this new recovery code to the user for secure storage.
+
+Steps 1-4 are the same as above.
+
+5. End user chooses to use the recovery code.
+
+6. The Application prompts the end user to enter recovery code.
+
+7. The end user enters their recovery code into the Application.
+
+8. The Application forwards the recovery code to Auth0 using [grant_type=http://auth0.com/oauth/grant-type/mfa-otp](/api/authentication#resource-owner-password) and includes the `mfa_token` from step 4.
+
+9. Auth0 validates the recovery code and returns the Access Token and the Refresh Token.
+
+10. The Application can use the Access Token to call the API on behalf of the end user.
+
+## Samples
+
+The following are sample implementations involving MFA.
+
+### Resource Owner Password Grant Request
+
+```javascript
+var request = require("request");
+
+var options = { method: 'POST',
+  url: 'https://${account.namespace}/oauth/token',
+  headers: { 'content-type': 'application/x-www-form-urlencoded' },
+  form:
+   { grant_type: 'password',
+     username: 'USERNAME',
+     password: 'PASSWORD',
+     audience: 'API_IDENTIFIER',
+     scope: 'SCOPE',
+     client_id: '${account.clientId}',
+     client_secret: 'YOUR_CLIENT_SECRET' }
+  };
+
+request(options, function (error, response, body) {
+  if (error) throw new Error(error);
+
+  if (body.error === 'mfa_required') {
+    // Show mfa flow and give user option to go to the recovery flow (if supported)
+
+    if (/* MFA Recovery is requested*/) {
+      const recovery_code = // Prompt for recovery code
+      mfaRecovery(body.mfa_token, recovery_code) // See MFA Recovery grant
+    } else {
+      mfaChallenge(body.mfa_token)
+    }
+  }
+});
+```
+
+### Challenge Request
+
+```javascript
+function mfaChallenge(mfa_token) {
+  var options = { method: 'POST',
+    url: 'https://${account.namespace}/mfa/challenge',
+    headers: { 'content-type': 'application/json' },
+    body:
+    { mfa_token: mfa_token,
+      challenge_type: 'oob otp', // Supported challenge types, space separated
+      client_id: '${account.clientId}',
+      client_secret: 'YOUR_CLIENT_SECRET' },
+    json: true };
+
+  request(options, function (error, response, body) {
+    if (error) throw new Error(error);
+
+    if (body.challenge_type === 'otp') {
+      const otp = // Prompt for otp code (see MFA OTP grant request)
+      mfaOTP(mfa_token, otp)
+    } else if (body.challenge_type === 'oob') {
+      if (body.binding_method === 'prompt') {
+        const binding_code = // Prompt for binding code (see MFA OOB with binding code grant request)
+        mfaOOB(mfa_token, body.oob_code, binding_code)
+      } else if (!body.binding_method) {
+        // Ask the user to accept the challenge and start polling (see MFA OOB without binding code grant request)
+        mfaOOB(mfa_token, body.oob_code)
+      } else {
+        console.error('Unsupported binding_method');
+      }
+    } else {
+      console.error('Something went wrong');
+    }
+  });
+}
+```
+
+### MFA OTP Grant Request
+
+```javascript
+function mfaOTP(mfa_token, otp) {
+  var options = { method: 'POST',
+    url: 'https://${account.namespace}/oauth/token',
+    headers: { 'content-type': 'application/x-www-form-urlencoded' },
+    form:
+    { mfa_token: mfa_token,
+      otp: otp,
+      grant_type: 'http://auth0.com/oauth/grant-type/mfa-otp',
+      client_id: '${account.clientId}',
+      client_secret: 'YOUR_CLIENT_SECRET' }
+  };
+
+  request(options, function (error, response, body) {
+    if (error) throw new Error(error);
+
+    if (response.statusCode === 200) {
+      // The tokens returned depend on the scopes requested on the password grant request
+      console.log(body.access_token, body.id_token, body.refresh_token);
+    } else if (body.error === 'invalid_grant') {
+      // Invalid otp code
+      console.error('Invalid otp');
+    } else {
+      console.error('Something went wrong');
+    }
+  });
+}
+```
+
+### MFA OOB Grant Request
+
+```javascript
+function mfaOOB(mfa_token, oob_code, /* optional */ binding_code) {
+  makeOOBGrantRequest(mfa_token, oob_code, binding_code, function(error, result) {
+    if (error) { throw error; }
+
+    if (result.state === 'authorization_pending') {
+      // Poll every 10 seconds
+      setTimeout(() => makeOOBGrantRequest(mfa_token, oob_code, binding_code), 10000);
+    } else if (result.state === 'authorized')  {
+      console.log(result.body.access_token, result.body.id_token, result.body.refresh_token);
+    } else {
+      console.error('You are not authorized')
+    }
+  });
+}
+
+function makeOOBGrantRequest(mfa_token, oob_code, /* optional  */ binding_code, cb) {
+  var options = { method: 'POST',
+    url: 'https://${account.namespace}/oauth/token',
+    headers: { 'content-type': 'application/x-www-form-urlencoded' },
+    form:
+    { mfa_token: mfa_token,
+      oob_code: oob_code,
+      binding_code: binding_code, // Only when binding_method = prompt
+      grant_type: 'http://auth0.com/oauth/grant-type/mfa-oob',
+      client_id: '${account.clientId}',
+      client_secret: 'YOUR_CLIENT_SECRET' }
+    };
+
+  request(options, function (error, response, body) {
+    if (error) { return cb(error); }
+
+    if (response.statusCode === 200) {
+      // The tokens returned depend on the scopes requested on the password grant request
+      cb(null, { state: 'authorized', body });
+    } else if (body.error === 'invalid_grant') {
+      // Invalid otp code
+      cb(null, { state: 'not_authorized' });
+    } else if (body.error === 'authorization_pending') {
+      cb(null, { state: 'authorization_pending' });
+    } else if (body.error === 'slow_down') {
+      // You are polling too fast, slow down the polling rate,
+      // You may want to check rate-limiting headers to manage your polling rate
+      setTimeout(() => cb({ state: 'authorization_pending' }), 20000);
+    } else {
+      cb(new Error('Something went wrong'))
+    }
+  });
+}
+```
+
+### MFA Recovery Grant Request
+
+```javascript
+function mfaRecovery(mfa_token, recovery_code) {
+  var options = { method: 'POST',
+    url: 'https://${account.namespace}/oauth/token',
+    headers: { 'content-type': 'application/x-www-form-urlencoded' },
+    form:
+    { mfa_token: mfa_token,
+      recovery_code: recovery_code,
+      grant_type: 'http://auth0.com/oauth/grant-type/mfa-recovery-code',
+      client_id: '${account.clientId}',
+      client_secret: 'YOUR_CLIENT_SECRET' }
+    };
+
+  request(options, function (error, response, body) {
+    if (error) throw new Error(error);
+
+    if (response.statusCode === 200) {
+      console.log('Please store this new recovery code safely -- the previous code will no longer work.', body.recovery_code)
+
+      // The tokens returned depend on the scopes requested on the password grant request
+      console.log(body.access_token, body.id_token, body.refresh_token);
+    } else if (body.error === 'invalid_grant') {
+      // Invalid recovery code
+      console.error('Invalid recovery_code');
+    } else {
+      console.error('Something went wrong');
+    }
+  });
+}
+```
+
+## MFA API
+
+See [MFA API](/mfa/concepts/mfa-api) for detailed information about Auth0's MFA API endpoints.
diff --git a/ja-jp/articles/mfa/guides/mfa-api/otp.md b/ja-jp/articles/mfa/guides/mfa-api/otp.md
new file mode 100644
index 0000000000..f2efd0e81a
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/mfa-api/otp.md
@@ -0,0 +1,221 @@
+---
+title: Enroll and Challenge OTP Authenticators
+description: Build your own MFA flows using OTP as a factor.
+topics:
+  - mfa
+  - mfa-api
+  - mfa-authenticators
+  - otp
+contentType:
+  - how-to
+  - reference
+useCase:
+  - customize-mfa
+---
+# Enroll and Challenge OTP Authenticators
+
+Auth0 provides a built-in MFA enrollment and authentication flow using [Universal Login](/universal-login). However, if you want to create your own user interface, you can use the MFA API to accomplish it. 
+
+This guide explains how to enroll and challenge users with OTP using the MFA API. First, make sure that OTP is [enabled as factor](/mfa/guides/configure-otp) in the Dashboard or using the [Management API](/api/management/v2#!/Guardian/put_factors_by_name).
+
+<%= include('../../_includes/_authenticator-before-start') %>
+
+## Enrolling with OTP
+
+### 1. Get the MFA Token
+
+<%= include('../../_includes/_get_mfa_token') %>
+
+### 2. Enroll the Authenticator 
+
+<%= include('../../_includes/_request_association') %>
+
+To enroll with OTP you need to set the `authenticator_types` parameter to `[otp]`.
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/mfa/associate",
+	"headers": [
+    { "name": "Authorization", "value": "Bearer MFA_TOKEN" },
+    { "name": "Content-Type", "value": "application/json" }
+  ],
+	"postData": {
+		"mimeType": "application/json",
+		"text": "{ \"authenticator_types\": [\"otp\"] }"
+	}
+}
+```
+
+If successful, you'll receive a response like this:
+
+```json
+{
+  "authenticator_type": "otp",
+  "secret": "EN...S",
+  "barcode_uri": "otpauth://totp/tenant:user?secret=...&issuer=tenant&algorithm=SHA1&digits=6&period=30",
+  "recovery_codes": [ "N3B...XC"]
+}
+```
+
+If you get a `User is already enrolled error`, the user already has an MFA factor enrolled. Before associating another factor with the user, you need to challenge the user with the existing factor.
+
+#### Recovery Codes
+
+<%= include('../../_includes/_recovery_codes') %>
+
+### 3. Confirm the OTP enrollment
+
+To confirm the enrollment, the end user will need to enter the secret obtained in the previous step in an OTP generator application like Google Authenticator. They can enter the secret by scanning a QR code with the `barcode_uri` or by typing the `secret` code manually in that OTP application. You should provide users a way to get the `secret` as text in case they cannot scan the QR code (e.g. if they are enrolling from a mobile device, or using a desktop OTP application).
+
+After the users enter the secret, the OTP application will display a 6-digit code, that the user should enter in your application. The application should then make a `POST` request to the `oauth/token` endpoint, including that `otp` value.
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+	"postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "http://auth0.com/oauth/grant-type/mfa-otp"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "mfa_token",
+        "value": "MFA_TOKEN"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "otp",
+        "value": "USER_OTP_CODE"
+      }
+    ]
+	}
+}
+```
+
+<%= include('../../_includes/_successful_confirmation') %>
+
+## Challenging with OTP
+
+To challenge a user with OTP, follow the steps detailed below.
+
+### 1. Get the MFA token
+
+<%= include('../../_includes/_get_mfa_token_challenge') %>
+
+### 2. Retrieve the enrolled authenticators
+
+To be able to challenge the user, you need the `authenticator_id` for the factor you want to challenge. You can list all enrolled authenticators by using the `/mfa/authenticators` endpoint:
+
+```har
+{
+	"method": "GET",
+	"url": "https://${account.namespace}/mfa/authenticators",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer MFA_TOKEN" },
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ]
+}
+```
+
+You will get a list of authenticators with the format below:
+
+```json
+[
+    {
+        "id": "recovery-code|dev_qpOkGUOxBpw6R16t",
+        "authenticator_type": "recovery-code",
+        "active": true
+    },
+    {
+        "id": "totp|dev_6NWz8awwC8brh2dN",
+        "authenticator_type": "otp",
+        "active": true
+    }
+]
+```
+
+### 3. Challenge the user with OTP
+
+To trigger an OTP challenge, `POST` to the to `mfa/challenge` endpoint, using the corresponding `authenticator_id` ID and the `mfa_token`. 
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/mfa/challenge",
+	"postData": {
+		"mimeType": "application/json",
+		"text": "{ \"client_id\": \"YOUR_CLIENT_ID\", \"challenge_type\": \"otp\", \"mfa_token\": \"MFA_TOKEN\", \"authenticator_id\" : \"totp|dev_6NWz8awwC8brh2dN\" }"
+	}
+}
+```
+
+### 4. Complete authentication using the received code
+
+If successful, you'll receive the following response: 
+
+```json
+{
+  "challenge_type": "otp"
+}
+```
+
+The user will collect a one-time password, which you will then collect from them. You can the  verify the code and get authentication tokens using the `/oauth/token` endpoint, specifying the one-time password in the `otp` parameter:
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "http://auth0.com/oauth/grant-type/mfa-otp"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "mfa_token",
+        "value": "MFA_TOKEN"
+      },
+      {
+        "name": "otp",
+        "value": "USER_OTP_CODE"
+      }
+    ]
+  }
+}
+```
+
+<%= include('../../_includes/_successful_challenge') %>
+
+## Keep Reading
+
+* [Configure One-Time Passwords for MFA](/mfa/guides/configure-otp)
+* [Managing MFA Enrollments](/mfa/guides/mfa-api/manage)
+* [Enroll and Challenge Push Authenticators](/mfa/guides/mfa-api/push)
+* [Enroll and Challenge SMS or Voice Authenticators](/mfa/guides/mfa-api/phone)
+* [Enroll and Challenge Email Authenticators](/mfa/guides/mfa-api/email)
+* [Challenge a Recovery Code](/mfa/guides/mfa-api/recovery-code)
diff --git a/ja-jp/articles/mfa/guides/mfa-api/phone.md b/ja-jp/articles/mfa/guides/mfa-api/phone.md
new file mode 100644
index 0000000000..02ec707bba
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/mfa-api/phone.md
@@ -0,0 +1,256 @@
+---
+title: Enroll and Challenge SMS or Voice Authenticators
+description: Build your own MFA flows using SMS or Voice as a factor.
+topics:
+  - mfa
+  - mfa-api
+  - mfa-authenticators
+  - sms
+contentType:
+  - how-to
+  - reference
+useCase:
+  - customize-mfa
+---
+# Enroll and Challenge SMS or Voice Authenticators
+
+Auth0 provides a built-in MFA enrollment and authentication flow using [Universal Login](/universal-login). However, if you want to create your own user interface, you can use the MFA API to accomplish it. 
+
+::: warning
+Voice MFA is currently a Beta feature. It should not be used in production environments.
+::: 
+
+This guide explains how to enroll and challenge users with SMS or a voice call using the MFA API. First, make sure that Phone is [enabled as factor](/mfa/guides/configure-phone) in the Dashboard or using the [Management API](/api/management/v2#!/Guardian/put_factors_by_name).
+
+<%= include('../../_includes/_authenticator-before-start') %>
+
+## Enrolling with SMS or Voice
+
+### 1. Get the MFA token
+
+<%= include('../../_includes/_get_mfa_token') %>
+
+### 2. Enroll the Authenticator 
+
+<%= include('../../_includes/_request_association') %>
+
+When a user enrolls with Voice or SMS, they are actually enrolling a phone number that can be challenged either with SMS or Voice.
+
+You need to specify the parameters below to call the endpoint. The `oob_channels` parameter indicates how you want to send the code to the user (SMS or Voice):
+
+- `authentication_types` = `[oob]`
+- `oob_channels` = `[sms]` or `[voice]`.
+- `phone_number` = `+11...9`, the phone number [E.164 format](https://en.wikipedia.org/wiki/E.164)
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/mfa/associate",
+	"headers": [
+    { "name": "Authorization", "value": "Bearer MFA_TOKEN" },
+    { "name": "Content-Type", "value": "application/json" }
+  ],
+	"postData": {
+		"mimeType": "application/json",
+		"text": "{ \"authenticator_types\": [\"oob\"], \"oob_channels\": [\"sms\"], \"phone_number\": \"+11...9\" }"
+	}
+}
+```
+
+If successful, you'll receive a response like the one below:
+
+```json
+{
+  "authenticator_type": "oob",
+  "binding_method": "prompt",
+  "recovery_codes": [ "N3BGPZZWJ85JLCNPZBDW6QXC" ],
+  "oob_channels": "sms",
+  "oob_code": "ata6daXAiOi..."
+}
+```
+
+If you get a `User is already enrolled error`, it is because the user already has an MFA factor enrolled. Before associating it with another factor, you need to challenge the user with the existing one.
+
+#### Recovery Codes
+
+<%= include('../../_includes/_recovery_codes') %>
+
+### 3. Confirm the SMS or Voice enrollment
+
+Users should receive an message with a 6-digit code that they need to provide to the application.
+
+To complete enrollment, make a `POST` request to the `oauth/token` endpoint. You need to include the `oob_code` returned in the previous response, and the `binding_code` with the value received in the message.
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer MFA_TOKEN" },
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+	"postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "http://auth0.com/oauth/grant-type/mfa-oob"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "mfa_token",
+        "value": "MFA_TOKEN"
+      },
+      {
+        "name": "oob_code",
+        "value": "OOB_CODE"
+      },
+      {
+        "name": "binding_code",
+        "value": "USER_OTP_CODE"
+      }
+    ]
+	}
+}
+```
+
+<%= include('../../_includes/_successful_confirmation') %>
+
+## Challenging with SMS or Voice
+
+To challenge a user with SMS or Voice, follow the steps detailed below.
+
+### 1. Get the MFA token
+
+<%= include('../../_includes/_get_mfa_token_challenge') %>
+
+### 2. Retrieve the enrolled authenticators
+
+To be able to challenge the user, you need the `authenticator_id` for the factor you want to challenge. You can list all enrolled authenticators by using the `/mfa/authenticators` endpoint:
+
+```har
+{
+	"method": "GET",
+	"url": "https://${account.namespace}/mfa/authenticators",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer MFA_TOKEN" },
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ]
+}
+```
+
+You will get a list of authenticators with the format below:
+
+```json
+[
+    {
+        "id": "recovery-code|dev_O4KYL4FtcLAVRsCl",
+        "authenticator_type": "recovery-code",
+        "active": true
+    },
+    {
+        "id": "sms|dev_NU1Ofuw3Cw0XCt5x",
+        "authenticator_type": "oob",
+        "active": true,
+        "oob_channels": "sms",
+        "name": "XXXXXXXX8730"
+    },
+        {
+        "id": "voice|dev_NU1Ofuw3Cw0XCt5x",
+        "authenticator_type": "oob",
+        "active": true,
+        "oob_channels": "voice",
+        "name": "XXXXXXXX8730"
+    }
+]
+```
+
+Note that you have two authenticators with different `authenticator_id` for Voice or SMS. 
+
+### 3. Challenge the user with SMS or Voice
+
+To trigger the challenge, `POST` to the to `mfa/challenge` endpoint, using the corresponding `authenticator_id` and the MFA Access Token.
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/mfa/challenge",
+	"postData": {
+		"mimeType": "application/json",
+		"text": "{ \"client_id\": \"YOUR_CLIENT_ID\",  \"client_secret\": \"YOUR_CLIENT_SECRET\", \"challenge_type\": \"oob\", \"authenticator_id\": \"sms|dev_NU1Ofuw3Cw0XCt5x\", \"mfa_token\": \"MFA_TOKEN\" }"
+	}
+}
+```
+
+### 4. Complete authentication using the received code
+
+If successful, you'll receive the following response, and the user will get a message containing the required six-digit code:
+
+```json
+{
+  "challenge_type": "oob",
+  "oob_code": "asdae35fdt5...",
+  "binding_method": "prompt"
+}
+```
+
+Your application needs to prompt the user for 6-digit code sent in the message, and should be set in the `binding_code` parameter.
+
+You can then verify the code and get the authentication tokens using the `/oauth/token` endpoint, using the `binding_code` and the `oob_code` returned by the previous call:
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "http://auth0.com/oauth/grant-type/mfa-oob"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "mfa_token",
+        "value": "MFA_TOKEN"
+      },
+      {
+        "name": "oob_code",
+        "value": "OOB_CODE"
+      },
+      {
+        "name": "binding_code",
+        "value": "USER_OTP_CODE"
+      }
+    ]
+  }
+}
+```
+
+<%= include('../../_includes/_successful_challenge') %>
+
+## Keep reading
+
+* [Configure SMS or Voice Notifications for MFA](/mfa/guides/configure-phone)
+* [Managing MFA Enrollments](/mfa/guides/mfa-api/manage)
+* [Enroll and Challenge Push Authenticators](/mfa/guides/mfa-api/push)
+* [Enroll and Challenge OTP Authenticators](/mfa/guides/mfa-api/otp)
+* [Enroll and Challenge Email Authenticators](/mfa/guides/mfa-api/email)
+* [Challenge a Recovery Code](/mfa/guides/mfa-api/recovery-code)
diff --git a/ja-jp/articles/mfa/guides/mfa-api/push.md b/ja-jp/articles/mfa/guides/mfa-api/push.md
new file mode 100644
index 0000000000..d2d0902bdd
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/mfa-api/push.md
@@ -0,0 +1,250 @@
+---
+title: Enroll and Challenge Push Authenticators
+description: Build your own MFA flows using Push as a factor.
+topics:
+  - mfa
+  - mfa-api
+  - mfa-authenticators
+contentType:
+  - how-to
+  - reference
+useCase:
+  - customize-mfa
+---
+# Enroll and Challenge Push using Guardian
+
+Auth0 provides a built-in MFA enrollment and authentication flow using [Universal Login](/universal-login). However, if you want to create your own user interface, you can use the MFA API to accomplish it.
+
+This guide explains to enroll and challenge users using Push Notifications with the Guardian Application or SDK, using the MFA API. First, make sure that Push is [enabled as factor](/mfa/guides/configure-push) in the Dashboard or using the [Management API](/api/management/v2#!/Guardian/put_factors_by_name).
+
+<%= include('../../_includes/_authenticator-before-start') %>
+
+## Enrolling with Push
+
+### 1. Get the MFA token
+
+<%= include('../../_includes/_get_mfa_token') %>
+
+### 2. Enroll the Authenticator 
+
+<%= include('../../_includes/_request_association') %>
+
+To enroll with Push, you need to use the following parameters:
+
+- `authentication_types` = `[oob]`
+- `oob_channels` = `[auth0]`
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/mfa/associate",
+	"headers": [
+    { "name": "Authorization", "value": "Bearer MFA_TOKEN" },
+    { "name": "Content-Type", "value": "application/json" }
+  ],
+	"postData": {
+		"mimeType": "application/json",
+		"text": "{ \"authenticator_types\": [\"oob\"], \"oob_channels\": [\"auth0\"] }"
+	}
+}
+```
+
+If successful, you'll receive a response like the one below:
+
+```json
+{
+    "authenticator_type": "oob",
+    "barcode_uri": "otpauth://totp/tenant:user?enrollment_tx_id=qfjn2eiNYSjU3xID7dBYeCBSrdREWJPY&base_url=tenan",
+    "recovery_codes": [
+        "ALKE6EJZ4853BJYLM2DM2WU7"
+    ],
+    "oob_channels": "auth0",
+    "oob_code": "Fe26.2...SYAg"
+}
+```
+
+If you get a `User is already enrolled error`, the user already has an MFA factor enrolled. Before associating another factor with the user, you need to challenge the user with the existing factor.
+
+#### Recovery Codes
+
+<%= include('../../_includes/_recovery_codes') %>
+
+### 3. Confirm the Push enrollment
+
+To confirm the enrollment, the end user will need to scan the a QR code with the `barcode_uri` in the Guardian App. Once that is done the Guardian App will notify Auth0 that the user enrolled successfully. To know if that happened, you need to poll the `/oauth/token` endpoint with the `oob_code` returned by the `/associate` call:
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer MFA_TOKEN" },
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+	"postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "http://auth0.com/oauth/grant-type/mfa-oob"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "mfa_token",
+        "value": "MFA_TOKEN"
+      },
+      {
+        "name": "oob_code",
+        "value": "OOB_CODE"
+      }
+    ]
+	}
+}
+```
+
+If the user did has not scanned the code, it will return an `authorization_pending` response, indicating you need to call `oauth_token` again in a few seconds:
+
+```json
+{
+    "error": "authorization_pending",
+    "error_description": "Authorization pending: please repeat the request in a few seconds."
+}
+```
+
+<%= include('../../_includes/_successful_confirmation') %>
+
+## Challenging with Push
+
+To challenge a user with Push, follow the steps detailed below.
+
+### 1. Get the MFA token
+
+<%= include('../../_includes/_get_mfa_token_challenge') %>
+
+### 2. Retrieve the enrolled authenticators
+
+To be able to challenge the user, you need the `authenticator_id` for the factor you want to challenge. You can list all enrolled authenticators by using the `/mfa/authenticators` endpoint:
+
+```har
+{
+	"method": "GET",
+	"url": "https://${account.namespace}/mfa/authenticators",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer MFA_TOKEN" },
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ]
+}
+```
+
+You will get a list of authenticators with the format below:
+
+```json
+[
+    {
+        "id": "recovery-code|dev_Ahb2Tb0ujX3w7ilC",
+        "authenticator_type": "recovery-code",
+        "active": true
+    },
+    {
+        "id": "push|dev_ZUla9SQ6tAIHSz6y",
+        "authenticator_type": "oob",
+        "active": true,
+        "oob_channels": "auth0",
+        "name": "user's device name"
+    },
+    {
+        "id": "totp|dev_gJ6Y6vpSrjnKeT67",
+        "authenticator_type": "otp",
+        "active": true
+    }
+]
+```
+
+Note that when users enroll with Push, they also get enrolled in OTP, as Guardian supports [challenging with OTP](/mfa/guides/mfa-api/otp/#challenging-with-otp) for scenarios where the user does not have connectivity.  
+
+### 3. Challenge the user with Push
+
+To trigger an Push challenge, `POST` to the to `mfa/challenge` endpoint, using the corresponding `authenticator_id` ID and the `mfa_token`. 
+
+```har
+{
+	"method": "POST",
+	"url": "https://${account.namespace}/mfa/challenge",
+	"postData": {
+		"mimeType": "application/json",
+		"text": "{ \"client_id\": \"YOUR_CLIENT_ID\",  \"client_secret\": \"YOUR_CLIENT_SECRET\", \"challenge_type\": \"oob\", \"authenticator_id\": \"push|dev_ZUla9SQ6tAIHSz6y\", \"mfa_token\": \"MFA_TOKEN\" }"
+	}
+}
+```
+
+### 4. Complete authentication using the received code
+
+If successful, you'll receive the following response, and the user will get an Push notification:
+
+```json
+{
+    "challenge_type": "oob",
+    "oob_code": "Fe26...jGco"
+}
+
+```
+
+Your application needs to start polling the `/oauth/token` endpoint until the user accepts the Push notification. If the endpoint returns `
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "http://auth0.com/oauth/grant-type/mfa-oob"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "mfa_token",
+        "value": "MFA_TOKEN"
+      },
+      {
+        "name": "oob_code",
+        "value": "OOB_CODE"
+      }
+    ]
+  }
+}
+```
+
+This call can return one of the following results:
+
+- `authorization_pending` error: if the challenge has not been accepted nor rejected.
+- `slow_down` error: if the polling is too frequent.
+- an `access_token` and a `refresh_token`: if the challenge has been accepted; polling should be stopped at this point.
+- `invalid_grant` error: if the challenge has been rejected; polling should be stopped at this point.
+
+## Keep Reading
+
+* [Configure Push Notifications for MFA](/mfa/guides/configure-push)
+* [Managing MFA Enrollments](/mfa/guides/mfa-api/manage)
+* [Enroll and Challenge SMS Authenticators](/mfa/guides/mfa-api/sms)
+* [Enroll and Challenge OTP Authenticators](/mfa/guides/mfa-api/otp)
+* [Enroll and Challenge Email Authenticators](/mfa/guides/mfa-api/email)
+* [Challenge a Recovery Code](/mfa/guides/mfa-api/recovery-code)
diff --git a/ja-jp/articles/mfa/guides/mfa-api/recovery-code.md b/ja-jp/articles/mfa/guides/mfa-api/recovery-code.md
new file mode 100644
index 0000000000..038abaefc1
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/mfa-api/recovery-code.md
@@ -0,0 +1,91 @@
+---
+description: Use the MFA API to challenge users who lose access to their device or account using recovery codes.
+topics:
+  - mfa
+  - mfa-api
+  - mfa-authenticators
+  - recovery-codes
+contentType:
+  - how-to
+  - reference
+useCase:
+  - customize-mfa
+---
+# Challenge with Recovery Codes
+
+Auth0 automatically generates recovery codes when users enroll with MFA. These codes can be used when users lost access to the device or account they used to enroll MFA.
+
+This guide explains how to enable users to authenticate using a recovery code using the MFA API.
+
+## 1. Prompt the user for the recovery code
+
+When the user enrolls with MFA, Auth0 generates a recovery code, that the user should capture. That value should be entered in the application for the user to authenticate. 
+
+::: note
+Auth0 does not generate recovery codes for DUO and for the legacy `google-authenticator` factor.
+:::
+
+## 2. Authenticate using the Recovery Code
+
+Call the `/oauth/token` endpoint with the recovery code to authenticate and generate a new recovery code. You need to specify the following parameters:
+
+- `grant_type` : `http://auth0.com/oauth/grant-type/mfa-recovery-code`
+- `recovery_code` : the recovery code provided by the user
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "http://auth0.com/oauth/grant-type/mfa-recovery-code"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "mfa_token",
+        "value": "MFA_TOKEN"
+      },
+      {
+        "name": "recovery_code",
+        "value": "RECOVERY_CODE"
+      }
+    ]
+  }
+}
+```
+
+### 3. Ask the user to capture the new Recovery Code
+
+If the call is successful, you'll get the authentication tokens and a new recovery code:
+
+```json
+{
+    "access_token": "O3...H4",
+    "id_token": "eyJh...w",
+    "scope": "openid profile",
+    "expires_in": 86400,
+    "recovery_code": "K6LGLV3RSH3VERMKET8L7QKU",
+    "token_type": "Bearer"
+}
+```
+
+You should let the user know that a new recovery code was generated and ask them to capture it.
+
+* [Managing MFA Enrollments](/mfa/guides/mfa-api/manage)
+* [Enroll and Challenge Push Authenticators](/mfa/guides/mfa-api/push)
+* [Enroll and Challenge OTP Authenticators](/mfa/guides/mfa-api/otp)
+* [Enroll and Challenge SMS Authenticators](/mfa/guides/mfa-api/sms)
+* [Enroll and Challenge Email Authenticators](/mfa/guides/mfa-api/email)
diff --git a/ja-jp/articles/mfa/guides/reset-user-mfa.md b/ja-jp/articles/mfa/guides/reset-user-mfa.md
new file mode 100644
index 0000000000..fde72fc781
--- /dev/null
+++ b/ja-jp/articles/mfa/guides/reset-user-mfa.md
@@ -0,0 +1,52 @@
+---
+description: Learn how to reset a user's MFA in case they lose their mobile device and do not have a recovery code. 
+topics:
+  - mfa
+  - user-management
+contentType:
+  - how-to
+useCase:
+  - customize-mfa
+---
+# Reset User's MFA
+
+If a user has lost their mobile device, they can use their recovery code to log in. If they do not have a recovery code, they will need their tenant administrator to reset their multi-factor authentication (MFA). 
+
+This action is equivalent to removing or deleting the user's MFA registration. The MFA settings associated with their user will be removed, which allows them to set up MFA as if they were a new user on their next login attempt.
+
+::: note
+If you need to reset an admin's MFA as opposed to an end user's MFA, please contact [Auth0 Support](https://auth0.com/docs/support).
+:::
+
+## Reset MFA in the Dashboard
+
+1. Go to [Dashboard > Users & Roles > Users](${manage_url}/#/users).
+2. Click on the user whose MFA you want to reset.
+3. Click on the **Actions** button on the top right of the screen.
+4. Select **Reset Multi-factor** from the dropdown.
+
+  Admins will also see a **Reset MFA** link at the bottom of the **Multi-Factor Authentication** tab of the **User Details** page if the user is already enrolled in MFA. Both these methods function the same way. 
+
+5. There will be a pop up box to confirm your decision.  Click **YES, RESET IT** to reset the user's MFA.
+
+The next time the user logs in, they will need to setup their MFA just like a new user.
+
+## Reset MFA using the Management API
+
+As an admin, you can also use the Management API to delete a user's MFA enrollment using `DELETE /api/v2/guardian/enrollments/{id}`. This requires getting the enrollment ID first with a `GET` to the same endpoint. If the user has more than one enrollment, you will need to repeat the process for each enrollment.
+
+## Recovery codes
+
+With most MFA factors, the end user will be given a recovery code upon signup, which should be noted and kept secret. If they do not have their device or are otherwise temporarily unable to use their normal MFA process, the user can log in by entering this code after their username and password. 
+
+![MFA Recovery Code](/media/articles/mfa/recovery-code.png)
+
+::: note
+If a recovery code is used, a new recovery code will be provided at that time.
+:::
+
+If a user uninstalls then later re-installs Guardian, they may be prompted to enter their recovery code. If the recovery code has been lost, the user can perform a new installation of the app by disabling automatic restoration of their Guardian backup. To do so, the user will need to uninstall Guardian, temporarily disable automatic restoration of backups within their device settings (steps to do so will vary according to the device), then re-install the app. They will then need to add their MFA account(s) to the app as if performing a first-time setup. If automatic backups or automatic restoration are not enabled on the user's device, re-installation of the app will not prompt for a recovery code and the user will be required to add their MFA account(s) as in a first-time setup.
+
+## Keep reading
+
+* [Reset Auth0 Account Password](/support/reset-account-password)
diff --git a/ja-jp/articles/mfa/index.md b/ja-jp/articles/mfa/index.md
new file mode 100644
index 0000000000..a31faa4646
--- /dev/null
+++ b/ja-jp/articles/mfa/index.md
@@ -0,0 +1,31 @@
+---
+title: Multi-factor Authentication
+description: Understand how MFA works in Auth0.
+classes: topic-page
+topics:
+    - mfa
+contentType:
+  - index
+useCase:
+  - customize-mfa
+---
+# Multi-factor Authentication
+
+Multi-factor Authentication (MFA) provides a method to verify a user's identity by requiring them to provide more than one piece of identifying information. This ensures that only valid users can access their accounts even if they use a username and password that may have been compromised from a different application. 
+
+To enable MFA, go to [Dashboard > Multifactor Auth](${manage_url}/#/guardian) and toggle on the factors you want to enable on your tenant, such as push notifications or SMS. Next, perform any further setup required to configure that factor, then choose whether you wish to force MFA for all users or not. You can also customize your MFA flow with Auth0 [Rules](/rules/references/use-cases#multi-factor-authentication) to allow MFA to only be required in specific circumstances or force a particular factor to be used.
+
+See the following sections for more details:
+
+<%= include('../_includes/_topic-links', { links: [
+  'mfa/concepts/mfa-factors',
+  'mfa/guides/enable-mfa',
+  'mfa/concepts/guardian',
+  'mfa/guides/customize-mfa-universal-login',
+  'mfa/guides/reset-user-mfa',
+  'mfa/guides/import-user-mfa',
+  'mfa/concepts/mfa-developer-resources',
+  'mfa/concepts/step-up-authentication',
+  'mfa/references/troubleshoot-mfa'
+] }) %>
+
diff --git a/ja-jp/articles/mfa/references/guardian-error-code-reference.md b/ja-jp/articles/mfa/references/guardian-error-code-reference.md
new file mode 100644
index 0000000000..696d3e70de
--- /dev/null
+++ b/ja-jp/articles/mfa/references/guardian-error-code-reference.md
@@ -0,0 +1,49 @@
+---
+title: Guardian Error Code Reference
+description: Lists Guardian error codes and descriptions.
+topics:
+    - guardian
+contentType:
+  - reference
+useCase:
+  - customize-mfa
+---
+# Guardian Error Code Reference
+
+Use the error codes to display informative messages and to distinguish between recoverable and unrecoverable errors. 
+
+| Error Code |	Description |
+| -- | -- |
+| `invalid_token`	| Invalid request or transaction token
+| `insufficient_scope` | You don't have enought grants to perform the requested operation
+| `invalid_bearer_format`	| The bearer put in authentication header was not valid
+| `enrollment_conflict`	| There is another enrollment for the same user. You cannot enroll twice.
+| `tenant_not_found`	| The tenant associated cannot be found. Should not normally happen at least that you delete the tenant
+| `login_transaction_not_found`	| The mfa auth transaction is not active or has already expired
+| `error_sending_push_notification`	| Push notification delivery failed
+| `push_notification_wrong_credentials`	| Push notification delivery failed because of wrong credentials
+| `invalid_otp`	| Provided otp code was not valid
+| `invalid_recovery_code`	| Provided recovery code was not valid
+| `invalid_body`	| Body validation failed. Bad request.
+| `invalid_query_string`	| Query string validation failed. Bad request.
+| `enrollment_transaction_not_found`	| The mfa enrollment transaction is not active or has expired
+| `invalid_phone_number`	| The provided phone number is invalid
+| `error_sending_sms`	| SMS Delivery error
+| `feature_disabled`	| The requested feature is currently globally not available (contact the provider)
+| `feature_disabled_by_admin`	| The requested feature is currently disabled by your admin
+| `pn_endpoint_disabled`	| We were unable to deliver the push notification after retrying many times. Try removing you account for the device and adding it again.
+| `too_many_sms`	| You have exeed the amount of SMSs assigned to your user
+| `too_many_pn`	| You have exeed the amount of push notifications assigned to your user
+| `too_many_sms_per_tenant`	| You have exeed the amount of SMSs assigned to your tenant
+| `too_many_pn_per_tenant`	| You have exeed the amount of push notifications assigned to your tenant
+| `field_required`	| A field is required to perform the operation (this errors has a field attribute with a code for the field: `otpCode`, `recoveryCode`)
+| `method_not_found`	| You have requested a method that is currently not supported (should not happen)
+| `no_method_available`	| There is currently no method to enroll (all of them are disabled)
+| `enrollment_method_disabled`	| The specified enrollment method is disabled, this error has also a .method field
+| `auth_method_disabled`	| The specified authentication method is disabled, this error has also a .method field
+| `invalid_otp_format`	| OTP format validation error
+| `invalid_recovery_code_format`	| Recovery code format validation error
+| `transaction_expired`	| The transaction has already expired
+| `already_enrolled`	| You are already enrolled, cannot enroll again
+| `not_enrolled`	| You not enrolled. Must enroll first
+| `invalid_enrollment`	| The enrollment provided to transaction#requestAuth method is not valid or is null/undefined
diff --git a/ja-jp/articles/mfa/references/language-dictionary.md b/ja-jp/articles/mfa/references/language-dictionary.md
new file mode 100644
index 0000000000..614f9d1c5f
--- /dev/null
+++ b/ja-jp/articles/mfa/references/language-dictionary.md
@@ -0,0 +1,231 @@
+---
+description: Describes the MFA hosted page configuration options for customizing the theme properties of the MFA pages. 
+topics:
+  - mfa
+  - hosted-pages
+contentType: reference
+useCase: customize-hosted-pages
+---
+# MFA Theme Language Dictionary
+
+## defaultLocation
+
+```js
+return new Auth0MFAWidget({
+
+...
+
+  defaultLocation : ['United Kingdom', 'GB', '+44'],
+  
+...
+
+})
+```
+
+## languageDictionary
+
+The `languageDictionary` can be used to override the text for many areas of the MFA process on Universal Login Classic Experience. You do this with the following format:
+
+```
+languageDictionary:
+  optionsCategory:
+    option: value
+```
+
+Here is an example, modifying the `headerText` attribute in `smsEnrollmentConfirm`:
+
+```js
+return new Auth0MFAWidget({
+
+...
+
+  languageDictionary:{ // Use the Language Dictionary option
+    smsEnrollmentConfirm:{  // Indicate which category/section you are modifying
+      headerText: "Some custom text - In order to confirm enrollment we need to confirm your phone. Please enter the received code." // Provide the new value for the specific attribute you wish to modify
+    }
+  }
+
+...
+
+})
+```
+
+See below for a list of available categories and options.
+
+### languageDictionary options
+
+```js
+defaults: {
+  iddleHelpUrl: '#',
+  rememberBrowserCheckbox: 'Remember this browser',
+  title: 'Login to {tenantName}'
+},
+
+downloadApp: {
+  headerText: 'Download Auth0 Guardian for free:',
+  pushEnrollmentAction: 'I\'ve already downloaded it',
+  smsAndTotpEnrollmentActions: 'I\'d rather use SMS or Google Authenticator',
+  pushAndTotpEnrollmentActions: 'I\'d rather use Guardian or Google Authenticator',
+  pushAndSmsEnrollmentActions: 'I\'d rather use Guardian or SMS',
+  totpEnrollmentActions: 'I\'d rather use Google Authenticator',
+  smsEnrollmentActions: 'I\'d rather use SMS',
+  pushEnrollmentActions: 'I\'d rather use Guardian',
+  iosLabel: 'App Store',
+  iosUrl: 'https://itunes.apple.com/us/app/auth0-guardian/id1093447833?ls=1&mt=8',
+  iosImg: '',
+  androidLabel: 'Google Play',
+  androidUrl: 'https://play.google.com/store/apps/details?id=com.auth0.guardian',
+  androidImg: ''
+},
+
+pushAuth: {
+  pushSent: {
+    useTotpFallback: 'If you haven\'t received the notification,

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

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

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

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

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

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

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

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

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

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

      Your app can keep the ID Token in memory.

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

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

      To learn more about this migration and the steps you should follow to upgrade your implementation, see Migration Guide: Extensibility and Node.js v12.
+      
      Instagram Connection Deprecation5 March 202031 March 2020Facebook announced that on March 31th, 2020, they will turn off the Instagram legacy APIs, and they won't provide an alternative to implement Login with Instagram
      Changes in the Yahoo user profile1 March 20201 March 2020Yahoo changed the way to retrieve the user profile and the information included on it.
      Management API v1October 2016
+        Public Cloud: 13 July 2020
      
+        Private Cloud: November 2020 release
      
+            		Management API v1 will reach its End of Life in the Public Cloud on July 13, 2020. Management API v1 will be included in the Private Cloud until the November 2020 monthly release, which is the first release that will not include Management API v1. You may be required to take action before that date to ensure no interruption to your service. A migration guide is available to walk you through the required steps. Notifications have been and will continue to be sent to customers that need to complete this migration.
      Useful Resources:
      
+        Management API v1 to v2 Migration Guide
      
+        Management API v2 documentation
      
+        Management API v1 documentation
      
+        Breaking changes
      
+      
      /oauth/ro deprecation for Passwordless Connections8 June 2017
+        TBD
+      On June 8th 2017 we deprecated the /oauth/ro endpoint for passwordless connections. You can now implement the same functionality using the /oauth/token endpoint.
      User Search v26 June 201830 June 2019User Search v2 is being deprecated and you may be required to take action before June 30, 2019. A migration guide is available to walk you through the steps required. Notifications have been and will continue to be sent to customers that need to complete this migration.
      Useful Resources:
      
+        User Search v3
      
+        User Search v3 - Query Syntax
      
+        User Search Best Practices
      
+        User Search v2 to v3 Migration Guide
      
+      
      Tenant Logs Search v221 May 2019
+        Free: 9 July 2019
      
+        Developer: 20 August 2019
      
+        Developer Pro: 20 August 2019
      
+        Enterprise: 4 November 2019
+            		To provide our customers with the most reliable and scalable solution, Auth0 has deprecated Tenant Logs Search Engine v2 in favor of v3. Auth0 is proactively migrating customers unaffected by this change, while those who are potentially affected are being notified to opt in for v3 during the provided grace period.  See the migration guide for more information.
      
+
+If you have any questions, please visit the Migrations section of the [Auth0 Community site](https://community.auth0.com/c/auth0-community/Migrations) or create a ticket in our [Support Center](${env.DOMAIN_URL_SUPPORT}).
diff --git a/ja-jp/articles/product-lifecycle/product-release-stages.md b/ja-jp/articles/product-lifecycle/product-release-stages.md
new file mode 100644
index 0000000000..f663e50032
--- /dev/null
+++ b/ja-jp/articles/product-lifecycle/product-release-stages.md
@@ -0,0 +1,71 @@
+---
+toc: true
+title: Product Release Stages
+description: Learn how we stage, release, and retire product functionality.
+topics:
+  - migrations
+  - product-lifecycle
+contentType:
+  - reference
+useCase:
+  - migrate
+---
+
+# Product Release Stages
+
+Product release stages describe how we stage, release, and retire product functionality. Product features may not progress through all release stages, and the time in each stage will vary depending on the scope and impact of the feature.
+
+## Early Access (Alpha)
+
+Early access offerings give a limited number of subscribers or customer development partners (CDPs) the opportunity to test and provide feedback on future functionality. At this stage, functionality may not be complete, but is ready for validation. 
+
+During this stage, we work with participants to
+
+* confirm that functionality aligns with the intended goal
+* validate that the solution is usable in practice
+* elicit suggested improvement
+
+During this stage, our goal is to ensure that the eventual release provides the maximum value to our customers.
+
+When participating in an early access program, you should understand the following:
+
+* Functionality is under active development, so we do not yet support it for production use.
+* We expect breaking changes, but will do our best to communicate them.
+* The program provides a private preview available to only a limited number of select subscribers.
+* Your feedback may help shape the General Availability (GA) or a subsequent release.
+
+Early Access offerings are subject to our Beta Service Terms, which you can view at [Legal](https://auth0.com/legal).
+
+## Beta (Private or Public)
+
+Beta releases give subscribers time to explore and adopt new product capabilities while providing final feedback prior to a General Availability (GA) release. Functionality is code-complete, stable, useful in a variety of scenarios, and believed to meet or almost meet quality expectations for a GA release. Beta releases may be restricted to a select number of subscribers (private) or open to all subscribers (public).
+
+When participating in a beta release, you should understand the following:
+
+* Functionality is feature complete, but we do not yet support it for production use.
+* Breaking changes may occur, and we will do our best to communicate them.
+* Your feedback may help prioritize improvements and fixes in a subsequent release.
+
+Beta releases are subject to our Beta Service Terms, which you can view at [Legal](https://auth0.com/legal).
+
+## General Availability
+
+General Availability (GA) releases are fully functional and available to all subscribers (limited by pricing tier) for production use. If a new release replaces an existing feature, we provide a period of backward compatibility in accordance with our deprecation policy and inform customers so they have time to adopt the new release.
+
+## Deprecation
+
+Deprecated features are not supported for use by new subscribers, are not actively being enhanced, and are being only minimally maintained. Tenants using the feature at the time of deprecation will continue to have access. 
+
+Deprecation begins when we introduce new behavior that customers would experience as a breaking change without mediation and ends when the old behavior moves into the End of Life product release stage. During Deprecation, customers should engage in a migration to move away from the deprecated feature or behavior. To learn more, see [Migration Process](/product-lifecycle/migration-process).
+
+Although we know that deprecations can be disruptive, they are necessary to allow us to upgrade technology, improve security and quality, and continue to invest in resources that provide the most value for our customers.
+
+We are committed to transparency, so we try to proactively notify subscribers when deprecations result in breaking changes or cause altered use of Auth0. Additionally, we try to provide end-of-life notices with accompanying recommendations for migration and replacement capabilities where available.
+
+For self-service subscribers, Deprecation is subject to our [Identity Platform Terms of Service](https://auth0.com/legal/ss-tos). For enterprise customers, Deprecation is subject to the Subscription Agreement, which you can view at [Legal](https://auth0.com/legal). 
+
+## End Of Life
+
+Features that reach this stage are removed from the platform. Continued use of these features will likely result in errors.
+
+For self-service subscribers, End of Life is subject to our [Identity Platform Terms of Service](https://auth0.com/legal/ss-tos). For enterprise customers, End of Life is subject to the Subscription Agreement, which you can view at [Legal](https://auth0.com/legal). 
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/index.html b/ja-jp/articles/protocols/index.html
new file mode 100644
index 0000000000..18daba8d31
--- /dev/null
+++ b/ja-jp/articles/protocols/index.html
@@ -0,0 +1,77 @@
+---
+url: /protocols
+section: articles
+classes: topic-page
+title: Protocols
+description: Which authentication and authorization protocols Auth0 supports and how they work.
+topics:
+  - protocols
+  - oauth2
+  - oidc
+  - saml
+  - ws-fed
+  - ldap
+contentType:
+  - index
+useCase:
+  - add-idp
+---
+
+
      
+  
      
+  
      Protocols
      
+  
      
+    Which authentication and authorization protocols Auth0 supports and how they work.
+  
      
+
      
+
+
      
+  Auth0 implements proven, common and popular identity protocols used in consumer oriented web products (OAuth 2.0, OpenID Connect (OIDC)) and in enterprise deployments (SAML, WS-Federation, LDAP).
+
      
+
+
        
+  
      • 
+    OAuth 2.0
+    
        
+      OAuth 2.0 is an authorization framework that enables a third-party application to obtain limited access to resources the end-user owns. It is about resource access and sharing.
+    
        
+    
+  
        • 
+  
      • 
+    OpenID Connect
+    
        
+      OpenID Connect (OIDC) is an identity layer built on top of the OAuth 2.0 framework. It allows third-party applications to verify the identity of the end-user and to obtain basic user profile information. At the core, OIDC is about user authentication.
+    
        
+  
        • 
+  
      • 
+    SAML
+    
        
+      Security Assertion Markup Language (SAML) is an XML-based framework for authentication and authorization between two entities: a Service Provider and an Identity Provider. The Service Provider agrees to trust the Identity Provider to authenticate users. The Identity Provider authenticates users and provides to Service Providers an Authentication Assertion that indicates a user has been authenticated.
+    
        
+  
        • 
+  
      • 
+    WS-Federation
+    
        
+      WS-Federation is part of the larger WS-Security framework and an extension to the functionality of WS-Trust. The features of WS-Federation can be used directly by SOAP applications and web services.
+    
        
+  
        • 
+  
      • 
+    LDAP
+    
        
+      Lightweight Directory Access Protocol (LDAP) is an application protocol, used for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.
+    
        
+  
        • 
+
      
diff --git a/ja-jp/articles/protocols/ldap/index.md b/ja-jp/articles/protocols/ldap/index.md
new file mode 100644
index 0000000000..03aaf00b10
--- /dev/null
+++ b/ja-jp/articles/protocols/ldap/index.md
@@ -0,0 +1,24 @@
+---
+description: Details about the LDAP protocol and how it is used by Auth0.
+topics:
+    - protocols
+    - ldap
+contentType:
+  - concept
+useCase:
+  - development
+---
+
+# LDAP
+
+The **Lightweight Directory Access Protocol (LDAP)** is an application protocol, used for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network.
+
+The function of LDAP is to enable access to an existing directory, like Active Directory.
+
+In Auth0 we use LDAP to integrate with Active Directory/LDAP through the Active Directory/LDAP Connector that you install in your network.
+
+For more information refer to [Active Directory/LDAP Connector](/connector).
+
+::: note
+You can use [this endpoint proxy implementation](https://github.com/auth0/auth0-ldap-endpoint) to connect a legacy application to Auth0 using the LDAP protocol.
+:::
diff --git a/ja-jp/articles/protocols/oauth2/index.md b/ja-jp/articles/protocols/oauth2/index.md
new file mode 100644
index 0000000000..528c308a9a
--- /dev/null
+++ b/ja-jp/articles/protocols/oauth2/index.md
@@ -0,0 +1,171 @@
+---
+description: What is the OAuth 2.0 Authorization Framework and how it works.
+toc: true
+topics:
+    - protocols
+    - oauth2
+    - oauth
+contentType:
+  - concept
+useCase:
+  - development
+---
+# OAuth 2.0 Authorization Framework
+
+[OAuth 2.0](https://tools.ietf.org/html/rfc6749) is a protocol that allows a user to grant a third-party web site or application access to the user's protected resources, without necessarily revealing their long-term credentials or even their identity. 
+
+OAuth introduces an authorization layer and separates the role of the client from that of the resource owner. In OAuth, the client requests access to resources controlled by the resource owner and hosted by the resource server and is issued a different set of credentials than those of the resource owner. Instead of using the resource owner's credentials to access protected resources, the client obtains an access token; a string denoting a specific scope, lifetime, and other access attributes. Access tokens are issued to third-party clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.
+
+::: panel Access Token Format
+By default, Auth0 generates Access Tokens for [API Authorization scenarios](/api-auth) in JSON Web Token (JWT) format. JWTs contain three parts: a header, a payload, and a signature:
+- The header contains metadata about the type of token and the cryptographic algorithms used to secure its contents.
+- The payload contains a set of claims, which are statements about the permissions that should be allowed, and other information like the intended audience and the expiration time.
+- The signature is used to validate that the token is trustworthy and has not been tampered with.
+:::
+
+The permissions represented by the access token, in OAuth terms are known as **scopes**. When an application authenticates with Auth0, it specifies the scopes it wants. If those scopes are authorized by the user, then the access token will represent these authorized scopes. For example, a Contacts API may accept three different authorization levels specifying the corresponding scopes: 
+- Reading contacts (`read:contacts`)
+- Creating contacts (scope `create:contacts`)
+- Deleting contacts (scope `delete:contacts`)
+
+For more information refer to [Scopes](/scopes).
+
+## OAuth roles
+
+In any OAuth 2.0 flow we can identify the following roles:
+
+- **Resource Owner**: the entity that can grant access to a protected resource. Typically this is the end-user.
+
+- **Resource Server**: the server hosting the protected resources. This is the API you want to access.
+
+- **Client**: the app requesting access to a protected resource on behalf of the Resource Owner.
+
+- **Authorization Server**: the server that authenticates the Resource Owner, and issues Access Tokens after getting proper authorization. In this case, Auth0.
+
+## Protocol flow
+
+We will now have a more detailed look on how the protocol works. As we will see in a while, OAuth has many "flavors" (called authorization grant types) that you can use. For now we will have a more generic look into the flow.
+
+![Generic OAuth Flow](/media/articles/protocols/oauth2-generic-flow.png)
+
+1. The Application (Client) asks for authorization from the Resource Owner in order to access the resources.
+
+1. Provided that the Resource Owner authorizes this access, the Application receives an **Authorization Grant**. This is a credential representing the Resource Owner's authorization.
+
+1. The Application requests an **Access Token** by authenticating with the Authorization Server and giving the Authorization Grant.
+
+1. Provided that the Application is successfully authenticated and the Authorization Grant is valid, the Authorization Server issues an Access Token and sends it to the Application.
+
+1. The Application requests access to the protected resource by the Resource Server, and authenticates by presenting the Access Token.
+
+1. Provided that the Access Token is valid, the Resource Server serves the Application's request.
+
+## Authorization grant types
+
+The [OAuth 2.0 Authorization Framework specification](https://tools.ietf.org/html/rfc6749) defines four flows to get an Access Token. These flows are called **grant types**. Deciding which one is suited for your case depends mostly on the type of your application.
+
+- [Authorization Code](/flows/concepts/auth-code): used by Web Apps executing on a server. This is also used by mobile apps, using the [Proof Key for Code Exchange (PKCE) technique](/flows/concepts/auth-code-pkce).
+
+- [Implicit](/flows/concepts/implicit): used by JavaScript-centric apps (Single-Page Applications) executing on the user's browser.
+
+- [Resource Owner Password Credentials](/api-auth/grant/password): used by trusted apps.
+
+- [Client Credentials](/flows/concepts/client-credentials): used for machine-to-machine communication.
+
+The specification also provides an extensibility mechanism for defining additional types.
+
+For details on how each grant type works and when it should be used refer to [API Authorization](/api-auth).
+
+## OAuth endpoints
+
+OAuth 2.0 utilizes two endpoints: the **Authorization** endpoint and the **Token** endpoint.
+
+### Authorization endpoint
+
+The Authorization endpoint is used to interact with the resource owner and get the authorization to access the protected resource. To better understand this, imagine that you want to log in to a service using your Google account. First, the service redirects you to Google in order to authenticate (if you are not already logged in) and then you will get a consent screen, where you will be asked to authorize the service to access some of your data (protected resources); for example, your email address and your list of contacts.
+
+The request parameters of the Authorization endpoint are:
+- `response_type`: Tells the authorization server which grant to execute. Refer to the [How Response Type Works paragraph](#how-response-type-works) for details.
+- `client_id`: The id of the application that asks for authorization.
+- `redirect_uri`: Holds a URL. A successful response from this endpoint results in a redirect to this URL.
+- `scope`: A space-delimited list of permissions that the application requires.
+- `state`: An opaque value, used for security purposes. If this request parameter is set in the request, then it is returned to the application as part of the `redirect_uri`.
+
+#### How response type works
+
+This endpoint is used by the **Authorization Code** and the **Implicit** [grant types](#authorization-grant-types). The authorization server needs to know which grant type the application wants to use, since it affects the kind of credential it will issue: 
+- For **Authorization Code** grant it will issue an authorization code (which can later be exchanged with an access token)
+- For **Implicit** grant it will issue an **access token**.
+
+An access token is an opaque string (or a [JWT](/tokens/concepts/jwts) in an Auth0 implementation) that denotes who has authorized which permissions (scopes) to which application. It is meant to be exchanged with an access token at the [token endpoint](#token-endpoint). 
+
+To inform the authorization server which grant type to use, the `response_type` request parameter is used as follows:
+
+- For **Authorization Code** grant, use `response_type=code` to include an authorization code.
+
+- For **Implicit** grant, use `response_type=token` to include an access token. An alternative is to set `response_type=id_token token` to include both an access token and an ID token.
+
+::: panel ID Token
+The ID Token is a JWT that contains information about the logged in user. It was introduced by **OpenID Connect (OIDC)**. For more info, see [OpenID Connect](/protocols/oidc) and [ID Token](/tokens/concepts/id-tokens).
+:::
+
+#### How response mode works
+
+The [OAuth 2.0 Multiple Response Type Encoding Practices](https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html) specification added a new parameter that specifies how the result of the authorization request is formatted. This parameter is called `response_mode`, it's optional and can take the following values:
+
+- `query`: This is the default for **Authorization Code** grant. A successful response is `302 Found`, which triggers a redirect to the `redirect_uri`. The response parameters are embedded in the query component (the part after `?`) of the `redirect_uri` in the `Location` header.
+
+  For example, a response might be:
+
+  ```text
+  HTTP/1.1 302 Found
+  Location: https://my-redirect-uri/callback?code=js89p2x1
+  ```
+
+  Where, the `redirect_uri` is `https://my-redirect-uri/callback` and the authorization code is `js89p2x1`.
+
+- `fragment`: This is the default for **Implicit** grant. A successful response is `302 Found`, which triggers a redirect to the `redirect_uri` (which is a request parameter). The response parameters are embedded in the fragment component (the part after `#`) of the `redirect_uri` in the `Location` header.
+
+  For example, a response might be:
+
+  ```text
+  HTTP/1.1 302 Found
+  Location: https://my-redirect-uri/callback#access_token=eyB...78f&token_type=Bearer&expires_in=3600
+  ```
+
+  Where, the `redirect_uri` is `https://my-redirect-uri/callback`, the Access Token is `eyB...78f`, it's a Bearer token and it expires in 3600 seconds.
+
+- `form_post`: This response mode is defined in the [OAuth 2.0 Form Post Response Mode](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html) specification. A successful response is `200 OK` and the response parameters are embedded in an HTML form as hidden params. The `action` of the form is the `redirect_uri` and the `onload` attribute is configured to submit the form. After the HTML is loaded by the browser, a redirect to the `redirect_uri` is done.
+
+  For example, a response might be:
+
+  ```html
+  HTTP/1.1 200 OK
+  
+   Submit
+   
+    
      
+      
+      
+    
      
+   
+  
+  ```
+
+- `web_message`: This response mode is defined in the [OAuth 2.0 Web Message Response Mode specification](https://tools.ietf.org/html/draft-sakimura-oauth-wmrm-00). It uses HTML5 Web Messaging instead of the redirect for the Authorization Response from the Authorization Endpoint. This is particularly useful when using [Silent Authentication](/api-auth/tutorials/silent-authentication). To use this response mode you have to register your app's URL at the __Allowed Web Origins__ field of your [Application's settings](${manage_url}/#/applications/${account.clientId}/settings).
+
+### Token endpoint
+
+The Token endpoint is used by the application in order to get an [access token](/tokens/concepts/access-tokens) or a [refresh token](/tokens/concepts/refresh-tokens). It is used by all flows, except for the [Implicit Flow](/flows/concepts/implicit) (since an access token is issued directly).
+
+- In the [Authorization Code Flow](/flows/concepts/auth-code), the application exchanges the authorization code it got from the Authorization endpoint for an access token.
+
+- In the [Client Credentials Flow](/flows/concepts/client-credentials) and [Resource Owner Password Credentials Grant](/api-auth/grant/password), the application authenticates using a set of credentials and then gets an access token.
+
+## Keep reading
+
+* [Which OAuth 2.0 flow should I use?](/api-auth/which-oauth-flow-to-use)
+* [API Authorization](/api-auth)
+* [State Parameter](/protocols/oauth2/oauth-state)
+* [Mitigate CSRF Attacks](/protocols/oauth2/mitigate-csrf-attacks)
+* [Redirect Users](/protocols/oauth2/redirect-users)
diff --git a/ja-jp/articles/protocols/oauth2/mitigate-csrf-attacks.md b/ja-jp/articles/protocols/oauth2/mitigate-csrf-attacks.md
new file mode 100644
index 0000000000..28dc65952a
--- /dev/null
+++ b/ja-jp/articles/protocols/oauth2/mitigate-csrf-attacks.md
@@ -0,0 +1,74 @@
+---
+title: Mitigate CSRF Attacks with State Parameters
+description: Learn how to use the OAuth 2.0 state parameters against CSRF attacks.
+topics:
+    - protocols
+    - oauth
+    - state-parameter
+    - csrf
+    - xsrf
+contentType: how-to
+useCase: development
+---
+# Mitigate CSRF Attacks With State Parameters
+
+You can deny malicious requests by using the `state` parameter to hold a correlation value for verification.
+
+A CSRF attack can occur when a malicious program causes a user's web browser to perform an unwanted action on a trusted site on which the user is currently authenticated. This type of attack specifically targets state-changing requests to initiate an action instead of getting user data because the attacker has no way to see the response to the forged request.
+
+The state parameter helps mitigate CSRF attacks to ensure that the response belongs to a request that was initiated by the same user. For the most basic cases the state parameter should be a nonce, used to correlate the request with the response received from the authentication. 
+
+::: note
+Most modern OIDC and OAuth2 SDKs, including Auth0.js in single-page applications, handle the state generation and validation automatically. 
+:::
+
+1. Before redirecting a request to the [IdP](/identityproviders), have the application generate a random string. For example:
+
+   ```text
+   xyzABC123
+   ```
+
+::: note
+The allowed length for state is not unlimited. If you get the error `414 Request-URI Too Large` try a smaller value.
+:::
+
+2. Store this string locally. Choose a method based on your type of application. For example:
+
+   * For regular web apps, use a cookie or session
+   * For a single-page app, use local storage in the browser
+   * For a native app, use memory or local storage
+
+   ```text
+   storeStateLocally(xyzABC123)
+   ```
+
+3. Add the `state` parameter to the request (URL-encoding if necessary).
+
+   ```js
+   // Encode the String
+   tenant.auth0.com/authorize?...&state=xyzABC123
+   ```
+
+   After the request is sent, the user is redirected back to the application by Auth0. The `state` value will be included in this redirect. Note that depending on the type of connection used, this value might be in the body of the request or in the query string.
+
+   ```text
+   /callback?...&state=xyzABC123
+   ```
+
+4.  Retrieve the returned `state` value and compare it with the one you stored earlier. If the values match, then approve the authentication response, else deny it.
+
+   ```js
+   // Decode the String
+   var decodedString = Base64.decode(encodedString);
+   if(receivedState === retrieveStateStoredLocally()) {
+    	// Authorized request
+   } else {
+    	// This response is not for us, reject it
+   }
+   ```
+
+## Keep reading
+
+* [State Parameter Overview](/protocols/oauth2/oauth-state)
+* [OAuth 2.0 Framework](/protocols/oauth2)
+* [Protecting against other common threats](/security/common-threats)
diff --git a/ja-jp/articles/protocols/oauth2/oauth-state.md b/ja-jp/articles/protocols/oauth2/oauth-state.md
new file mode 100644
index 0000000000..4667907642
--- /dev/null
+++ b/ja-jp/articles/protocols/oauth2/oauth-state.md
@@ -0,0 +1,51 @@
+---
+title: State Parameter
+description: Explains how to use the state parameter in authentication requests to help prevent CSRF attacks and restore state
+topics:
+    - protocols
+    - oauth
+    - state-parameter
+    - csrf
+    - xsrf
+    - redirecting
+    - manage-users
+contentType:
+  - concept
+useCase:
+  - development
+---
+
+# State Parameter
+
+Authorization protocols provide a `state` parameter that allows you to restore the previous state of your application. The `state` parameter preserves some state object set by the client in the Authorization request and makes it available to the client in the response.  
+
+## CSRF attacks
+
+The primary reason for using the `state` parameter is to mitigate [CSRF attacks](https://en.wikipedia.org/wiki/Cross-site_request_forgery).
+
+When you use `state` for CSRF mitigation on the redirection endpoint, that means that within the `state` value there is a unique and non-guessable value associated with each authentication request about to be initiated. It’s that unique and non-guessable value that allows you to prevent the attack by confirming if the value coming from the response matches the one you expect (the one you generated when initiating the request). The `state` parameter is a string so you can encode any other information in it. 
+
+The way this works is that you send a random value when starting an authentication request and validate the received value when processing the response. This requires you to store something on the client application side (in session or another medium) that allows you to perform the validation. If you receive a response with a state that does not match, you may be the target of an attack because this is either a response for an unsolicited request or someone trying to forge the response. For more information, see [Mitigate CSRF Attacks With State Parameters](/protocols/oauth2/mitigate-csrf-attacks).
+
+![Diagram of CSRF attack](/media/articles/protocols/CSRF_Diagram.png)
+
+::: warning
+The cookie in which the `state` value is stored should be signed to prevent attackers to forge it.
+:::
+
+## Redirect users
+
+You can also use the `state` parameter to encode an application state that will round-trip to the client application after the transaction completes. In this way, the application can put the user where they were before the authentication process happened. For more information, see [Redirect Users With State Parameters](/protocols/oauth2/redirect-users). 
+
+## Limitations
+
+* From a security perspective, neither the request nor the response is integrity-protected so a user can manipulate them. That is true for adding a parameter to the `redirect_uri` as well.
+* The allowed length for `state` is not unlimited. If you get the error `414 Request-URI Too Large`, try a smaller value.
+
+## Keep reading
+
+* [OAuth 2.0 Authorization Framework](/protocols/oauth2)
+* [Which OAuth 2.0 flow should I use?](/api-auth/which-oauth-flow-to-use)
+* [API Authorization](/api-auth)
+* [Mitigate CSRF Attacks With State Parameters](/protocols/oauth2/mitigate-csrf-attacks)
+* [Redirect Users With State Parameters](/protocols/oauth2/redirect-users)
diff --git a/ja-jp/articles/protocols/oauth2/redirect-users.md b/ja-jp/articles/protocols/oauth2/redirect-users.md
new file mode 100644
index 0000000000..5ccdcadfa4
--- /dev/null
+++ b/ja-jp/articles/protocols/oauth2/redirect-users.md
@@ -0,0 +1,63 @@
+---
+title: Redirect Users With State Parameters
+description: How to redirect users with the OAuth 2.0 state parameter. 
+topics:
+  - users
+  - user-management
+  - state-parameter
+  - redirection
+contentType: how-to
+useCase: manage-users
+---
+# Redirect Users with State Parameters
+
+You can store the application state parameter before you redirect users to authenticate so that you can redirect them back to a URL. For example, if a user intends to access a protected page in your application, and that action triggers the request to authenticate, you can store that URL to redirect the user back to their intended page after the authentication finishes.
+
+Use the `state` parameter to lookup and restore the previous state of your application. Generate and store a `nonce` locally (cookies/session/localstorage), along with any desired state data (like the redirect URL). Use the `nonce` as a state in the protocol message. If the returned state matches the stored nonce, accept the OAuth2 message and fetch the corresponding state data from storage. This is the approach used by Auth0.js.
+
+::: warning
+Passing URLs in plaintext or in any predictable way is unsafe. State should always be unique and opaque to ensure that:
+
+* `state` can be used for defense against CSRF attacks
+* your app is not vulnerable to open redirect exploits, which can lead to phishing attacks
+:::
+
+1. Generate the `nonce` that you will use to protect against CSRF attacks as explained before. Store the `nonce` locally, using it as the key to store all the other application state like the URL where the user intended to go. For example:
+
+   ```json
+   {
+     "xyzABC123" : {
+       redirectUrl: '/protectedResource',
+       expiresOn: [...]
+     }
+   }
+   ```
+
+2. Authenticate the user, sending the generated `nonce` as the state.
+
+3. As part of the callback processing and response validation, verify that the state returned matches the `nonce` stored locally. If it does, retrieve the rest of the application state (like the `redirectUrl`). 
+
+4. Once you complete the callback processing, redirect the user to the URL previously stored.
+
+   Again, how you store the `nonce` and the URL or other information pertinent to the application state depends on your application's type. It can be local storage in single-page or native apps or a cookie in a regular web app. 
+
+## Alternate method
+
+Alternatively, you can:
+
+1. Generate and store a `nonce` locally. 
+
+2. Encode any desired `state` (like the redirect URL) along with the `nonce` in a protected message (that will need to be encrypted/signed to avoid tampering). 
+
+3. In the response processing, unprotect the message, getting the `nonce` and other properties stored. 
+
+4. Validate that the included `nonce` matches what was stored locally and, if so, accept the OAuth2 message.
+
+## Keep reading
+
+* [OAuth 2.0 Authorization Framework](/protocols/oauth2)
+* [State Parameter](/protocols/oauth2/oauth-state)
+* [Rules](/rules)
+* [Redirect Users After Login Authentication](/users/guides/redirect-users-after-login)
+* [Which OAuth 2.0 flow should I use?](/api-auth/which-oauth-flow-to-use)
+* [API Authorization](/api-auth)
diff --git a/ja-jp/articles/protocols/oidc/identity-providers/okta.md b/ja-jp/articles/protocols/oidc/identity-providers/okta.md
new file mode 100644
index 0000000000..b0e4ca230e
--- /dev/null
+++ b/ja-jp/articles/protocols/oidc/identity-providers/okta.md
@@ -0,0 +1,178 @@
+---
+description: How to configure Okta for use as an OpenID Connect identity provider.
+toc: true
+topics:
+    - protocols
+    - oidc
+    - okta
+contentType:
+  - concept
+useCase:
+  - development
+  - add-idp
+---
+# Configure Okta as an OpenID Connect Identity Provider
+
+This article walks you through configuring Okta for use as an OpenID Connect (OIDC) identity provider.
+
+## 1. Create an Okta Application
+
+First, [log in to your Okta account](https://login.okta.com) and head to your Okta dashboard. 
+
+Select **Applications** on the top menu. On the Applications page, click the **Add Application** button to create a new app.
+
+![Okta Applications Dashboard](/media/articles/oidc/identity-providers/okta/okta-app-dashboard.png)
+
+On the **Create New Application** page, select the **Platform** for your application.
+
+![Okta Create Application Select Platform](/media/articles/oidc/identity-providers/okta/okta-create-app-platform.png)
+
+Next, provide the following information for your application settings:
+
+Field | Description
+------|------------
+Name | The name of your application.
+Base URIs (optional) | The domain(s) of your application.
+Login redirect URIs | This should be set to `https://${account.namespace}/login/callback`.
+Group assignments (optional) | The user groups that can sign in to this application.
+Grant type allowed | The grant types to enable for your application.
+
+::: note
+The application settings fields may differ depending on the platform your choose.
+:::
+
+![Okta Create Application Settings](/media/articles/oidc/identity-providers/okta/okta-create-app-settings.png)
+
+Click **Done** to proceed. You'll be taken to the **General** page of your app.
+
+## 2. Get Your Client ID and Client Secret
+
+Go to the **General** page of your app and scroll down to the **Client Credentials** section. This section contains the **Client ID** and **Client Secret** to be used in the next step.
+
+## 3. Create a Custom OpenID Connection with Auth0
+
+At this point, you will configure the integration from the Auth0 side.
+
+Auth0 supports creating custom OpenID Connections by using the [Custom Social Connections Extension](/extensions/custom-social-extensions). Follow the guide to [Setup a New Social Connection](/extensions/custom-social-extensions#set-up-a-new-social-connection) and use the following values for the connection settings:
+
+- __Name__: The name of the connection. Use a name that clearly identify the okta account, you are free to name the connection whatever you would like;
+- __Client ID__: Use the **Client ID** you obtained in the *General* page of your application in Okta;
+- __Client Secret__: Use the **Client Secret** you obtained in the *General* page of your application in Okta;
+- __Authorization URL__: Set `https://{okta-account}/oauth2/v1/authorize`, replacing *{okta-account}* with the DNS name of the Okta account where you registered the application;
+- __Token URL__: Set `https://{okta-account}/oauth2/v1/token`, replacing *{okta-account}* with the DNS name of the Okta account where you registered the application;
+- __Scope__: The scope parameters to get the profile, as a first approach you can use `openid email profile`;
+- __Fetch User Profile Script__: Use the following Script, replacing *{okta-account}* with the DNS name of the Okta account where you registered the application.
+    ```javascript
+    function(accessToken, ctx, cb) {
+      request({
+        url: "https://{okta-account}/oauth2/v1/userinfo",
+        method: "GET",
+        headers: {
+            "Authorization": "Bearer " + accessToken,
+            "Content-Type": "application/json"
+        }
+        },
+        function(e, r, b) {
+        if (e) return cb(e);
+        if (r.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode));
+        profile = JSON.parse(b);
+        profile.user_id = profile.sub;
+        delete profile.sub;
+        cb(null, profile);
+        }
+      );
+    }
+    ```
+- __Custom Headers__: Leave it empty
+
+Click **Save** to proceed and then continue following the instructions to enable the [connection in your applications](/extensions/custom-social-extensions#new-connection-apps).
+
+## 4. Create an Okta Authorization Server
+
+To retrieve custom claims from Okta, ensure you've set up an Okta authorization server and configured your custom claims in the authorization server settings.
+
+::: note
+For more information on creating an Okta authorization server and adding claims, check out the [Set Up an Authorization Server](https://developer.okta.com/docs/how-to/set-up-auth-server.html) page of the Okta documentation.
+:::
+
+Once the Okta authorization server is set up, continue with the following sections to update the [custom connection](/extensions/custom-social-extensions) you previously created for Okta.
+
+## 5. Get Your Okta Authorization Server Issuer URI
+
+[Log in](https://login.okta.com) to your Okta dashboard and select **Authorization Servers** from the **API** menu at the top.
+
+![Okta Dashboard API Menu](/media/articles/oidc/identity-providers/okta/okta-dashboard-api-menu.png)
+
+On the **Authorization Servers** page, locate the authorization server you created, and make note of the **Issuer URI**. The **Issuer URI** should have the following structure:
+
+`https://{okta-account}/oauth2/{authorization-server-id}`
+
+The **Issuer URI** will be used in the next step.
+
+## 6. Update Your Custom Okta Connection
+
+Visit to the [Extensions](${manage_url}/#/extensions) page on the Auth0 dashboard and click **Custom Social Connections**.
+
+![Manage Auth0 Extensions](/media/articles/oidc/identity-providers/okta/extensions.png)
+
+Next, select your custom Okta connection. In the **Settings** section, update the following fields with your **Issuer URI** and the appropriate endpoint:
+
+Field | Value
+------|------
+Authorization URL | `https://{okta-account}/oauth2/{authorization-server-id}/v1/authorize`
+Token URL | `https://{okta-account}/oauth2/{authorization-server-id}/v1/token`
+
+Then, scroll down to the **Fetch User Profile Script**, it should look something like this:
+
+```javascript
+function(accessToken, ctx, cb) {
+  request({
+    url: "https://{okta-account}/oauth2/v1/userinfo",
+    method: "GET",
+    headers: {
+        "Authorization": "Bearer " + accessToken,
+        "Content-Type": "application/json"
+    }
+    },
+    function(e, r, b) {
+    if (e) return cb(e);
+    if (r.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode));
+    profile = JSON.parse(b);
+    profile.user_id = profile.sub;
+    delete profile.sub;
+    cb(null, profile);
+    }
+  );
+}
+```
+
+Update the `request.url` with your **Issuer URI** and the `/userinfo` endpoint. For example:
+
+```javascript
+function(accessToken, ctx, cb) {
+  request({
+    url: "https://{okta-account}/oauth2/{authorization-server-id}/v1/userinfo",
+    method: "GET",
+    headers: {
+        "Authorization": "Bearer " + accessToken,
+        "Content-Type": "application/json"
+    }
+    },
+    function(e, r, b) {
+    if (e) return cb(e);
+    if (r.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode));
+    profile = JSON.parse(b);
+    profile.user_id = profile.sub;
+    delete profile.sub;
+    cb(null, profile);
+    }
+  );
+}
+```
+
+Next, click the **Try** button to test the connection. If accepted, you should see the **It Works!** confirmation page.
+
+## Keep reading
+
+* [Configure Applications with OpenID Connect Discovery](/protocols/oidc/openid-connect-discovery)
+* [OIDC Handbook](https://auth0.com/resources/ebooks/the-openid-connect-handbook)
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/oidc/index.md b/ja-jp/articles/protocols/oidc/index.md
new file mode 100644
index 0000000000..1c0ecdbdf1
--- /dev/null
+++ b/ja-jp/articles/protocols/oidc/index.md
@@ -0,0 +1,54 @@
+---
+url: /protocols/oidc
+title: OpenID Connect
+description: Learn about the OpenID Connect (OIDC) protocol and how it works.
+topics:
+    - protocols
+    - connections
+    - oidc
+    - open-id-connect
+contentType:
+  - index
+  - concept
+useCase:
+  - development
+  - oidc
+---
+# OpenID Connect
+
+OpenID Connect (OIDC) is an authentication protocol, based on the OAuth 2.0 family of specifications. It uses simple JSON Web Tokens (JWT), which you can obtain using flows conforming to the OAuth 2.0 specifications.
+
+While OAuth 2.0 is about resource access and sharing, OIDC is all about user authentication. Its purpose is to give you one login for multiple sites. Each time you need to log in to a website using OIDC, you are redirected to your OpenID site where you login, and then taken back to the website.
+
+For example, if you chose to sign in to Auth0 using your Google account then you used OIDC. Once you successfully authenticate with Google and authorize Auth0 to access your information, Google will send back to Auth0 information about the user and the authentication performed. This information is returned in a JWT. You'll receive an Access Token and, if requested, an ID Token.
+
+## How it works
+
+Let's use the example we mentioned earlier, signing into Auth0 using your Google account, for a high level overview on how the flow works:
+
+1. When you choose to sign in to Auth0 using your Google account, Auth0 sends an **Authorization Request** to Google.
+1. Google authenticates your credentials or asks you to login if you are not already signed in, and asks for your authorization (lists all the permissions that Auth0 wants, for example read your email address, and asks you if you are ok with that).
+1. Once you authenticate and authorize the sign in, Google sends an Access Token, and (if requested) an ID Token, back to Auth0.
+1. Auth0 can retrieve user information from the ID Token or use the Access Token to invoke a Google API.
+
+## Access Tokens
+
+[Access Tokens](/tokens/concepts/access-tokens) are credentials that can be used by an application to access an API. Access Tokens can be an opaque string, JWT, or non-JWT token. Its purpose is to inform the API that the bearer of this token has been granted delegated access to the API and request specific actions (as specified by the scopes that have been granted).
+
+## ID Tokens
+
+The [ID Token](/tokens/id_token) is a JSON Web Token (JWT) that contains identity data. It is consumed by the application and used to get user information like the user's name, email, and so forth, typically used for UI display. ID Tokens conforms to an industry standard (IETF [RFC 7519](https://tools.ietf.org/html/rfc7519)) and contain three parts: a header, a body and a signature.
+
+### Claims
+
+JWT Tokens contain [claims](/tokens/concepts/jwt-claims), which are statements (such as name or email address) about an entity (typically, the user) and additional metadata.
+
+The [OpenID Connect specification](https://openid.net/specs/openid-connect-core-1_0.html) defines a set of [standard claims](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims). The set of standard claims include name, email, gender, birth date, and so on. However, if you want to capture information about a user and there currently isn't a standard claim that best reflects this piece of information, you can create [custom claims and add them to your tokens](/scopes/current/sample-use-cases#add-custom-claims-to-a-token).
+
+## Keep reading
+
+* [Configure Applications with OpenID Connect Discovery](/protocols/oidc/openid-connect-discovery)
+* [User Profiles Returned from OIDC-Compliant Pipelines](/users/normalized/oidc)
+* [OIDC Conformant Authentication Adoption Guide](/api-auth/tutorials/adoption)
+* [Webinar: Intro to OpenID Connect](https://auth0.com/resources/webinars/intro-openid-connect)
+* [OIDC Handbook](https://auth0.com/resources/ebooks/the-openid-connect-handbook)
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/oidc/openid-connect-discovery.md b/ja-jp/articles/protocols/oidc/openid-connect-discovery.md
new file mode 100644
index 0000000000..8f2a93e9ca
--- /dev/null
+++ b/ja-jp/articles/protocols/oidc/openid-connect-discovery.md
@@ -0,0 +1,72 @@
+---
+description: How to use OpenID Connect discovery to configure applications with Auth0.
+topics:
+    - protocols
+    - oidc-discovery
+    - oidc
+contentType:
+  - how-to
+useCase:
+  - development
+  - configure-apps
+  - oidc-discovery
+---
+
+# Configure Applications with OpenID Connect Discovery
+
+Auth0 exposes OpenID Connect (OIDC) discovery documents (`https://${account.namespace}/.well-known/openid-configuration`). These can be used to automatically configure applications.
+
+A good example is __OpenID Connect middleware for Katana v3 (OWIN)__:
+
+![](/media/articles/oidc-rs256-owin/oidc-discovery.png)
+
+1. Install the nuget package `Microsoft.Owin.Security.OpenIdConnect` (v3.x.x)
+2. Go to `App_Start\Startup.Auth.cs`, and replace your implementation with the following:
+
+  ```cs
+  app.UseCookieAuthentication(new CookieAuthenticationOptions
+  {
+    AuthenticationType = CookieAuthenticationDefaults.AuthenticationType
+  });
+
+  app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
+  {
+    Authority = "https://${account.namespace}/",
+    ClientId = "{YOUR_AUTH0_CLIENT_ID}",
+    SignInAsAuthenticationType = CookieAuthenticationDefaults.AuthenticationType,
+    ResponseType = "token",
+    Notifications = new OpenIdConnectAuthenticationNotifications
+    {
+      // OPTIONAL: you can read/modify the claims that are populated based on the JWT
+      SecurityTokenValidated = context =>
+      {
+        // add Auth0 Access Token as claim
+        var accessToken = context.ProtocolMessage.AccessToken;
+        if (!string.IsNullOrEmpty(accessToken))
+        {
+          context.AuthenticationTicket.Identity.AddClaim(new Claim("access_token", accessToken));
+        }
+
+        return Task.FromResult(0);
+      }
+    }
+  });
+  ```
+
+## Use RSA algorithm for JWTs
+
+The OpenID Connect middleware does not support JWTs signed with symmetric keys. Make sure you configure your app to use the RSA algorithm using public/private keys:
+
+On the Auth0 dashboard:
+
+1. Go to ${manage_url}/#/applications/{YOUR_AUTH0_CLIENT_ID}/settings
+2. Click on `Show Advanced Settings`.
+3. Set `RS256` as `JsonWebToken Token Signature Algorithm` and click on `Save`.
+
+![RSA 256](/media/articles/oidc-rs256-owin/rsa256.png)
+
+With this setting, Auth0 will issue JWTs signed with your private signing key. Your app will verify them with your public signing key.
+
+## Keep reading
+
+* [OIDC Handbook](https://auth0.com/resources/ebooks/the-openid-connect-handbook)
diff --git a/ja-jp/articles/protocols/saml/adfs.md b/ja-jp/articles/protocols/saml/adfs.md
new file mode 100644
index 0000000000..1651e92e6f
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/adfs.md
@@ -0,0 +1,128 @@
+---
+description: How to Set up an Auth0 SAML Connection Against ADFS
+toc: true
+topics:
+  - saml
+  - adfs
+  - active-directory-federation-services
+contentType:
+  - how-to
+useCase:
+  - add-idp
+  - saml-adfs
+---
+
+# Set Up an ADFS SAML Connection
+
+Create a custom SAML connection to Microsoft's Active Directory Federation Services (ADFS) to get more flexibility when configuring your mappings. 
+
+To create the custom connection, you will need to:
+
+1. Configure ADFS.
+2. Create a SAML connection where Auth0 acts as the service provider.
+3. Edit the Relying Party Trust in ADFS.
+4. Enable and test your integration.
+
+The following sections will guide you through this process. 
+
+## Configure ADFS
+
+### Add a Relying Party Trust
+
+See [Create a relying party trust](https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/create-a-relying-party-trust) for complete details.
+
+1. Launch your instance of ADFS and start the **Add Relying Party Trust** wizard.
+2. On the **Welcome** page, choose **Claims aware** and click **Start**. 
+3. On the **Select Data Source** page, select **Enter data about the relying party manually** and click **Next**.
+4. On the **Specify Display Name** page, provide a descriptive name for your relying party (the typical format is `urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME`) and a brief description under **Notes**. Be sure to replace `YOUR_CONNECTION_NAME` with a unique name you will also use to create a connection in Auth0 in a [later step](#Create-a-SAML-connection-with-Auth0-as-the-service-provider). If you are unsure of the connection name at this time, you can always edit the connection name later. Click **Next**.
+5. On the **Configure Certificate** page, click **Next**. (We will come back to configure the certificate later.)
+6. On the **Configure URL** page, check the box for **Enable support for the SAML 2.0 WebSSO protocol**. The wizard then asks for a **Relying party SAML 2.0 SSO service URL**. For the time being, provide a placeholder URL; we will return to this step later. Click **Next**.
+7. On the **Configure Identifiers** page, indicate that the **Relying party trust identifier** is `urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME` (or whatever value you used as the display name when you started using the wizard). Click **Next**.
+8. On the **Choose Access Control Policy** page, select **Permit everyone** and click **Next**.
+9. Review the settings you provided on the **Ready to Add Trust** page and click **Next** to save your information. If you were successful, you'll see a message indicating that on the **Finish** page. 
+10. Make sure that the **Configure claims issuance policy for this application** checkbox is selected, and click **Close**.
+
+### Edit the Claim Issuance Policy
+
+After you close the **Add Relying Party Trust** wizard, the **Edit Claim Issuance Policy** window appears.
+
+1. Click **Add Rule...** to launch the wizard. 
+2. Select **Send LDAP Attributes as Claims** for your **Claim rule template**, and click **Next**.
+3. Provide a value for the **Claim rule name**, such as "LDAP Attributes" (it can be anything you want). 
+4. Choose **Active Directory** as your **Attribute Store**. 
+5. Map your LDAP attributes to the following outgoing claim types:
+
+    | LDAP Attribute | Outgoing Claim |
+    | - | - |
+    | E-Mail-Addresses | E-Mail Address |
+    | Display-Name | Name |
+    | User-Principal-Name | Name ID |
+    | Given-Name | Given Name |
+    | Surname | Surname |
+
+    ::: note
+    The `Name ID` outgoing claim should always be present to ensure correct session handling. We strongly recommend adding all of the claims listed above, especially `E-Mail Address`, since they are the ones most commonly used.
+    :::
+
+    You can add additional claim mappings if necessary. See [Connect Your Application to Microsoft ADFS](/connections/enterprise/adfs#add-additional-ldap-attributes) for details.
+
+6. Click **Finish**.
+7. In the **Edit Claim Issuance Policy** window, click **Apply**. You can now exit out of this window.
+
+### Export the Signing Certificate
+
+Finally, you'll need to export the signing certificate from the ADFS console to upload it to Auth0.
+
+1. Using the left-hand navigation pane, go to **ADFS > Service > Certificates**. Select the **Token-signing** certificate, and right click to select **View Certificate**.
+2. On the **Details** tab, click **Copy to File...**. This launches the **Certificate Export Wizard**. Click **Next**.
+3. Choose **Base-64 encoded X.509 (.CER)** as the format you'd like to use. Click **Next**.
+4. Provide the location to where you want the certificate exported. Click **Next**.
+5. Verify that the settings for your certificate are correct and  click **Finish**.
+
+## Create a SAML connection with Auth0 as the service provider
+
+1. Follow the tutorial on creating a SAML connection where [Auth0 acts as the service provider](/protocols/saml/saml-sp-generic). Where prompted, upload the signing certificate you exported from ADFS.
+
+    The sign in and sign out URLs are usually in the form of `https://your.adfs.server/adfs/ls`.
+
+2. Click **Save**. A page with instructions for creating a new Relying Party Trust in ADFS appears displaying the exact values required for your Auth0 account/connection. Make a note of these values. 
+
+    Here is an example: 
+    
+    | Parameter | Example Value |
+    | - | - |
+    | Post-back URL | `https:///login/callback?connection=YOUR_CONNECTION_NAME` if a [custom domain](/custom-domains) is configured |
+    | --- | `https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME` if not using custom domains |
+    | Entity ID | `urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME` |
+    
+## Edit the Relying Party Trust
+
+1. In the ADFS console, go to **ADFS > Relying Party Trusts** using the left-hand navigation pane. Select the Relying Party Trust you created earlier and click **Properties** (located on the right-hand navigation pane). 
+2. Select the **Identifiers** tab, and populate the **Relying Party Identifier** with the **Entity ID** value from the previous screen. Be sure to click **Add** to add the identifier to your list.
+3. Select the **Endpoints** tab, and select the placeholder URL you provided earlier. Click **Edit...**.
+4. Populate the **Trusted URL** with the **Post-back URL** value.
+5. Click **OK**. Finally, click **Apply** and exit the Properties window.
+
+## Optional: Enable sign requests
+
+Optionally, you can sign your SAML requests to the ADFS server.
+
+1. Go to the **Settings** page for your SAMLP Identity Provider in the Auth0 Dashboard.
+2. Enable **Sign Requests**.
+3. Just below the **Sign Requests** toggle is a link to download your certificate.
+4. Return to ADFS and load the downloaded certificate using the **Signatures** tab of the Relying Party properties dialog.
+
+## Enable and test your integration
+
+Before you test your integration, make sure that you've completed the following steps:
+
+* Create a user on the IdP that you can use to test your new connection.
+* [Enable your Connection](/connections) for at least one application.
+
+1. To test your connection, navigate to **Connections > Enterprise > SAML**. 
+2. Click the ADFS row (or the hamburger icon to the right to bring up a list of your SAML connections). 
+3. Select the one you want to test and click the **play** button to test the connection.
+
+## Keep reading
+
+* [Troubleshooting SAML Configuration](/protocols/saml/saml-configuration/troubleshoot)
diff --git a/ja-jp/articles/protocols/saml/identity-providers/index.md b/ja-jp/articles/protocols/saml/identity-providers/index.md
new file mode 100644
index 0000000000..6b88cd5e80
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/identity-providers/index.md
@@ -0,0 +1,24 @@
+---
+title: SAML Identity Providers
+description: How to configure Auth0 to use other SAML Identity Providers.
+classes: topic-page
+topics:
+    - connections
+    - saml
+contentType:
+    - index
+useCase: customize-connections
+---
+
+# SAML Identity Providers
+
+The following articles will cover how you can configure these tools for use with Auth0 as SAML Identity Providers.
+
+<%= include('../../../_includes/_topic-links', { links: [
+  'protocols/saml/identity-providers/okta',
+  'protocols/saml/identity-providers/onelogin',
+  'protocols/saml/identity-providers/ping7',
+  'protocols/saml/identity-providers/salesforce',
+  'protocols/saml/identity-providers/siteminder',
+  'protocols/saml/identity-providers/ssocircle'
+] }) %>
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/saml/identity-providers/okta.md b/ja-jp/articles/protocols/saml/identity-providers/okta.md
new file mode 100644
index 0000000000..aa6b9c3a9b
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/identity-providers/okta.md
@@ -0,0 +1,78 @@
+---
+title: Okta
+description: How to configure Okta for use as an identity provider.
+toc: true
+topics:
+    - saml
+    - identity-providers
+    - okta
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Configure Okta as an Identity Provider
+
+In this article, we will cover how you can configure Okta for use with Auth0 as a SAML Identity Provider.
+
+## Configure Okta
+
+1. Sign in to the [Okta Developer Console](https://login.okta.com). If you don't already have an Okta account, you will need to create one. 
+2. Use the [App Integration Wizard](https://help.okta.com/en/prod/Content/Topics/Apps/Apps_App_Integration_Wizard.htm) to add an application for use with Auth0. 
+3. Use Okta's [SAML App Wizard](https://help.okta.com/en/prod/Content/Topics/Apps/Apps_App_Integration_Wizard.htm#SAMLWizard) to create your SAML integration. When done, you'll be directed to the **Sign On** page for your newly-created app. Click on **View Setup Instructions** to complete the process.
+4. Take note of the **Identity Provider Single Sign-On URL**, and download a copy of the X.509 certificate.
+
+## Configure Auth0
+
+At this point, you will configure the integration from the Auth0 side.
+
+Log in to your Auth0 account, and go to the [Management Dashboard](${manage_url}). Go to **Connections** -> **Enterprise** -> **SAMLP** and click the **plus** icon to be redirected to the page that allows you to create a new Connection.
+
+You will be prompted to provide the appropriate configuration settings for this Connection.
+
+The only mandatory fields are as follows:
+
+* **Connection Name**: a friendly name for your new Connection;
+* **Sign In URL**: the **Identity Provider Single Sign-On URL** you made note of when you set up your Okta app;
+* **X509 Signing Certificate**: the certificate you downloaded from Okta. You will need to upload the certificate directly to Auth0.
+
+Click **Save** to persist your changes and proceed.
+
+In the next window, you'll be provided two options. If you are a domain administrator, you can click **Continue** for additional instructions on SAML Identity Provider Configuration. If you are not, you can give your domain administrator the provided URL so that they can finish the configuration.
+
+## Enable Access to the Connection
+
+Now that you've created and configured your Connection, you'll need to enable access to the Connection for your Application(s).
+
+Using the [Management Dashboard](${manage_url}), go to the [Applications](${manage_url}/#/applications) to see the list of Applications associated with your Auth0 account.
+
+To enable your Connection for a given Application, click **Connections** on its associated row.
+
+Scroll down to the *Enterprise* section, and click the slider to enable your Okta Connection for the associated Application.
+
+## Test your Connection
+
+You can test your Okta-Auth0 integration using the [Management Dashboard](${manage_url}) if you are an Okta user.
+
+Go to **Connections** -> **Enterprise** -> **SAML**. On the row associated with Okta, click the **play** icon to *Try* your Connection.
+
+If your test was successful, you'll see the **It works!** screen. If not, you'll see an error message containing details on what the issue might be.
+
+::: note
+The **Try** button works for users logged in to Auth0 dashboard. You can't send this to an anonymous user, such as a customer. If you don't have a Okta user, you'll need to configure [IdP Initiated SignOn](#idp-initiated-signon) so the someone else can try on their portal.
+:::
+
+## IdP Initiated SignOn
+
+Okta provides an Application Portal/Launcher for their users. If you would like to support the Okta Application Portal/Launcher, change the **Single Sign-on URL** in the Okta dashboard to `https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME`
+
+Be sure to change `YOUR_CONNECTION_NAME` to the name of your Auth0 Connection.
+
+See [IdP-Initiated SSO](/protocols/saml/idp-initiated-sso) for information on configuring your Auth0 Connection to route the incoming SAML Response.
+
+## Troubleshooting
+
+The user might see the Okta dashboard after authenticating using a Service Provider-initiated login flow. If you integrated you application with Auth0 using the OpenID Connect (OIDC) protocol, Auth0 takes the value of the `state` parameter and passes it to Okta using the SAML "RelayState" parameter. As such, make sure that you set `state` to a value that Okta can use.
+
+<%= include('../../../connections/_quickstart-links.md') %>
diff --git a/ja-jp/articles/protocols/saml/identity-providers/onelogin.md b/ja-jp/articles/protocols/saml/identity-providers/onelogin.md
new file mode 100644
index 0000000000..373d099c62
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/identity-providers/onelogin.md
@@ -0,0 +1,141 @@
+---
+title: OneLogin
+description: How to configure OneLogin as an identity provider.
+toc: true
+topics:
+    - saml
+    - identity-providers
+    - onelogin
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+# Configure OneLogin as an Identity Provider
+
+In this article, we will cover how you can configure OneLogin for use with Auth0 as a SAML Identity Provider.
+
+## Step 1: Configure OneLogin
+
+1. Log in to the [OneLogin](https://www.onelogin.com/) Dashboard, and click **Apps** > **Add Apps**.
+2. Search for **SAML**, and select **SAML Test Connector (IdP w/attr)**.
+3. When prompted, change the **Display Name** of your app. Click **SAVE**.
+4. Go to the **SSO** tab, and copy the values for **SAML 2.0 Endpoint (HTTP)** and **SLO Endpoint (HTTP)**. Click on the **View Details** link at the **X.509 Certificate** field.
+5. Download the X.509 certificate **onelogin.pem**.
+
+## Step 2: Configure the connection using the Auth0 dashboard
+
+At this point, you will configure the integration from the Auth0 side.
+
+Log in to your Auth0 account, and go to the [Management Dashboard](${manage_url}). Go to **Connections** -> **Enterprise** -> **SAMLP** and click the **plus** icon to be redirected to the page that allows you to create a new Connection.
+
+You will be prompted to provide the appropriate configuration settings for this Connection.
+
+The only mandatory fields are as follows:
+
+* **Sign In URL**: provide the **SAML 2.0 Endpoint (HTTP)** value you made note of when setting up your OneLogin app
+* **Sign Out URL**: provide the **SLO Endpoint (HTTP)** value you made note of when setting up your OneLogin app 
+* **X509 Signing Certificate**: the certificate you downloaded from Onelogin. You will need to upload the certificate directly to Auth0.
+
+Click **Save** to persist your changes and proceed.
+
+In the next window, you'll be provided two options. If you are a domain administrator, you can click **Continue** for additional instructions on SAML Identity Provider Configuration. If you are not, you can give your domain administrator the provided URL so that they can finish the configuration.
+
+### Auth0 configuration values
+
+To finish configuration of the SAML application, the admin will need the following information regarding Auth0:
+
+* **SAML Consumer URL**: `https://${account.namespace}/login/callback`
+* **SAML Audience**: `urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME`
+
+Also make sure to copy the values of the **post-back URL** and the **Entity ID** before heading back to the Configuration tab of your [OneLogin](https://www.onelogin.com/) app:
+
+| Auth0 value | OneLogin configuration field |
+| - | - |
+| Post-back URL | ACS (Consumer) URL **and** Recipient |
+| Entity ID | Audience |
+
+You'll also need to provide a valid regular expression for the **ACS (Consumer) URL Validator** (for example, `[-a-zA-Z0-9@:%._\+~#=]{2,256}\.[a-z]{2,6}\b([-a-zA-Z0-9@:%_\+.~#?&//=]*)`)
+
+## Step 3: Test your connection
+
+Before testing your connection:
+
+* Be sure that you have a OneLogin user that you can use for testing. If not, go to the **Users** tab on the OneLogin dashboard and add one
+* Be sure that your new Auth0 SAMLP connection has been associated with an [application](/application) (otherwise you will get an `invalid_request: the connection was disabled` error)
+
+At this point, you are set to test the connection! Next to your **SAML** connection, click the **Try** button.
+
+If all goes well, you will be redirected to a page informing you that the connection works.
+
+::: note
+The **Try** button only works for users logged in to the Auth0 dashboard. You cannot provide a link to this to an anonymous user (such as a customer) for testing.
+
+If you don't have a OneLogin user, please read the following section on configuring IdP-Initiated Signon so that your customer can test using their portal.
+:::
+
+## IdP-initiated sign on
+
+OneLogin offers an Application Portal/Launcher to their users. If you want to take advantage of this functionality, you will have to change the **SAML Consumer URL** in OneLogin dashboard to include the `connection` parameter (e.g., `https://${account.namespace}/login/callback?connection=onelogin-customer`). Be sure to replace `onelogin-customer` with the name of your Auth0 connection.
+
+Finally, be sure to pick the application to which your user is redirected *after* the SAML assertion is consumed. You can find more information in the [IdP-Initiated SSO page](/protocols/saml/idp-initiated-sso).
+
+## Edit connection mappings
+
+If you use OneLogin and Auth0 out of the box, users logging in using OneLogin and being created in the Auth0 dashboard will be missing some profile information you might like to have.
+
+To collect additional user information, you must edit the appropriate parameters in the OneLogin dashboard, include the parameters in the SAML assertion, and create the mappings in the Auth0 connection.
+
+### User profile attributes
+
+Sometimes the standard User Profile Attributes are not enough for the functionality you want to build. If this is the case, you can use custom attributes in order to enhance the SAML token. Let's work through a basic example.
+
+The SAML token contains, among others, two attributes: `FirstName` and `LastName`. Let's add a new custom attribute, named `FullName`, that will contain the concatenation of first and last name.
+
+In order to do so, navigate to the OneLogin dashboard and edit your app.
+
+On the __Parameters__ tab, click __Add Parameter__.
+
+In the pop-up, set a name for your new custom attribute using the __Field name__ text box. Make sure you check the __Include in SAML assertion__ flag. Click __Save__.
+
+The new attribute you created is displayed. Click on the __Value__ field, which is currently displaying `- No default -`.
+
+Click the __Value__ dropdown menu and select `- Macro -`.
+
+At the text box, set the value to `{firstname} {lastname}`. Click __Save__.
+
+At this point, we're ready to test our changes.
+
+Go back to [Auth0 dashboard > Connections > Enterprise > SAML](${manage_url}/#/connections/enterprise). On your __SAML__ connection, click the __Try__ button. The result should include the new attribute `FullName`.
+
+::: note
+You can find more information on _Attribute Macros_ at the [OneLogin Help Center](https://support.onelogin.com/hc/en-us/articles/201174464-Attribute-macros).
+:::
+
+### Add new parameter to the SAML assertion
+
+For the purposes of demonstration, let's see how we can add the `EmailAddress` information, which is more than the concatenation of two fields we're already sending, to our login.
+
+### OneLogin configuration
+
+Before you can map users' **EmailAddress**, you must add this field as a custom parameter to the OneLogin dashboard. Set **Field name** to `EmailAddress` and **Value** as `Email`.
+
+You can find details on the steps needed to customize the user profile [in the section above](#customize-the-user-profile).
+
+Once you've made your changes, save them, and test your connection once again. 
+
+Now, review your Auth0 user, making sure that the `EmailAddress` information is now included and that the value is correct.
+
+### Auth0 mappings
+
+You are now ready to proceed with mapping the user information fields in Auth0.
+
+Go to the __Settings__ of your [SAML](${manage_url}/#/connections/enterprise) and navigate to the tab __Mappings__. For the email addresses, copy the mapping below, and paste it into the text box.
+
+```javascript
+{
+  "email": "EmailAddress"
+}
+```
+
+Save your changes, and try your connection again. Once you have successfully logged in, go to [Dashboard > Users](${manage_url}/#/users), and check your login. You will see additional information for the appropriate user.
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/saml/identity-providers/ping7.md b/ja-jp/articles/protocols/saml/identity-providers/ping7.md
new file mode 100644
index 0000000000..1165cfb3d1
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/identity-providers/ping7.md
@@ -0,0 +1,69 @@
+---
+title: PingFederate
+description: How to configure PingFederate as an identity provider.
+topics:
+    - saml
+    - identity-providers
+    - pingfederate
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+# Configure PingFederate as an Identity Provider
+
+In this article, we will cover how you can configure PingFederate for use with Auth0 as a SAML Identity Provider.
+
+PingFederate is a federation server that provides identity management, single sign-on, and API security for the enterprise. To configure Auth0 to use PingFederate as an identity provider, you will use primarily the default values and your Auth0 tenant metadata file to upload the required configuration parameter values for your Auth0 tenant. If the metadata upload fails for some reason, these are the most important configuration parameters:
+
+* __EntityID:__ `urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME`
+* __Assertion Consumer Service URL:__ `https://${account.namespace}/login/callback`
+* __Logout URL:__ `https://${account.namespace}/logout`
+* __HTTP-Redirect__ binding for SAML Request
+* __HTTP-POST__ binding for SAML Response
+
+::: panel IdP-Initiated SSO
+If you want to use **IdP-Initiated SSO**, make sure to include the `connection` parameter in the Assertion Consumer Service URL: `https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME`.
+:::
+
+1. Download your Auth0 metadata file from `https://YOUR_DOMAIN/samlp/metadata?connection=YOUR_CONNECTION_NAME`. Make sure that you use your custom domain if you have one configured. You will upload this file to import your Auth0 tenant information into the PingFederate configuration.
+
+2. Sign on to your PingFederated account and select **Create New** from the **SP Connections** section.
+
+3. Configure the __SP Connection__. 
+
+    - Select the __Browser SSO Profiles__ as the __Connection Type__.
+    - Select __Browser SSO__ as the __Connection Options__.
+
+4. Upload the metadata file that you downloaded in step 1. The __Entity ID__, __Connection Name__ and the __Base URL__ will be automatically populated based on the information from the metadata file. 
+
+5. Configure __Browser SSO__. 
+
+    - Select __SP-Initiated SSO__ and __SP-Initiated SLO__ in __SAML Profiles__.
+    - Go to the __Assertion Creation__ section and click __Configure Assertion__. Accept all defaults for the next two screens. 
+
+6. Go to the __IdP Adapter Mapping__ section. This is where users will be authenticated. Likely, you already have one configured in your PingFederate installation. Select one, or add a new one.
+
+    ::: note
+    Auth0 only requires the __NameIdentifier__ claim. All other  attributes will be passed further to the end application.
+    :::
+
+7. Configure __Protocol Settings__. Values for __Protocol Settings__ are imported from the metadata file. Next, you will see the __Assertion Consumer Service URL__ and the Sign-Out URLs. Click __Next__ to the __Allowable SAML Bindings__ section.
+
+8. Leave __POST__ and __Redirect__ enabled. Make sure __SAML Assertion__ is always signed.
+
+9. Configure __Credentials__. On __Digital Signature Settings__, select your signing certificate and make sure you check the option to include it in the `` element.
+
+10. Configure the certificate used to sign incoming requests. You can download the Auth0 certificate (use `https://YOUR_TENANT.auth0.com/pem`) and upload it here. 
+
+    ::: note
+    Auth0 signs `SAMLRequests` by default; you can change that when you configure the connection. 
+    :::
+
+11. Review your settings and set as __Active__ or __Inactive__. 
+
+12. Click __Save__ at the bottom of the screen. You should see the new SP Connection on the __Main__ screen.
+
+## Keep reading
+
+* See the complete PingFederate instructions to [configure PingFederate as an identity provider](https://docs.pivotal.io/p-identity/1-5/pingfederate/config-pingfederate.html). 
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/saml/identity-providers/salesforce.md b/ja-jp/articles/protocols/saml/identity-providers/salesforce.md
new file mode 100644
index 0000000000..35bbe93e2b
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/identity-providers/salesforce.md
@@ -0,0 +1,138 @@
+---
+description: How to configure Auth0 to use Salesforce as an identity provider.
+topics:
+    - saml
+    - identity-providers
+    - salesforce
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Configure Salesforce as an Identity Provider
+
+In this article, we will cover how you can configure Salesforce for use with Auth0 as a SAML Identity Provider.
+
+There are 6 steps to this sample:
+
+1. Obtain Salesforce certificate and metadata.
+2. Set up Auth0 as a Service Provider.
+3. Configure the Salesforce Identity Provider (IDP).
+4. Grant Privileges to users in Salesforce.
+5. Test the connection to the Salesforce IDP.
+6. Troubleshooting
+
+## 1. Obtain Salesforce Certificate and Metadata
+
+1. Register for a [Salesforce.com](http://salesforce.com) account. You must select one of the account types that include Identity Provider support.
+2. Create your [Salesforce Domain](https://help.salesforce.com/apex/HTViewHelpDoc?id=domain_name_setup.htm&language=en_US).
+2. Log into your Salesforce domain `https://YOUR_DOMAIN.my.salesforce.com` and click on **Setup** on the top right.
+4. In the left menu, expand **Security Controls** and select **Identity Provider**.
+
+5. Create an Identity Provider by clicking **Enable Identity Provider**.
+
+6. Select the default certificate and click **Save**.
+
+7. Click **Download Certificate** to download the Identity Provider certificate.
+
+8. Click **Download Metadata** to download the Identity Provider metadata.
+
+## 2. Set up Auth0 as a Service Provider
+
+In this step, you will configure Auth0 as a Service Provider to communicate with the **Salesforce** Identity Provider for Single Sign-on (SSO).
+
+1. Navigate to the [Connections > Enterprise](${manage_url}/#/connections/enterprise) section of the Auth0 dashboard.
+2. Click on **SAML**
+3. Click on **Create New Connection**
+4. In the configuration window, enter the following information:
+
+  **Connection Name:** You can choose any name, such as "SFIDP".
+
+  **Email Domains:** Enter the email domain name that your users will be logging in from. For example, if your users have an email domain of `abc-example.com`, you would enter that into this field. You can enter multiple email domains if needed.
+
+  **Sign In URL:** Open the metaData file you downloaded from Salesforce and locate the line that contains the `SingleSignOnService` binding. The value of the `Location` attribute on this line is your Sign In URL. It will be something like:
+
+    `https://{sf-account-name}.my.salesforce.com/idp/endpoint/HttpRedirect`
+
+  where "{sf-account-name}" is your Salesforce account domain name.
+
+  **Sign Out URL:** enter the same URL that was entered for Sign In URL.
+
+  **Certificate:**  The certificate downloaded from Salesforce is in .crt format. Convert this certificate to .pem format with the following command.
+
+    `openssl x509 -in original.crt -out sfcert.pem -outform PEM`
+
+  where `original.crt` is the filename of the downloaded .crt file.
+
+5. Click **UPLOAD CERTIFICATE**  and select the `.pem` file you just created. (`sfcert.pem` in the example above). You can ignore the rest of the fields for now.
+
+6. Click **SAVE**.
+
+7. Click **CONTINUE**. In the window that appears, SAML metadata for the Auth0 Service Provider will be displayed. Keep this window open since you will need to enter some of this information into Salesforce to finish the configuration.
+
+::: note
+You can always access the metadata for an Auth0 SAML connection with this URL syntax: `https://${account.namespace}/samlp/metadata?connection=YOUR_CONNECTION_NAME`.
+:::
+
+## 3. Configure the Salesforce Identity Provider
+
+In this step, you will configure Salesforce with the metadata from Auth0 so it can receive and respond to SAML-based authentication requests from Auth0.
+
+1. Open **[salesforce.com](http://salesforce.com)**.
+2. Go to **Setup** > **Manage Apps**. Click **Connected Apps**.
+3. Create a new Connected App and fill out the following fields:
+
+  **Entity ID:** `urn:auth0:${account.namespace}:YOUR_CONNECTION_NAME`
+
+  **ACS URL:** `https://${account.namespace}/login/callback`
+
+  **Subject Type:** `Persistent ID`
+
+  **Name ID Format:** Choose the one with emailAddress
+
+  **Issuer:** `https://{your-saleforce-domain}.my.salesforce.com`
+
+6. Click **Save** to complete the configuration of the IDP.
+
+## 4. Grant Privileges to Users in Salesforce
+
+1. Open **[salesforce.com](http://salesforce.com)** and click **Setup**.
+2. Under **Manage Users**, click **Profiles**.
+3. Scroll down to find the profile called **Standard User** (on page 2).
+4. Click on **Edit** to edit the profile.
+5. Scroll down to the **Connected App Access** section.
+6. Check the box next to the name of your connected app to enable it for this profile.
+7. Click **Save**.
+8. Under **Manage Users**, click **Users**.
+9. Click **Edit** to edit your test user and set the profile to **Standard User**.
+
+::: note
+If you wish to use a different Salesforce profile, you must enable the connected app for that profile and ensure that all users that login through the Salesforce Identity Provider have that profile.
+:::
+
+## 5. Test the connection to the Salesforce IDP
+
+In this step, you will test the SAML configuration between Auth0 and Salesforce.
+
+* Navigate to the [Connections > Enterprise](${manage_url}/#/connections/enterprise) section of the Auth0 dashboard. Select the **SAMLP Identity Provider**.
+* Click the **Try** button for the SAML connection you created earlier. You should be redirected from Auth0 to the Salesforce login page.
+* Once you are at the **Salesforce login screen**, login with the credentials you provided when you created the Salesforce account.
+
+If the SAML configuration works, your browser will be redirected back to an Auth0 page that says **"It works!!!"**. This page will display the contents of the SAML authentication assertion sent by the Salesforce IDP to Auth0.
+
+If it didn't work, double check the steps above and consult the **troubleshooting** section below.
+
+::: note
+The **Try** button only works for users logged into the Auth0 dashboard.
+:::
+
+## 6. Troubleshooting
+
+When troubleshooting SSO, it is often helpful to capture an HTTP trace of the interaction and save it in a HAR file. See [Generate and Analyze HAR Files](/troubleshoot/guides/generate-har-files) for details.
+
+Once you have an http trace tool, capture the login sequence from start to finish and analyze the trace for the sequence of GETs. You should see a redirect from your original site to the IDP, a post of credentials if you had to log in, and then a redirect back to the callback URL. The HAR file will also contain the SAML response.
+
+Make sure that cookies and JavaScript are enabled for your browser.
+
+Make sure that the user's profile in Salesforce has permission to login via the Salesforce IDP (See section 4 above).
diff --git a/ja-jp/articles/protocols/saml/identity-providers/siteminder.md b/ja-jp/articles/protocols/saml/identity-providers/siteminder.md
new file mode 100644
index 0000000000..f8a0765b73
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/identity-providers/siteminder.md
@@ -0,0 +1,71 @@
+---
+title: SiteMinder
+description: How to configure SiteMinder as an identity provider.
+topics:
+    - saml
+    - identity-providers
+    - siteminder
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+# Configure SiteMinder as an Identity Provider
+
+In this article, we will cover how you can configure SiteMinder for use with Auth0 as a SAML Identity Provider.
+
+When configuring SiteMinder, you will use the default values for most options. However, you will need the following Auth0-related values in the configuration steps were cover later on in this guide:
+
+* __EntityID:__ `urn:auth0:${account.tenant}`
+* __Assertion Consumer Service URL:__ `https://${account.namespace}/login/callback`
+* __Logout URL:__ `https://${account.namespace}/logout`
+* __HTTP-Redirect__ binding for SAML Request
+* __HTTP-POST__ binding for SAML Response
+
+The instructions below will guide you into where these values need to be entered in SiteMinder.
+
+### 1. Open the SAML Service Provider Dialog
+
+Provide an appropriate name for this Service Provider. We suggest using:
+
+* __Name:__ `${account.tenant}`
+
+### 2. Defining NameIdentifier
+
+You can define many ways of generating a `NameIdentifier` for users authenticating with SiteMinder. Typically you will map this value to one of the user properties in the User Directory as `uid`.
+
+### 3. Configure the Service Provider General SAML properties
+
+Use the following values when prompted:
+
+* __SP ID:__ `urn:auth0:${account.tenant}`
+* __SAML Version:__ `2.0`
+* __Skew Time:__ `30 seconds`
+
+### 4. Configure the Assertion Consumer Service URL
+
+The __Assertion Consumer Service URL__ is the location where SiteMinder will POST back the SAML Token. This Service Provider (${account.tenant}) only supports the `HTTP-POST` binding for SAML Responses. Use these values:
+
+* __Assertion Consumer Service:__ `https://${account.namespace}/login/callback`
+* __HTTP-Post__: `checked`
+
+### 5. Configure additional user properties to send in the token
+
+Add any other properties you wish to share about the authenticated user to this Service Provider. Common values are: `name`, `lastname`, `email address`, and so on. This Service Provider will use the `NameIdentifier` defined in [step 2](#2-defining-nameidentifier) as a unique handle of the user. These attributes will be treated as reference information.
+
+### 6. Enter the Single Sign-Out URL
+
+* __SLO Location URL:__ `https://${account.namespace}/logout`
+
+### 7. Optional Assertion Encryption
+
+The Service Provider supports encryption of Assertions.
+To use this option, do the following to download the Service Provider public key certificate.
+
+* In the Auth0 Dashboard, click on __Connections__ and then __Enterprise__
+* Click on SAMLP Identity Provider
+* Click on the Setup icon (pencil)
+
+In the window which appears, the seventh (last) bullet gives you links to download the .pem or .cer format certificate.
+
+Download the desired certificate and add it to the SiteMinder __Policy Server Keystore__.
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/saml/identity-providers/ssocircle.md b/ja-jp/articles/protocols/saml/identity-providers/ssocircle.md
new file mode 100644
index 0000000000..b5b1f0448e
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/identity-providers/ssocircle.md
@@ -0,0 +1,188 @@
+---
+title: SAML Single Sign-On with SSOCircle as an Identity Provider
+description: Learn how to configure an application to use Auth0 for SAML Single Sign-on (SSO), authenticating users against SSOCircle
+toc: true
+topics:
+    - saml
+    - identity-providers
+    - ssocircle
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+# Configure SSOCircle as an Identity Provider
+
+In this article, we will cover how you can configure SSOCircle for use with Auth0 as a SAML Identity Provider.
+
+::: warning
+As of July 8, 2016, SSOCircle supports integration via [manual configuration using public settings](http://www.ssocircle.com/en/idp-tips-tricks/public-idp-configuration/). If you have previously used account-specific metadata, your integration will still function, though this usage is now deprecated.
+:::
+
+## 1. Obtain the SSOCircle Metadata
+
+Navigate to [SSOCircle's IDP page](https://idp.ssocircle.com/) to see the metadata required for integration. You will be shown an XML file.
+
+From this page, you will need to save the following attributes (you will use these values for Step 2 of this tutorial):
+
+1. The Location URL for the `SingleSignOnService` attribute with an `HTTP-Redirect` type.
+
+2. The Location URL for the `SingleLogoutService` attribute with an `HTTP-Redirect` type.
+
+[Download](http://www.ssocircle.com/en/idp-tips-tricks/public-idp-configuration) and save the SSOCircle CA Certificate. You will also use this in Step 2.
+
+## 2. Configure an enterprise connection in Auth0
+
+In this step, you will configure the integration from the Auth0 side.
+
+To do so, see [Connect Your App to SAML Identity Providers](/connections/enterprise/saml). 
+
+While setting up your connection, make sure you use the following settings:
+
+| Field | Description |
+| ----- | ----------- |
+| **Connection name** | Logical identifier for your connection; it must be unique for your tenant. Once set, this name can't be changed. |
+| **IdP Domains** (optional) | Comma-separated list of valid domains. Only needed if using the Lock login widget. |
+| **Sign In URL** | SAML single login URL. Enter the location URL for the `SingleSignOnService` attribute with an `HTTP-Redirect` type from SSOCircle's metadata. |
+| **X.509 Signing Certificate** | Signing certificate (encoded in PEM or CER). Upload the **SSOCircle CA Certificate** you saved in [step 1](#1-obtain-the-ssocircle-metadata). |
+| **Sign Out URL** (optional) | SAML single logout URL. Enter the Location URL for the `SingleLogoutService` attribute with an `HTTP-Redirect` type from SSOCircle's metadata. |
+
+When setting up mappings, use the following JSON to properly map SAML attributes from SSO Circle, and click **Save**:
+
+```json
+{
+  "email": "EmailAddress",
+  "given_name": "FirstName",
+  "family_name": "LastName"
+}
+```
+
+::: note
+In general, you can access the metadata for an Auth0 SAML connection using a URL with the following format: `https://${account.namespace}/samlp/metadata?connection=YOUR_CONNECTION_NAME`.
+
+You will need to provide this metadata to SSOCircle at a later point during the configuration process.
+:::
+
+## 3. Configure the SSOCircle Identity Provider
+
+In this step, you will configure the integration from the SSOCircle side.
+
+Log in to your [SSOCircle](http://ssocircle.com) account. You will be directed to your user profile, and to the left of that is a navigation bar.
+
+In the navigation bar, click **Manage Metadata**.
+
+Select **Add New Service Provider**, and provide the following information to configure the new service provider (which, in this case, is Auth0):
+
+* **FQDN of the ServiceProvider:** `auth0.com`
+* **Attributes to send in assertion:** check the box for `EmailAddress`
+* **Insert your metadata information:** paste in the XML metadata that you downloaded after you configured your Auth0 Connection (the file begins with `callback URLs includes those to which users will be redirected after authentication. The URL(s) entered here must match the **callback URL** in the HTML code you will create in a later step. Normally, you would enter a URL for your Application, but to keep this example simple, users will simply be sent to the Auth0 JWT Tool.
+
+Click **SAVE CHANGES**.
+
+Returning to the top of **Settings**, click on  **Connections**.
+
+Scroll down to the section with the **Enterprise** heading. Find the row for the SAML Connection you created above and click the on/off toggle to enable the SAML Connection.
+
+## 5. Test the Auth0-SSOCircle Connection
+
+In this step, you will test to make sure the SAML configuration between Auth0 and SSOCircle is working.
+
+To test your connection, see [Test Enterprise Connections](/dashboard/guides/connections/test-connections-enterprise).
+
+During this process you will be asked to log in and consent. Everything should go smoothly, but if the test shows that something didn't work, please review the above steps and consult the [Troubleshooting](#8-troubleshooting) section.
+
+Additionally, if you receive a window that says, "Your session has timed out," click the **Return to Login page** link below the message.
+
+## 6. Create the HTML Page for the Test Application
+
+In this section, you will create a simple HTML page that uses the **Auth0 Lock Widget**. Lock will then trigger the SAML login sequence.
+
+```html
+
+
+  
+    
       Click on the button to log in 
      
+
+    
+    
+    
+  
+
+```
+
+Be sure to fill in the first parameter of the `Auth0Lock` with your Client ID. To find the Client ID, go to **[Auth0 Dashboard](${manage_url}) > [Applications](${manage_url}/#/applications)** and click the **Settings** icon to the right of your Application name. Copy the **Client ID** value.
+
+Save this file. For the purposes of this example, we'll call it `hello-saml.html`.
+
+## 7. Test Your Sample Application
+
+In this step, you will complete an end-to-end test using your sample HTML application that uses the Auth0 SAML connection you set up to perform SSO with SSOCircle.
+
+Open the `hello-saml.html` file with a web browser. You should see a white page with a login button on it.
+
+![Test Homepage](/media/articles/saml/identity-providers/ssocircle/hello-saml.png)
+
+Click **Login**. The **Auth0 Lock** Widget will appear.
+
+::: note
+If you are prompted to enter an email address, make sure the domain for the email address you enter is listed under **Settings** for the Auth0 Application you previously configured.
+:::
+
+Provide the requested log in credentials and click **Access** to initiate the SAML SSO sequence with SSOCircle.
+
+At this point, you will be redirected to the SSOCircle IDP to log in.
+
+![Login Screen](/media/articles/saml/identity-providers/ssocircle/login.png)
+
+Once you have logged in, you will see a SAML Consent Page. Click the box indicating that you're not a robot, then click **Continue SAML Single Sign-On**.
+
+![Consent to SAML Screen Screen](/media/articles/saml/identity-providers/ssocircle/saml-consent.png)
+
+::: note
+Please note that you will not be prompted for your credentials if you still have an active session at SSOCircle. If this is the case, you will simply be redirected to the callback URL specified in `hello-saml.html`.
+:::
+
+If you successfully authenticate, you will be redirected to the callback URL specified in `hello-saml.html` (`http://jwt.io`). You will see the token that your Application receives.
+
+## 8. Troubleshooting
+
+* If logging in to your Application doesn't work the first time, clear your browser's history and cookies before testing again. The browser may not be picking up the latest version of your HTML.
+* When troubleshooting SSO, it is often helpful to capture an HTTP trace of the interaction. There are many tools that will capture the HTTP traffic from your browser for analysis (search for "HTTP Trace" to find one appropriate for your needs). Once you have an HTTP tracer, capture the login sequence from start to finish and analyze the trace to see the sequence of `GET` requests to see where the error occurs. You should see:
+  * A redirect from your original site to the IDP;
+  * A post of credentials (if you were asked to log in);
+  * A redirect to the callback URL.
+* Ensure that your browser has enabled cookies and JavaScript.
+* Check to make sure that the callback URL specified in the HTML is also listed in the **Allowed Callback URLs** field in the **Settings** tab of the Auth0 Application.
diff --git a/ja-jp/articles/protocols/saml/idp-initiated-sso.md b/ja-jp/articles/protocols/saml/idp-initiated-sso.md
new file mode 100644
index 0000000000..bf2e5617b9
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/idp-initiated-sso.md
@@ -0,0 +1,91 @@
+---
+title: IdP-Initiated Single Sign-On
+description: How to setup SAML Identity Provider-initiated Single Sign-on (SSO).
+topics:
+  - saml
+  - sso
+contentType:
+  - how-to
+  - concept
+useCase:
+  - add-idp
+---
+
+# IdP-Initiated Single Sign-On
+
+Many instructions for setting up a SAML federation begin with Single Sign-on (SSO) initiated by the service provider. The service provider redirects the user to the identity provider for the purposes of authentication. This process is commonly used for consumer-facing scenarios.
+
+However, in enterprise scenarios, it is sometimes common to begin with the identity provider initiating SSO, not the service provider. For example, an enterprise company might set up a portal to ensure that users navigate to the correct application after they sign on to the portal.
+
+## Risks of using an IdP-Initiated SSO flow
+
+::: warning
+IdP-Initiated flows carry a security risk and are therefore NOT recommended. Make sure you understand the risks before enabling IdP-Initiated SSO. 
+:::
+
+In an IdP-initiated flow neither Auth0 (which receives the unsolicited response from the Identity Provider) nor the application (that receives the unsolicited response generated by Auth0) can verify that the user actually started the flow. Because of this, enabling this flow opens the possibility of an [Login CSRF attack](https://support.detectify.com/support/solutions/articles/48001048951-login-csrf), where an attacker can trick a legitimate user into unknowingly logging into the application with the identity of the attacker.  
+
+The recommendation is to use SP-Initiated flows whenever possible.
+
+### On IdP-Initiated flows and OpenID Connect
+
+OpenID Connect (OIDC) does not support the concept of an IdP-Initiated flow. So while Auth0 offers the possibility of translating a SAML IdP-Initiated flow (from a SAML connection) into an OIDC response for an application, any application that properly implements the OIDC/OAuth2 protocol will reject an unrequested response. 
+
+When using OIDC applications, the best option is to have the users start the login flow **at the application** or configure the portals to send the user to the application's login initiation endpoint (without an IdP-Initiated SAML response) so that, again, the application starts the authentication flow.
+
+## How to set up IDP-initiated SSO
+
+
+
+To setup IdP-Initiated SSO, go to the [Enterprise Connections](${manage_url}/#/connections/enterprise) section of the dashboard and choose **SAMLP Identity Provider**. Under the **Settings** section you can see the configuration for IdP-Initiated SSO.
+
+![Configure SAML Idp-Initiated SSO Settings](/media/articles/dashboard/connections/enterprise/conn-enterprise-saml-idp-initiated-sso.png)
+
+**Default Application:** When the IdP initiated login succeeds this is the application where users are routed. This setting shows available applications enabled for this connection. Select the application from the dropdown that you want the users to login with IdP initiated. Only one application can be selected for an IdP-initiated login per SAML connection.
+
+**Response Protocol:** This is the protocol used to connect your selected **Default Application**. Most commonly applications are configured with the OpenID Connect protocol (read [here](#on-idp-initiated-flows-and-OIDC) for possible pitfalls). However if you have configured a SAML2 Web App addon for your application and want to route the SAML assertion you will need to select SAML.
+
+**Query String:** Query string options help to customise the behavior when the OpenID Connect protocol is used. You can set multiple options similar to setting parameters with a [query string](https://en.wikipedia.org/wiki/Query_string). You can set:
+
+* `redirect_uri`: When the IdP-initiated login has completed the request is then redirected to the first URL listed in the **Allowed Callback URLs** for the application. However if you set a `redirect_uri` the IdP will redirect to this URL. This brings flexibility for cases like when you have set subdomain scheme with a wildcard and you only want to redirect to one specific subdomain.
+* `scope`: You could define scopes for the ID Token sent. Note that it is possible to set multiple scopes.
+* `response_type`: This field is used to set the token for Implicit Grant Flow for SPA applications. You could set code for Authorization Code Grant Flow for regular web applications.
+
+Example Query String:
+
+`redirect_uri=https://jwt.io&scope=openid email&response_type=token`
+
+## Post-back URL
+
+When using **IdP-Initiated SSO**, please make sure to include the `connection` parameter in the post-back URL: `https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME`
+
+## Lock/Auth0.js
+
+If your application is a Single-Page Application that uses Lock or Auth0.js to process the authentication results, you will have to explicitly indicate that you want to allow IdP-Initiated flows (and thus [open the application to possible Login CSRF attacks](#risks-of-using-an-idp-Initiated-SSO-flow)).
+
+If you are using [Auth0.js](/libraries/auth0js), you have to update the **webAuth.parseHash** of the [library](/libraries/auth0js/v9#extract-the-authresult-and-get-user-info) and set the flag **__enableIdPInitiatedLogin** to `true`.
+
+```javascript
+var data = webAuth.parseHash(
+  {
+    ...
+    __enableIdPInitiatedLogin: true
+    ...
+  }
+```
+
+If you're using [Lock](/lock), you can include the flag using the options parameter sent to the constructor.
+
+```javascript
+const lock = new Auth0Lock(clientID, domain, options)
+```
+
+Here's the flag itself:
+
+```javascript
+var options = {
+    _enableIdPInitiatedLogin: true
+};
+```
+
+Note that the **enableIdPInitiatedLogin** flag is preceded by **one** underscore when used with Lock and **two** underscores when used with the auth0.js library.
diff --git a/ja-jp/articles/protocols/saml/index.html b/ja-jp/articles/protocols/saml/index.html
new file mode 100644
index 0000000000..7be7d02149
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/index.html
@@ -0,0 +1,114 @@
+---
+url: /protocols/saml
+section: articles
+classes: topic-page
+title: SAML
+topics:
+  - saml
+contentType:
+  - index
+useCase:
+  - add-idp
+---
+
+
      
+  
      
+  
      SAML
      
+  
      
+    Documentation on SAML protocol.
+  
      
+
      
+
+
diff --git a/ja-jp/articles/protocols/saml/saml-apps/_header.md b/ja-jp/articles/protocols/saml/saml-apps/_header.md
new file mode 100644
index 0000000000..d3708bc803
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/_header.md
@@ -0,0 +1,5 @@
+# ${meta.title}
+
+## SAML Configuration
+
+Use the following SAML configuration:
diff --git a/ja-jp/articles/protocols/saml/saml-apps/atlassian.md b/ja-jp/articles/protocols/saml/saml-apps/atlassian.md
new file mode 100644
index 0000000000..7d2bae9c92
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/atlassian.md
@@ -0,0 +1,73 @@
+---
+description: Learn how to configure Single Sign-on (SSO) with Atlassian.
+topics:
+    - saml
+    - identity-providers
+    - atlassian
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Atlassian SAML Configuration
+
+You can configure Auth0 as the SAML SSO identity provider for Atlassian.
+
+## Prerequisites
+
+* A verified domain in your [Atlassian Organization](https://admin.atlassian.com/).
+* [Atlassian Access](https://www.atlassian.com/software/access)
+
+## Configure Auth0 identity provider application
+
+1. Go to [Dashboard > Applcations](${manage_url}/#/applications) and click **Regular Web Applications** to create an app.
+2. Add connections to your app. Make sure that the correct set of Auth0 connections are associated with your identity provider app.
+3. Go to **Addons** tab and enable the **SAML2 Web App** addon. 
+4. Click the **Usage** tab. Here you will find information to populate SAML metadata in Atlassian Access. Note the settings. 
+
+## Configure Atlassian SAML connection
+
+1. Log in to your [Atlassian Admin](https://admin.atlassian.com/) dashboard.
+2. Go to **Organization > Security > SAML single sign-on**.
+3. Copy the configuration settings from the Auth0 SAML2 Web App addon usage page:
+
+| Setting | Description|
+| -- | -- |
+| **Identity provider Entity ID** | `urn:TENANT.auth0.com` |
+| **Identity provider SSO URL** | `https://TENANT.auth0.com/samlp/APP_ID` |
+| **Public x509 certificate** | Content from your .pem file: `https://TENANT.auth0.com/pem` |
+
+4. Click **Save configuration**.
+5. On the summary page, copy the **SP Assertion Consumer Service URL**.
+
+## Configure callback URL in Auth0
+
+1. Go back to [Dashboard > Applcations](${manage_url}/#/applications) to your applications SAML2 addon settings.
+2. Update the **Application Callback URL** with the **SP Assertion Consumer Service URL** you copied in the previous section.
+3. On the **Settings** tab, update the metadata mapping file. For example:
+
+```js
+{
+  "mappings": {
+    "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+    "given_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
+    "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
+  },
+  "nameIdentifierProbes": [
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
+  ],
+  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:email"
+}
+```
+
+![SAML2 Web App Settings](/media/articles/protocols/saml/atlassian-saml2-web-app-settings.png)
+
+4. Click **Save**.
+
+## Test connection
+
+1. Go to [id.atlassian.com](https://id.atlassian.com/) and log in.
+2. Login with SAML identity provider and return to Atlassian.
diff --git a/ja-jp/articles/protocols/saml/saml-apps/cisco-webex.md b/ja-jp/articles/protocols/saml/saml-apps/cisco-webex.md
new file mode 100644
index 0000000000..4c32cef3d7
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/cisco-webex.md
@@ -0,0 +1,37 @@
+---
+title: Cisco WebEx SAML Configuration
+description: Cisco WebEx SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - cisco
+    - cisco-webex
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+```json
+{
+   "mappings": {
+     "email": ["email", "uid", "Name_ID"]
+   },
+  "createUpnClaim":       false,
+  "passthroughClaimsWithNoMapping": false,
+  "mapUnknownClaimsAsIs": false,
+  "mapIdentities":        false,
+  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+  "nameIdentifierProbes": [
+     "email",
+   ]
+}
+```
+
+Notice that Webex has an option to automatically provision new users. You will need to send that info along as claims (lastname, and so on).
+
+:::note
+If you integrate Auth0 with Cisco Spark services, you might find this article helpful: [Single Sign-On with Cisco Spark Services](https://collaborationhelp.cisco.com/article/en-us/lfu88u).
+:::
diff --git a/ja-jp/articles/protocols/saml/saml-apps/datadog.md b/ja-jp/articles/protocols/saml/saml-apps/datadog.md
new file mode 100644
index 0000000000..45b50ab027
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/datadog.md
@@ -0,0 +1,34 @@
+---
+title: Datadog SAML Configuration
+description: Datadog SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - datadog
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+```json
+{
+  "audience": "https://app.datadoghq.com/account/saml/metadata.xml",
+   "mappings": {
+   },
+   "createUpnClaim":       false,
+   "passthroughClaimsWithNoMapping": false,
+   "mapUnknownClaimsAsIs": false,
+   "mapIdentities":        false,
+   "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+   "nameIdentifierProbes": [
+     "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+   ],
+}
+```
+
+The **Callback URL** is `https://app.datadoghq.com/account/saml/assertion`.
+
+Notice that Datadog has an option to automatically provision new users. Check [Datadog docs](http://docs.datadoghq.com/guides/saml/) for more details.
diff --git a/ja-jp/articles/protocols/saml/saml-apps/egencia.md b/ja-jp/articles/protocols/saml/saml-apps/egencia.md
new file mode 100644
index 0000000000..6fbc053c54
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/egencia.md
@@ -0,0 +1,33 @@
+---
+title: Egencia SAML Configuration
+description: Egencia SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - egencia
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+
+```json
+{
+  "audience": "https://{YOUR_ACCOUNT_NAME}.egencia.com",
+   "mappings": {
+   },
+   "createUpnClaim":       false,
+   "passthroughClaimsWithNoMapping": false,
+   "mapUnknownClaimsAsIs": false,
+   "mapIdentities":        false,
+   "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+   "nameIdentifierProbes": [
+     "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+   ],
+}
+```
+
+The **Callback URL** is `https://www.egencia.com/auth/v1/artifactConsumer`.
diff --git a/ja-jp/articles/protocols/saml/saml-apps/eloqua.md b/ja-jp/articles/protocols/saml/saml-apps/eloqua.md
new file mode 100644
index 0000000000..cabc886eb5
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/eloqua.md
@@ -0,0 +1,39 @@
+---
+title: Eloqua (Oracle Eloqua Marketing Cloud) SAML Configuration
+description: Eloqua (Oracle Eloqua Marketing Cloud) SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - eloqua
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+
+```json
+{
+"audience": "",
+ "recipient": "https://login.eloqua.com/auth/saml2/acs",
+   "mappings": {
+    "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+    "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+    "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
+   },
+ "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+ "nameIdentifierProbes": [
+        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+        ],
+ "destination": "https://login.eloqua.com/auth/saml2/acs"
+  }
+
+```
+
+The **Callback URL** is `https://login.eloqua.com/auth/saml2/acs`.
+
+::: note
+The Service Provider Entity URL copied from within the IDP settings in Eloqua to set the audience restriction within Auth0.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/saml/saml-apps/freshdesk.md b/ja-jp/articles/protocols/saml/saml-apps/freshdesk.md
new file mode 100644
index 0000000000..5e528c57ff
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/freshdesk.md
@@ -0,0 +1,39 @@
+---
+title: Freshdesk SAML Configuration
+description: Freshdesk SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - freshdesk
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+
+The Application Callback URL would found at: Freshworks Dashboard => Security => SAML SSO => Assertion Consumer Service(ACS) URL
+The audience can be at Freshworks Dashboard => Security => SAML SSO => Service Provider(SP) Entity ID URL
+
+```json
+{
+  "audience": "https://{FD Domain}.freshworks.com/sp/SAML/{xxxxxxxxxxxxxxxxxxx}/metadata",
+  "mappings": {
+    "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+    "given_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
+    "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"
+  },
+  "createUpnClaim": false,
+  "passthroughClaimsWithNoMapping": false,
+  "mapUnknownClaimsAsIs": false,
+  "mapIdentities": false,
+  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+  "nameIdentifierProbes": [
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+  ]
+}
+```
+
+The **Callback URL** is `https://{FD Domain}.freshdesk.com/login/saml`.
diff --git a/ja-jp/articles/protocols/saml/saml-apps/github-cloud.md b/ja-jp/articles/protocols/saml/saml-apps/github-cloud.md
new file mode 100644
index 0000000000..fdd173f9e9
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/github-cloud.md
@@ -0,0 +1,88 @@
+---
+title: Configure Auth0 as Identity Provider for GitHub Enterprise Cloud
+description: This page explains how to configure Auth0 to be the SAML Identity Provider for a GitHub Enterprise Cloud (github.com) organization.
+topics:
+    - saml
+    - identity-providers
+    - github
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Configure Auth0 as Identity Provider for GitHub Enterprise Cloud
+
+These instructions explain how to configure Auth0 to serve as an Identity Provider for [GitHub Enterprise Cloud](https://help.github.com/en/articles/about-authentication-with-saml-single-sign-on) (i.e., github.com). Note that GitHub requires an Enterprise-level subscription to enable using an external SAML identity provider.
+
+When setting up SAML Single Sign-on (SSO) in your organization, you can test your implementation without affecting your organization members by leaving Require SAML SSO authentication for all members of the organization name organization unchecked. See [GitHub documentation on authentication with SAML](https://help.github.com/en/articles/about-authentication-with-saml-single-sign-on) for more information.
+
+::: note
+**Heads up!** This article applies to GitHub Enterprise Cloud (github.com). If you are looking for instructions to set up Auth0 as the identity provider for GitHub Enterprise Server (private instance), check [this page](/protocols/saml/saml-apps/github-server) instead.
+:::
+
+## Configure the Addon: SAML2 Web App
+
+Login to [Auth0 dashboard](${manage_url}) and create a new [Application](${manage_url}/#/applications). Give it a meaningful name like "GitHub". You can choose any application type really, but the "Regular Web App" type is the more representative. 
+
+Navigate to the [Addons](${manage_url}/#/applications/${account.clientId}/addons) tab and enable the **SAML2 Web App** using the toggle switch.
+
+![Application Addons](/media/articles/protocols/saml/github-cloud/client-addons.png)
+
+The *Settings* window will be displayed. Set the following values:
+
+- **Application Callback URL**: `https://github.com/orgs/{YOUR_GITHUB_ORG_NAME}/saml/consume`
+
+- **Settings**:
+
+```json
+{
+  "audience": "https://github.com/orgs/{YOUR_GITHUB_ORG_NAME}",
+  "mappings": {
+    "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+    "email": "emails",
+    "name": "full_name"
+  },
+  "passthroughClaimsWithNoMapping": false,
+  "mapIdentities": false,
+  "signatureAlgorithm": "rsa-sha256",
+  "digestAlgorithm": "sha256",
+  "nameIdentifierProbes": [
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"
+  ]
+}
+```
+
+**Note**: Make sure to replace `{YOUR_GITHUB_ORG_NAME}` with the GitHub organization name that corresponds to your subscription.
+
+The above mapping will send the `user_id` as the Name Identifier to GitHub. This is a good option if you enable more than one connection for the GitHub application, as it will ensure uniqueness (every user will have a different ID). If you are using a single connection, you might prefer to use the `nickname` or another unique identifier as a friendlier Name Identifier (but **make sure that the property you choose is indeed unique**). 
+
+As an example, if you want `nickname` as the Name Identifier, the `mappings` section above will look like this:
+
+```json
+{
+  [...]
+  "mappings": {
+    "nickname": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+    "email": "emails",
+    "name": "full_name"
+  },
+  [...]
+}
+```
+
+## Configure SAML Single Sign-On on GitHub
+Follow the instruction from GitHub's [Enabling and testing SAML Single Sign-on (SSO) for your organization](https://help.github.com/en/articles/enabling-and-testing-saml-single-sign-on-for-your-organization) to complete the configuration on GitHub Enterprise Cloud. You will need the following information:
+
+* **Sign On URL** (for step 6): `https://${account.namespace}/samlp/{CLIENT_ID}`
+  `{CLIENT_ID}` will be the `client_id` for the GitHub application you just created in Auth0.
+* **Issuer** (step 7): `urn:auth0:${account.tenant}`
+* **Public Certificate** (step 8): Download it from `https://${account.namespace}/pem`. Open the downloaded file with a text editor, copy the contents and paste them in the text area on GitHub.
+* **Signature method** (step 9): `RSA256-SHA256`
+* **Digest method** (step 9): `SHA256`
+
+The **Sign On URL**, **Issuer** and **Certificate** information can also be found in the **Usage** tab on the SAML Web App addon settings dialog:
+
+![Usage tab](/media/articles/protocols/saml/github-cloud/usage.png)
+
+As recommended in GitHub's documentation, before enabling SAML SSO for your organization, click **Test SAML configuration** to ensure that the information you've entered is correct.
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/saml/saml-apps/github-server.md b/ja-jp/articles/protocols/saml/saml-apps/github-server.md
new file mode 100644
index 0000000000..4495d0bca6
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/github-server.md
@@ -0,0 +1,85 @@
+---
+title: Configure Auth0 as Identity Provider for GitHub Enterprise Server
+description: This page explains how to configure Auth0 to be the SAML Identity Provider for a GitHub Enterprise Server private instance.
+topics:
+    - saml
+    - identity-providers
+    - github
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Configure Auth0 as Identity Provider for GitHub Enterprise Server
+
+These instructions explain how to configure Auth0 to serve as an Identity Provider for [GitHub Enterprise Server](https://help.github.com/en/enterprise/2.16/admin/user-management/using-saml) (i.e. your private GitHub appliance). 
+
+::: note
+**Heads up!** This article applies to GitHub Enterprise Server (deployed as a private instance). If you are looking for instructions to set up Auth0 as the identity provider for GitHub Enterprise Cloud (github.com), check [this page](/protocols/saml/saml-apps/github-cloud) instead.
+:::
+
+## Configure the Addon: SAML2 Web App
+
+Login to [Auth0 dashboard](${manage_url}) and create a new [Application](${manage_url}/#/applications). Give it a meaningful name like "GitHub". You can choose any application type really, but the "Regular Web App" type is the more representative. 
+
+Navigate to the [Addons](${manage_url}/#/applications/${account.clientId}/addons) tab and enable the **SAML2 Web App** using the toggle switch.
+
+![Application Addons](/media/articles/protocols/saml/github-cloud/client-addons.png)
+
+The *Settings* window will be displayed. Set the following values:
+
+- **Application Callback URL**: `{YOUR_GITHUB_SERVER_URL}/saml/consume`
+
+- **Settings**:
+
+```json
+{
+  "audience": "{YOUR_GITHUB_SERVER_URL}",
+  "mappings": {
+    "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+    "email": "emails",
+    "name": "full_name"
+  },
+  "passthroughClaimsWithNoMapping": false,
+  "mapIdentities": false,
+  "signatureAlgorithm": "rsa-sha256",
+  "digestAlgorithm": "sha256",
+  "nameIdentifierProbes": [
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"
+  ]
+}
+```
+
+**Note**: Make sure to replace `{YOUR_GITHUB_SERVER_URL}` with the URL assigned to your GitHub Server (i.e. `https://github.example.com`).
+
+The above mapping will send the `user_id` as the Name Identifier to GitHub. This is a good option if you enable more than one connection for the GitHub application, as it will ensure uniqueness (every user will have a different ID). If you are using a single connection, you might prefer to use the `nickname` or another unique identifier as a friendlier Name Identifier (but **make sure that the property you choose is indeed unique**). 
+
+As an example, if you want `nickname` as the Name Identifier, the `mappings` section above will look like this:
+
+```json
+{
+  [...]
+  "mappings": {
+    "nickname": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+    "email": "emails",
+    "name": "full_name"
+  },
+  [...]
+}
+```
+
+## Configure SAML Single Sign-on on GitHub
+Follow the instruction from [Using SAML on Enterprise Server- GitHub Help](https://help.github.com/en/enterprise/admin/user-management/using-saml#configuring-saml-settings) to complete the configuration on GitHub Enterprise Cloud. You will need the following information:
+
+* **Sign On URL**: `https://${account.namespace}/samlp/{CLIENT_ID}`
+  `{CLIENT_ID}` will be the `client_id` for the GitHub application you just created in Auth0.
+* **Issuer**: `urn:auth0:${account.tenant}`
+* **Verification Certificate**: You will need to download it from `https://${account.namespace}/pem` and upload it in this field.
+* **User Attributes**: you should leave the defaults here, as the mapping that we configured in the SAML Web App addon uses the default attribute names proposed by GitHub.
+* **Signature method**: `RSA256-SHA256`
+* **Digest method**: `SHA256`
+
+The **Sign On URL**, **Issuer** and **Certificate** information can also be found in the **Usage** tab on the SAML Web App addon settings dialog:
+
+![Usage tab](/media/articles/protocols/saml/github-cloud/usage.png)
diff --git a/ja-jp/articles/protocols/saml/saml-apps/google-apps.md b/ja-jp/articles/protocols/saml/saml-apps/google-apps.md
new file mode 100644
index 0000000000..1bb7255078
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/google-apps.md
@@ -0,0 +1,35 @@
+---
+title: G Suite SAML Configuration
+description: G Suite SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - g-suite
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+```json
+{
+  "audience": "https://www.google.com/a/{YOUR-GOOGLE-DOMAIN}/acs",
+  "mappings": {
+    "nickname": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
+  },
+  "createUpnClaim": false,
+  "passthroughClaimsWithNoMapping": false,
+  "mapUnknownClaimsAsIs": false,
+  "mapIdentities": false,
+  "signatureAlgorithm": "rsa-sha256",
+  "digestAlgorithm": "sha256",
+  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:email",
+  "nameIdentifierProbes": [
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+  ],
+}
+```
+
+The **Callback URL** is `https://www.google.com/a/{YOUR-GOOGLE-DOMAIN}/acs`.
diff --git a/ja-jp/articles/protocols/saml/saml-apps/heroku.md b/ja-jp/articles/protocols/saml/saml-apps/heroku.md
new file mode 100644
index 0000000000..2cefaeeea2
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/heroku.md
@@ -0,0 +1,75 @@
+---
+description: Learn how to configure Single Sign-on (SSO) with Heroku.
+topics:
+    - saml
+    - identity-providers
+    - heroku
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Configure Single Sign-on with Heroku
+
+::: note
+You must have administrative rights to your organization account on Heroku to configure Single Sign-on (SSO). Organization accounts are included with Heroku Enterprise plans.
+:::
+
+You can configure Single Sign-on (SSO) so that your users can log into Heroku using any of Auth0's supported [identity providers](/identityproviders).
+
+## 1. Obtain Your Heroku Identifiers
+
+On the Settings page for your organization in Heroku, scroll to the **Single Sign-On (SSO)** section.
+
+![](/media/articles/saml/saml-apps/heroku/heroku-dashboard.png)
+
+You will need the following two parameters from this section to integrate with Auth0:
+
+* __Heroku Entity ID__
+* __ACS URL__
+
+## 2. Register Heroku with Auth0
+
+Log in to your [Auth0 Dashboard](${manage_url}/#/applications) and select the [application](/applications) for which you want to configure SSO with Heroku. Go to the __Addons__ section of your Application, and enable __SAML2 Web App__:
+
+![](/media/articles/saml/saml-apps/heroku/auth0-dashboard.png)
+
+Enter the __ACS URL__ from the previous step into the __Application Callback URL__ field and update the settings as follows:
+
+```json
+{
+ "audience":"THE-HEROKU-ENTITY-ID",
+ "mappings": {
+   "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+ },
+ "createUpnClaim": false,
+ "passthroughClaimsWithNoMapping": false,
+ "mapUnknownClaimsAsIs": false,
+ "mapIdentities": false,
+ "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+ "nameIdentifierProbes": [
+   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+ ]
+}
+```
+
+![](/media/articles/saml/saml-apps/heroku/auth0-dashboard-saml.png)
+
+::: note
+The `audience` parameter is the __Heroku Entity ID__. It will be formatted like this: `https://sso.heroku.com/saml/YOUR-HEROKU-ORG`
+:::
+
+Click **Save**. 
+
+![](/media/articles/saml/saml-apps/heroku/auth0-dashboard-saml-usage.png)
+
+## 3. Provide Auth0 Metadata to Heroku
+
+Open up the __Usage__ section of the SAML2 Web App Configuration pop-up and download the __Identity Provider Metadata__.
+
+Return to Heroku. Click on __Upload Metadata__ and select the file containing the **Identity Provider Metadata** you downloaded in the previous step.
+
+![](/media/articles/saml/saml-apps/heroku/heroku-dashboard.png)
+
+Once you've uploaded your metadata, your SSO integration is fully set up.
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/saml/saml-apps/hosted-graphite.md b/ja-jp/articles/protocols/saml/saml-apps/hosted-graphite.md
new file mode 100644
index 0000000000..cbeb6da827
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/hosted-graphite.md
@@ -0,0 +1,26 @@
+---
+title: Hosted Graphite SAML Configuration
+description: Hosted Graphite SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - hosted-graphite
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+```json
+{
+  "audience": "https://www.hostedgraphite.com/metadata/{YOUR-USER-ID}/",
+  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+  "nameIdentifierProbes": [
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+  ]
+}
+```
+
+The **Callback URL** is `https://www.hostedgraphite.com/complete/saml/{YOUR-USER-ID}/`.
diff --git a/ja-jp/articles/protocols/saml/saml-apps/index.md b/ja-jp/articles/protocols/saml/saml-apps/index.md
new file mode 100644
index 0000000000..472ae21b8d
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/index.md
@@ -0,0 +1,44 @@
+---
+title: SAML Configurations for Single Sign-on Integrations
+description: This page lists SAML Configurations for various Single Sign-on (SSO) integrations including G Suite, Hosted Graphite, Litmos, Cisco Webex, Sprout Video, FreshDesk, Tableau Server, Datadog, Egencia, Workday, Pluralsight and Workpath.
+classes: topic-page
+topics:
+    - saml
+    - identity-providers
+contentType:
+  - index
+useCase:
+  - add-idp
+---
+
+
+
      
+  
      
+  
      SAML Configurations for Single Sign-on Integrations
      
+  
      
+    This page lists SAML Configurations for various Single Sign-on (SSO) integrations.
+  
      
+
      
+
+## SAML Configuration Tutorials
+
+<%= include('../../../_includes/_topic-links', { links: [
+  'protocols/saml/saml-apps/atlassian',
+  'protocols/saml/saml-apps/cisco-webex',
+  'protocols/saml/saml-apps/datadog',
+  'protocols/saml/saml-apps/egencia',
+  'protocols/saml/saml-apps/eloqua',
+  'protocols/saml/saml-apps/freshdesk',
+  'protocols/saml/saml-apps/github-cloud',
+  'protocols/saml/saml-apps/github-server',
+  'protocols/saml/saml-apps/google-apps',
+  'protocols/saml/saml-apps/heroku',
+  'protocols/saml/saml-apps/hosted-graphite',
+  'protocols/saml/saml-apps/litmos',
+  'protocols/saml/saml-apps/pluralsight',
+  'protocols/saml/saml-apps/sprout-video',
+  'protocols/saml/saml-apps/tableau-online',
+  'protocols/saml/saml-apps/tableau-server',
+  'protocols/saml/saml-apps/workday',
+  'protocols/saml/saml-apps/workpath'
+] }) %>
diff --git a/ja-jp/articles/protocols/saml/saml-apps/litmos.md b/ja-jp/articles/protocols/saml/saml-apps/litmos.md
new file mode 100644
index 0000000000..756f9ca3b4
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/litmos.md
@@ -0,0 +1,131 @@
+---
+title: Litmos SAML Configuration
+description: Litmos SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - litmos
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+```json
+{
+ "mappings": {
+   "user_id":     "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+   "email":       "Email",
+   "given_name":  "FirstName",
+   "family_name": "LastName"
+ },
+ "createUpnClaim":       false,
+ "passthroughClaimsWithNoMapping": false,
+ "mapUnknownClaimsAsIs": false,
+ "mapIdentities":        false,
+ "signatureAlgorithm":   "rsa-sha1",
+ "digestAlgorithm":      "sha1",
+ "destination":          "https://{YOUR DOMAIN}.litmos.com/integration/samllogin",
+ "lifetimeInSeconds":    3600,
+ "signResponse":         false,
+ "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+ "nameIdentifierProbes": [
+   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+ ]
+}
+```
+
+The **Callback URL** is `https://{YOUR DOMAIN}.litmos.com/integration/samllogin`.
+
+## Sample SAML
+
+```xml
+
+    urn:{tenant}.auth0.com
+    
+        
+    
+    
+        urn:{tenant}.auth0.com
+        
+            
+                
+                
+                
+                    
+                        
+                        
+                    
+                    
+                    cdFGeW7M8cxg9xEVh/gLxRKlWDA=
+                
+            
+            *********
+            
+                
+                    *********
+                
+            
+        
+        
+            brandon@litmos.com
+            
+                
+            
+        
+        
+            
+                
+            
+        
+        
+            
+                urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
+            
+        
+        
+            
+                Smith
+            
+            
+                John
+            
+            
+                john@mail.com
+            
+        
+    
+
+```
diff --git a/ja-jp/articles/protocols/saml/saml-apps/pluralsight.md b/ja-jp/articles/protocols/saml/saml-apps/pluralsight.md
new file mode 100644
index 0000000000..ea769d56c2
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/pluralsight.md
@@ -0,0 +1,37 @@
+---
+title: Pluralsight SAML Configuration
+description: Pluralsight SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - pluralsight
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+
+```json
+{
+  "audience":  "www.pluralsight.com",
+  "mappings": {
+    "user_id":     "id",
+    "email":       "email",
+    "given_name":  "firstName",
+    "family_name": "lastName"
+  },
+  "createUpnClaim":       false,
+  "passthroughClaimsWithNoMapping": false,
+  "mapUnknownClaimsAsIs": false,
+  "mapIdentities":        false,
+  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+  "nameIdentifierProbes": [
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+  ]
+}
+```
+
+The **Callback URL** is `https://prod-pf.pluralsight.com/sp/ACS.saml2`.
diff --git a/ja-jp/articles/protocols/saml/saml-apps/sprout-video.md b/ja-jp/articles/protocols/saml/saml-apps/sprout-video.md
new file mode 100644
index 0000000000..fd4ada302c
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/sprout-video.md
@@ -0,0 +1,32 @@
+---
+title: Sprout Video SAML Configuration
+description: Sprout Video SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - sprout-video
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+```json
+{
+ "audience":  "https://{YOUR SPROUT VIDEO ACCOUNT}.vids.io",
+ "mappings": {  
+       "user_id":     "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+       "email":       "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+ },
+ "createUpnClaim":       false,
+ "passthroughClaimsWithNoMapping": false,
+ "mapUnknownClaimsAsIs": false,
+ "mapIdentities":        false,
+ "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+ "nameIdentifierProbes": [
+   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+ ],
+}
+```
diff --git a/ja-jp/articles/protocols/saml/saml-apps/tableau-online.md b/ja-jp/articles/protocols/saml/saml-apps/tableau-online.md
new file mode 100644
index 0000000000..685f3b65b4
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/tableau-online.md
@@ -0,0 +1,40 @@
+---
+title: Tableau Online SAML Configuration
+description: Tableau Online SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - tableau
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+```json
+{
+ "audience":  "https://sso.online.tableau.com/public/sp/metadata?alias={YOUR TABLEAU ALIAS}",
+ "recipient": "https://sso.online.tableau.com/public/sp/SSO/{YOUR TABLEAU ALIAS}",
+ "mappings": {
+    "email": "Email"
+ },
+ "createUpnClaim":       false,
+ "passthroughClaimsWithNoMapping": false,
+ "mapUnknownClaimsAsIs": false,
+ "mapIdentities":        false,
+ "signatureAlgorithm":   "rsa-sha1",
+ "digestAlgorithm":      "sha1",
+ "destination":          "https://sso.online.tableau.com/public/sp/SSO/{YOUR TABLEAU ALIAS}",
+ "lifetimeInSeconds":    3600,
+ "signResponse":         false,
+ "nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:attrname-format:basic",
+ "nameIdentifierProbes": [
+   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
+ ]
+}
+```
+The **Callback URL** is `https://sso.online.tableau.com/public/sp/SSO/{YOUR TABLEAU ALIAS}`.
+The recipient, destination and callback URLL value is same as Assertion Consumer Service URL from Tableau Authentication Page.
+See [https://onlinehelp.tableau.com/current/online/en-us/saml_config_site.htm](https://onlinehelp.tableau.com/current/online/en-us/saml_config_site.htm) for more information.
diff --git a/ja-jp/articles/protocols/saml/saml-apps/tableau-server.md b/ja-jp/articles/protocols/saml/saml-apps/tableau-server.md
new file mode 100644
index 0000000000..e299a22d92
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/tableau-server.md
@@ -0,0 +1,39 @@
+---
+title: Tableau Server SAML Configuration
+description: Tableau Server SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - tableau
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+```json
+{
+ "audience":  "{YOUR TABLEAU AUDIENCE}",
+ "recipient": "http://{YOUR TABLEAU SERVER}/wg/saml/SSO/index.html",
+ "mappings": {
+    "email": "username"
+ },
+ "createUpnClaim":       false,
+ "passthroughClaimsWithNoMapping": false,
+ "mapUnknownClaimsAsIs": false,
+ "mapIdentities":        false,
+ "signatureAlgorithm":   "rsa-sha1",
+ "digestAlgorithm":      "sha1",
+ "destination":          "http://{YOUR TABLEAU SERVER}/wg/saml/SSO/index.html",
+ "lifetimeInSeconds":    3600,
+ "signResponse":         false,
+ "nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:attrname-format:basic",
+ "nameIdentifierProbes": [
+   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
+ ]
+}
+```
+
+The **Callback URL** is `http://{YOUR TABLEAU SERVER}/wg/saml/SSO/index.html`.
diff --git a/ja-jp/articles/protocols/saml/saml-apps/workday.md b/ja-jp/articles/protocols/saml/saml-apps/workday.md
new file mode 100644
index 0000000000..1e3f3f6970
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/workday.md
@@ -0,0 +1,35 @@
+---
+title: Workday SAML Configuration
+description: Workday SAML Configuration
+topics:
+    - saml
+    - identity-providers
+    - workday
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+```json
+{
+  "audience": "http://www.workday.com",
+  "recipient": "https://www.myworkday.com//login-saml.htmld",
+  "mappings": {
+  },
+  "createUpnClaim":       false,
+  "passthroughClaimsWithNoMapping": false,
+  "mapUnknownClaimsAsIs": false,
+  "mapIdentities":        false,
+  "signResponse":         true,
+  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName",
+  "nameIdentifierProbes": [
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+  ],
+  "authnContextClassRef": "urn:oasis:names:tc:SAML:2.0:ac:classes:X509",
+}
+```
+
+The **Callback URL** is `https://impl.workday.com//login-saml.htmld`. You may want to change the subdomain `impl` depending on the Workday data center you are using.
diff --git a/ja-jp/articles/protocols/saml/saml-apps/workpath.md b/ja-jp/articles/protocols/saml/saml-apps/workpath.md
new file mode 100644
index 0000000000..60e2f170b2
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-apps/workpath.md
@@ -0,0 +1,23 @@
+---
+title: Workpath SAML Configuration
+description: Workpath SAML Configuration
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+<%= include('./_header') %>
+
+```json
+{
+  "audience": "https://api.workpath.com/v1/saml/metadata/{YOUR-WORKPATH-SUBDOMAIN}",
+  "mappings": {
+    "email": "email",
+    "given_name": "first_name",
+    "family_name": "last_name"
+  }
+}
+```
+
+The **Callback URL** is `https://api.workpath.com/v1/saml/assert/{YOUR-WORKPATH-SUBDOMAIN}`.
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/auth0-as-identity-and-service-provider.md b/ja-jp/articles/protocols/saml/saml-configuration/auth0-as-identity-and-service-provider.md
new file mode 100644
index 0000000000..999e7a133b
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/auth0-as-identity-and-service-provider.md
@@ -0,0 +1,30 @@
+---
+description: How to configure Auth0 for use as a SAML service AND identity provider
+topics:
+    - saml  
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Configure Auth0 as a Service and Identity Provider
+
+::: note
+Auth0 provides a non-exhaustive [list of SAML-compliant providers](/samlp-providers).
+:::
+
+::: warning
+Auth0 only supports:
+* Using Auth0 as the service provider in SAML configurations with **SAML 1.1** or **SAML 2.0**.
+* Using Auth0 as the identity provider in SAML configurations with **SAML 2.0**.
+:::
+
+When using Auth0 as both the SAML Service and Identity Provider, you need to configure **two** federations:
+
+* [Configure Auth0 as a Service Provider](/protocols/saml/saml-configuration/auth0-as-service-provider)
+* [Configure Auth0 as an Identity Provider](/protocols/saml/saml-configuration/auth0-as-identity-provider).
+
+## Using Two Auth0 Tenants
+
+The section above assumes that you're using the same Auth0 tenant as the service provider *and* the identity provider. However, you can also implement a [SAML scenario using **two** Auth0 tenants](/samlsso-auth0-to-auth0) (usually for testing purposes), where one tenant acts as the identity provider and the other acts as the service provider.
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/auth0-as-identity-provider.md b/ja-jp/articles/protocols/saml/saml-configuration/auth0-as-identity-provider.md
new file mode 100644
index 0000000000..56178f72e1
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/auth0-as-identity-provider.md
@@ -0,0 +1,72 @@
+---
+description: How to configure Auth0 for use as a SAML identity provider
+topics:
+  - saml
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Configure Auth0 as an Identity Provider
+
+::: warning
+Auth0 only supports using Auth0 as the identity provider in SAML configurations with **SAML 2.0**.
+:::
+
+Depending on the type of application you're working with, configuring Auth0 to serve as the SAML Identity Provider (IdP) is done in several places.
+
+## Single Sign-on Integrations with Built-in Auth0 Support
+
+For some Single Sign-on (SSO) Integrations that support SAML, the configuring Auth0 is done using the [**SSO Integrations** area of the Management Dashboard](${manage_url}/#/externalapps). To create a new integration, click **Create SSO Integration**.
+
+![](/media/articles/protocols/saml/saml-configuration/sso-integrations.png)
+
+ On the *New Single Sign-On Integration* page, select the integration in which you're interested. Currently, your options are as follows:
+
+* Active Directory
+* Box
+* CloudBees
+* Concur
+* Dropbox
+* Microsoft Dynamics CRM
+* Adobe EchoSign
+* Egnyte
+* New Relic
+* Office 365
+* Salesforce
+* SharePoint
+* Slack
+* SpringCM
+* Zendesk
+* Zoom
+
+![](/media/articles/protocols/saml/saml-configuration/sso-integrations-supported.png)
+
+Provide a name for your new integration. Click **Create** to proceed.
+
+You will now see additional configuration instructions that are specific to the integration that you have chosen.
+
+![](/media/articles/protocols/saml/saml-configuration/name-sso-integration.png)
+
+You can also refer to [Using Auth0 in SAML2 Web Apps](/saml2webapp-tutorial) for instructions specific to configuring a given SSO Integration.
+
+## Manually Configure a SSO Integration
+
+If the Service Provider option you've chosen doesn't come with built-in Auth0 support, you can [manually add the configuration](/saml-idp-generic).
+
+Navigate to the [Applications section of the Management Dashboard](${manage_url}/#/applications), find the Application you're working with, and click on **Settings**.
+
+![](/media/articles/protocols/saml/saml-configuration/applications.png)
+
+Switch over to the **Addons** tab.
+
+![](/media/articles/protocols/saml/saml-configuration/add-ons.png)
+
+Enable **SAML2 Web App**. You will see a screen asking you to provide additional configuration information, with details on what the fields mean and what the expected value types are located directly on that page.
+
+![](/media/articles/protocols/saml/saml-configuration/configure-app.png)
+
+In addition, [SAML Settings Needed for Some SSO Integrations](/saml-apps) provide additional information for integrations that require special settings.
+
+When done, click **Save**.
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/auth0-as-service-provider.md b/ja-jp/articles/protocols/saml/saml-configuration/auth0-as-service-provider.md
new file mode 100644
index 0000000000..7ed558c5f6
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/auth0-as-service-provider.md
@@ -0,0 +1,34 @@
+---
+description: How to configure Auth0 for use as a SAML service provider
+topics:
+  - saml
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Configure Auth0 as a Service Provider
+
+::: warning
+Auth0 only supports using Auth0 as the service provider in SAML configurations with **SAML 1.1** or **SAML 2.0**.
+:::
+
+This video provides an overview of how to configure Auth0 for use as a SAML service provider.
+
+
+
+
+When Auth0 serves as the SAML service provider, you need to use an Auth0 Connection to configure the service provider side of each SAML federation.
+
+Finally, you'll configure the Identity Provider (IdP) portion of your SAML setup. We have docs for the following providers:
+
+* [ADFS](/adfs)
+* [Okta](/okta)
+* [OneLogin](/onelogin)
+* [Ping7](/ping7)
+* [Salesforce](/saml/identity-providers/salesforce)
+* [SiteMinder](/siteminder)
+* [SSOCircle](/ssocircle)
+
+If you are using any other SAML-compliant IdP with Auth0 as the Service Provider, you can use the [Generic Service Provider Configuration Instructions](/saml-sp-generic).
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/deprovision-users.md b/ja-jp/articles/protocols/saml/saml-configuration/deprovision-users.md
new file mode 100644
index 0000000000..08d1523ec3
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/deprovision-users.md
@@ -0,0 +1,18 @@
+---
+description: Best practices on deprovision users of your SAML integration
+topics:
+  - saml
+contentType:
+  - how-to
+  - concept
+useCase:
+  - add-idp
+---
+
+# Deprovision Users
+
+If you ever need to remove application access for users, you'll need to *deprovision* them, at minimum, with the identity provider. Depending on the identity provider you're using, the steps required to deprovision a user account varies; check with your provider for further instructions.
+
+Once a user's account is removed or disabled with the identity provider, the user will not be able to log in.
+
+You may also want to remove the Auth0 user accounts for those who've been deprovisioned if Auth0 is the service provider or if your app integrates with Auth0. Regardless of whether Auth0 is the identity or service provider, you can remove users using the Management [Dashboard](${manage_url}/#/users) or [API](/api/management/v2#!/Users/delete_users_by_id).
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/design-considerations.md b/ja-jp/articles/protocols/saml/saml-configuration/design-considerations.md
new file mode 100644
index 0000000000..68ac4fbf90
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/design-considerations.md
@@ -0,0 +1,46 @@
+---
+description: Things to consider when designing your SAML integration
+topics:
+  - saml
+contentType:
+  - concept
+useCase:
+  - add-idp
+---
+
+# SAML Design Considerations
+
+Regardless of how you implement SAML Single Sign-on (SSO), it's important to consider:
+
+* Which system(s) will serve as the authoritative source for user profile information if there's ever a conflict between two or more sources;
+* What user profile attributes each application needs;
+* How user profile information will be distributed to the systems that need it.
+
+## Considerations for Using Auth0 as Service Provider
+
+* If Auth0 serves as the Service Provider in a SAML federation, Auth0 can [route authentication requests to an Identity Provider](/hrd) without already having an account pre-created for a specific user. Using the assertion returned by the identity provider, Auth0 can capture information needed to create a user profile for the user (this process is sometimes called just-in-time provisioning).
+
+* Even though Auth0 doesn't require pre-created user accounts prior to the authentication process, the application integrated with Auth0 might. If this is the case, you have several options when it comes to handling this:
+
+  * After the identity provider creates the user, you can use an out-of-band process can create the accompanying user in the application (or Auth0) and add any user profile attributes required by the application. If, after authentication, any attributes are missing in the profile, the application can obtain them from the appropriate source and store them in the Auth0 user profile. The additional attributes are then sent to the application (in addition to any added by the identity provider) the next time the user logs in.
+
+  * You can use an Auth0 [rule](/rules) to call an API to retrieve any missing information and dynamically add it to the Auth0 profile (which is then returned to the application). Rules execute after successful authentication, and your application can retrieve profile attributes each time *or* you can save the attributes to the Auth0 profile.
+
+  * Auth0 can pass the basic profile information from the identity provider to the application, which then retrieves any missing information from another source. With the two sets of information, the application creates a local user profile.
+
+* You can specify email domains as part of the Auth0 SAMLP Connection configuration to control the IDP that handles a select group of users. For example, if you add email domain `example.com` to the Auth0 SAMLP Connection configuration for Company X, all users with emails with the `example.com` domain get handled by the specific IDP for Company X.
+
+## Considerations for Using Auth0 as Identity Provider
+
+If Auth0 is serving as the Identity Provider in a SAML federation, user accounts may be created multiple ways:
+
+* Using a back-end authentication system, such as an LDAP directory, a database, or another SAML identity provider;
+* Using the [Auth0 Management Dashboard](${manage_url}/#/users);
+* Calling the [Auth0 Management API](/api/management/v2#!/Users/post_users);
+* Implementing self-service user signup.
+
+If your application is written to retrieve user profile information from a local store, you'll need to create the local profile after the accounts have been created in Auth0. Some of the ways you might do this include:
+
+ * An out-of-band process creating user profiles in the application;
+ * An Auth0 [rule](/rules) that executes on first login that calls an application API to create the user profile in the application;
+ * Modifying the application to create user profiles dynamically, based on information in the SAML assertion.
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/index.md b/ja-jp/articles/protocols/saml/saml-configuration/index.md
new file mode 100644
index 0000000000..0c6ff2b5b3
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/index.md
@@ -0,0 +1,57 @@
+---
+description: An overview of the SAML configuration process
+topics:
+  - saml
+  - saml-configuration
+contentType:
+  - index
+useCase:
+  - add-idp
+---
+
+# SAML Configuration
+
+SAML-based federation involves two parties:
+
+1. An **identity provider** (IdP): authenticates users and provides to Service Providers an Authentication Assertion if successful;
+2. A **service provider** (SP): relies on the Identity Provider to authenticate users.
+
+Auth0 supports the SAML protocol and can serve as the identity provider, the service provider, or both.
+
+## SAML Identity Providers
+
+Some applications (such as Salesforce, Box, and Workday) allow users to authenticate against an external IdP using the SAML protocol. You can then integrate the application with Auth0, which serves as the application's SAML IdP.
+
+Application users will be redirected to Auth0 to log in, and Auth0 can authenticate them using any backend authentication connection, such as an LDAP directory, a database, or another SAML IdP or Social Provider.
+
+Once the user is authenticated, Auth0 returns a SAML assertion to the application that indicates such.
+
+![](/media/articles/saml/saml-configuration/saml-case2.png)
+
+## SAML Service Providers
+
+Applications, especially custom ones, can authenticate users against an external IdP using protocols such as OpenID Connect (OIDC) or OAuth 2.0. However, you might want to leverage an enterprise SAML provider for authentication, even if you wrote your application to utilize either protocol.
+
+![](/media/articles/saml/saml-configuration/saml-case1.png)
+
+## Auth0 as the SAML Service and Identity Providers
+
+You may opt to use Auth0 as both the SAML Service Provider **and** SAML Identity Provider.
+
+![](/media/articles/saml/saml-configuration/saml-case3.png)
+
+## Configuration
+
+The following documentation cover the different aspects of SAML configuration:
+
+* [Configure Auth0 as a Service Provider](/protocols/saml/saml-configuration/auth0-as-service-provider)
+* [Configure Auth0 as an Identity Provider](/protocols/saml/saml-configuration/auth0-as-identity-provider)
+* [Configure Auth0 as Both Service and Identity Provider](/protocols/saml/saml-configuration/auth0-as-identity-and-service-provider)
+* [SAML Design Considerations](/protocols/saml/saml-configuration/design-considerations)
+* [Supported SAML Options and Bindings](/protocols/saml/saml-configuration/supported-options-and-bindings)
+* [Special Configuration Scenarios](/protocols/saml/saml-configuration/special-configuration-scenarios)
+* [Customize SAML Assertions](/protocols/saml/saml-configuration/saml-assertions)
+* [Select Between Multiple Identity Providers](/hrd)
+* [Logout](/protocols/saml/saml-configuration/logout)
+* [Deprovision Users](/protocols/saml/saml-configuration/deprovision-users)
+* [Troubleshoot](/protocols/saml/saml-configuration/troubleshoot)
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/logout.md b/ja-jp/articles/protocols/saml/saml-configuration/logout.md
new file mode 100644
index 0000000000..efc2414f46
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/logout.md
@@ -0,0 +1,76 @@
+---
+description: Learn how to log users out of Auth0 as the SAML identity provider.
+topics:
+  - saml
+  - logout
+  - session-termination
+contentType:
+  - how-to
+useCase:
+  - add-idp
+  - manage-logout
+  - user-management
+---
+# Log Users Out of Auth0 as the SAML Identity Provider
+
+When integrating with a SAML identity provider, there are many ways to implement logout or *user session termination*.
+
+SAML logout is configured differently depending on whether Auth0 acts as the service provider (when you create a SAML **connection**) the identity provider (when you have an application with the SAML2 Web App addon) or both.
+
+## Logout scenarios
+
+When Auth0 is acting as a [SAML Identity Provider](/protocols/saml/saml-idp-generic), you can have the following two scenarios:
+
+* Single logout
+* Non-single logout
+
+### SAML Single Logout (SLO) Scenario
+
+After determining that your service provider supports SAML SLO, configure the service provider to call `https://${account.namespace}/samlp/CLIENT_ID/logout` (also listed in the SAML IdP metadata). 
+
+When a logout request is triggered by the service provider, a SAML logout request is sent to this endpoint. Auth0 starts the SAML SLO flow by notifying the existing session participants using a frontend channel.
+
+1. Log into the [Management Dashboard](${manage_url})
+
+2. Navigate to your [Application's Addons page](${manage_url}/#/applications/${account.clientId}/addons).
+
+3. Click to open the **SAML2 Web App** addon.
+
+4. In the **Settings** editor, uncomment the `logout` portion and update it with your callback URL:
+
+  ```json
+  "logout": {
+    "callback": "CALLBACK_URL"
+  }
+  ```
+
+   To prevent a session participant from being notified, you can set `logout.slo_enabled` to `false` in the `SAML2 Web App` application addon's settings. 
+
+5. Click **Save**.
+
+For SAML-compliant endpoints, Auth0 uses this URL to send SAML logout requests or logout responses (the exact choice depends on whether the service provider initiated the session or not). If you don't want to notify the service provider about a session termination, you can set the `slo_enabled` key inside logout to `false`:
+
+```json
+"logout": {
+  "callback": "CALLBACK_URL",
+  "slo_enabled": false
+}
+```
+
+By default, SAML logout responses are sent using the **HTTP-POST** protocol binding. If you want to use **HTTP-Redirect** you can configure the `binding` key to `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect`:
+
+```json
+"logout": {
+  "callback": "CALLBACK_URL"
+},
+"binding": "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"
+```
+
+### Non-Single Logout Scenario
+
+If your service provider does not support SAML SLO, but provides a redirect URL where the user will be redirected to after logging out of the service provider, configure the redirect URL to `https://${account.namespace}/v2/logout`. This won't notify other session participants that a logout was initiated, but it will remove the session from Auth0.
+
+## Keep reading
+
+* [Log Users Out of SAML Identity Providers](/logout/guides/logout-saml-idps)
+* [Logout](/logout)
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/saml-assertions.md b/ja-jp/articles/protocols/saml/saml-configuration/saml-assertions.md
new file mode 100644
index 0000000000..797c742986
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/saml-assertions.md
@@ -0,0 +1,117 @@
+---
+description: How to customize SAML assertions
+topics:
+  - saml
+  - saml-assertions
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Customize SAML Assertions
+
+You can customize your SAML assertions, as well as the SAML and WS-Fed protocol parameters.
+
+## Auth0 as the Identity Provider
+
+To customize your SAML assertions when Auth0 acts as the identity provider, you can do so by configuring the addon itself or using [rules](/rules).
+
+### Use the Application Addon
+
+To customize your SAML assertion using the application add-on, navigate to [Applications > Settings > Addons](${manage_url}/#/applications/${account.clientId}/addons). Click on **SAML2 Web App** to launch the *Settings* tab that allows you to make several types of customizations including:
+
+* Specifying an audience other than the default issuer of the SAML request;
+* Specifying a recipient;
+* Mapping profile attributes to specific attribute statements;
+* Changing the signature or digest algorithm;
+* Specifying whether just the assertion or the entire response should be signed.
+
+### Use Rules
+
+You can use rules to add more extensive or dynamic customizations to the SAML response.
+
+Customizations done in Rules override customizations done using the Application Addons tab.
+
+::: note
+The `context.samlConfiguration.mappings` object is used to override default SAML attributes or add new attributes. The object keys are the name of the SAML attribute to override or add and the values are a string of the `user` object property to use as the attribute value.
+:::
+
+#### Example: Changing the SAML Token Lifetime and Using UPN as NameID
+
+```js
+function (user, context, callback) {
+  // change SAML token lifetime to 10 hours
+  context.samlConfiguration.lifetimeInSeconds = 36000;
+
+  // if available, use upn as NameID
+  if (user.upn) {
+    context.samlConfiguration.mappings = {
+      "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier": "upn" // use user.upn as the value
+    }
+  }
+
+  callback(null, user, context);
+}
+```
+
+#### Example: Include `user_metadata` Attributes in an Assertion
+
+```js
+function (user, context, callback) {
+  user.user_metadata = user.user_metadata || {};
+  user.user_metadata.color = "purple";
+  context.samlConfiguration.mappings = {
+    "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/color": "user_metadata.color", // use user.user_metadata.color as the value
+  };
+  callback(null, user, context);
+}
+```
+
+## Configuration Options
+
+The following is a list of customization options for your SAML assertions.
+
+* **audience** (string): The audience of the SAML Assertion. Default will be the Issuer on SAMLRequest.
+
+* **recipient** (string): The recipient of the SAML Assertion (SubjectConfirmationData). Default is `AssertionConsumerUrl` on SAMLRequest or Callback URL if no SAMLRequest was sent.
+
+* **mappings** (Object): The mappings between Auth0 profile and the output attributes on the SAML Assertion. Default mapping is shown above.
+
+* **createUpnClaim** (bool): Whether or not a UPN claim should be created. Default is true.
+
+* **passthroughClaimsWithNoMapping** (bool): If true (default), for each claim that is not mapped to the common profile, Auth0 will passthrough those in the output assertion. If false, those claims won't be mapped. Default is true.
+
+* **mapUnknownClaimsAsIs** (bool): if `passthroughClaimsWithNoMapping` is true and this is false (default), for each claim that is not mapped to the common profile Auth0 will add a prefix `http://schema.auth0.com`. If true it will passthrough the claim as-is. Default is false.
+
+* **mapIdentities**: If true, it will will add more information in the token like the provider used (google, adfs, ad, and so on) and the Access Token if available. Default is true.
+
+* **signatureAlgorithm**: Signature algorithm to sign the SAML Assertion or response. Default is `rsa-sha1` and it could be `rsa-sha256`.
+
+* **digestAlgorithm**: Digest algorithm to calculate digest of the SAML Assertion or response. Default is `sha1` and it could be `sha256`.
+
+* **destination**: Destination of the SAML Response. If not specified, it will be `AssertionConsumerUrl` of SAMLRequest or Callback URL if there was no SAMLRequest.
+
+* **lifetimeInSeconds** (int): Expiration of the token. Default is `3600` seconds (1 hour).
+
+* **signResponse** (bool): Whether or not the SAML Response should be signed. By default the SAML Assertion will be signed, but not the SAML Response. If true, SAML Response will be signed instead of SAML Assertion.
+
+* **nameIdentifierFormat** (string): Default is `urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified`.
+
+* **nameIdentifierProbes** (Array): Auth0 will try each of the attributes of this array in order. If one of them has a value, it will use that for the Subject/NameID. The order is: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier (mapped from user_id), http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress (mapped from email), http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name (mapped from name).
+
+* **authnContextClassRef** (string): Default is `urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified`.
+
+* **typedAttributes** (bool): Default is `true`. When set to true, we infer the xs:type of the element. Types are `xs:string`, `xs:boolean`, `xs:double `and `xs:anyType`. When set to false all `xs:type` are `xs:anyType`
+
+* **includeAttributeNameFormat** (bool): Default is `true`. When set to `true`, we infer the NameFormat based on the attribute name. NameFormat values are `urn:oasis:names:tc:SAML:2.0:attrname-format:uri`, `urn:oasis:names:tc:SAML:2.0:attrname-format:basic` and `urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified`. If set to `false`, the attribute NameFormat is not set in the assertion.
+
+* **logout** (object): An object that controls SAML logout. It can contain two properties:`callback` (of type `string`), that contains the service provider (client application)'s **Single Logout Service URL**, where Auth0 will send logout requests and responses, and `slo_enabled`(boolean) that controls whether Auth0 should notify service providers of session termination. The default value is`true` (notify service providers).
+
+* **binding** (string): Optionally indicates the protocol binding used for SAML logout responses. By default Auth0 uses `HTTP-POST`, but you can switch to `HTTP-Redirect` by setting `"binding"` to `"urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"`.
+
+* **signingCert** (string): Optionally indicates the public key certificate used to validate SAML requests. If set, SAML requests will be required to be signed. A sample value would be
+
+  ```
+  "-----BEGIN PUBLIC KEY-----\nMIGf...bpP/t3\n+JGNGIRMj1hF1rnb6QIDAQAB\n-----END PUBLIC KEY-----\n"
+  ```
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/special-configuration-scenarios/idp-initiated-sso.md b/ja-jp/articles/protocols/saml/saml-configuration/special-configuration-scenarios/idp-initiated-sso.md
new file mode 100644
index 0000000000..09ec481adf
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/special-configuration-scenarios/idp-initiated-sso.md
@@ -0,0 +1,66 @@
+---
+  description: Learn to set up IdP-initiated Single Sign-on (SSO)
+  topics:
+    - saml
+    - sso
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Special Configuration Scenarios: IdP-Initiated Single Sign-On
+
+Many instructions for setting up a SAML federation begin with Single Sign-on (SSO) initiated by the service provider:
+
+1. The service provider returns a browser redirect so that the user authenticates using the identity provider.
+2. After authentication, the browser redirects the user back to the Service Provider with a SAML assertion containing information about the authentication status.
+
+This is commonly used for consumer-facing scenarios.
+
+## Alternative to Service Provider-Initiated SSO
+
+You might choose to begin with the identity provider initiating SSO instead of the service provider. The user:
+
+1. Invokes a URL on the identity provider;
+2. Is prompted to authenticate
+3. Is redirected to the service provider with a SAML assertion
+
+This is commonly used in enterprise scenarios.
+
+For example, an organization might set up a portal to ensure that users navigate to the correct application:
+
+1. The user navigates to the portal's URL;
+2. The user is redirected to the IdP, which authenticates the user;
+3. If successfully authenticated, the user clicks on the appropriate link;
+4. The user is redirected to the service provider with a SAML assertion.
+
+## Risks of Using an IdP-Initiated SSO Flow
+
+In general, it is recommended to use Service-Provided flows whenever available. When an application actively requests an authentication as a first step (as is the case for SP-Initiated flows), it can check that the authentication response matches the original request. 
+In IdP-initiated scenarios, on the other hand, the application can not verify that the user actually started the flow. Because of this, the IdP-Initiated flow opens the possibility of an [Login CSRF attack](https://support.detectify.com/customer/portal/articles/1969819-login-csrf), where an attacker can trick a legitimate user into using a session created by the attacker. 
+
+Login CSRF attacks are generally less of a concern in enterprise-only scenarios, as any would-be attacker would have to come from the same directory of users. But it's definitely a security concern in consumer-facing applications, so we strongly advise against enabling IdP-Inititated flows on SAML connections.
+
+## Auth0 as Service Provider Where IdP Initiates SSO
+
+For information on how to configure IdP-Initiated flows when Auth0 is the Service Provider see [How to setup IdP-Initiated SSO in a SAML connection](/protocols/saml/idp-initiated-sso).
+
+## Auth0 as Identity Provider Where IdP Initiates SSO
+
+If Auth0 acts as the identity provider, you can use the application's SAML Sign In URL endpoint directly (without a SAML request):
+
+* Invoke the IdP-initiated login using the following URL:
+
+  ```text
+  https://${account.namespace}/samlp/${account.clientId}
+  ```
+
+* Append the `RelayState` parameter to the URL to which the service provider redirects the user after processing the SAML response. For example, the following URL is where the service provider redirects the URL after its processed the SAML response from Auth0:
+
+  ```text
+  https://${account.namespace}/samlp
+  /${account.clientId}?RelayState=https://FINAL_DESTINATION_URL
+  ```
+
+Note: it's up to the target application to accept IdP-Initiated flows and use the `RelayState` in a meaningful way if provided.
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/special-configuration-scenarios/index.md b/ja-jp/articles/protocols/saml/saml-configuration/special-configuration-scenarios/index.md
new file mode 100644
index 0000000000..d27d7e9011
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/special-configuration-scenarios/index.md
@@ -0,0 +1,24 @@
+---
+description: Special configuration scenarios when setting up a SAML Integration
+  topics:
+    - saml
+    - sso
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+# Special Configuration Scenarios
+
+Once you've set up a basic SAML Integration, there are a number of additional requirements you might need to implement so that your integration reflects your needs and requirements.
+
+## Prerequisites
+
+This article assumes that you've already set up a [Connection](/protocols/saml/saml-configuration/auth0-as-service-provider) or an [Application](/protocols/saml/saml-configuration/auth0-as-identity-provider).
+
+The instructions below assume that you're altering specific settings for an existing SAML integration, not configuring an integration from scratch.
+
+## Scenarios
+
+* [IdP-Initiated SSO](/protocols/saml/saml-configuration/special-configuration-scenarios/idp-initiated-sso)
+* [Signing and Encrypting SAML Requests](/protocols/saml/saml-configuration/special-configuration-scenarios/signing-and-encrypting-saml-requests)
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/special-configuration-scenarios/signing-and-encrypting-saml-requests.md b/ja-jp/articles/protocols/saml/saml-configuration/special-configuration-scenarios/signing-and-encrypting-saml-requests.md
new file mode 100644
index 0000000000..dc76d7a160
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/special-configuration-scenarios/signing-and-encrypting-saml-requests.md
@@ -0,0 +1,255 @@
+---
+description: Signing and encrypting SAML requests
+  topics:
+    - saml
+    - sso
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Special Configuration Scenarios: Signing and Encrypting SAML Requests
+
+To increase the security of your transactions, you can sign or encrypt both your requests and your responses in the SAML protocol. In this article you'll find configurations for specific scenarios, separated under two use cases:
+
+- Auth0 as the SAML **service provider** (i.e. a SAML **Connection**)
+- Auth0 as the SAML **identity provider** (i.e. an **Application** configured with the **SAML Web App Addon**)
+
+## Auth0 as the SAML Service Provider
+
+These scenarios apply when Auth0 is the SAML Service Provider, i.e. Auth0 connects to a SAML identity provider by creating a SAML connection.
+
+### Sign the SAML Authentication Request
+
+If Auth0 is the SAML **service provider**, you can sign the authentication request Auth0 sends to the IdP as follows:
+
+1. For the Connection in which you're interested, navigate to **Enterprise** -> **SAMLP Identity Provider** -> **Settings**.
+2. Enable the **Sign Request** toggle.
+3. Download the certificate beneath the **Sign Request** toggle and provide it to the IdP so that it can validate the signature.
+
+#### Enable/Disable Deflate Encoding
+
+By default, SAML authentication requests are sent via HTTP-Redirect and use deflate encoding, which puts the signature in a query parameter.
+
+To turn off deflate encoding, you can make a [PATCH call to the Management API's Update a Connection endpoint](/api/management/v2#!/Connections/patch_connections_by_id) and set the `deflate` option to `false`.
+
+::: note
+Updating the `options` object for a connection overrides the whole `options` object. To keep previous connection options, get the existing `options` object and add new key/values to it.
+:::
+
+Endpoint: `https://${account.namespace}/api/v2/connections/YOUR_CONNECTION_ID`
+
+Payload: 
+
+```json
+{
+	{ 
+		"options" : {
+			[...], // all the other connection options
+		  "deflate": false
+	}
+}
+```
+
+### Use a custom certificate to sign requests
+
+By default, Auth0 uses the tenant private key to sign SAML requests (when the **Sign Request** toggle is enabled). You can also provide your own private/public key pair to sign requests coming from a specific connection.
+
+You can generate your own certificate and private key using this command:
+
+```shell
+openssl req -x509 -nodes -sha256 -days 3650 -newkey rsa:2048 -keyout private_key.key -out certificate.crt
+```
+
+Changing the key used to sign requests in the connection can't be done on the Dashboard UI, so you will have to use the [Update a Connection endpoint](/api/management/v2#!/Connections/patch_connections_by_id) from the Management API v2, and add a `signing_key` property to the `options` object, as shown in the payload example below.
+
+::: note
+Updating the `options` object for a connection overrides the whole `options` object. To keep previous connection options, get the existing `options` object and add new key/values to it.
+:::
+
+Endpoint: `https://${account.namespace}/api/v2/connections/YOUR_CONNECTION_ID`
+
+Payload:
+
+```json
+{
+	{ 
+		"options" : {
+			[...], // all the other connection options
+		  "signing_key": {
+				"key":"-----BEGIN PRIVATE KEY-----\n...{your private key here}...\n-----END PRIVATE KEY-----",
+				"cert":"-----BEGIN CERTIFICATE-----\n...{your public key cert here}...\n-----END CERTIFICATE-----"
+			}
+	}
+}
+```
+
+See [Working with private and public keys as strings](#working-with-certificates-as-strings) for details on how to get the private key and certificate formatted as a JSON string to use in the payload.
+
+### Receive Signed SAML Authentication Responses
+
+If Auth0 is the SAML **service provider**, all SAML responses from your identity provider should be signed to indicate it hasn't been tampered with by an unauthorized third-party.
+
+You will need to configure Auth0 to validate the responses' signatures by:
+
+* Obtaining a signing certificate from the IdP
+* Loading the certificate from the IdP into your Auth0 Connection (in the Management Dashboard, go to the **Upload Certificate** section for your Connection by navigating to **Connections** -> **Enterprise** -> **SAMLP Identity Provider** -> **Settings**)
+
+Auth0 can accept a signed response for the assertion, the response, or both.
+
+### Receive Encrypted SAML Authentication Assertions
+
+If Auth0 is the SAML **service provider**, it may need to receive encrypted assertions from an identity provider. To do this, you must provide tenant's public key certificate to the IdP. The IdP encrypts the SAML assertion using the public key and sends it to Auth0, which decrypts it using the tenant's private key.
+
+To retrieve the certificate you need to send to your IdP from the [Management Dashboard](${manage_url}), go to **Connections** -> **Enterprise** -> **SAMLP Identity Provider** and click on the **Setup Instructions** button next to the connection.
+
+Navigate to the section titled **Encrypted Assertions** and download the certificate in the format requested by the IdP.
+
+### Use your own key pair to decrypt encrypted responses
+
+As noted above, Auth0 will by default use your tenant's private/public key pair to handle encryption. You can also provide your own public/private key pair if an advanced scenario requires so.
+
+Changing the key pair used to encrypt and decrypt requests in the connection can't be done on the Dashboard UI, so you will have to use the [Update a Connection endpoint](/api/management/v2#!/Connections/patch_connections_by_id) from the Management API v2, and add a `decryptionKey` property to the `options` object, as shown in the payload example below.
+
+::: note
+Updating the `options` object for a connection overrides the whole `options` object. To keep previous connection options, get the existing `options` object and add new key/values to it.
+:::
+
+Endpoint: `https://${account.namespace}/api/v2/connections/YOUR_CONNECTION_ID`
+
+Payload:
+
+```json
+{
+	{ 
+		"options" : {
+			[...], // all the other connection options
+		  "decryptionKey": {
+				"key":"-----BEGIN PRIVATE KEY-----\n...{your private key here}...\n-----END PRIVATE KEY-----",
+				"cert":"-----BEGIN CERTIFICATE-----\n...{your public key cert here}...\n-----END CERTIFICATE-----"
+			}
+	}
+}
+```
+
+The SAML metadata available for the connection will be updated with the provided certificate, so that the identity provider can pick it up to sign the SAML response. 
+
+## Auth0 as the SAML Identity Provider
+
+This scenarios apply when Auth0 is the SAML Identity Provider for an application. This is represented in the dashboard by an **Application** that has the SAML Web App Addon enabled.
+
+### Sign the SAML Responses/Assertions
+
+If Auth0 is the SAML **identity provider**, it will sign SAML assertions with the tenant's private key and provide the service provider with the public key/certificate necessary to validate the signature.
+
+To retrieve the certificate you need to send to your IdP from the [Management Dashboard](${manage_url}):
+
+1. Go to **Applications** -> **Settings** -> **Show Advanced Settings**.
+2. Scroll to the *Certificates* section, and click **Download Certificate* to obtain the signing certificate you need to provide to your IdP.
+3. Send your certificate to the service provider.
+
+By default, Auth0 signs the SAML **assertion** within the response. If you want to sign the SAML **response** instead, follow this instructions:
+
+1. In the [Management Dashboard](${manage_url}), navigate to **Applications**. Find the Application you're interested in go to **Addons** > SAML2 WEB APP > Settings.
+2. Look for the `"signResponse"` key. Add it or uncommented if required, and set its value to `true` (the default value is `false`). The configuration should look like this:
+
+```json
+{
+  [...], // other settings
+  "signResponse": true
+}
+```
+
+#### Change the signing key for SAML responses
+
+Auth0 will by default use the private/public key pair assigned to your tenant to sign SAML responses or assertions. For very specific scenarios you might wish to provide your own key pair. You can do so with a rule like this:
+
+```javascript
+function (user, context, callback) {
+  // replace with the ID of the application that has the SAML Web App Addon enabled
+	// for which you want to change the signing key pair.
+	var samlIdpClientId = 'YOUR_SAML_APP_CLIENT_ID';
+  // only for a specific client
+  if (context.clientID !== samlIdpClientId) {
+    return callback(null, user, context);
+  }
+
+	// provide your own private key and certificate here  
+  context.samlConfiguration.cert = "-----BEGIN CERTIFICATE-----\nnMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV[..all the other lines..]-----END CERTIFICATE-----\n";
+  context.samlConfiguration.key = "-----BEGIN PRIVATE KEY-----\nnMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV[..all the other lines..]-----END PRIVATE KEY-----\n";
+      
+  callback(null, user, context);
+}
+```
+
+Take a look at [Working with certificates as strings](#working-with-certificates-as-strings) for information on how to turn the private key and certificate files into strings that you can use in a rule.
+
+### Receive Signed SAML Authentication Requests
+
+If Auth0 is the SAML **identity provider**, it can received requests signed with the service provider's private key. Auth0 will then use the service providers' public key/certificate to validate the signature.
+
+To configure signature validation, you'll need to download the service provider's certificate with the public key and store the value in the `signingCert` key of the SAML Web App Addon `options` JSON object. You can find the `options` JSON object field in the [Management Dashboard](${manage_url}) by going to **Applications** > **Addons** > **SAML2 WEB APP** > **Settings**.
+
+The configuration should look like this:
+
+```json
+{
+  [...], // other settings
+  "signingCert": "-----BEGIN CERTIFICATE-----\nMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV\n[..all the other lines..]-----END CERTIFICATE-----\n"
+}
+```
+
+### Send Encrypted SAML Authentication Assertions
+
+If Auth0 is the SAML **identity provider**, you can use [Rules](/rules) to encrypt the SAML assertions it sends.
+
+You'll need to obtain the certificate and the public key from the service provider. If you only got the certificate, you can derive the public key using `openssl`. Assuming that the certificate file is named `certificate.pem` you can do:
+
+```shell
+openssl x509 -in certificate.pem -pubkey -noout > public_key.pem
+```
+
+Once you get the certificate and public key files, you'll need to [turn them into strings](#working-with-certificates-as-strings) to use them in a rule. The rule will look like this:
+
+```js
+function (user, context, callback) {
+  // this rule sets a specific public key to encrypt the SAML assertion generated from Auth0 
+  if (context.clientID === 'THE_CLIENT_ID_OF_THE_APP_WITH_THE_SAML_APP_ADDON') {
+	  context.samlConfiguration = (context.samlConfiguration || {});
+    context.samlConfiguration.encryptionPublicKey = "-----BEGIN PUBLIC KEY-----\nnMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV\n[..all the other lines..]-----END PUBLIC KEY-----\n";
+    context.samlConfiguration.encryptionCert = "-----BEGIN CERTIFICATE-----\nnnMIIC8jCCAdqgAwIBAgIJObB6jmhG0QIEMA0GCSqGSIb3DQEBBQUAMCAxHjAcBgNV\n[..all the other lines..]-----END CERTIFICATE-----\n";
+	}
+  callback(null, user, context);
+}
+```
+
+The following algorithms are used:
+
+* AES256 (`http://www.w3.org/2001/04/xmlenc#aes256-cbc`) for assertion encryption
+* RSA-OAEP (including MGF1 with SHA1, `http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p`) for key transport
+
+## Working with certificates as strings
+
+When working with certificates or keys in rules or Management API v2 requests, you will most likely require a string representation of the file.
+
+If you open a certificate file (`cer`, `pem`) with a text editor, you'll see something like this:
+
+```
+-----BEGIN CERTIFICATE-----
+MIICzDCCAbQCCQDH8GvxPIeH+DANBgkqhkiG9w0BAQsFADAoMQswCQYDVQQGEwJh
+cjEZMBcGA1UEAwwQaHR0cHM6Ly9uaWNvLmNvbTAeFw0xOTA0MDgxODA3NTVaFw0y
+//
+// more lines of base64-encoded information
+//
+nSWyabd+LiBGtLTMB+ZLbOIi3EioWPGw/nHOI8jzPrqhiCLuZCSQmiqrLQYNsc1W
+-----END CERTIFICATE-----
+```
+
+The lines between the `-----BEGIN CERTIFICATE-----` header and `-----END CERTIFICATE-----` footer contain base64-encoded binary information. Public keys and private keys (`.key` files) will look similar, with just a different header/footer.
+
+For a string representation of a certificate/key file, you will need to concatenate everything in one line, with a `\n` (escaped new-line) sequence replacing the actual new lines in the file. So from the above sample you'd obtain something like this:
+
+```
+"-----BEGIN CERTIFICATE-----\nMIICzDCCAbQCCQDH8GvxPIeH+DANBgkqhkiG9w0BAQsFADAoMQswCQYDVQQGEwJh\n[..all the other lines..]-----END CERTIFICATE-----\n"
+```
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/supported-options-and-bindings.md b/ja-jp/articles/protocols/saml/saml-configuration/supported-options-and-bindings.md
new file mode 100644
index 0000000000..64d9449197
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/supported-options-and-bindings.md
@@ -0,0 +1,24 @@
+---
+description: Supported SAML bindings and options
+topics:
+  - saml
+  - saml-bindings
+contentType:
+  - reference
+useCase:
+  - add-idp
+---
+
+# Supported SAML Bindings and Options
+
+Auth0 supports the following SAML bindings:
+
+* HTTP Redirect
+* HTTP POST
+
+Auth0 supports the following SAML options:
+
+* Web Browser SSO Profile
+* Single Logout Profile
+* Name Identifier Management Profile
+* Name Identifier Mapping Profile
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-idp.md b/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-idp.md
new file mode 100644
index 0000000000..39fa5e5c5b
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-idp.md
@@ -0,0 +1,140 @@
+---
+description: How to troubleshoot SAML-related configuration issues when Auth0 is the identity provider
+toc: true
+  topics:
+    - saml
+    - sso
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Troubleshooting SAML when Auth0 is the Identity Provider
+
+When troubleshooting a SAML login, there are four primary stages to check:
+
+* Stage 1: The user is successfully redirected to IDP and is able to login.
+* Stage 2: After login with the IDP, the user returns to Auth0 with a successful login event recorded.
+* Stage 3: After a successful login event in Auth0, the user profile in Auth0 is correct.
+* Stage 4: The user successfully redirects back to application and is able to access application.
+
+The following sections describe how to check each stage and how to identify if there are any issues with a given stage.
+
+## A successful login event does not show up in Auth0 logs
+
+In this case, the user successfully logs in with the idp, but a successful login event does *not* show up in auth0 logs.
+
+* If you're using an Auth0 Database Connection:
+
+  * Check that the user exists and the entered password is correct.
+
+  * Disable your [rules](/rules) temporarily to make sure that nothing is interfering with the login process.
+
+  * If you've enabled multi-factor authentication (MFA), disable it temporarily to make sure that it is not interfering with the login process.
+
+* If you're using an Auth0 Database Connection **or** a remote SAML connection:
+
+  * Check that the SAML Connection works by [using **Try** to run a Connection test](#issue-the-idp-login-page-doesn-t-display).
+
+## The user's profile attributes are incorrect
+
+In this case, the user successfully logs in with the idp, a successful login event shows up in auth0 logs, but the user's profile attributes are incorrect.
+
+If the user:
+
+* Appears to log in successfully
+
+* The [Logs](${manage_url}/#/logs) and [Users](${manage_url}/#/users) pages in the Auth0 Dashboard should successful login events
+
+The next step is to check that the user's profile contains the necessary user profile attributes.
+
+### Checking the user profile
+
+1. After logging in to the [Auth0 Dashboard, navigate to *Users*](${manage_url}/#/users).
+
+2. Find and click on the specific user to open up their profile. If there are multiple rows for a given user, be sure to open up the record associated with the SAML Connection.
+
+3. On the user's profile, you can view their details in one of two ways. You can use the *Details* tab or the *Raw JSON* tab. This shows you what attributes Auth0 has received from the identity provider.
+
+If an attribute is missing, check with the identity provider to confirm that it has the attribute and that it is returning that attribute to Auth0.
+
+## The user cannot access the application
+
+In this case, the user successfully logs in with the idp, a successful login event shows up in auth0 logs, and the user's profile attributes are correct, but the user cannot access the application.
+
+* Check to see if the user's Auth0 profile populated correctly:
+
+  1. After logging in to the [Auth0 Dashboard, navigate to *Users*](${manage_url}/#/users).
+
+  2. Find and click on the specific user to open up their profile. If there are multiple rows for a given user, be sure to open up the record associated with the SAML Connection.
+
+  3. On the user's profile, you can view their details in one of two ways. You can use the *Details* tab or the *Raw JSON* tab. This shows you what attributes Auth0 has received from the identity provider. Ensure that the profile includes all of the details required by the application.
+
+  If a user attribute is missing, check with the identity provider to confirm that it has the attribute and that it is returning that attribute to Auth0.
+
+* Check the application's log files to see if there are any error messages indicating why the user is unable to access the application. The two most common causes for this issue are missing user profile information or incorrect/missing authorization information.
+
+* Check the information that Auth0 sends to the application by [capturing an HTTP trace of the login sequence](/troubleshoot/guides/generate-har-files). To analyze the HTTP trace:
+
+  1. View the trace in a HAR file analyzer, such as [Google's HAR Analyzer](https://toolbox.googleapps.com/apps/har_analyzer/).
+
+  2. Scan through the sequence of URLS invoked in the HTTP trace:
+
+    * The first few will be URLs for your application.
+
+    * There will then by a redirect to an Auth0 URL (such as `${account.namespace}`).
+
+    * After one or more intervening URLS, there will be a POST back to your application containing the SAML assertion with user information. The URL should be for the Assertion Consumer Service (ACS) of your application, which consumes the assertion and extracts the needed information. Be sure that the assertion includes this information:
+
+      1. Click on the row for the POST call in the HAR analyzer.
+
+      2. Switch to the POST Data tab, and look for the SAML response.
+
+      3. Copy and paste the SAML response into a [SAML debugger](https://samltool.io/).
+
+      4. Remove the SAML response at the beginning, as well as anything beginning with `&RelayState=` at the end.
+
+      5. Click **Decode SAML message** and check the following fields:
+
+        * **Destination**: the application URL that consumes the SAML assertion (and is also known as the Assertion Callback URL)
+
+        * **Status Field**: this field should indicate success: ``
+
+        * **Recipient**: the correct URL appears in the recipient field (indicated by th `urn:{DOMAIN}:{YOUR APPLICATION}`
+
+        * **Naming**: the attribute identified by the `NameIdentifier` field should be known to the application. If it's not, the identifier should be some other attribute within the assertion (such as an internal IdP identifier for the user or an email address)
+
+        * **Signature Key**: check that the value indicated by the `X509Certificate` element matches the value provided to your connection
+
+        * **Certificate**: compare the certificate sent to the one that you provided to the application
+
+* Ensure that the SAML assertion contains any additional information required by the application and that the information is present in the attributes expected by the application.
+
+  * If you need to alter the assertion sent from Auth0 to your application, you can add or map attributes using [rules](/rules).
+
+    * Log into Auth0 and [navigate to Rules](${manage_url}/#/rules).
+
+    * Click **Create Rule** and, in the next page, choose the **Change your SAML configuration** template.
+
+    * In the rules editor, uncomment the lines you want to use. Lines 9-17 in the template can be used to map attributes as needed. You can also add lines to implement mappings.  The left side of each line specifies the identifier for the attribute in the assertion. The right side of each line references the Auth0 user profile attribute whose value will be used to populate the outgoing assertion sent to the application.
+
+    ```text
+    //context.samlConfiguration.mappings = {
+    //   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier":      "user_id",
+    //   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress":        "email",
+    //   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name":                "name",
+    //   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname":           "given_name",
+    //   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname":             "family_name",
+    //   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn":                 "upn",
+    //   "http://schemas.xmlsoap.org/claims/Group":                                   "groups"
+    // };
+    ```
+
+    ![](/media/articles/protocols/saml/saml-configuration/saml-rules.png)
+
+## When I try to logout I get the error: No active session(s) found matching LogoutRequest
+
+The `SessionIndex` and `NameID` values in the SAML Logout request need to match the ones received by the service provider in the original SAML assertion.
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-sp.md b/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-sp.md
new file mode 100644
index 0000000000..b80302d710
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/auth0-as-sp.md
@@ -0,0 +1,212 @@
+---
+description: How to troubleshoot SAML-related configuration issues when Auth0 is the service provider
+toc: true
+topics:
+  - saml
+  - sso
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Troubleshooting SAML when Auth0 is the Service Provider
+
+When troubleshooting a SAML login, there are four primary stages to check:
+
+* Stage 1: The user is successfully redirected to an identity provider (IdP) and is able to login.
+* Stage 2: After login with the IdP, the user returns to Auth0 with a successful login event recorded.
+* Stage 3: After a successful login event in Auth0, the user profile in Auth0 is correct.
+* Stage 4: The user successfully redirects back to application and is able to access application.
+
+The following sections describe how to check each stage and how to identify if there are any issues with a given stage.
+
+## Issue: The IdP Login Page Doesn't Display
+
+### Test the Connection
+
+Navigate to [Connections -> Enterprise](${manage_url}/#/connections/enterprise). Open up the list of **SAMLP Identity Providers**, and click **Try** (represented by the triangle icon) next to the Connection to test the interaction between Auth0 and the remote IdP.
+
+If the Connection does **not** work, continue with the steps detailed in this section. If it does, [proceed to the next section](#).
+
+  ![](/media/articles/protocols/saml/saml-configuration/test-connection.png)
+
+### Check the Connection's Settings
+
+Navigate to [Connections -> Enterprise](${manage_url}/#/connections/enterprise). Open up the list of **SAMLP Identity Providers**, and click **Settings** (represented by the gear icon) to launch the tab associated with your Connection.
+
+  ![](/media/articles/protocols/saml/saml-configuration/check-connection-settings.png)
+
+Check and confirm the following with the IdP administrator:
+
+* That the Sign In URL is the correct Single Sign-on (SSO) URL. This is the URL that Auth0 will redirect the user to for authentication.
+* If the IdP expects HTTP-POST binding or HTTP-Redirect binding. You can switch the default binding in the __Settings__ tab.
+* If your authentication requests should be signed. If so, which signing algorithm does the IdP expect you to use? (Note that authentication requests are not commonly signed.) If you're sending signed requests, enable the Connection Settings **Sign Request** toggle and make sure the **Signing Algorithm** value matches what the IdP expects.
+* Ask the IdP administrator to check for log entries that might provide information on the problem.
+
+## Issue: Auth0 Logs Don't Show Successful Login Event
+
+In this case, the user successfully logs in with the identity provider, but the Auth0 logs do not show a successful login event. You can check the [Logs](${manage_url}/#/logs) and [Users](${manage_url}/#/users) pages in the Auth0 Dashboard to see if Auth0 shows a successful login event.
+
+If Auth0's logs don't show a successful login event, there is probably an issue with the SAML Authentication Assertion returned by the IdP or Auth0 is unable to consume the assertion.
+
+### Check the SAML Authentication Assertion
+
+Check the information that Auth0 sends to the application by [capturing an HTTP trace of the login sequence](/troubleshoot/guides/generate-har-files) and analyzing the HTTP trace.
+
+#### Retrieve the Assertion
+
+You can view the HTTP trace in a HAR file analyzer, such as [Google's HAR Analyzer](https://toolbox.googleapps.com/apps/har_analyzer/).
+
+1. First, scan through the sequence of URLs invoked in the HTTP trace.
+    * The first few will be URLs for your application.
+    * There will then be a redirect to an Auth0 URL (such as `${account.namespace}`).
+2. After one or more intervening URLs, there will be a POST back to Auth0 containing the SAML assertion with user information. The URL should be for the Assertion Consumer Service (ACS) of Auth0, which consumes the assertion and extracts the needed information.
+3. Click on the row for the POST call in the HAR analyzer.
+4. Switch to the POST Data tab, and look for the SAML response.
+5. Copy and paste the SAML response into a [SAML debugger](https://samltool.io/).
+6. Remove the "SAML response" at the beginning, as well as anything beginning with `&RelayState=` at the end.
+
+#### Check the Assertion
+
+After retrieving and decoding the SAML message, check the following fields:
+
+Field | Description
+------|-------------
+Destination | Check that the destination for the SAML response is the correct Auth0 Tenant and Connection (`https://{TENANT}.auth0.com/login/callback?connection={CONNECTION}`).
+Status Field | This field should indicate success. (``).
+Recipient | Check that the `urn:auth0:{TENANT}:{CONNECTION}`).
+Naming | The attribute identified by the `NameIdentifier` field should be known to the application. If it's not, the identifier should be some other attribute within the assertion (such as an internal IdP identifier for the user or an email address).
+Signature Key | Check that the value indicated by the `X509Certificate` element matches the value provided to your connection.
+Certificate | Compare the certificate sent to the one that you provided to the application
+
+## Issue: The User's Profile Attributes are Incorrect
+
+In this case the user successfully logs in with the IdP, the Auth0 logs show a successful login event, but the user's profile attributes are __not__ correct
+
+Check to see if the user's Auth0 profile populated correctly:
+
+  1. After logging in to the [Auth0 Dashboard, navigate to *Users*](${manage_url}/#/users).
+
+  2. Find and click on the specific user to open up their profile. If there are multiple rows for a given user, be sure to open up the record associated with the SAML Connection.
+
+  3. On the user's profile, you can view their details in one of two ways. You can use the *Details* tab or the *Raw JSON* tab. This shows you what attributes Auth0 has received from the identity provider.
+
+### If the User Profile Attribute is Missing
+
+If the attribute is missing, check to see if the attribute was included in the assertion. You can do this by [decoding the SAML assertion](#), or you can enable debugging for the connection.
+
+To enable debugging for the connection, navigate to [Connections -> Enterprise](${manage_url}/#/connections/enterprise). Open up the list of **SAMLP Identity Providers**, click on **Settings**, and enable **Debug Mode**.
+
+![](/media/articles/protocols/saml/saml-configuration/debug-connection.png)
+
+With **Debug Mode** enabled, **Success Login** log entries [in the dashboard](${manage_url}/#/logs) will have an `original_profile` property listing every attribute included in the SAML assertion by the Identity Provider. You can use this list to see the information that the IdP is sending and to help you create the mappings. If the missing attribute is not in the assertion at all, please work with the IdP to make sure it is included.
+
+### If the User Profile Attribute is Incorrectly Mapped
+
+If an attribute value exists in the Auth0 user profile, but is not mapped to the right attribute, you can correct this via the Connection Mapping capability.
+
+You can do this by navigating to [Connections -> Enterprise](${manage_url}/#/connections/enterprise). Open up the list of **SAMLP Identity Providers**, click on **Settings**, and switching over to the **Mappings** tab.
+
+![](/media/articles/protocols/saml/saml-configuration/mappings.png)
+
+Within the provided editor, there is a JSON snippet you can edit to configure your mappings. The name on the left is the Auth0 user profile attribute to which the assertion value will be mapped. The value on the right is the identifier in the SAML assertion from which the attribute comes.
+
+::: warning
+When Auth0 incorporates unmapped SAML attributes into the user profile, attribute identifiers containing dots `.` are replaced with semicolons `:`. While configuring your mappings, ensure the identifiers you provide match those in the SAML assertion.
+:::
+
+## Issue: The User Cannot Access the Application
+
+In this case the user successfully logs in with the identity provider, Auth0 logs show a successful login event, and the user's profile attributes are correct; but the user __cannot__ access the application.
+
+### Check the Application Logs
+
+Check your application's log files to see if there are any error messages indicating why the user is unable to access the application.
+
+The two most common causes for this issue are:
+
+* Missing user profile information
+* Incorrect or missing authorization information.
+
+### Check the SAML Assertion
+
+Check the information that Auth0 sends to the application by [capturing an HTTP trace of the login sequence](/troubleshoot/guides/generate-har-files) and analyzing the HTTP trace.
+
+#### Retrieve the Assertion
+
+You can view the HTTP trace in a HAR file analyzer, such as [Google's HAR Analyzer](https://toolbox.googleapps.com/apps/har_analyzer/).
+
+1. First, scan through the sequence of URLs invoked in the HTTP trace.
+    * The first few will be URLs for your application.
+    * There will then be a redirect to an Auth0 URL (such as `${account.namespace}`).
+2. After one or more intervening URLs, there will be a POST back to your application containing the SAML assertion with user information. The URL should be for the Assertion Consumer Service (ACS) of your application, which consumes the assertion and extracts the needed information.
+3. Click on the row for the POST call in the HAR analyzer.
+4. Switch to the POST Data tab, and look for the SAML response.
+5. Copy and paste the SAML response into a [SAML debugger](https://samltool.io/).
+6. Remove the "SAML response" at the beginning, as well as anything beginning with `&RelayState=` at the end.
+
+#### Check the Assertion
+
+After retrieving and decoding the SAML message, check the following fields:
+
+Field | Description
+------|-------------
+Destination | The application URL that consumes the SAML assertion, also known as the Assertion Callback URL.
+Status Field | This field should indicate success. (``).
+Recipient | Check that the correct URL appears in the recipient field (indicated by the `urn:auth0:{TENANT}:{CONNECTION}`).
+Naming | The attribute identified by the `NameIdentifier` field should be known to the application. If it's not, the identifier should be some other attribute within the assertion (such as an internal IdP identifier for the user or an email address).
+Signature Key | Check that the value indicated by the `X509Certificate` element matches the value provided to your connection.
+Certificate | Compare the certificate sent to the one that you provided to the application.
+
+### Check the ID Token
+
+If your authorization flow uses an OIDC-conformant protocol, you can [capture a HAR trace](/troubleshoot/guides/generate-har-files) and view it using [Google's HAR Analyzer](https://toolbox.googleapps.com/apps/har_analyzer/).
+
+1. Scan through the sequence of URLs in the trace, and look for the following:
+
+    * The first few will be URLs for your application.
+
+    * There will then by a redirect to an Auth0 URL (such as `${account.namespace}`).
+
+2. Further down is your application's callback URL. Make sure that it's correct.
+
+3. Retrieve the ID Token from this call, and paste it into [a JWT decoder](https://jwt.io/). Check that the claims in the token contain the information needed by the application.
+
+### Troubleshooting IdP-initiated Flows
+
+If you're using an IdP-initiated flow (for example, the user starts at the identity provider in a portal application), be sure that:
+
+* The  Assertion Consumer Service (ACS) URL at the identity provider includes the connection name (for example `https://${account.namespace}/login/callback?connection=CONNECTION_NAME`)
+
+* The IdP-initiated configuration tab for the Connection is properly filled in, including:
+
+  * The application to which the user should be sent;
+
+  * The protocol between the application and Auth0 (which is not necessarily **SAML** like the connection, and most likely is **OpenID Connect**);
+
+  * Any protocol-specific values to include in the query string, such as `scope`, `response_type`, `redirect_uri`, and `audience`. These values should match the ones expected by the application when using a SP-initiated flow.
+
+* Disable your [rules](/rules) temporarily to make sure that nothing is interfering with the login process.
+
+* If you've enabled multi-factor authentication (MFA), disable it temporarily to make sure that it is not interfering with the login process.
+
+* Check that the SAML Connection works in an SP-Initiated flow by [using **Try** to run a Connection test](#issue-the-idp-login-page-doesn-t-display).
+
+## Error: The request could not be performed due to an error on the part of the SAML responder or SAML authority
+
+The error may appear as follows:
+
+```text
+
+
+
+```
+
+### How to Fix
+
+Make sure that the signature algorithm on your Auth0 connection is the same as the configuration on the ADFS side: either `rsa-sha256` or `rsa-sha1`. Alternatively you can contact your ADFS administrator to learn the expected signing method or to see if their logs contain further information about the reason for the error.
+
+![ADFS SAML Properties](/media/articles/protocols/saml-adfs/adfs-saml-properties.png)
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/common-saml-errors.md b/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/common-saml-errors.md
new file mode 100644
index 0000000000..6f438059d8
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/common-saml-errors.md
@@ -0,0 +1,102 @@
+---
+description: Common SAML errors and troubleshooting steps
+topics:
+  - saml
+  - sso
+  - errors
+contentType:
+  - reference
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Common SAML Errors
+
+This article covers SAML errors you might encounter when Auth0 acts as the service provider and the steps you should take to resolve them.
+
+## Error: The Connection was Disabled
+
+```json
+{
+  "error": "invalid_request",
+  "error_description": "the connection was disabled"
+}
+```
+
+This message indicates that the Application doesn't have an active Connection associated.
+
+### How to Fix
+
+1. Navigate to [Connections > Enterprise](${manage_url}/#/connections/enterprise).
+2. Find your Connection, and click on **Settings**.
+3. Switch to the *Applications* tab.
+4. Enable at least one Application (if you don't see any in the list, you will need to [create an application](/applications) before proceeding).
+
+## Error: IdP-Initiated Default App Not Configured
+
+```json
+{
+  "invalid_request": "Default App for IdP-Initiated is not configured. Make sure to configure that from connection settings or include client_id in RelayState parameter."
+}
+```
+
+This error typically occurs because the ACS URL configured in the IdP used the default Auth0 tenant domain, whereas the authentication transaction was started by calling the custom domain `/authorize` endpoint.
+
+The ACS URL should use the same domain as the initial authentication request. If using custom domains, this should use the custom domain callback URL.
+
+### How to Fix
+
+1. Navigate to [Connections > Enterprise](${manage_url}/#/connections/enterprise).
+2. Find your Connection, and click on **Settings**.
+3. Switch to the **IdP-Initiated** tab.
+4. Select the **Default Application** and the **Response Protocol** used by that Application, and (optionally) specify any additional parameters you want passed to the Application.
+
+::: panel SP-Initiated Login
+If you see this error when using a SP-initiated flow, one of the following is missing or empty:
+
+* The `RelayState` parameter
+* The `InResponseTo` attribute in the SAML response
+
+If these are missing or empty, Auth0 treats the login as IdP-initiated. You can fix this error by checking your configuration to ensure that both fields are populated and returned appropriately.
+:::
+
+## Error: Missing RelayState
+
+This error occurs when the identity provider doesn't return the `RelayState` parameter along with its response.
+
+### How to Fix
+
+Work with the identity provider to ensure that it returns the `RelayState` parameter.
+
+## Error: Audience is Invalid
+
+This error occurs if the value of the `audience` element from the identity provider's SAML response doesn't match the value expected by Auth0. Auth0 expects the value to be the Entity ID for the Connection.
+
+**Find Your Connection's Entity ID**
+
+1. Navigate to [Connections > Enterprise](${manage_url}/#/connections/enterprise). Find your Connection, and click on **Setup Instructions**.
+2. Under the *Common Settings* section, your **Entity ID** is the second parameter provided.
+
+### How to Fix
+
+Make sure that the identity provider sends the correct `audience` value in the SAML response.
+
+## Error: Specifying the Incorrect Protocol
+
+One common error is specifying the incorrect response protocol on the IdP-Initiated tab. The response protocol is the one used between Auth0 and the Application (not the remote identity provider). For example, if you set this value to **SAML** when your Application expects **OpenID Connect** or **WS-Fed** results in errors due to the incorrect configuration.
+
+### How to Fix
+
+1. Navigate to [Connections > Enterprise](${manage_url}/#/connections/enterprise).
+2. Find your Connection, and click on **Settings**.
+3. Switch to the *IdP-Initiated* tab.
+4. Check the value you have set in the **Response Protocol** field.
+
+## Issue: User isn't logged out from the IdP
+
+When ADFS is configured as SAML IdP, if the ADFS is relaying party trust `Name ID` attribute isn't mapped the logout flow fails. For example, with the federated parameter `v2/logout?federated&...` user isn't redirected to the ADFS SAML logout endpoint but redirects back to application callback URL directly. As a consequence, the user isn't logged out from the IdP in that case.
+
+### How to Fix
+
+Add the `Name ID` attribute as a rule on the SAML Relaying Party Trust. 
diff --git a/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/index.md b/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/index.md
new file mode 100644
index 0000000000..044c1a5c7c
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-configuration/troubleshoot/index.md
@@ -0,0 +1,88 @@
+---
+description: Describes troubleshooting for SAML configuration issues.
+toc: true
+topics:
+  - saml
+  - sso
+contentType:
+  - index
+  - reference
+useCase:
+  - add-idp
+---
+
+# Troubleshoot SAML Configuration
+
+This guide serves to help you troubleshoot any issues that may arise during the SAML configuration process. It is not intended to be an exhaustive guide, but one that covers the most commonly encountered issues during setup.
+
+## Understand the Situation
+
+When troubleshooting, it's important that all parties involved are using the same terminology to facilitate understanding. This section describes key vocabulary and situations that will be referred to later in this guide.
+
+* **Is Auth0 serving as the SAML Service Provider (SP), the SAML Identity Provider (IdP), or both?**
+
+  Generally speaking, the SP redirects users elsewhere for authentication. The IdP authenticates the user by prompting them to login and validating the information provided. If your application redirects the user to Auth0 for authentication via SAML, then Auth0 is the IdP. If Auth0 redirects users via a Connection to a remote IdP via SAML, then Auth0 is the SP to the remote IdP.
+
+  Auth0 can act as the SP, IdP, or both.
+
+* **Does your authentication flow use an SP-initiated model, an IdP-initiated model, or both?**
+
+  SP-initiated authentication flows begin with the user navigating to the SP application and getting redirected to the IdP for login. An IdP-initiated flow means the user navigates to the IdP, logs in, and then gets redirected to the SP application.
+
+  Within enterprise settings, the IdP-initiated flow is most common.
+
+* **Which user profile attribute identifies the user at the IdP (during login) and within each application?**
+
+  If the naming attribute differs between the IdP and the application(s), you'll need to configure the appropriate mappings within Auth0 so that it sends the correct user profile attributes to the application(s).
+
+  * From our experience, using the email address as the unique identifier is the easiest option, though there are privacy concerns with this option.
+  * Enterprise organizations often use an internal ID of some type with the IdP, which needs to be mapped to another attribute meaningful to outsourced SaaS applications.
+
+* **Are your authentication requests signed?**
+* **Are your authentication assertions encrypted?**
+
+## Information Gathering
+
+When troubleshooting, we recommend beginning by gathering information that helps answer the following questions:
+
+1. How many users experience the issue? Just one user? All users?
+2. Is this an issue with a new setup, or is this an existing integration that's stopped working?
+3. How many applications does the issue affect?
+4. What is the expected behavior? What is the behavior you're seeing?
+5. How far through the login sequence does the user get?
+
+## Troubleshooting approaches
+
+* [Troubleshooting SAML when Auth0 is the Service Provider](/protocols/saml/saml-configuration/troubleshoot/auth0-as-sp)
+* [Troubleshooting SAML when Auth0 is the Identity Provider](/protocols/saml/saml-configuration/troubleshoot/auth0-as-idp)
+
+## If the Issue Affects Only One (or Just a Few) Users
+
+* Check the user's profile, browser, or device for any issues.
+* Check to see if it happens in all browsers for the affected users (indicating a data issue) or just certain types of browsers (indicating a browser-specific issue).
+* Check to see if the browser has enabled JavaScript and cookies.
+* Check that the caps lock key is disabled.
+* If the user is using a mobile device, check to see if there's any software that might impact authentication and/or authorization (such as not running some type of required software).
+* Check to see if the user can access some of the app's key URLs, such as the IdP's Single Sign-on (SSO) URL (indicating a network connectivity issue).
+
+## Next Steps
+
+If the troubleshooting steps listed above don't solve the issue you're seeing, please request assistance from Auth0 by opening up a ticket in the Support Center. Be sure to include the following information:
+
+1. The number of users experiencing this issue. One? All?
+2. Whether this issue involves a new setup or if it involves an existing integration that suddenly stopped working
+3. The number of applications affected
+4. What the expected behavior is, as well as what the current behavior is
+5. How far through the login sequence the user gets
+6. The name of the application registered in Auth0 and the identity protocol it uses
+7. The name of the Connection involved
+8. Whether or not you're using the Auth0 Lock widget (if so, what version?)
+9. Is a customized version of Lock used?
+10. An HTTP trace of the SSO interaction in [a .har file](/troubleshoot/guides/generate-har-files)
+11. An Auth0 log entry for the failed authentication
+12. An authentication log file from any third-party applications (such as Sharepoint) involved
+
+### Keep reading
+
+* [Common SAML Errors](/protocols/saml/saml-configuration/troubleshoot/common-saml-errors)
+
diff --git a/ja-jp/articles/protocols/saml/saml-idp-eloqua.md b/ja-jp/articles/protocols/saml/saml-idp-eloqua.md
new file mode 100644
index 0000000000..89817dd1d3
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-idp-eloqua.md
@@ -0,0 +1,103 @@
+---
+description: How to configure Auth0 to serve as an Identity Provider for Oracle Eloqua.
+topics:
+  - saml
+  - oracle
+  - eloqua
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Configure Auth0 as Identity Provider for Oracle Eloqua
+
+These instructions explain how to configure Auth0 to serve as an Identity Provider for [Oracle Eloqua Marketing Cloud](http://www.oracle.com/partners/en/products/applications/eloqua-marketing-cloud-service/get-started/index.html).
+
+## Configure the Addon: SAML2 Web App
+
+Login to [Auth0 dashboard](${manage_url}) and create a new [Application](${manage_url}/#/applications).
+
+Navigate to the [Addons](${manage_url}/#/applications/${account.clientId}/addons) tab and enable the **SAML2 Web App** using the toggle switch.
+
+![Application Addons](/media/articles/protocols/saml/eloqua/client-addons.png)
+
+The *Settings* window will be displayed. Set the following values:
+
+- **Application Callback URL**: `https://login.eloqua.com/auth/saml2/acs`
+
+- **Settings**:
+
+  ```text
+  {
+    "audience": "http://foo",
+    "recipient": "https://login.eloqua.com/auth/saml2/acs",
+    "mappings": {
+      "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+      "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",  
+      "name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
+      "given_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",  
+      "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
+      "upn": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
+      "groups": "http://schemas.xmlsoap.org/claims/Group"
+    },
+    "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress",
+    "nameIdentifierProbes": [
+      "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
+    ],
+    "destination": "https://login.eloqua.com/auth/saml2/acs"
+  }
+
+  ```
+
+Note that the `audience` is set to `http://foo`. This will be changed when the Identity Provider settings are completed on the Eloqua side.
+
+Click **Save**.
+
+Go to the *Usage* tab and download the Identity Provider metadata. This IDP metadata will be used while setting up the configuration in Eloqua.
+
+![Download Identity Provider Metadata](/media/articles/protocols/saml/eloqua/download-idp-metadata.png)
+
+## Configure Oracle Eloqua
+
+Login as Admin on Eloqua and click on *Settings > Users > Single Sign-On > Identity Provider Settings*.
+
+Click **Upload Identity Provider from Metadata**. You should upload here the Identity Provider metadata you downloaded in the previous from the Auth0 dashboard.
+
+![Upload Identity Provider Metadata](/media/articles/protocols/saml/eloqua/upload-idp-metadata-1.png)
+
+Browse to find the downloaded metadata file.
+
+![Upload Identity Provider Metadata](/media/articles/protocols/saml/eloqua/upload-idp-metadata-2.png)
+
+Edit the newly added identity provider and complete the following steps:
+
+- Set the **User Identity Mapping** to `Assertion contains the Email Address from the User object` and click **Save**.
+
+- From the *Identity Provider Details* copy the **Service Provider Entity URL**.
+
+- Within ELOQUA IDP settings, if this is the default IDP, mark this IDP as default.
+
+
+## Update the Audience Restriction
+
+We will now use the **Service Provider Entity URL** copied from within the IDP settings in Eloqua to set the `audience` restriction within Auth0.
+
+Navigate to __Dashboard > Applications > select your application > Addons > SAML2 Web App > Settings__ and set the `audience` to the value you copied.
+
+## Test
+
+Login to Eloqua with Auth0 should be enabled now. You can sign in to Eloqua with both IDP initiated login and SP initiated login.
+
+### SP Initiated Login
+
+Navigate to [https://login.eloqua.com/auth/saml2](https://login.eloqua.com/auth/saml2) , enter your company name and start the SAML login process with Auth0.
+
+![Eloqua SP Initiated Login](/media/articles/protocols/saml/eloqua/sp-login.png)
+
+
+### IdP Initiated Login
+
+For IDP Initiated login use the **Identity Provider Login URL** defined under the **Dashboard > Applications > select your application > Addons > SAML 2 Web App > Usage**.
+
+![Eloqua IdP Initiated Login](/media/articles/protocols/saml/eloqua/idp-login.png)
diff --git a/ja-jp/articles/protocols/saml/saml-idp-generic.md b/ja-jp/articles/protocols/saml/saml-idp-generic.md
new file mode 100644
index 0000000000..5c5576a8e3
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-idp-generic.md
@@ -0,0 +1,80 @@
+---
+title: Auth0 as Identity Provider
+description: How to configure Auth0 to serve as an Identity Provider in a SAML federation.
+toc: true
+topics:
+  - saml
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+# Auth0 as Identity Provider
+
+These instructions explain how to configure Auth0 to serve as an Identity Provider in a SAML federation.
+
+## 1. Obtain Information from the Service Provider
+
+You will need to obtain from the Service Provider (application) the URL to which the SAML Authentication Assertion should be sent. This may be called **Assertion Consumer Service URL**, **the Post-back URL**, or **Callback URL**.
+
+## 2. Configure Auth0 as IDP
+
+In this section you will configure Auth0 to serve as an Identity Provider. You will do this by registering an application and using an addon.
+
+1. Go to [Dashboard > Applications](${manage_url}/#/applications).
+1. Click the **+ CREATE APPLICATION** button on the right.
+1. In the **Name** field, enter a name like `MySAMLApp`, and select the [application type](/applications).
+1. Click **SAVE**.
+1. Go back to [Dashboard > Applications](${manage_url}/#/applications).
+1. Find the row for the application you just created, and click on the **Settings** icon to the right of the application name. (the round gear icon)
+1. Scroll down and click on the **Advanced Settings** link.
+1. In the expanded window, select the **Certificates** tab and click on the **DOWNLOAD CERTIFICATE** button.  In the popup which appears, select `PEM` to select a PEM-formatted certificate.  The certificate will be downloaded to a file called `${account.tenant}.pem`.  Save this file as you will need to upload it when you configure the Service Provider.
+    ![Download Certificate](/media/articles/saml/saml-idp-generic/saml-idp-generic1.png)
+1. Select the **Endpoints** tab and scroll down to **SAML**.  Copy the contents of the **SAML Protocol URL** field and save it as you will need to provide it to the Service Provider.
+    ![SAML Protocol URL](/media/articles/saml/saml-idp-generic/saml-idp-generic2.png)
+1. Scroll back up and click on the **Addons** tab.  Then click on **SAML2 WEB APP**.
+    ![SAML2 WEB APP](/media/articles/saml/saml-idp-generic/saml-idp-generic3.png)
+1. In the **Application Callback URL** field, enter the URL of the Service Provider (or application) to which the SAML assertions should be sent after Auth0 has authenticated the user. This is the Assertion Consumer Service (ACS) URL. If your Service Provider is sending multiple ACS URLs in the SAML Request, you will need to whitelist them by adding them to the Application's **Allowed Callback URLs** setting in Application Settings.
+    ![Application Callback URL](/media/articles/saml/saml-idp-generic/saml-idp-generic4.png)
+1.  In the Addon SAML2 Web App popup, click on the **Usage** tab.  This tab will provide you with the information needed to configure the Service Provider application.
+    ![Usage](/media/articles/saml/saml-idp-generic/saml-idp-generic5.png)
+
+## 3. Configure the Service Provider
+
+In this section you will add some information to the Service Provider so they know how to send SAML-based authentication requests to Auth0. 
+
+The instructions provided here are generic. You will need to find the appropriate screens and fields on the Service Provider.
+
+If the Service Provider supports uploading a metadata file, you can simply provide the metadata URL obtained in the step above (**Applications > Addons > Usage**).
+
+If the Service Provider does not support uploading a metadata file, you can configure it manually, using the information from the Auth0 **Applications > Addons > Usage** screen as follows:
+
+- **Identity Provider Login URL**: This is the URL to which the Service Provider should send its SAML Authentication Requests.
+
+Note that if you have [custom domains](/custom-domains) set up, you should use the custom domain based URL rather than your Auth0 domain. So, instead of using a URL in the format of `https://[YOUR TENANT].auth0.com/samlp/CLIENTID?connection=Username-Password-Authentication` you will want to use one in this format: `https://[YOUR CUSTOM DOMAIN]/samlp/CLIENTID?connection=Username-Password-Authentication`.
+
+If the Service Provider also has a field for a Logout URL, you can enter the same **Identity Provider Login URL**. Both login and logout are handled by the same URL.
+
+The Service Provider will need a certificate from Auth0. 
+
+You can download this certificate from the **Applications > Addons > Usage** screen. This certificate will be used to validate the signature of the SAML Authentication Assertions sent from Auth0 to the Service Provider.
+
+If the Service Provider asks for an Issuer, this can also be obtained from the same screen.
+
+## 4. Test
+
+Once you have completed the above configuration, test the login.
+
+If the Service Provider has been configured correctly, it should redirect the user browser to Auth0 for login. After authenticating the user, Auth0 should redirect the user browser back to the application.
+
+## 5. Troubleshooting
+
+This section has a few ideas for things to check if your sample doesn't work.
+
+- If your application doesn't work the first time, you should clear your browser history and ideally cookies each time before you test again. Otherwise, the browser may not be picking up the latest version of your html page or it may have stale cookies that impact execution.
+
+- When troubleshooting Single Sign-on (SSO), it is often helpful to capture an HTTP trace of the interaction. There are many tools that will capture the HTTP traffic from your browser for analysis.  Search for `HTTP Trace` to find some. Once you have an http trace tool, capture the login sequence from start to finish and analyze the trace to see the sequence of GETs to see how far in the expected sequence you get. You should see a redirect from the Service Provider to the Identity Provider, a post of credentials if you had to log in, and then a redirect back to the callback URL or the Service Provider application.
+
+- Make sure cookies and javascript are enabled for your browser.
+
+- The [http://samltool.io](http://samltool.io) tool can decode a SAML assertion and is a useful debugging tool.
diff --git a/ja-jp/articles/protocols/saml/saml-sp-generic.md b/ja-jp/articles/protocols/saml/saml-sp-generic.md
new file mode 100644
index 0000000000..2a110ab059
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml-sp-generic.md
@@ -0,0 +1,180 @@
+---
+description: How to configure Auth0 to serve as a Service Provider in a SAML federation.
+toc: true
+topics:
+  - saml
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Auth0 as Service Provider
+
+These instructions explain how to configure Auth0 to serve as a Service Provider in a SAML federation.
+
+There are **5 sections**, including a troubleshooting section at the end.
+
+1. Obtain information from IDP
+2. Configure Auth0 as Service Provider
+3. Add your Service Provider metadata to the Identity Provider
+4. Test the connection from Service Provider to Identity Provider
+5. Troubleshooting
+
+## 1. Obtain information from IDP
+
+You will need to obtain some information from the Identity Provider.  The instructions here will be generic.  You will have to locate this information in your specific Identity Provider.
+
+* **SSO URL** - The URL at the Identity Provider to which SAML authentication requests should be sent. This is often called a Single Sign-on (SSO) URL.
+* **Logout URL** - The URL at the Identity Provider to which SAML logout requests should be sent.  This is often called a logout URL, a global logout URL or single logout URL.
+* **Signing certificate** - The Identity Provider will digitally sign authentication assertions and the signing certificate is needed by the Service Provider to validate the signature of the signed assertions. There should be a place to download the signing certificate from the Identity Provider. If the certificate is not in .pem or .cer format, you should convert it to one of those formats.
+
+## 2. Configure Auth0 as Service Provider
+
+In this section you will configure Auth0 to serve as a SAML Service Provider.
+
+**In the Auth0 dashboard:**
+
+1. Click on **"Connections"** link at left.
+1. In the list of options below "Connections", click on **"Enterprise"**.
+1. Click on the **"Create Connection"** button.
+
+In the **"New SAML Connection"** window, enter the following information:
+
+- **Connection Name:** You can enter any name, such as `SAML-SP`.
+- **Display Name:** If a value is provided, Universal Login will have the button say "Continue with (Display Name)".
+- **IdP Domains:** (optional) Provide a comma-separated list of the domains that can be authenticated in the Identity Provider. This step is only needed for identifier-first authentication flows  If you leave this field blank, users with any email domain can use the IdP.
+- **Sign In URL:** Enter the **SAML SSO URL** that you obtained from the Identity Provider.
+- **Sign Out URL:** Enter the **SAML Logout URL** obtained from the Identity Provider.
+- **Certificate:**  Click on the red **"UPLOAD CERTIFICATE"** button and select the `.pem` file you obtained from the Identity Provider.
+- **User Id Attribute**: The attribute in the SAML token that will be mapped to the `user_id` property in Auth0. If not set, then the `user_id` will be retrieved from the following (in listed order):
+  - `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier`
+  - `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn`
+  - `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name`
+
+You can ignore the rest of the fields for now.
+
+Click on the blue **"SAVE"** button at the bottom.
+
+A window will appear with a red **"CONTINUE"** button. (You might have to scroll up to see it)
+
+Click on the **"CONTINUE"** button.
+
+In the window that appears, metadata about this SAML service provider is displayed. You will need to use the information from this screen to configure the Identity Provider.
+
+The first bullet is the post-back URL or Assertion Consumer Service (ACS) URL. This is the URL the Identity Provider will send Authentication Assertions to after authenticating a user. Enter this value where the Identity Provider asks for Assertion Consumer Service URL. It may just call this a Service Provider URL.
+
+The second bullet tells you the **"Entity ID"**.  It will be of the form __urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME__.
+
+Copy and save this entire Entity ID field from "urn" all the way to the end of the connection name. Use this value if the Identity Provider asks for Entity ID or SAML Audience.
+
+The third bullet indicates the binding that will be used to send the SAML Request from Auth0 to the Identity Provider. If the Identity Provider provides a choice, select HTTP-Redirect as shown on your metadata screen.
+
+The fourth bullet indicates that Auth0 expects the Identity Provider to respond with an HTTP POST, such as the Authentication Assertion from the Identity Provider will be sent using the HTTP POST binding. If the Identity Provider provides a choice, indicate that HTTP-POST binding should be used for Authentication Assertions.
+
+The nameid format is the format for the attribute that will be used to identify users.
+
+In that same window, near the bottom, there is a line that says, _"You can access the metadata for your connection in Auth0 here:"_.
+
+In general, you can access the metadata for a SAML connection in Auth0 here: `https://${account.namespace}/samlp/metadata?connection=YOUR_CONNECTION_NAME`.
+
+Make a note of this metadata URL as you may be able to use it to configure the Identity Provider in the next step.
+
+## 3. Add your Service Provider metadata to the Identity Provider
+
+In this section you will add some information to the Identity Provider so the Identity Provider knows how to receive and respond to SAML-based authentication requests from the Auth0 Service Provider. The instructions provided here are generic. You will need to find the appropriate screens and fields on the Identity Provider.
+
+Locate the screens in the Identity Provider that allow you to configure SAML.
+
+If the Identity Provider supports uploading a metadata file, you can simply provide the metadata URL obtained in the step above.
+
+If the Identity Provider does not support uploading a metadata file, you can configure it manually as follows:
+
+The Identity Provider will need to know where to send the SAML assertions after it has authenticated a user. This is the **Assertion Consumer Service URL** in Auth0. The Identity Provider may call this any of the following:
+
+* Assertion Consumer Service URL
+* Application Callback URL
+
+```text
+https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME
+```
+
+The `connection` URL parameter is required for identity provider-initiated flows.
+
+Note that if you have [custom domains](/custom-domains) set up, you should use the custom domain based URL rather than your Auth0 domain. So, it should be in the format of `https://YOUR_CUSTOM_COMAIN/login/callback?connection=YOUR_CONNECTION_NAME`.
+
+If the Identity Provider has a field called "Audience" or "Entity ID", you should enter into that field the **Entity ID** from Auth0:
+
+```text
+"audience":"urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME"
+```
+
+If the Identity Provider provides a choice for bindings, you should select **HTTP-Redirect** for Authentication Requests.
+
+The **Single Logout Service URL**, where SAML logout requests and/or responses from the Identity Provider must be sent, should be configured as:
+
+```text
+https://${account.namespace}/logout
+```
+
+**Signing Logout Requests**: When configuring the Identity Provider, make sure that SAML Logout Requests sent to the Service Provider are signed.
+
+## 4. Test the connection from Service Provider to Identity Provider
+
+In this section, you will test to make sure the SAML configuration between Auth0, the Service Provider, and the remote SAML Identity Provider is working.
+
+* In the [Dashboard](${manage_url}), navigate to:  __Connections > Enterprise > SAMLP Identity Provider__.
+
+* Click on the triangular **Try** button for the SAML connection you created earlier.  This button is to the right of the name of the connection. You can hover your mouse over the button to have the text label appear.
+
+* You will first see a Lock login widget appear that is triggered by the Service Provider.  Enter the username. If you entered an email domain in the SAMLP connection configuration, the username should belong to that email domain.
+
+You will then be redirected to the login screen of the Identity Provider. Login with the credentials for a user that exists in the Identity Provider.
+
+If the SAML configuration works, your browser will be redirected back to an Auth0 page that says __It works__.  This page will display the contents of the SAML authentication assertion sent by the Identity Provider to Auth0 Service Provider.
+This means the SAML connection from Auth0 Service Provider to Identity Provider is working.
+
+If it didn't work, double check the above steps and then consult the **troubleshooting** section at the end of this document.
+
+::: note
+The **Try** button only works for users logged in to the Auth0 dashboard. You cannot send this to an anonymous user to have them try it.
+:::
+
+Here is a sample of the **It Works** screen:
+
+![](/media/articles/saml/saml-sp-generic/saml-auth0-9.png)
+
+## 5. Troubleshooting
+
+This section has a few ideas for things to check if your sample doesn't work.
+
+Note that if your application doesn't work the first time, you should clear your browser history and ideally cookies each time before you test again. Otherwise, the browser may not be picking up the latest version of your HTML page or it may have stale cookies that impact execution.
+
+When troubleshooting SSO, it is often helpful to capture an HTTP trace of the interaction.  There are many tools that will capture the HTTP traffic from your browser for analysis.  Search for "HTTP Trace" to find some.  Once you have an HTTP trace tool, capture the login sequence from start to finish and analyze the trace to see the sequence of GETs to see how far in the expected sequence you get. You should see a redirect from your original site to the Service Provider, and then to the Identity Provider, a post of credentials if you had to log in, and then a redirect back to the callback URL or the Service Provider and then finally a redirect to the callback URL specified in your application.
+
+Be sure to check to make sure cookies and javascript are enabled for your browser.
+
+Check to make sure that the callback URL specified by your application in its authentication request is listed in the **Allowed Callback URLs** field.  
+
+To do so, go to [Dashboard](${manage_url}), click on __Applications__, then on the __Settings__ icon to the right of the application name.
+
+The [http://samltool.io](http://samltool.io) tool can decode a SAML assertion and is a useful debugging tool.
+
+## Supported algorithms for signatures
+
+We currently support the following algorithms for processing XML Digital Signatures:
+
+* Canonicalization
+  * 'http://www.w3.org/2001/10/xml-exc-c14n#'
+  * 'http://www.w3.org/2001/10/xml-exc-c14n#WithComments'
+  * 'http://www.w3.org/2000/09/xmldsig#enveloped-signature'
+
+* Signature
+
+  * 'http://www.w3.org/2000/09/xmldsig#rsa-sha1'
+  * 'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256'
+
+* Digest
+
+  * 'http://www.w3.org/2000/09/xmldsig#sha1'
+  * 'http://www.w3.org/2001/04/xmlenc#sha256'
diff --git a/ja-jp/articles/protocols/saml/saml2webapp-tutorial.md b/ja-jp/articles/protocols/saml/saml2webapp-tutorial.md
new file mode 100644
index 0000000000..26cc31a6f7
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/saml2webapp-tutorial.md
@@ -0,0 +1,82 @@
+---
+description: How to use Auth0 in a SAML2 web application.
+topics:
+  - saml
+  - web-apps
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# Using Auth0 with a SAML2 Web App
+
+You can configure a SAML2 Web Application for use with an Auth0 Application via the Management Dashboard.
+
+## Enable the SAML2 Web App Addon for your Auth0 Application
+
+1. Log in to Auth0, and navigate to the [Applications](${manage_url}/#/applications) page of the [Management Dashboard](${manage_url}).
+
+  ![](/media/articles/protocols/saml/saml2-web-app/mgmt-dshbrd-clients.png)
+
+2. Identify the Application with which you want to use a SAML2 Web Application. Click the Application's name to go to its configuration settings pages.
+3. Go to the *Addons* page for the Application.
+
+  ![](/media/articles/protocols/saml/saml2-web-app/select-addon.png)
+
+4. In the SAML2 Web App box, click the slider to enable the Addon. You will see a *Settings* page for the Addon.
+
+  ![](/media/articles/protocols/saml/saml2-web-app/configure-addon.png)
+
+5. To enable the Addon from the Auth0 side, you will need to provide your **Application Callback URL**, which receives the SAML response, as well as the **Settings** for your setup. Within the *Settings* page, there is a sample object that you can use when determining which settings you want to enable:
+
+```js
+{
+// "audience":  "urn:foo",
+// "recipient": "http://foo",
+// "mappings": {
+//   "user_id":     "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+//   "email":       "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+//   "name":        "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
+//   "given_name":  "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
+//   "family_name": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
+//   "upn":         "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn",
+//   "groups":      "http://schemas.xmlsoap.org/claims/Group"
+// },
+// "createUpnClaim":       true,
+// "passthroughClaimsWithNoMapping": true,
+// "mapUnknownClaimsAsIs": false,
+// "mapIdentities":        true,
+// "signatureAlgorithm":   "rsa-sha1",
+// "digestAlgorithm":      "sha1",
+// "destination":          "http://foo",
+// "lifetimeInSeconds":    3600,
+// "signResponse":         false,
+// "typedAttributes":      true,
+// "includeAttributeNameFormat":  true,
+// "nameIdentifierFormat": "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified",
+// "nameIdentifierProbes": [
+//   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
+//   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
+//   "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"
+// ],
+// "authnContextClassRef": "urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified",
+// "logout": {
+//   "callback": "http://foo/logout"
+// }
+}
+```
+
+You can click **Debug** to test if your provided parameters are valid.
+
+Click **Save** when done.
+
+## Provide Your Auth0 Application Details to Your SAML2 Web App
+
+While the specific steps for providing your Auth0 Application details to your SAML2 Web App will vary, you can get the configuration information you need from the *Usage* tab after you have set up the Addon from the Auth0 side.
+
+  ![](/media/articles/protocols/saml/saml2-web-app/usage.png)
+
+## Passive SAML Requests
+
+Currently, the SAML2 Web App addon does *not* support passive SAML requests (e.g. where `isPassive=true`).
\ No newline at end of file
diff --git a/ja-jp/articles/protocols/saml/samlp-providers.md b/ja-jp/articles/protocols/saml/samlp-providers.md
new file mode 100644
index 0000000000..b42a172665
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/samlp-providers.md
@@ -0,0 +1,38 @@
+---
+description: List of Identity Provider services known to support the SAML protocol.
+topics:
+  - saml
+contentType:
+  - reference
+useCase:
+  - add-idp
+---
+# List of SAML-P Identity Providers
+
+This is a list of Identity Provider services known to support the SAML protocol. There may be additional services beyond what is shown below.
+
+## SAML-P
+
+The following providers have participated in a Kantara inter-operability test and are therefore likely to conform well to the SAML spec.
+
+  * __adAS__
+  * __ADFS__
+  * __Dot Net Workflow__
+  * __Elastic SSO Team & Enterprise__
+  * __Entrust GetAccess & IdentityGuard__  (check protocol supported)
+  * __EIC__  (check protocol supported)
+  * __Ilex Sign&go__
+  * __iWelcome__
+  * __NetIQ Access Manager__
+  * __OpenAM__
+  * __RCDevs Open SAMPL IdP__
+  * __Optimal IdM VIS Federation Services__
+  * __Oracle Access Manager__ (Oracle Identity Federation merged into this)
+  * __PingFederate__  (IDP Light)
+  * __RSA Federated Identity__  (IDP Light)
+  * __SecureAuth__
+  * __Symplified__
+  * __Tivoli Federated Identity Manager__
+  * __TrustBuilder__
+  * __Ubisecure SSO__
+  * __WSO2 Identity Server__
diff --git a/ja-jp/articles/protocols/saml/samlp.md b/ja-jp/articles/protocols/saml/samlp.md
new file mode 100644
index 0000000000..3b32321d29
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/samlp.md
@@ -0,0 +1,74 @@
+---
+title: SAML
+description: SAML Identity Provider Configuration
+topics:
+  - saml
+  - samlp
+contentType:
+  - reference
+useCase:
+  - add-idp
+---
+
+# SAML Identity Provider Configuration
+
+## Common settings
+
+These are the parameters used to configure a SAML Identity Provider (IdP):
+
+* The __post-back URL__ (also called __Assertion Consumer Service URL__) is: `https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME`
+* The __Entity ID__ of the Service Provider is: `urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME` (default value). Use `connection.options.entityId` if available. You can obtain this value using the [Get a connection by its id APIv2 endpoint](/api/management/v2#!/Connections/get_connections_by_id):
+
+```har
+{
+    "method": "GET",
+    "url": "https://${account.namespace}/api/v2/connections/CONNECTION_ID",
+    "httpVersion": "HTTP/1.1",
+    "cookies": [],
+    "headers": [{
+        "name": "Authorization",
+        "value": "Bearer ACCESS_TOKEN"
+    }]
+}
+```
+
+::: note
+You need to replace the `ACCESS_TOKEN` header value, with a Management APIv2 Access Token. For information on how to do that see [Access Tokens for the Management API](/api/management/v2/tokens).
+:::
+
+* The __SAML Request Binding__ (also called the __Protocol Binding__): sent to the IdP from Auth0. If possible, dynamically set the value based on `connection.options.protocolBinding`:
+
+| `connection.options.protocolBinding` value           | SAML Request Binding value |
+| ---------------------------------------------------- | -------------------------- |
+| Empty value ("") or not present                      | `HTTP-Redirect`            |
+| `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect` | `HTTP-Redirect`            |
+| `urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST`     | `HTTP-POST`                |
+
+If dynamically setting the value isn't possible, then set as either `HTTP-Redirect` (default) or `HTTP-Post` if you selected this option in **Protocol Binding**
+
+* The __SAML Response Binding__ : how the SAML token is received by Auth0 from IdP, set as `HTTP-Post`
+* The __NameID format__: `unspecified`
+* The SAML assertion, and the SAML response can be individually or simultaneously signed.
+* The __SingleLogout service URL__, where the SAML Identity Provider will send logout requests and responses, is: `https://${account.namespace}/logout`. SAML logout requests must be signed by the Identity Provider.
+
+## Signed assertions
+
+By default, SAML assertions for IdP connections are signed, which we recommend. You can use the following public keys to configure the IdP: 
+
+* [CER](https://${account.namespace}/cer?cert=connection)
+* [PEM](https://${account.namespace}/pem?cert=connection)
+* [raw PEM](https://${account.namespace}/rawpem?cert=connection)
+* [PKCS#7](https://${account.namespace}/pb7?cert=connection)
+* [Fingerprint](https://${account.namespace}/fingerprint?cert=connection)
+
+## IdP-initiated Single Sign-on
+
+[Click here to learn more about IdP-Initiated Single Sign-on (SSO)](/protocols/saml/idp-initiated-sso)
+
+## Metadata
+
+Some SAML Identity Providers can accept importing metadata directly with all the required information. You can access the metadata for your connection in Auth0 here:
+
+```text
+https://${account.namespace}/samlp/metadata?connection=YOUR_CONNECTION_NAME
+```
diff --git a/ja-jp/articles/protocols/saml/samlsso-auth0-to-auth0.md b/ja-jp/articles/protocols/saml/samlsso-auth0-to-auth0.md
new file mode 100644
index 0000000000..6440d44a11
--- /dev/null
+++ b/ja-jp/articles/protocols/saml/samlsso-auth0-to-auth0.md
@@ -0,0 +1,340 @@
+---
+description: Learn how to use SAML Single Sign-on (SSO) with Auth0 as both the Service Provider and Identity Provider, using two Auth0 tenants, allowing you to test your Auth0 SAML without configuring another provider to do so.
+toc: true
+topics:
+  - saml
+  - sso
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+
+# SAML SSO with Auth0 as Service Provider and as an Identity Provider
+
+This tutorial will create a simple example application that uses Auth0 to do SAML Single Sign-on (SSO), using one Auth0 tenant (tenant 1) as a SAML Service Provider(SP), and authenticating users against a second Auth0 tenant (tenant 2) serving as SAML Identity Provider(IDP).  This gives you a way to test your Auth0 SAML tenant (tenant 1) configuration, using Auth0 as an IDP so you don't have to learn and set up another IDP.
+
+There are **9 steps** to this sample and the tenth is a troubleshooting section to help resolve any problems that might arise.
+
+1. [Establish two Auth0 tenants](#1-establish-two-auth0-tenants)
+2. [Set up the Auth0 Identity Provider (IDP) (tenant 2)](#2-set-up-the-auth0-idp-tenant-2-)
+3. [Set up the Auth0 Service Provider (SP) (tenant 1)](#3-set-up-the-auth0-service-provider-tenant-1-)
+4. [Add your Service Provider metadata to the Identity Provider](#4-add-your-service-provider-metadata-to-the-identity-provider)
+5. [Test the Identity Provider](#5-test-identity-provider)
+6. [Register a simple HTML application with which to test the end-to-end connection](#6-register-a-simple-html-application-with-which-to-test-the-end-to-end-connection-)
+7. [Test the connection from Service Provider to Identity Provider](#7-test-the-connection-from-service-provider-to-identity-provider)
+8. [Create the HTML page for the application](#8-create-the-html-page-for-a-test-application)
+9. [Test your sample application](#9-test-your-sample-application)
+10. [Troubleshooting](#10-troubleshooting)
+
+## 1. Establish two Auth0 Tenants
+
+If you do not already have two Auth0 tenants, you will need to create them. If you do already have two tenants, you can skip to step #2.
+
+### In the Auth0 Dashboard
+
+In the upper right corner, click on the name of your tenant and in the popup menu which appears, select **+ Create Tenant**.  
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-01.png)
+
+In the window which appears, enter a name for your second tenant in the **"Your Auth0 domain"** field and press the **"SAVE"** button.
+
+You can switch back and forth between the tenants by going to the upper right corner of the dashboard, clicking on the name of the current tenant, and using the popup menu which appears to switch between your tenants.
+
+## 2. Set up the Auth0 IDP (tenant 2)
+
+In this section you will configure one Auth0 tenant (tenant 2) to serve as an Identity Provider.  You will do this by registering an application, but in this case, the 'application' you register is really a representation of tenant 1, the SAML Service Provider.
+
+Log into **Tenant 2**
+
+**In the Auth0 dashboard:**
+
+1. Click on **"Applications"** link at left.
+
+2. Click on the red **"+ CREATE APPLICATION"** button on the right.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-02.png)
+
+3. In the **Name** field, enter a name like "My-Auth0-IDP".
+
+4. Press the blue **"SAVE"** button.
+
+5. Click on the **"Settings"** tab.
+
+6. Scroll down and click on the **"Show Advanced Settings"** link.
+
+7. In the expanded window, scroll down to the **"Certificates"** section and click on the **"DOWNLOAD CERTIFICATE"** link and select PEM from the dropdown, to download a PEM-formatted certificate.  The certificate will be downloaded to a file called "${account.tenant}.pem".  Save this file as you will need to upload this file when configuring the other Auth0 tenant, tenant 1.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-03.png)
+
+8. Click on the **"Endpoints"** tab and go to the **"SAML"** section.  Copy the entire contents of the **"SAML Protocol URL"** field and save it as in the next step you will need to paste it into the other Auth0 tenant, tenant 1.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-04.jpg)
+
+Next, create a user to use in testing the SAML SSO sequence.
+**In the Auth0 dashboard:**
+
+1. Click on the **"+ CREATE YOUR FIRST USER"** button.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-05.png)
+
+2. In the **Email** field, enter an email for your test user.  The domain name for the email should match what you enter in section 3 below.  For example, if your user is `john.doe@abc-example.com`, you would enter that here, and then enter "abc-example.com" in step 3 below for the Email domain.
+
+3. Enter a password for the user
+
+4. For the Connection, leave it at the default value. (Username-Password-Authentication)
+
+5. Press the blue **"SAVE"** button.
+
+
+## 3. Set up the Auth0 service provider (tenant 1)
+
+In this section you will configure another Auth0 tenant (tenant 1) so it knows how to communicate with the second Auth0 tenant (tenant 2) for SSO via the SAML protocol.
+
+Switch to **Tenant 1**. You can do this using the **Switch tenant** option in the upper-right menu.
+
+**In the Auth0 dashboard:**
+
+1. Click on **"Connections"** link at left.
+2. In the list of options below "Connections", click on **"Enterprise"**
+3. In the middle of the screen, click on **"SAMLP Identity Provider"**
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-06.jpg)
+
+4. Click on the blue **"Create New Connection"** button
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-07.jpg)
+
+In the **"Create SAMLP Identity Provider"** connection window, enter the following information into the "Configuration" tab.
+
+**Connection Name:** You can enter any name, such as "SAML-Auth0-IDP"
+
+**Email Domains:** In this example, we will use the Lock widget, so in the Email Domains field enter the email domain name for the users that will log in via this connection.
+For example, if your users have an email domain of 'abc-example.com', you would enter that into this field. You can enter multiple email domains if needed.  Make sure the test user you created in section 2 has an email address with email domain that matches what you enter here.
+
+**Sign In URL:** enter the **SAML Protocol URL** field that you copied in section 2 above (from tenant 2, go to: **Dashboard > Applications > Settings > Advanced Settings > ENDPOINTS section > SAML tab > SAML Protocol URL field**).
+
+**Sign Out URL:** enter the same URL as for the Sign In URL above.
+
+**X509 Signing Certificate:**  
+Click on the red **"UPLOAD CERTIFICATE..."** button and select the `.pem` file you downloaded from tenant 2 in section 2 above.
+
+You can ignore the rest of the fields for now.
+
+**Save:** Click on the blue **"SAVE"** button at the bottom.
+
+After pressing the **"SAVE"** button, A window will appear with a red **"CONTINUE"** button. (You might have to scroll up to see it)
+
+Copy and save the URL below the **"CONTINUE"** button, and then click on the **"CONTINUE"** button.
+
+In the window that appears, metadata about this SAML provider (tenant 1) should be displayed. If you are not logged into the Auth0 documentation site, generic SAML provider configuration data will be displayed. Click "Login" in the top right corner of the page, log in with your Auth0 management dashboard credentials, and then go to the URL you saved in the previous step.
+
+You will need to collect two pieces of information about this Auth0 tenant (the service provider) that you will then paste into the other Auth0 tenant you set up (the identity provider).
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-08.jpg)
+
+First, look for the second bullet in the list of information that tells you the **"Entity ID"**.  It will be of the form __urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME__.  
+
+Copy and save this entire Entity ID field from "urn" all the way to the end of the connection name. You will need to replace **YOUR_CONNECTION_NAME** with the name of the connection you created previously ('SAML-Auth0-IDP' in the example above).
+
+In that same window, near the bottom, there is a line that says, _"You can access the metadata for your connection in Auth0 here:"_.  
+
+Copy the URL below that line into your browser address bar. Again, you will need to replace **YOUR_CONNECTION_NAME** with the name of the connection you created previously ('SAML-Auth0-IDP' in the example above).
+
+In general, you can access the metadata for a given SAML connection in Auth0 here: `https://${account.namespace}/samlp/metadata?connection=YOUR_CONNECTION_NAME`.
+
+Once you go to that metadata URL, it will display the metadata (or prompt you to save the metadata file) for this connection in tenant 1 (service provider side of the federation). It will look something like the following with your tenant name in place of the 'xxxxx':
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-09.jpg)
+
+You need to locate the row that starts with **"AssertionConsumerService"** and copy the value of the **"Location"** field.  It will be a URL of the form `https://${account.namespace}/login/callback?connection=YOUR_CONNECTION_NAME`.
+
+Copy and save this URL. This is the URL on Tenant 1 that will receive the SAML assertion from the IDP. In the next section you will give this URL to the IDP so it knows where to send the SAML assertion.
+
+## 4. Add your Service Provider metadata to the Identity Provider
+
+In this section you will go back and add some information about the Service Provider (Tenant 1) to the Identity Provider (tenant 2) so the Identity Provider Auth0 tenant knows how to receive and respond to SAML-based authentication requests from the Service Provider Auth0 tenant.
+
+* Switch back to **Tenant 2**.
+
+**In the Auth0 dashboard:** for Tenant 2
+
+1. Click on **"Applications"** link at left.
+
+2. Find the row for the application you created earlier, and click on the **"Add Ons"** icon to the right of the application name. (the angle bracket and slash icon)
+3. Locate the box with the **"SAML2 WEB APP"** label and click on the circle toggle to turn it green.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-10.jpg)
+
+4. Next, a configuration window will pop up for the **"Addon: SAML2 Web App"**.  Make sure you are in the **Settings**" tab.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-11.png)
+
+5. In the **"Application Callback URL"** field, paste in the **Assertion Consumer Service URL** that you copied and saved in section 3 above (the last step).
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-12.png)
+
+6. In the Settings field below, go to line 2 that has the "audience" attribute.  
+
+First remove the "//" at the beginning of the line to uncomment it, and remove the comma (',') from the end of the line.
+
+Next, replace the original value (urn:foo) with the **Entity ID** value you saved and copied in step 3 above (including your actual connection name). The new line 2 should look something like:
+
+```text
+"audience":"urn:auth0:${account.tenant}:YOUR_CONNECTION_NAME"
+```
+
+7. Click on the blue **"SAVE"** button at the bottom of the screen
+
+## 5. Test Identity Provider
+
+In the same screen, click on the red **"DEBUG"** button.
+
+That will trigger a login screen from tenant 2, the Identity Provider.
+
+Log in with the credentials for the user you created above.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-13.png)
+
+If your configuration is correct, you will see a screen titled **"It works!"**
+
+This screen will show you the encoded and decoded SAML response that would be sent by the Identity Provider.
+
+Check the decoded SAML response and locate (about half-way down) the `""` tag and make sure it matches the **Entity ID** you entered in the previous screen (obtained during step 3).
+
+Click on **"Close this window"** at the bottom of the screen.
+
+## 6. Register a simple HTML application with which to test the end-to-end connection.
+
+In this section, you will register an application in Auth0 that will use the SAML connection you set up in the above steps.
+
+Make sure you are logged into the **Tenant 1 Auth0 dashboard**.
+
+* In the **Auth0 dashboard**, click on the **"Applications"** link at left.
+
+* Click on the red **"+ CREATE APP"** button on the right.
+
+* In the **Name** field, enter a name like "My-HTML-SAML-App".
+
+* Select "Regular Web App"
+
+* Press the blue **"SAVE"** button.
+
+* Click on the **"Settings"** tab.
+
+* Save the **"Domain"** and **"Client ID"** values for use below in step 8.
+
+* In the **"Allowed Callback URLs"** field, enter **[http://jwt.io](http://jwt.io)**.
+
+* The list of allowed callback URLs is a list of URL(s) to which users will be redirected after authentication.  The URL(s) entered here must match the **"callback URL"** in the HTML code created in the next step.  Normally you would enter a URL for your application, but to keep this example simple, users will simply be sent to the Auth0 JWT online tool which will provide some information about the JSON Web Token (JWT) returned at the end of the authentication sequence.
+
+* Press the blue **"SAVE CHANGES"** button at the bottom of the screen.
+
+* In the same screen, click on the blue **"Connections"** tab (In the row that says Quick Start, Settings and so on.
+
+* Scroll down to the section near the bottom where it says **"ENTERPRISE"**.
+
+* Find the row for the SAML connection you created above and click on the on/off toggle at right so that it is green, for "on".  That enables the SAML connection for this application.  
+
+## 7. Test the connection from Service Provider to Identity Provider
+
+In this section, you will test to make sure the SAML configuration between Auth0 tenant 1 (Service Provider) and Auth0 tenant 2 (Identity Provider) is working.
+
+* On the [Dashboard](${manage_url}), navigate to:  __Connections -> Enterprise -> SAMLP Identity Provider__.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-14.jpg)
+
+* Click on the triangular **"Try"** button for the SAML connection you created earlier.  This button is to the right of the name of the connection.  You can hover your mouse over the button to have the text label appear.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-15.png)
+
+* Because you already logged in while testing this connection above, you will likely be sent directly to the "It Works!" page shown previously. If you are presented with the Lock login screen, login using the credentials for the user you created above. On some older tenants, you may see the "Last time you signed in using" dialog as shown below, in which case you can just click on your email address to continue.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-16.png)
+
+If the SAML configuration works, your browser will be redirected back to an Auth0 page that says __"It works!"__.  This page will display the contents of the SAML authentication assertion sent by the Auth0 Identity Provider to Auth0 Service Provider.
+This means the SAML connection from Auth0 Service Provider to Auth0 Identity Provider is working.
+
+If it didn't work, double check the above steps and then consult the **troubleshooting** section at the end of this document.
+
+::: note
+The **Try** button only works for users logged in to the Auth0 dashboard.  You cannot send this to an anonymous user to have them try it.
+:::
+
+## 8. Create the HTML page for a test application
+
+In this section you will create a very simple HTML page that invokes the **Auth0 Lock Widget** which will trigger the SAML login sequence.  This will enable an end-to-end test of the SAML SSO.
+
+Create an HTML page and insert the following HTML and javascript code:
+
+```html
+
+
+
+
       Click on the button to log in 
      
+
+
+
+
+
+
+
+```
+
+Make sure you replace **YOUR_CLIENT_ID** and **YOUR_DOMAIN** with the actual values of the app you registered in step 6 above. If you did not record these values in step 6, they can be found in the **Auth0 dashboard** for **Tenant 1** by going to "Applications" link and clicking on the "Settings" (gear) icon to the right of your application's name.
+
+You can also replace **audience** with the value appropriate for your Application -- however, for the purposes of this test, a placeholder will work. When specifying the **audience** parameter, be sure that it matches an identifier of an existing API that [has been configured in Auth0](/apis#how-to-configure-an-api-in-auth0).
+
+Save this file in a place where you can access it via a browser.
+For this example, we'll call it **"hello-saml.html"**.
+
+## 9. Test your sample application
+
+In this step, you will test your sample HTML application that uses the Auth0 SAML connection you set up in Tenant 1 to perform SSO via SAML against Tenant 2, serving as the SAML Identity Provider.
+
+* Open the HTML file created above with a browser. You should first see a white page with a login button on it.
+
+* Click on the **login** button.
+
+The **Auth0 Lock** widget should appear with one login option.
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-18.png)
+
+If you have other connections turned on for your application, your **Auth0 Lock Widget** may look slightly different.  If you are prompted to enter an email address, make sure the email address you enter has the same domain name as the domain(s) you entered in the __Settings__ tab for the application in the Tenant 1 Auth0 dashboard  (__Applications > Settings__).
+
+![](/media/articles/saml/samlsso-auth0-to-auth0/samlsso-auth0-19.png)
+
+After entering your email address, the blue button on the Lock widget may have a new label. Click on the button which may be labeled **"saml"** or **ACCESS** or with the email domain of the email address you are logging in with, to initiate the SAML sso sequence with the Auth0 Identity Provider.
+
+* As above, whether you are prompted for credentials or immediately redirected to the callback URL depends on whether you still have an active session at the Identity Provider.
+
+From the "try me" test you did earlier, you may still have an active session at the Identity Provider.  If this is the case, you will not be prompted to log in again and will simply be redirected to the callback URL specified in the HTML file. (Remember that this callback URL must also be in the __Allowed Callback URLs__ in the application's Settings tab in the Auth0 dashboard.)
+
+If sufficient time has passed, or if you delete your browser cookies before initiating the test, then you will be prompted to login when redirected to the Identity Provider.  Log in to the Identity Provider using the credentials for the test user you created in Auth0 Tenant 2.
+
+## 10. Troubleshooting
+
+This section has a few ideas for things to check if your sample doesn't work.
+
+Note that if your application doesn't work the first time, you should clear your browser history and ideally cookies each time before you test again.  Otherwise, the browser may not be picking up the latest version of your html page or it may have stale cookies that impact execution.
+
+When troubleshooting SSO, it is often helpful to capture an HTTP trace of the interaction.  There are many tools that will capture the HTTP traffic from your browser for analysis.  Search for "HTTP Trace" to find some.  Once you have an http trace tool, capture the login sequence from start to finish and analyze the trace to see the sequence of GETs to see how far in the expected sequence you get.  You should see a redirect from your original site to the Service Provider, and then to the Identity Provider, a post of credentials if you had to log in, and then a redirect back to the callback URL or the Service Provider and then finally a redirect to the callback URL specified in your application.
+
+Be sure to check to make sure cookies and javascript are enabled for your browser.
+
+Check to make sure that the callback URL specified in the HTML file is also listed in the **Allowed Callback URLs** field in the "Settings" tab of the application registered in the Auth0 Dashboard.  (In dashboard, Click on Applications link, then on the "Settings" icon to the right of the application's name.)
+
+The **[http://samltool.io](http://samltool.io)** tool can decode a SAML assertion and is a useful debugging tool.
diff --git a/ja-jp/articles/protocols/ws-fed/index.md b/ja-jp/articles/protocols/ws-fed/index.md
new file mode 100644
index 0000000000..bff4091e38
--- /dev/null
+++ b/ja-jp/articles/protocols/ws-fed/index.md
@@ -0,0 +1,76 @@
+---
+description: The WS-Federation protocol and how it is used in Auth0.
+topics:
+  - saml
+  - ws-federation
+contentType:
+  - how-to
+useCase:
+  - add-idp
+---
+# WS-Federation
+
+WS-Federation (which is short for Web Services Federation) is a protocol that can be used to negotiate the issuance of a token. You can use this protocol for your applications (such as a Windows Identity Foundation-based app) and for identity providers (such as Active Directory Federation Services or Azure AppFabric Access Control Service).
+
+## For Applications (Clients)
+
+By registering your application as an [application](/applications) in Auth0, it will automatically be assigned a WS-Fed endpoint of the form:
+
+```text
+https://${account.namespace}/wsfed/${account.clientId}
+```
+
+You can find all available options for configuring WS-Federation under the [advanced settings](${manage_url}/#/applications/${account.clientId}/settings) area for your application.
+
+![WS-Fed Endpoints](/media/articles/protocols/ws-fed-endpoints.png)
+
+You will need to configure the **Relying Party**, which can be done using the following metadata endpoint:
+
+```text
+https://${account.namespace}/wsfed/FederationMetadata/2007-06/FederationMetadata.xml
+```
+
+You can also use the **samlConfiguration** object (available in [rules](/rules)) to configure claims sent via the  token, as well as other lower-level WS-Fed and SAML-P settings.
+
+When redirecting your users to your WS-Fed endpoint, you can use the following (optional) parameters:
+
+* `wa=wsignin1.0`: whether Auth0 should issue a token for the relying party (this is the default action)
+* `wa=wsignout1.0`: whether Auth0 should clear the user session/log the user out
+* `wreply={callback_URL}`: specifies where the response should be sent
+* `wctx={state}`: your application's state
+* `whr={connection_name}`: connection to be used (allows users to skip the Auth0 login page)
+* `wfresh=0`: whether the user must re-authenticate, even if there's a session in place (`0` requires re-authentication)
+
+Here's a sample of what your URL with the optional parameters might look like:
+
+```text
+https://${account.namespace}/wsfed/${account.clientId}?whr=google-oauth2
+```
+
+## Identity Providers
+
+If you're using Auth0 with an identity provider that utilizes the WS-Federation protocol (such as Active Directory Federation Services, Azure AppFabric Access Control Service, and IdentityServer), the easiest way to set up your integration is to create and use the **ADFS** connection type. When setting up an ADFS-based connection,  you can import the required parameters by providing Auth0 with the **Federation Metadata** endpoint *or* by importing uploading your Federation Metadata file.
+
+![New Connection Configuration Screen](/media/articles/protocols/create-adfs-connection.png)
+
+Click **Save** to proceed. You will then be presented with the instructions you need to finish configuring the integration.
+
+The Federation Metadata file contains information about the identity provider's certificates. If you provide the Federation Metadata endpoint (typically of the form ending with `/FederationMetadata/2007-06/FederationMetadata.xml`), Auth0 can check daily for changes in the configuration, such as the addition of a new signing certificate that was added in preparation for a rollover.
+
+Because of this, enabling the Federation Metadata endpoint is preferred to providing a standalone metadata file. If you provide a standalone metadata file, we will notify you via email when the certificates are close to their expiration date.
+
+::: note
+If the Federation Metadata contains both the primary **and** secondary certificates, you can use both in Auth0.
+:::
+
+To roll over certificates using the Federation Metadata endpoint, you must:
+
+1. Generate a new certificate and add as the secondary in your ADFS environment at least two days before the certificate expiry of your current primary certificate.
+
+1. Generate a new certificate, and add it as the **secondary certificate** for your ADFS environment. This should be **done at least two days before** the expiration of your active primary certificate.
+
+1. Allow Auth0 to obtain your new certificate from the Federation Metadata endpoint. Auth0 checks your endpoints once a day, so be sure to allow sufficient time for Auth0 to complete this step. 
+	
+	Alternatively, you can manually complete this step by logging in to the Auth0 Dashboard, navigating to the appropriate ADFS connection, and click  **Save**. This action results in Auth0 downloading the certificates immediately.
+
+1. Set the now-secondary certificate as the primary certificate **before** the existing primary certificate expires in your ADFS environment.
diff --git a/ja-jp/articles/quickstart/_includes/_auth0-angular-install.md b/ja-jp/articles/quickstart/_includes/_auth0-angular-install.md
new file mode 100644
index 0000000000..4dd7e6ae4a
--- /dev/null
+++ b/ja-jp/articles/quickstart/_includes/_auth0-angular-install.md
@@ -0,0 +1,11 @@
+
+
+## Install the Auth0 Angular SDK
+
+Run the following command within your project directory to install the Auth0 Angular SDK:
+
+```bash
+npm install @auth0/auth0-angular
+```
+
+The SDK exposes several types that help you integrate Auth0 with your Angular application idiomatically, including a module and an authentication service.
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/_includes/_auth0-react-classes-info.md b/ja-jp/articles/quickstart/_includes/_auth0-react-classes-info.md
new file mode 100644
index 0000000000..b01542e23e
--- /dev/null
+++ b/ja-jp/articles/quickstart/_includes/_auth0-react-classes-info.md
@@ -0,0 +1,5 @@
+
+
+:::note
+This guide focuses on using the `useAuth0()` custom React Hook. If you are using class components, check out [these samples using the `withAuth0()` higher-order component](https://github.com/auth0/auth0-react/blob/master/EXAMPLES.md#use-with-a-class-component).
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/_includes/_auth0-react-install.md b/ja-jp/articles/quickstart/_includes/_auth0-react-install.md
new file mode 100644
index 0000000000..e7a4d96fd7
--- /dev/null
+++ b/ja-jp/articles/quickstart/_includes/_auth0-react-install.md
@@ -0,0 +1,11 @@
+
+
+## Install the Auth0 React SDK
+
+Run the following command within your project directory to install the Auth0 React SDK:
+
+```bash
+npm install @auth0/auth0-react
+```
+
+The SDK exposes methods and variables that help you integrate Auth0 with your React application idiomatically using [React Hooks](https://reactjs.org/docs/hooks-overview.html) or [Higher-Order Components](https://reactjs.org/docs/higher-order-components.html).
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/_includes/_auth0-vue-install.md b/ja-jp/articles/quickstart/_includes/_auth0-vue-install.md
new file mode 100644
index 0000000000..c2cc9be635
--- /dev/null
+++ b/ja-jp/articles/quickstart/_includes/_auth0-vue-install.md
@@ -0,0 +1,11 @@
+
+
+## Install the Auth0 Vue SDK
+
+Run the following command within your project directory to install the Auth0 Vue SDK:
+
+```bash
+npm install @auth0/auth0-vue
+```
+
+The SDK exposes several types that help you integrate Auth0 with your Vue application idiomatically, including a module and an authentication service.
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/_includes/_configure_auth0_interactive.md b/ja-jp/articles/quickstart/_includes/_configure_auth0_interactive.md
new file mode 100644
index 0000000000..a603228285
--- /dev/null
+++ b/ja-jp/articles/quickstart/_includes/_configure_auth0_interactive.md
@@ -0,0 +1,39 @@
+## Configure Auth0 {{{ data-action=configure }}}
+
+To use Auth0 services, you’ll need to have an application set up in the Auth0 Dashboard. The Auth0 application is where you will configure how you want authentication to work for the project you are developing.
+
+### Configure an application
+
+Use the interactive selector to create a new Auth0 application or select an existing application that represents the project you want to integrate with. Every application in Auth0 is assigned an alphanumeric, unique client ID that your application code will use to call Auth0 APIs through the SDK.
+
+Any settings you configure using this quickstart will automatically update for your Application in the Dashboard, which is where you can manage your Applications in the future.
+
+If you would rather explore a complete configuration, you can view a sample application instead.
+
+### Configure Callback URLs
+
+A callback URL is a URL in your application that you would like Auth0 to redirect users to after they have authenticated. If not set, users will not be returned to your application after they log in.
+
+::: note
+If you are following along with our sample project, set this to `${callback}`.
+:::
+
+### Configure Logout URLs
+
+A logout URL is a URL in your application that you would like Auth0 to redirect users to after they have logged out. If not set, users will not be able to log out from your application and will receive an error.
+
+::: note
+If you are following along with our sample project, set this to `${returnTo}`.
+:::
+
+<% if (typeof showWebOriginInfo !== 'undefined' && showWebOriginInfo === true) { %>
+
+### Configure Allowed Web Origins
+
+An Allowed Web Origin is a URL that you want to be allowed to access to your authentication flow. This must contain the URL of your project. If not properly set, your project will be unable to silently refresh authentication tokens, so your users will be logged out the next time they visit your application or refresh a page.
+
+::: note
+If you are following along with our sample project, set this to `${webOriginUrl}`.
+:::
+
+<% } %>
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_auth_preamble.md b/ja-jp/articles/quickstart/backend/_includes/_api_auth_preamble.md
new file mode 100644
index 0000000000..443f2c5a67
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_auth_preamble.md
@@ -0,0 +1,6 @@
+
+This example demonstrates:
+
+* How to check for a JSON Web Token (JWT) in the `Authorization` header of an incoming HTTP request.
+
+* How to check if the token is valid, using the [JSON Web Key Set (JWKS)](/tokens/concepts/jwks) for your Auth0 account. To learn more about validating Access Tokens, see [Validate Access Tokens](/tokens/guides/validate-access-tokens).
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_create.html b/ja-jp/articles/quickstart/backend/_includes/_api_create.html
new file mode 100644
index 0000000000..32e85b9c9d
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_create.html
@@ -0,0 +1,7 @@
+
      Before applying authentication to your resource server/API, you need to create an entry for it in the Auth0 dashboard. This is done from the APIs section which can be found in the sidebar.
      
+
+<% if (account.userName) { %>
+  
      In the APIs section in dashboard, click the Create API button. Provide a Name and Identifier for your API. You must choose the RS256 signing algorithm. Once it is created, navigate to the Scopes tab and create the applicable scopes for your API.
      
+<% } else { %>
+  
      Create an Auth0 account (or login) navigate to the APIs section in Dashboard. Click the Create API button and provide a Name and Identifier for your API. You must choose the RS256 signing algorithm. Once it is created, navigate to the Scopes tab and create the applicable scopes for your API.
      
+<% } %>
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_create_new.md b/ja-jp/articles/quickstart/backend/_includes/_api_create_new.md
new file mode 100644
index 0000000000..4310502988
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_create_new.md
@@ -0,0 +1,16 @@
+## Configure Auth0 APIs
+
+### Create an API
+
+In the [APIs](${manage_url}/#/apis) section of the Auth0 dashboard, click **Create API**. Provide a name and an identifier for your API, for example, `https://quickstarts/api`. You will use the identifier as an `audience` later, when you are configuring the Access Token verification. Leave the **Signing Algorithm** as **RS256**.
+
+![Create API](/media/articles/server-apis/create-api.png)
+
+<% if (typeof sampleLink == 'string') { %>
+<%= include('./_api_jwks_description', { sampleLink: sampleLink }) %>
+<% } else { %>
+<%= include('./_api_jwks_description') %>
+<% }  %>
+
+### Define permissions
+<%= include('./_api_scopes_access_resources') %>
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_create_new_2.md b/ja-jp/articles/quickstart/backend/_includes/_api_create_new_2.md
new file mode 100644
index 0000000000..ba4222d532
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_create_new_2.md
@@ -0,0 +1,5 @@
+## Create a Resource Server (API)
+
+In the [APIs](${manage_url}/#/apis) section of the Auth0 dashboard, click **Create API**. Provide a name and an identifier for your API, for example, `https://quickstarts/api`. You will use the identifier as an `audience` later, when you are configuring the Access Token verification. For **Signing Algorithm**, select **RS256**.
+
+![Create API](/media/articles/server-apis/create-api.png)
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_endpoints.md b/ja-jp/articles/quickstart/backend/_includes/_api_endpoints.md
new file mode 100644
index 0000000000..bc59e707e0
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_endpoints.md
@@ -0,0 +1,5 @@
+The routes shown below are available for the following requests:
+
+- `GET /api/public`: available for non-authenticated requests
+- `GET /api/private`: available for authenticated requests containing an access token with no additional scopes
+- `GET /api/private-scoped`: available for authenticated requests containing an access token with the `read:messages` scope granted 
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_jwks_description.md b/ja-jp/articles/quickstart/backend/_includes/_api_jwks_description.md
new file mode 100644
index 0000000000..23d2c5b8b4
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_jwks_description.md
@@ -0,0 +1,7 @@
+By default, your API uses RS256 as the algorithm for signing tokens. Since RS256 uses a private/public keypair, it verifies the tokens against the public key for your Auth0 account. The public key is in the [JSON Web Key Set (JWKS)](/tokens/concepts/jwks) format, and can be accessed [here](https://${account.namespace}/.well-known/jwks.json).
+
+<% if (typeof sampleLink == 'string') { %>
+::: note
+We recommend using the default RS256 [signing algorithm](/tokens/concepts/signing-algorithms) for your API. If you need to use the HS256 algorithm, see the [HS256 integration sample](${sampleLink}).
+:::
+<% } %>
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_jwks_description_no_link.md b/ja-jp/articles/quickstart/backend/_includes/_api_jwks_description_no_link.md
new file mode 100644
index 0000000000..a27211ec1f
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_jwks_description_no_link.md
@@ -0,0 +1 @@
+By default, your API will be set up to use RS256 as the algorithm for signing tokens. Since RS256 works by using a private/public keypair, tokens can be verified against the public key for your Auth0 account. This public key is accessible at [https://${account.namespace}/.well-known/jwks.json](https://${account.namespace}/.well-known/jwks.json).
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_scope_description.md b/ja-jp/articles/quickstart/backend/_includes/_api_scope_description.md
new file mode 100644
index 0000000000..f7144c1f4c
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_scope_description.md
@@ -0,0 +1,3 @@
+So far, the API is only checking for whether the incoming request has valid authentication information. This solves the case of restricting endpoints such that only authenticated users can access them; however, it doesn't currently provide any way to check for **authorization**.
+
+Authorization can be added to your authentication flow by use of a **scope** claim in the Access Token which provides some indication of what that token allows access to. For more information on how to add scopes to an Access Token, see the [Scopes documentation](/scopes).
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_scopes_access_resources.md b/ja-jp/articles/quickstart/backend/_includes/_api_scopes_access_resources.md
new file mode 100644
index 0000000000..c2bb5146e9
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_scopes_access_resources.md
@@ -0,0 +1,9 @@
+Permissions let you define how resources can be accessed on behalf of the user with a given access token. For example, you might choose to grant read access to the `messages` resource if users have the manager access level, and a write access to that resource if they have the administrator access level.
+
+You can define allowed permissions in the **Permissions** view of the Auth0 Dashboard's [APIs](${manage_url}/#/apis) section.
+
+![Configure Permissions](/media/articles/server-apis/configure-permissions.png)
+
+::: note
+This example uses the `read:messages` scope.
+:::
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_troubleshooting.md b/ja-jp/articles/quickstart/backend/_includes/_api_troubleshooting.md
new file mode 100644
index 0000000000..892df4b22d
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_troubleshooting.md
@@ -0,0 +1,46 @@
+
+
+If you configured JWT validation correctly, you will be able to get proper responses from your API when you make requests. However, in the case where you get a 401 (Unauthorized) response from your API, it is because the configuration of your JWT middleware does not match with the JWT which was passed.
+
+This document will help you troubleshoot your JWT middleware configuration.
+
+## How Does a Token Get Validated?
+
+In terms of validating a JWT, there are various things to consider:
+
+1. **Is the token well-formed?** In other words, is this token conforming to the structure of a JSON Web Token (JWT)? To get more information on the structure of a JWT, please refer to [this section on the structure of a JWT](/jwt#what-is-the-json-web-token-structure-)
+
+2. **Has the token been tampered with?** The last part of a JWT is the signature. The signature is used to verify that the token was in fact signed by the sender and not altered in any way.
+
+3. **Has the token been received in its validity period?** JWTs are only valid for a specified time period (as expressed in the `exp` claim).
+
+4. **Is the token coming from the intended Authority?** This consists of 2 parts
+
+    * **Signature Verification**: Can we confirm that the JWT is correctly signed using the key issued by the issuing authority?
+
+    * **Issuer Value**: The Issuer is defined in the `iss` claim. Once again does this claim match up with what your application expects?
+
+5. **Is the token intended for the current application?** So does the `aud` claim of the JWT match with what your application is expecting?
+
+## Inspecting a Token
+
+A quick way to inspect a JWT is by using the [JWT.io](https://jwt.io/) website. It has a handy debugger which allows you to quickly check that a JWT is well-formed, and also inspect the values of the various claims.
+
+![Debugging a JWT on JWT.io](/media/articles/server-apis/aspnet-core-webapi/jwt-io-debugger-rs256.png)
+
+In the screenshot above you can see that the token was signed using the **RS256** algorithm. The **Issuer** of the token is **https://jerrie.auth0.com/**, and the **Audience** is **https://rs256.test.api**.
+
+So, in other words, these values in your JWT validation configuration registration must match **exactly** - including the trailing slash for the Issuer, such as
+
+```
+audience = "https://rs256.test.api",
+domain = "https://jerrie.auth0.com/"
+};
+```
+
+For a token signed using HS256, the debugger view will look a little different:
+
+![Debugging a JWT on JWT.io](/media/articles/server-apis/aspnet-core-webapi/jwt-io-debugger-hs256.png)
+
+In the screenshot above you can see that the token was signed using the **HS256** algorithm. The **Issuer** of the token is **https://jerrie.auth0.com/**, and the **Audience** is **https://hs256.test.api**.
+
diff --git a/ja-jp/articles/quickstart/backend/_includes/_api_using.md b/ja-jp/articles/quickstart/backend/_includes/_api_using.md
new file mode 100644
index 0000000000..c85b97671b
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_api_using.md
@@ -0,0 +1,120 @@
+
+
+## Calling the API From Your Application
+
+You can call the API from your application by passing an Access Token in the `Authorization` header of your HTTP request as a Bearer token.
+
+```har
+{
+  "method": "GET",
+  "url": "http://localhost:3010/api/private",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN" }
+  ]
+}
+```
+
+## Obtaining an Access Token
+
+If you are calling the API from a Single-Page Application or a Mobile/Native application, after the authorization flow is completed, you will get an Access Token. How you get the token and how you make the call to the API will be dependent on the type of application you are developing and the framework you are using. For more information refer to the relevant application Quickstarts which contain detailed instructions:
+
+* [Single-Page Applications](/quickstart/spa)
+* [Mobile / Native Application](/quickstart/native)
+
+If you are calling the API from a command-line tool or another service, where there isn't a user entering their credentials, you need to use the [OAuth Client Credentials flow](/api/authentication#client-credentials). To do that, register a [Machine to Machine Application](${manage_url}/#/applications), and then subsequently use the **Client ID** and **Client Secret** of this application when making the request below and pass those along in the `client_id` and `client_secret` parameters respectively. Also include the Audience for the API you want to call.
+
+:::note
+Read [Application Settings](https://auth0.com/docs/get-started/dashboard/application-settings) for more information on getting the Client ID and Client Secret for your machine-to-machine app.
+:::
+
+```har
+{
+  "method": "POST",
+  "url": "https://${account.namespace}/oauth/token",
+  "headers": [
+    { "name": "Content-Type", "value": "application/x-www-form-urlencoded" }
+  ],
+  "postData": {
+    "mimeType": "application/x-www-form-urlencoded",
+    "params": [
+      {
+        "name": "grant_type",
+        "value": "client_credentials"
+      },
+      {
+        "name": "client_id",
+        "value": "${account.clientId}"
+      },
+      {
+        "name": "client_secret",
+        "value": "YOUR_CLIENT_SECRET"
+      },
+      {
+        "name": "audience",
+        "value": "YOUR_API_IDENTIFIER"
+      }
+    ]
+  }
+}
+```
+
+:::note
+Auth0 customers are billed based on the number of Machine to Machine Access Tokens issued by Auth0. Once your application gets an Access Token it should keep using it until it expires, to minimize the number of tokens requested.
+:::
+
+For testing purposes, you can also get an Access Token from the **Test** tab in your [API settings](${manage_url}/#/apis).
+
+## Test Your API 
+
+**1. Calling the secure endpoint**
+
+You can make a request to the `/api/private` endpoint without passing any Access Token:
+
+```har
+{
+  "method": "GET",
+  "url": "http://localhost:3010/api/private"
+}
+```
+
+The API will return a 401 HTTP (Unauthorized) status code:
+
+![Response for unauthorized API request](/media/articles/server-apis/using/private-unauthorized.png)
+
+Once again, make the same request but this time pass along the Access Token as a Bearer token in the **Authorization** header of the request:
+
+```har
+{
+  "method": "GET",
+  "url": "http://localhost:3010/api/private",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN" }
+  ]
+}
+```
+
+This time the API will return a successful response:
+
+![Response for authorized API request](/media/articles/server-apis/using/private.png)
+
+**2. Testing the scoped endpoint**
+
+To test the endpoint that requires a scope, pass the Access Token containing the correct scope as a Bearer token in the Authorization header:
+
+```har
+{
+  "method": "GET",
+  "url": "http://localhost:3010/api/private-scoped",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN" }
+  ]
+}
+```
+
+If the required scope is present, the API call is successful:
+
+![Response for scoped API request](/media/articles/server-apis/using/private-scoped.png)
+
+If the required scope is not present, the API returns a 403 HTTP Status (Forbidden):
+
+![Response for forbidden scoped API request](/media/articles/server-apis/using/private-scoped-forbidden.png)
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/backend/_includes/_call_api.md b/ja-jp/articles/quickstart/backend/_includes/_call_api.md
new file mode 100644
index 0000000000..eb4073dc35
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_call_api.md
@@ -0,0 +1,19 @@
+
+
+### Make a Call to Your API
+
+To make calls to your API, you need an Access Token. You can get an Access Token for testing purposes from the **Test** view in your [API settings](${manage_url}/#/apis).
+
+![Obtain a JWT](/media/articles/server-apis/aspnet-core-webapi/request-access-token.png)
+
+Provide the Access Token as an `Authorization` header in your requests.
+
+```har
+{
+  "method": "GET",
+  "url": "http://your-domain.com/api_path",
+  "headers": [
+    { "name": "Authorization", "value": "Bearer YOUR_ACCESS_TOKEN_HERE" }
+  ]
+}
+```
diff --git a/ja-jp/articles/quickstart/backend/_includes/_updating_notice.md b/ja-jp/articles/quickstart/backend/_includes/_updating_notice.md
new file mode 100644
index 0000000000..2aa91865c6
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_includes/_updating_notice.md
@@ -0,0 +1,3 @@
+## Update Notice
+
+This doc is currently being updated, please check back soon.
diff --git a/ja-jp/articles/quickstart/backend/_thirdPartyApi.md b/ja-jp/articles/quickstart/backend/_thirdPartyApi.md
new file mode 100644
index 0000000000..f8a12791b9
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/_thirdPartyApi.md
@@ -0,0 +1,24 @@
+# <%= meta.name %> API
+
+Please follow the steps below to configure your Auth0 tenant to work with <%= meta.name %>.
+
+## 1. Activate the add-on
+
+<% if (account.clientId) { %>
+Go to Application Add-ons page and activate the <%= meta.name %> add-on.
+<% } else { %>
+Go to Application Add-ons page and activate the <%= meta.name %> add-on.
+<% } %>
+
+
+![](/media/articles/server-apis/addons.png)
+
+Each integration is different and requires different parameters and configuration. Once the add-on is activated, you will see tailored instructions with details on how to get this done.
+
+## 2. Use it
+
+The key to this integration is the Delegation endpoint in Auth0. Check the documentation of any of our frontend or Mobile SDKs to learn how to call [the /delegation endpoint](/api/authentication#delegation). You can download your favorite library from any of the [Quickstarts](/).
+
+## 3. You are done!
+
+Congrats! You've implemented Delegation for the <%= meta.name %> API
diff --git a/ja-jp/articles/quickstart/backend/acul/files/auth_config.md b/ja-jp/articles/quickstart/backend/acul/files/auth_config.md
new file mode 100644
index 0000000000..63471fea63
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/acul/files/auth_config.md
@@ -0,0 +1,12 @@
+---
+name: auth_config.json
+language: json
+---
+    
+```json
+//auth0-react-samples/Sample-01/src/auth_config.json
+{
+  "domain": "${account.namespace}",
+  "clientId": "${account.clientId}"
+}
+```
diff --git a/ja-jp/articles/quickstart/backend/acul/files/index.md b/ja-jp/articles/quickstart/backend/acul/files/index.md
new file mode 100644
index 0000000000..25b8cf231b
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/acul/files/index.md
@@ -0,0 +1,47 @@
+---
+name: index.tsx
+language: javascript
+---
+    
+```javascript
+import { LoginId } from '@auth0/auth0-acul-js';
+import { useState } from 'react';
+
+export const LoginIdScreen = () => {
+  const loginManager = new LoginId();
+  const [email, setEmail] = useState('');
+
+  return (
+    
      
+      
      
+         setEmail(e.target.value)}
+          className="w-full px-3 py-2 border border-gray-300 rounded-md shadow-sm placeholder-gray-400 focus:outline-none focus:ring-2 focus:ring-blue-500 focus:border-blue-500"
+        />
+
+        
+
+        {loginManager.transaction.alternateConnections?.map(({ name, strategy }) => (
+          
+        ))}
+      
      
+    
      
+  );
+};
+
+export default LoginIdScreen
+```
diff --git a/ja-jp/articles/quickstart/backend/acul/files/settings.md b/ja-jp/articles/quickstart/backend/acul/files/settings.md
new file mode 100644
index 0000000000..3ed683eb71
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/acul/files/settings.md
@@ -0,0 +1,34 @@
+---
+name: settings.json
+language: json
+---
+    
+```json
+{
+  "rendering_mode": "advanced",
+  "context_configuration": [
+    "screen.texts"
+  ],
+  "default_head_tags_disabled": false,
+  "head_tags": [
+    {
+      "attributes": {
+        "async": true,
+        "defer": true,
+        "integrity": [
+          "ASSET_SHA"
+        ],
+        "src": "http://127.0.0.1:8080/index.js"
+      },
+      "tag": "script"
+    },
+    {
+      "attributes": {
+        "href": "http://127.0.0.1:8080/index.css",
+        "rel": "stylesheet"
+      },
+      "tag": "link"
+    }
+  ]
+}
+```
diff --git a/ja-jp/articles/quickstart/backend/acul/interactive.md b/ja-jp/articles/quickstart/backend/acul/interactive.md
new file mode 100644
index 0000000000..4be654ab19
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/acul/interactive.md
@@ -0,0 +1,115 @@
+---
+title: Build a Login ID screen using ACUL
+description: Learn how to build a Login screen using ACUL
+interactive:  true
+files:
+ - files/settings
+ - files/auth_config
+ - files/index
+github:
+  path: https://github.com/auth0-samples/auth0-react-samples/tree/master/Sample-01
+locale: ja-JP
+---
+
+# Build a Login ID screen using ACUL
+
+
+
      `
      
+
+## 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.
      サンプルプロジェクトに沿って進めている場合は、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.
      サンプルプロジェクトに沿って進めている場合は、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.
      サンプルプロジェクトに沿って進めている場合は、http://localhost:3000に設定してください。
      
+
+## Configure ACUL for Login ID screen {{{ data-action="code" data-code="settings.json" }}}
+
+
+
      Use Auth0 CLI to enable ACLU Login ID screen in your tenant. 
+
+
+
+In the root directory of your project, save the settings.json file.
      Enable ACUL by running the following command in your terminal:
      auth0 ul customize --rendering-mode advanced --prompt login-id --screen login-id --settings-file ./settings.json
+
+
      
+
+
      Development Setup: This example is using localhost (127.0.0.1:8080) for development. 
      For production, you will need to update these URLs to point to your CDN or static hosting service.
      
+
+## Initiate Universal Login {{{ data-action="code" data-code="auth_config.json" }}}
+
+
+
      Use one of the sample apps provided by Auth0 to initiate Universal Login
      In the root folder of your project, clone the Auth0 sample application using the following command:
+
+
+
+
      git clone https://github.com/auth0-samples/auth0-react-samples
+
+
      
+
+
      Change directory to the auth0-react-samples/Sample-01 folder and install the sample application using the following command:
      cd auth0-react-samples/Sample-01
+
+npm install
+
+
      
+
+
      Change directory  to the auth0-react-samples/Sample-01/src folder and add the auth_config.json file. Edit the file to add your tenant's Custom Domain.
      Run the application
      npm run dev
+
+
      
+
+
      ACUL Login ID screen Step 2 - Checkpoint 
      1. Open your application (default: http://localhost:3000)
      2. Select the Log In button on the sample app
      3. You should be redirected to your Auth0 domain
      After selecting Log In, you should see a blank page. 
      This is expected! It means Auth0 is trying to load your custom UI assets, which we have not created yet. 
      
+
+  
      
+
+  
      If you see the default Auth0 page instead of a blank page:
      1. Check if your custom domain is properly configured.
      2. Ensure your application is using the custom domain.
      
+
+  
      
+
+
      
+
+ 
      
+
+
      
+
+## Build a custom interface for login-id screen {{{ data-action="code" data-code="index.tsx" }}}
+
+
+
      Run a single-page application to build custom login screens. 
      Configure the Boilerplate application
      1. In the root folder of your project, open a new terminal and clone the Auth0 boilerplate application using the following command:
      git clone https://github.com/auth0-samples/auth0-acul-react-boilerplate
+
+
      
+
+
      2. Change directory to the auth0-acul-react-boilerplate folder and install the application and the ACUL JS SDK.
      // open the directory where you git clone the boilerplate
+
+cd auth0-acul-react-boilerplate && npm i
+
+
+
+// Install the ACUL JS SDK
+
+npm install @auth0/auth0-acul-js
+
+
      
+
+
      3. Build the application
      npm run build
+
+
      
+
+
      4. Serve the assets
      npx http-server dist -p 8080
+
+
      
+
+
      The assets are served from localhost during development. 
      For production, you'll need to serve these assets from a CDN or static hosting service.
      ACUL Login ID screen quickstart step 4 checkpoint 
      After selecting Log In, you are greeted with a “Hello World” page. 
      
+
+  
      
+
+  
      Make sure to have installed the ACUL JS SDK after installing the boilerplate application.
      
+
+  
      Build the ACUL Login ID screen 
      Change directory to the auth0-acul-react-boilerplate/src/screens/loginId/ and edit the index.tsx file.
      Rebuild the application with the following command:
      npm run build
+
+
      
+
+
      ACUL Login ID screen quickstart step 4 rebuild the app checkpoint 
      Select Log In. 
      You should now see a customized login page as shown below:
      
+
+  
      
+
+  
      
+
+  
      
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..03f7cca1d3
--- /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: https://github.com/auth0-samples/auth0-aspnetcore-webapi-samples/tree/master/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スコープが付与されたアクセストークンを含む認証された要求に使用できる。
      
+
+  
      
+
+  
      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/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..7a7e104626
--- /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: https://github.com/auth0-samples/auth0-django-api/tree/master/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..0e60bc7e00
--- /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: https://github.com/auth0-samples/auth0-golang-api-samples/tree/master/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スコープが付与されたアクセストークンを含む認証された要求に使用できる。
      
+
+  
      
+
+  
      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/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..4394acf8f2
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/java-spring-security5/interactive.md
@@ -0,0 +1,129 @@
+---
+title: Spring Bootアプリケーションに認可を追加する
+description: このガイドは、新規または既存のSpring BootアプリケーションにAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/application
+ - files/SecurityConfig
+ - files/Message
+ - files/APIController
+github:
+  path: https://github.com/auth0-samples/auth0-spring-security5-api-sample/tree/master/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をテストおよび使用する方法についてお読みください。
      
+
+  
      
+
+  
      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/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..a62b0a1aec
--- /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: https://github.com/auth0-samples/laravel/tree/7.x/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'
      
+
+  
      
+
+  
      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.
      
+
+  
      その他の情報
      • ユーザーリポジトリとモデルは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..e76f1173d7
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/nodejs/interactive.md
@@ -0,0 +1,53 @@
+---
+title: Express.js APIアプリケーションに認可を追加する
+description: このガイドは、新規または既存のExpress.js APIアプリケーションにexpress-oauth2-jwt-bearerパッケージを使ってAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/server
+github:
+  path: https://github.com/auth0-samples/auth0-express-api-samples/tree/master/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://${account.namespace}/api_path \
+
+  --header 'authorization: Bearer YOUR_ACCESS_TOKEN_HERE'
+
+
      
+
+
      Node JS API手順4「チェックポイント」 
      アプリケーションの構成が完了したら、アプリケーションを実行して次の点を確認します：
      • GET /api/publicが認証を必要としない要求に使用できる。
      • GET /api/privateが認証された要求に使用できる。
      • GET /api/private-scopedがread:messagesスコープが付与されたアクセストークンを含む認証された要求に使用できる。
      
+
+  
      
+
+  
      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/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..f788ec3f89
--- /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: https://github.com/auth0-samples/auth0-php-api-samples/tree/main/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に関連したエラーを投入していない。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## ベアラートークンをリッスンする {{{ 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..389cbe34fb
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/python/interactive.md
@@ -0,0 +1,54 @@
+---
+title: Flask APIアプリケーションに認可を追加する
+description: このガイドは、Flaskを使ってビルドされた新規または既存のPython APIにAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/validator
+ - files/server
+github:
+  path: https://github.com/auth0-samples/auth0-python-api-samples/tree/master/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'
+
+
      
+
+
      
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..7f0fd69d9c
--- /dev/null
+++ b/ja-jp/articles/quickstart/backend/rails/interactive.md
@@ -0,0 +1,74 @@
+---
+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: https://github.com/auth0-samples/auth0-rubyonrails-api-samples/tree/master/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'
+
+
      
+
+
      Ruby on rails手順7「チェックポイント」 
      アプリケーションの構成が完了したら、アプリケーションを実行して次の点を確認します：
      • GET /api/publicが認証を必要としない要求に使用できる。
      • GET /api/privateが認証された要求に使用できる。
      • GET /api/private-scopedがread:messagesスコープが付与されたアクセストークンを含む認証された要求に使用できる。
      
+
+  
      
+
+  
      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/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..55317245c5
--- /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: https://github.com/auth0-samples/auth0-aspnet-owin-webapi-samples/tree/master/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スコープが付与されたアクセストークンを含む認証された要求に使用できる。
      
+
+  
      
+
+  
      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/ja-jp/articles/quickstart/config.yml b/ja-jp/articles/quickstart/config.yml
new file mode 100644
index 0000000000..a99856f831
--- /dev/null
+++ b/ja-jp/articles/quickstart/config.yml
@@ -0,0 +1,4 @@
+author:
+  name: Auth0
+  email: support@auth0.com
+  community: false
diff --git a/ja-jp/articles/quickstart/native/_includes/_authorization-create-rule.md b/ja-jp/articles/quickstart/native/_includes/_authorization-create-rule.md
new file mode 100644
index 0000000000..ef210437db
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_authorization-create-rule.md
@@ -0,0 +1,11 @@
+First, you will create a rule that assigns users to either an `admin` role, or a single `user` role. Go to the [New Rule](${manage_url}/#/rules/new) page on the Auth0 dashboard and select the **Set Roles To A User** template, under **Access Control**.
+
+By default, this rule will assign the user an `admin` role if their email contains `@example.com`. Otherwise, they will be assigned a regular `user` role.
+
+You can modify this line in the default script to change the domain name to one suitable for your setup:
+
+`if (user.email.indexOf('@example.com') > -1)`
+
+::: note
+You can set roles other than `admin` and `user` or customize the rule as needed.
+:::
diff --git a/ja-jp/articles/quickstart/native/_includes/_authorization-introduction.md b/ja-jp/articles/quickstart/native/_includes/_authorization-introduction.md
new file mode 100644
index 0000000000..a96342dad8
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_authorization-introduction.md
@@ -0,0 +1,5 @@
+Many identity providers will supply access claims, like roles or groups, with the user. You can request these in the token by setting `scope: openid roles` or `scope: openid groups`. However, not every identity provider supplies this type of information. Fortunately, Auth0 has an alternative, which is to create a rule for assigning different roles to different users.
+
+::: note
+This tutorial assumes that you have already completed the [rules tutorial](${ruleslink}) and that you know how to implement a basic rule in your app.
+:::
diff --git a/ja-jp/articles/quickstart/native/_includes/_callback-url-introduction.md b/ja-jp/articles/quickstart/native/_includes/_callback-url-introduction.md
new file mode 100644
index 0000000000..8b41d237de
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_callback-url-introduction.md
@@ -0,0 +1,9 @@
+
+
+A callback URL is a URL in your application where Auth0 redirects the user after they have been authenticated. Auth0 adds parameters to the callback URL, including a token. 
+
+Callback URLs can be manipulated by attackers. For security, add your application's URL to the **Allowed Callback URLs** field in your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings). 
+
+If you do not add your application's URL to the list of Allowed Callback URLs, your users will see a mismatch error when they try to log in.
+
+![Callback error](/media/articles/angularjs/callback_error.png)
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/_includes/_calling_api_create_api.md b/ja-jp/articles/quickstart/native/_includes/_calling_api_create_api.md
new file mode 100644
index 0000000000..755ffb537d
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_calling_api_create_api.md
@@ -0,0 +1,7 @@
+## Create an Auth0 API
+
+In the [APIs section](${manage_url}/#/apis) of the Auth0 dashboard, click **Create API**. Provide a name and an identifier for your API.
+You will use the identifier later when you're preparing the Web Authentication.
+For **Signing Algorithm**, select **RS256**.
+
+![Create API](/media/articles/api-auth/create-api.png)
diff --git a/ja-jp/articles/quickstart/native/_includes/_calling_api_create_scope.md b/ja-jp/articles/quickstart/native/_includes/_calling_api_create_scope.md
new file mode 100644
index 0000000000..6ea9af9d0b
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_calling_api_create_scope.md
@@ -0,0 +1,11 @@
+## Add a Scope
+
+By default, the Access Token does not contain any authorization information. To limit access to your resources based on authorization, you must use scopes. Read more about scopes in the [scopes documentation](/scopes).
+
+In the Auth0 dashboard, in the [APIs section](${manage_url}/#/apis), click **Scopes**. Add any scopes you need to limit access to your API resources.
+
+::: note
+You can give any names to your scopes. A common pattern is `:`. The example below uses the name `read:messages` for a scope.
+:::
+
+![create scope](/media/articles/api-auth/create-scope.png)
diff --git a/ja-jp/articles/quickstart/native/_includes/_cordova_setup.md b/ja-jp/articles/quickstart/native/_includes/_cordova_setup.md
new file mode 100644
index 0000000000..2c03b6254d
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_cordova_setup.md
@@ -0,0 +1,30 @@
+To integrate Auth0 in a hybrid Cordova application, you can use the `@auth0/cordova` package available on npm. This package provides an interface with Cordova which allows you to use the [Proof Key for Code Exchange (PKCE)](https://tools.ietf.org/html/rfc7636) spec. PKCE is recommended for native and hybrid applications to mitigate the threat of authorization code interception.
+
+::: note
+Please note that PKCE authentication requires testing on either an emulated or real device. Attempting authentication when testing in the browser will fail because PKCE requires a device browser.
+:::
+
+<%= include('../../../_includes/_new_app') %>
+
+<%= include('../../../_includes/_callback_url') %>
+
+The **Callback URL** to be used for your application includes your app's package ID which is found in the `config.xml` file for your app.
+
+Go to the Application Settings section in your Auth0 dashboard and set your **Callback URL** in the **Allowed Callback URLs** box.
+
+```bash
+# replace YOUR_PACKAGE_ID with your app package ID
+YOUR_PACKAGE_ID://${account.namespace}/cordova/YOUR_PACKAGE_ID/callback
+```
+
+Add `file` as an allowed origin to the **Allowed Origins (CORS)** box.
+
+```bash
+file://*
+```
+
+Lastly, be sure that the **Application Type** for your application is set to **Native** in its settings.
+
+${snippet(meta.snippets.dependencies)}
+
+${snippet(meta.snippets.setup)}
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/_includes/_create_application.md b/ja-jp/articles/quickstart/native/_includes/_create_application.md
new file mode 100644
index 0000000000..a91678b6e6
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_create_application.md
@@ -0,0 +1,3 @@
+## Create an application
+
+Create a new application in your [Auth0 dashboard](${manage_url}/#/application). For **Type**, select **Native**.
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/_includes/_dotnet-oidc-client-configuration.md b/ja-jp/articles/quickstart/native/_includes/_dotnet-oidc-client-configuration.md
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/ja-jp/articles/quickstart/native/_includes/_facebook_login_howto.md b/ja-jp/articles/quickstart/native/_includes/_facebook_login_howto.md
new file mode 100644
index 0000000000..9a6db5a92e
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_facebook_login_howto.md
@@ -0,0 +1,62 @@
+## Set up the “Continue with Facebook” button
+
+This guide will help you add authentication with Auth0 to the application you built in the first step.
+
+### Request Facebook permissions
+
+Your application is already able to sign in with Facebook. However, to ensure you have a rich user profile, you need to update the permissions with which the Facebook Login Button was set up.
+
+${snippet(meta.snippets.facebook_button_permissions)}
+
+Now, to kick off the authentication process with Auth0, create a new method in which you will prepare the payload to be sent. 
+
+${snippet(meta.snippets.facebook_button_config)}
+
+## Integrate Facebook
+
+When you sign in with Facebook at Auth0, the backend will perform some checks in the background to ensure the user is who they say they are. To achieve this, it needs to be provided with a Session Access Token. 
+
+Furthermore, if a user needs to be created on Auth0 to represent this Facebook user, the backend will require some of their information, such as their name, last name, and email. The email, if provided, will be **flagged as non-verified** on the Auth0 user profile.
+
+To obtain the Session Access Token and the user profile, two additional requests need to be made against the Facebook API.
+
+### Fetch Facebook session Access Token
+
+Make a new GET request against the Facebook API's `/oauth/access_token` endpoint.
+Use the following query parameters:
+- `grant_type`: `fb_attenuate_token`.
+- `fb_exchange_token`: the access token received upon login.
+- `client_id`: your App ID. This value comes from the Facebook Developer's dashboard and should already be in use in your application if you have integrated Facebook Login successfully.
+
+Put the logic from this step in its own method. You will be calling it later from the previously-added method.
+
+${snippet(meta.snippets.facebook_fetch_session_token)}
+
+### Fetch Facebook user profile
+
+Now make another GET request, just like in the step above. The endpoint path will be the User ID value from the Facebook login result (for example, `/904636746222815`).
+Use the following parameters:
+- `access_token`: the access token received upon login.
+- `fields`: the fields from the user profile that you'd like to get back in the response. These are directly tied to the Facebook Login Button permissions that were configured at the beginning. When a permission is optional, the user must first consent to give access to it. For the purpose of signing up a user at Auth0, their full name and email will suffice. 
+
+${snippet(meta.snippets.facebook_fetch_profile)}
+
+## Integrate Auth0
+
+Now that the required artifacts have been obtained, you are ready to trade them for Auth0 user credentials, such as the ID and Access Tokens. But first, you must set up the Auth0 SDK to make that last request.
+
+### Get your application keys
+
+Go to the **Applications** section of the [Auth0 Dashboard](https://manage.auth0.com/) and select the existing application in which you enabled **Sign in with Facebook**. If you need help with this step, please check the requirements section at the top of this article.
+
+Copy the **Domain** and **Client ID** values from the application settings page. These are required by the SDK.
+
+${snippet(meta.snippets.facebook_app_credentials)}
+
+### Install the Auth0 SDK
+
+${snippet(meta.snippets.facebook_install_auth0_sdk)}
+
+### Exchange the received data for Auth0 tokens
+
+${snippet(meta.snippets.facebook_token_exchange)}
diff --git a/ja-jp/articles/quickstart/native/_includes/_facebook_login_prerequisites.md b/ja-jp/articles/quickstart/native/_includes/_facebook_login_prerequisites.md
new file mode 100644
index 0000000000..ae286d7f70
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_facebook_login_prerequisites.md
@@ -0,0 +1,6 @@
+This tutorial describes how to implement login with the [Facebook SDK](https://developers.facebook.com/docs/).
+​
+## Before You Start
+​
+- Install and configure the [Facebook Login SDK](https://developers.facebook.com/docs/facebook-login/). You’ll also go through the process of creating a Facebook app in [https://developers.facebook.com](https://developers.facebook.com). **When you finish this step, you should have a mobile app running with Facebook Login integrated.**  
+- Configure your Auth0 application in the dashboard to use Facebook Native Sign In. See [Add Facebook Login to Native Apps](/connections/nativesocial/facebook). **When you finish this step, your application will be able to implement Facebook Native Login.**
diff --git a/ja-jp/articles/quickstart/native/_includes/_getting_started.md b/ja-jp/articles/quickstart/native/_includes/_getting_started.md
new file mode 100644
index 0000000000..23cbcdbe4f
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_getting_started.md
@@ -0,0 +1,7 @@
+::: note
+**New to Auth?** Learn [How Auth0 works](/overview), how it [integrates with Native Applications](/architecture-scenarios/application/mobile-api) and which [protocol](/api-auth/grant/authorization-code-pkce) it uses.
+:::
+
+<%= include('../../../_includes/_new_app') %>
+
+
diff --git a/ja-jp/articles/quickstart/native/_includes/_ionic_setup.md b/ja-jp/articles/quickstart/native/_includes/_ionic_setup.md
new file mode 100644
index 0000000000..9638a40d51
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_ionic_setup.md
@@ -0,0 +1,57 @@
+To integrate Auth0 in a hybrid Ionic app, you can use the `@auth0/cordova` package available on npm. This package provides an interface with Cordova which allows you to use the [Proof Key for Code Exchange (PKCE)](https://tools.ietf.org/html/rfc7636) spec. PKCE is recommended for native and hybrid applications to mitigate the threat of authorization code interception.
+
+::: note
+Please note that PKCE authentication requires testing on either an emulated or real device. Attempting authentication when testing in the browser will fail because PKCE requires a device browser.
+:::
+
+<%= include('../../../_includes/_new_app') %>
+
+<%= include('../../../_includes/_callback_url') %>
+
+The **Callback URL** to be used for your application includes your app's package ID which is found in the `config.xml` file for your app.
+
+Go to the Application Settings section in your Auth0 dashboard and set your **Callback URL** in the **Allowed Callback URLs** box.
+
+```bash
+# replace YOUR_PACKAGE_ID with your app package ID
+YOUR_PACKAGE_ID://${account.namespace}/cordova/YOUR_PACKAGE_ID/callback
+```
+
+Add `file` as an allowed origin to the **Allowed Origins (CORS)** box.
+
+```bash
+file://*
+```
+
+Lastly, be sure that the **Application Type** for your application is set to **Native** in the application settings.
+
+## Install the Dependencies
+
+The required dependencies for using Auth0 in an Ionic application are **auth0.js** and **auth0-cordova**. Install them with npm or yarn.
+
+```bash
+# installation with npm
+npm install auth0-js @auth0/cordova --save
+
+# installation with yarn
+yarn add auth0-js @auth0/cordova
+```
+
+## Add Cordova Plugins
+
+You must install the `SafariViewController` plugin from Cordova to be able to use Universal Login. The downloadable sample project already has this plugin added, but if you are embedding Auth0 in your own application, install the plugin via the command line.
+
+```bash
+ionic cordova plugin add cordova-plugin-safariviewcontroller
+```
+
+The `CustomURLScheme` plugin from Cordova is also required to handle redirects properly. The sample project has it already, but if you're adding Auth0 to your own project, install this plugin as well.
+
+```bash
+# replace YOUR_PACKAGE_ID with your app identifier
+ionic cordova plugin add cordova-plugin-customurlscheme --variable URL_SCHEME={YOUR_PACKAGE_ID} --variable ANDROID_SCHEME={YOUR_PACKAGE_ID} --variable ANDROID_HOST=${account.namespace} --variable ANDROID_PATHPREFIX=/cordova/{YOUR_PACKAGE_ID}/callback
+```
+
+## Modify config.xml
+
+Add `` to your config.xml. This will allow the Auth0 dialog to properly redirect back to your app.
diff --git a/ja-jp/articles/quickstart/native/_includes/_ios_config.md b/ja-jp/articles/quickstart/native/_includes/_ios_config.md
new file mode 100644
index 0000000000..d5e5a479a9
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_ios_config.md
@@ -0,0 +1,62 @@
+
+
+## Add Auth0 Credentials
+
+You will need some details about this application to communicate with Auth0. You can get these details from the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) in the Auth0 dashboard.
+
+You need the following information: 
+* **Client ID**
+* **Domain**
+
+::: note
+If you download the sample from the top of this page, these details are filled out for you.
+:::
+
+Add your credentials in `Auth0.plist`. If the file does not exist in your project yet, create one with the information below ([Apple documentation on Property List Files](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html)):
+
+```xml
+
+
+
+
+
+
+  ClientId
+  ${account.clientId}
+  Domain
+  ${account.namespace}
+
+
+```
+
+<%= include('../../../_includes/_callback_url') %>
+
+In your application's `Info.plist` file, register your iOS Bundle identifier as a custom scheme:
+
+```xml
+
+
+CFBundleURLTypes
+
+    
+        CFBundleTypeRole
+        None
+        CFBundleURLName
+        auth0
+        CFBundleURLSchemes
+        
+            $(PRODUCT_BUNDLE_IDENTIFIER)
+        
+    
+
+```
+
+::: note
+If your `Info.plist` file is not in the format shown above, you can right-click `Info.plist` in Xcode and select **Open As** > **Source Code**.
+:::
+
+Go to your [Dashboard Settings](${manage_url}/#/applications/${account.clientId}/settings) and make sure that the **Allowed Callback URLs** field contains the following callback URL:
+
+```text
+{PRODUCT_BUNDLE_IDENTIFIER}://${account.namespace}/ios/{PRODUCT_BUNDLE_IDENTIFIER}/callback
+```
diff --git a/ja-jp/articles/quickstart/native/_includes/_ios_dependency_centralized.md b/ja-jp/articles/quickstart/native/_includes/_ios_dependency_centralized.md
new file mode 100644
index 0000000000..86e62af190
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_ios_dependency_centralized.md
@@ -0,0 +1,49 @@
+
+
+## Install Dependencies
+
+### Cocoapods
+
+If you are using [Cocoapods](https://cocoapods.org), add this line to your `Podfile`:
+
+```ruby
+pod 'Auth0', '~> 1.0'
+```
+
+Then run `pod install`.
+
+::: note
+For more information on Cocoapods, check [their official documentation](https://guides.cocoapods.org/using/getting-started.html).
+:::
+
+### Carthage
+
+If you are using [Carthage](https://github.com/Carthage/Carthage), add the following line to your `Cartfile`:
+
+```ruby
+github "auth0/Auth0.swift" ~> 1.0
+```
+
+Then run `carthage bootstrap`.
+
+::: note
+For more information about Carthage usage, check [their official documentation](https://github.com/Carthage/Carthage#if-youre-building-for-ios-tvos-or-watchos).
+:::
+
+### SPM
+
+If you are using the Swift Package Manager, open the following menu item in Xcode:
+
+**File > Add Packages...**
+
+In the **Search or Enter Package URL** search box enter this url: 
+
+```text
+https://github.com/auth0/Auth0.swift.git
+```
+
+Then select the dependency rule and press **Add Package**.
+
+::: note
+For further reference on SPM, check [its official documentation](https://developer.apple.com/documentation/swift_packages/adding_package_dependencies_to_your_app).
+:::
diff --git a/ja-jp/articles/quickstart/native/_includes/_ios_link_accounts.md b/ja-jp/articles/quickstart/native/_includes/_ios_link_accounts.md
new file mode 100644
index 0000000000..956318d9bb
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_ios_link_accounts.md
@@ -0,0 +1,6 @@
+## Link the Accounts
+
+Now, you can link the accounts. To do this, you need the following values: 
+- `id`: the logged-in user's ID (see `profile.sub`)
+- `accessToken`: a Management API access token for the saved account the user initially logged in to; must have the `update:current_user_identities` scope
+- `otherUserToken`: the ID Token for the second account received in the last login response
diff --git a/ja-jp/articles/quickstart/native/_includes/_ios_unlink_accounts.md b/ja-jp/articles/quickstart/native/_includes/_ios_unlink_accounts.md
new file mode 100644
index 0000000000..c4c1ea1510
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_ios_unlink_accounts.md
@@ -0,0 +1,5 @@
+## Unlink the Accounts
+
+To unlink the accounts, you need to specify the following: 
+* `id`: the logged-in user's ID (see `profile.sub`)
+* `userId` and `provider`: the values in the `identity` object you want to unlink
diff --git a/ja-jp/articles/quickstart/native/_includes/_new_app.html b/ja-jp/articles/quickstart/native/_includes/_new_app.html
new file mode 100644
index 0000000000..6b84b0d4e5
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_new_app.html
@@ -0,0 +1,5 @@
+<% if (account.userName) { %>
+  
      Fetch your credentials (Domain, Client ID, and Client Secret) from your dashboard and store somewhere safe. You will need them while configuing Angular in your application. The sample is configured with your `Default App` credentials if you prefer to start with having a look at it.
      
+<% } else { %>
+  
      Create an Auth0 account (or login) and an authentication application instance from your dashboard. Once you create an app, you'll be provided with credentials (Domain, Client ID, and Client Secret) which should be stored somewhere safe (do not commit this information to your git repo!). You can start be downloading the sample after you login as it is configured with your `Default App` credentials
      
+<% } %>
diff --git a/ja-jp/articles/quickstart/native/_includes/_new_app_no_sample.html b/ja-jp/articles/quickstart/native/_includes/_new_app_no_sample.html
new file mode 100644
index 0000000000..039e33abfb
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_new_app_no_sample.html
@@ -0,0 +1,5 @@
+<% if (account.userName) { %>
+  
      Get your credentials (Domain, Client ID, and Client Secret) from the dashboard. Be sure to select Native as the Application Type. 
+<% } else { %>
+  
      Create an Auth0 account (or login) and add an authentication application instance from the dashboard. Once you create your application, you will be provided with credentials (Domain, Client ID, and Client Secret) which should be stored somewhere safe (do not commit this information to your git repo!). Be sure to select Native as the Application Type.
+<% } %>
diff --git a/ja-jp/articles/quickstart/native/_includes/_profile-metadata-explanation.md b/ja-jp/articles/quickstart/native/_includes/_profile-metadata-explanation.md
new file mode 100644
index 0000000000..c5503ba31a
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_profile-metadata-explanation.md
@@ -0,0 +1 @@
+Auth0 allows you to store user information that has not come from the identity provider as metadata. There are two types of metadata, **user_metadata** and **app_metadata**. For more information, see: [Metadata](/users/concepts/overview-user-metadata).
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/_includes/_rules-create-section.md b/ja-jp/articles/quickstart/native/_includes/_rules-create-section.md
new file mode 100644
index 0000000000..32426a0548
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_rules-create-section.md
@@ -0,0 +1,11 @@
+To create a rule, go to the [New Rule](${manage_url}/#/rules/new) page. You can create a rule from scratch by selecting an empty rule, or use one of the existing templates. These templates are written by Auth0 to assist you to in executing common tasks. 
+
+For this example, select the **Add country to the user profile** rule.
+
+![Empty rule](/media/articles/rules/rule-choose-add-country-template.png)
+
+This rule extracts the `country_name` from the `context` and adds it to the user profile as a new `country` attribute.
+
+![Add country rule](/media/articles/rules/rule-create-add-country-country.png)
+
+This is just the beginning, you can edit the rule to meet your business needs. Once complete, click **Save**. The rule will execute any time a user logs in, and the country will be added to the user's profile.
diff --git a/ja-jp/articles/quickstart/native/_includes/_rules-introduction.md b/ja-jp/articles/quickstart/native/_includes/_rules-introduction.md
new file mode 100644
index 0000000000..ffd19a504a
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_rules-introduction.md
@@ -0,0 +1 @@
+Rules are one of the most powerful features of Auth0. As JavaScript functions that execute each time a user authenticates, rules serve as middleware to extend the flexibility of your authentication flow. For a detailed description of rules, see the [full documentation](/rules).
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/_includes/_rules-test-result-intro.md b/ja-jp/articles/quickstart/native/_includes/_rules-test-result-intro.md
new file mode 100644
index 0000000000..af8850b325
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/_rules-test-result-intro.md
@@ -0,0 +1,3 @@
+To see the results of a created rule, login and fetch user profile information as explained in the [User Profile](${profilelink}) step.
+
+Then you can display the user profile's new `country` attribute added by the rule:
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/_includes/ionic/_add_login_intro.md b/ja-jp/articles/quickstart/native/_includes/ionic/_add_login_intro.md
new file mode 100644
index 0000000000..368ce98b12
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/ionic/_add_login_intro.md
@@ -0,0 +1,7 @@
+
+
+In a Capacitor application, the [Capacitor's Browser plugin](https://capacitorjs.com/docs/apis/browser) performs a redirect to the Auth0 [Universal Login Page](https://auth0.com/universal-login). Set the `openUrl` parameter on the `loginWithRedirect` function to use `Browser.open` so that the URL is opened using the device's system browser component ([SFSafariViewController](https://developer.apple.com/documentation/safariservices/sfsafariviewcontroller) on iOS, and [Chrome Custom Tabs](https://developer.chrome.com/docs/android/custom-tabs) on Android).
+
+:::note
+By default, the SDK's `loginWithRedirect` method uses `window.location.href` to navigate to the login page in the default browser application on the user's device rather than the system browser component appropriate for the platform. The user would leave your application to authenticate and could make for a suboptimal user experience.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/_includes/ionic/_add_logout_intro.md b/ja-jp/articles/quickstart/native/_includes/ionic/_add_logout_intro.md
new file mode 100644
index 0000000000..0cf81e522f
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/ionic/_add_logout_intro.md
@@ -0,0 +1,13 @@
+
+
+Now that users can log in, you need to configure [a way to log out](https://auth0.com/docs/logout/guides/logout-auth0). Users must redirect to the Auth0 logout endpoint in the browser to clear their browser session. Again, Capacitor's Browser plugin should perform this redirect so that the user does not leave your app and receive a suboptimal experience.
+
+To achieve this with Ionic and Capacitor in conjunction with the Auth0 SDK:
+
+* Construct the URL for your app Auth0 should use to redirect to after logout. This is a URL that uses your registered custom scheme and Auth0 domain. Add it to your **Allowed Logout URLs** configuration in the Auth0 Dashboard
+* Logout from the SDK by calling `logout`, and pass your redirect URL back as the `logoutParams.returnTo` parameter.
+* Set the `openUrl` parameter to a callback that uses the Capacitor browser plugin to open the URL using `Browser.open`. 
+
+:::note
+Similar to the login step, if you do not set `openUrl` when calling `logout`, the SDK redirects the user to the logout URL using the default browser application on the device, which provides a suboptimal user experience.
+:::
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/_includes/ionic/_article_intro.md b/ja-jp/articles/quickstart/native/_includes/ionic/_article_intro.md
new file mode 100644
index 0000000000..df7c935695
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/ionic/_article_intro.md
@@ -0,0 +1,7 @@
+
+
+## Getting started
+
+This quickstart assumes you already have an [Ionic](https://ionicframework.com/) application up and running with [Capacitor](https://capacitorjs.com/). If not, check out the [Using Capacitor with Ionic Framework guide](https://capacitorjs.com/docs/getting-started/with-ionic) to get started with a simple app, or clone [our sample apps](https://github.com/auth0-samples/auth0-ionic-samples).
+
+You should also be familiar with the [Capacitor development workflow](https://capacitorjs.com/docs/basics/workflow).
diff --git a/ja-jp/articles/quickstart/native/_includes/ionic/_configure_urls.md b/ja-jp/articles/quickstart/native/_includes/ionic/_configure_urls.md
new file mode 100644
index 0000000000..e17a9f3f2a
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/ionic/_configure_urls.md
@@ -0,0 +1,35 @@
+
+
+<%= include('../../../../_includes/_callback_url') %>
+
+:::note
+Throughout this article, `YOUR_PACKAGE_ID` is your application's package ID. This can be found and configured in the `appId` field in your `capacitor.config.ts` file. See [Capacitor's Config schema](https://capacitorjs.com/docs/config#schema) for more info.
+:::
+
+Go to the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) section in your Auth0 dashboard and set your **Callback URL** in the **Allowed Callback URLs** box.
+
+You should set the **Allowed Callback URL** to:
+
+```bash
+YOUR_PACKAGE_ID://${account.namespace}/capacitor/YOUR_PACKAGE_ID/callback
+```
+
+<%= include('../../../../_includes/_logout_url') %>
+
+You should set the **Allowed Logout URLs** to
+
+```bash
+YOUR_PACKAGE_ID://${account.namespace}/capacitor/YOUR_PACKAGE_ID/callback
+```
+
+### Configure Origins
+
+To be able to make requests from your application to Auth0, set the following **Allowed Origins** in your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings).
+
+```bash
+capacitor://localhost, http://localhost
+```
+
+These origins are required for iOS and Android respectively.
+
+Lastly, be sure that the **Application Type** for your application is set to **Native** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings).
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/_includes/ionic/_configure_urls_interactive.md b/ja-jp/articles/quickstart/native/_includes/ionic/_configure_urls_interactive.md
new file mode 100644
index 0000000000..b3ffd9d464
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/ionic/_configure_urls_interactive.md
@@ -0,0 +1,43 @@
+
+
+## Configure Auth0 {{{ data-action=configure }}}
+
+To use Auth0 services, you need to have an application set up in the Auth0 Dashboard. The Auth0 application is where you will configure how you want authentication to work for your project.
+
+:::note
+Throughout this article, `YOUR_PACKAGE_ID` is your application's package ID. This can be found and configured in the `appId` field in your `capacitor.config.ts` file. See [Capacitor's Config schema](https://capacitorjs.com/docs/config#schema) for more info.
+:::
+
+### Configure an application
+
+Use the interactive selector to create a new Auth0 application or select an existing application that represents the project you want to integrate with. Every application in Auth0 is assigned an alphanumeric, unique client ID that your application code will use to call Auth0 APIs through the SDK.
+
+Any settings you configure using this quickstart will automatically update for your application in the Dashboard, which is where you can manage your applications in the future.
+
+If you would rather explore a complete configuration, you can view a sample application instead.
+
+### Configure Callback URLs
+
+A callback URL is a URL in your application that you would like Auth0 to redirect users to after they have authenticated. If not set, users will not be returned to your application after they log in.
+
+::: note
+If you are following along with our sample project, set this to `YOUR_PACKAGE_ID://${account.namespace}/capacitor/YOUR_PACKAGE_ID/callback`
+:::
+
+### Configure Logout URLs
+
+A logout URL is a URL in your application that you would like Auth0 to redirect users to after they have logged out. If not set, users will not be able to log out from your application and will receive an error.
+
+::: note
+If you are following along with our sample project, set this to `YOUR_PACKAGE_ID://${account.namespace}/capacitor/YOUR_PACKAGE_ID/callback`.
+:::
+
+### Configure Allowed Origins
+
+To be able to make requests from your native application to Auth0, set the following **Allowed Origins** in your [Application Settings](${manage_url}/#/applications/${account.clientId}/settings).
+
+::: note
+If you are following along with our sample project, set this to `capacitor://localhost, http://localhost` for iOS and Android respectively.
+:::
+
+Lastly, be sure that the **Application Type** for your application is set to **Native** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings).
diff --git a/ja-jp/articles/quickstart/native/_includes/ionic/_handle_callback_intro.md b/ja-jp/articles/quickstart/native/_includes/ionic/_handle_callback_intro.md
new file mode 100644
index 0000000000..eaa4e75188
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/ionic/_handle_callback_intro.md
@@ -0,0 +1,7 @@
+
+
+Once users logs in with the Universal Login Page, they redirect back to your app via a URL with a custom URL scheme. The `appUrlOpen` event must be handled within your app. You can call the `handleRedirectCallback` method from the Auth0 SDK to initialize the authentication state.
+
+You can only use this method on a redirect from Auth0. To verify success, check for the presence of the `code` and `state` parameters in the URL.
+
+The `Browser.close()` method should close the browser when this event is raised.
diff --git a/ja-jp/articles/quickstart/native/_includes/ionic/_install_plugins.md b/ja-jp/articles/quickstart/native/_includes/ionic/_install_plugins.md
new file mode 100644
index 0000000000..b0e37b311a
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/ionic/_install_plugins.md
@@ -0,0 +1,16 @@
+
+
+### Install Capacitor plugins
+
+This quickstart and sample make use of some of Capacitor's official plugins. Install these into your app using the following command:
+
+```bash
+npm install @capacitor/browser @capacitor/app
+```
+
+- [`@capacitor/browser`](https://capacitorjs.com/docs/apis/browser) - allows you to interact with the device's system browser and is used to open the URL to Auth0's authorizaction endpoint
+- [`@capacitor/app`](https://capacitorjs.com/docs/apis/app) - allows you to subscribe to high-level app events, useful for handling callbacks from Auth0
+
+:::note
+Capacitor's Browser plugin on iOS uses [`SFSafariViewController`](https://developer.apple.com/documentation/safariservices/sfsafariviewcontroller), which on iOS 11+ does not share cookies with Safari on the device. This means that [SSO](https://auth0.com/docs/sso) will not work on those devices. If you need SSO, please instead use a compatible plugin that uses [ASWebAuthenticationSession](https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession).
+:::
diff --git a/ja-jp/articles/quickstart/native/_includes/ionic/_note_custom_schemes.md b/ja-jp/articles/quickstart/native/_includes/ionic/_note_custom_schemes.md
new file mode 100644
index 0000000000..b5002538c0
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/ionic/_note_custom_schemes.md
@@ -0,0 +1,5 @@
+
+
+:::note
+This article assumes you will be using Custom URL Schemes to handle the callback within your application. To do this, register your `YOUR_PACKAGE_ID` as a URL scheme for your chosen platform. To learn more, read [Defining a Custom URL Scheme](https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app) for iOS, or [Create Deep Links to App Content](https://developer.android.com/training/app-links/deep-linking) for Android.
+:::
diff --git a/ja-jp/articles/quickstart/native/_includes/ionic/_note_storage.md b/ja-jp/articles/quickstart/native/_includes/ionic/_note_storage.md
new file mode 100644
index 0000000000..89e9cde61f
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/_includes/ionic/_note_storage.md
@@ -0,0 +1,9 @@
+
+
+:::warning
+To persist authentication after closing and reopening the application, you may want to set `cacheLocation` to `localstorage` when configuring the SDK, but please be aware of [the risks of storing tokens in localstorage](https://auth0.com/docs/libraries/auth0-single-page-app-sdk#change-storage-options). Also, localstorage should be treated as **transient** in Capacitor app as the data might be recovered unexpectedly in certain circumstances. Please read the [guidance on storage in the Capacitor docs](https://capacitorjs.com/docs/guides/storage#why-cant-i-just-use-localstorage-or-indexeddb).
+
+Additionally, the SDK has the ability to [use a custom cache implementation](https://github.com/auth0/auth0-spa-js/blob/master/EXAMPLES.md#creating-a-custom-cache) to store tokens, if you have a requirement to use a more secure and persistent storage mechanism.
+
+**Note** that we recommend **against** using [Capacitor's Storage plugin](https://capacitorjs.com/docs/apis/storage) to store tokens, as this is backed by [UserDefaults](https://developer.apple.com/documentation/foundation/userdefaults) and [SharedPreferences](https://developer.android.com/reference/android/content/SharedPreferences) on iOS and Android respectively. Data stored using these APIs is not encrypted, not secure, and could also be synced to the cloud.
+:::
diff --git a/ja-jp/articles/quickstart/native/android-facebook-login/00-login-facebook.md b/ja-jp/articles/quickstart/native/android-facebook-login/00-login-facebook.md
new file mode 100644
index 0000000000..d0fc42be23
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android-facebook-login/00-login-facebook.md
@@ -0,0 +1,23 @@
+---
+title: Login
+description: This tutorial demonstrates how to add user login to an Android application using native Facebook Login.
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - android
+  - facebook native
+github:
+  path: 00-login-facebook
+contentType: tutorial
+useCase: quickstart
+requirements:
+  - Android Studio 3.6.1
+  - Android SDK 25
+  - Emulator - Nexus 5X - Android 6.0
+---
+
+
+
+<%= include('../_includes/_facebook_login_prerequisites') %>
+<%= include('../_includes/_facebook_login_howto') %>
diff --git a/ja-jp/articles/quickstart/native/android-facebook-login/download.md b/ja-jp/articles/quickstart/native/android-facebook-login/download.md
new file mode 100644
index 0000000000..20fbcf5b47
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/android-facebook-login/download.md
@@ -0,0 +1,16 @@
+To run it from the **command line**:
+
+1) Make sure the target device is available and install the App running the next command:
+
+```bash
+# In Linux / macOS
+./gradlew installDebug
+# In Windows
+gradlew installDebug
+```
+2) On the Android device, locate the App icon on the App Drawer and click it to launch it.
+
+To run it from the **Android Studio IDE**:
+
+1) Open the project on [Android Studio](https://developer.android.com/studio/index.html). 
+2) Click the `Run` button (The green play) or select the menu option `Run | Run 'app'`, and then choose a target device.
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/native/android-facebook-login/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..abdb6d6c64
--- /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: https://github.com/auth0-samples/auth0-android-native-social-sample/tree/master/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..f956418517
--- /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: https://github.com/auth0-samples/auth0-android-sample/tree/master/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がアプリにリダイレクトで戻されることを確認します。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="MainActivity.kt#40:52" }}}
+
+
+
      WebAuthProviderを使用して、認証時にブラウザーで設定されたクッキーを削除すると、ユーザーは次回の認証試行時に、資格情報を再入力するよう求められます。
      logoutメソッドをアプリに追加してユーザーのセッションを削除し、アプリからログアウトします。ここでは、初期設定の一部としてauth0Schemeマニフェストのプレースホルダーで使用されたスキーム値を渡すことができます。
      WebAuthProviderクラスを使用して、ログアウトを実装します。この呼び出しによってブラウザーが開き、ユーザーはログアウトエンドポイントに移動されます。ユーザーがログアウトをキャンセルする場合は、ユーザーを前のURLにリダイレクトすることを検討してください。
      Androidクイックスタート手順6「チェックポイント」 
      logoutを呼び出し、ユーザーをアプリケーションからログアウトするアプリにボタンを追加します。このボタンをクリックすると、Androidアプリがユーザーをログアウトページにリダイレクトしてからもう一度リダイレクトで戻すこと、そして、アプリケーションにログインしていないことを確認します。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## ユーザープロファイル情報を表示する {{{ data-action="code" data-code="MainActivity.kt#54:70" }}}
+
+
+
      AuthenticationAPIClientクラスを使用して、Auth0からユーザーのプロファイルを取得します。これには以下のものが必要です。
      • ログインフェーズから返されるアクセストークン
      • WebAuthProvider.loginにprofileスコープが含まれる必要がある
      ユーザーのメールアドレスを取得する必要がある場合は、emailスコープを指定する必要があります。
      このクイックスタートで、上のログイン手順中にデフォルトでopenid profile emailスコープが設定されます。
      以下に、ユーザーのプロファイルを取得して画面上に表示するために使用できる関数を示します。
      Androidクイックスタート手順7「チェックポイント」 
      ログイン後にshowUserProfile関数を呼び出します。onSuccessコールバックがユーザーのプロファイル情報を返すことを確認します。
      
+
+  
      
+
+  
      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/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..043f0c4803
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/device/interactive.md
@@ -0,0 +1,561 @@
+---
+title: デバイス認可フロー
+description: このチュートリアルでは、デバイス認可フローを使用して、入力に制約のあるデバイスからAPIを呼び出す方法について説明します。
+interactive:  true
+
+github:
+  path: https://auth0.github.io/device-flow-playground/
+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..ac29e2d337
--- /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: https://github.com/auth0-samples/auth0-flutter-samples/tree/main/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を呼び出した結果、トークンにアクセスできることを確認します
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## アプリケーションにログアウトを追加する {{{ 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アプリからログアウトエンドポイントにリダイレクトされ、再び戻されることを確認してください。アプリケーションにはログインされていないはずです。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## ユーザープロファイル情報を表示する {{{ data-action="code" data-code="profile_view.dart" }}}
+
+
+
      webAuthentication().login()を呼び出すと、ユーザープロファイルが自動的にユーザープロファイルプロパティを取得します。ログイン手順から返されたオブジェクトには、すべてのユーザープロファイルプロパティのあるuserプロパティが含まれ、これらはIDトークンをデコードすることで入力されます。
      Flutter - 手順7 - ユーザープロファイル情報を表示する 
      ログインして、結果のuserプロパティを調査します。emailや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/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..39945322ac
--- /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: https://github.com/auth0-samples/auth0-ionic-samples/tree/main/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がエラーなく初期化されること、そして、以前と同じように動作することを確認します。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## アプリケーションにログインを追加する {{{ 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のログインページにリダイレクトされ、エラーは一切受け取りません。
      
+
+  
      
+
+  
      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
      
+
+  
      
+
+## ログインコールバックを処理する {{{ 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を追加して、ログインします。ユーザーが認証して、アプリにログインすると、ブラウザーのウィンドウが閉じます。
      
+
+  
      
+
+  
      Sorry about that. Here's a couple things to double check:
      
+
+  
      
+
+## アプリケーションにログアウトを追加する {{{ 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パラメーターで指定したアドレスへ移動することを確認します。ユーザーがアプリケーションにログインしていないことを確認します。
      
+
+  
      
+
+  
      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
      
+
+  
      
+
+## ユーザープロファイルを表示する {{{ data-action="code" data-code="user-profile.ts" }}}
+
+
+
      Auth0 SDKは必要な任意のコンポーネントについて、名前やプロフィール写真など、ログイン済みのユーザーに関連付けられたプロファイル情報を取得し、ユーザーインターフェイスをパーソナライズします。プロファイル情報は、AuthServiceが公開するuser$プロパティを介して使用することができます。
      IonicとCapacitor（Angular）- 手順8 - ユーザープロファイルを表示する 
      ユーザーがアプリ内でユーザープロファイルの詳細を表示できる手段を提供し、ログインした後に自分のプロファイル情報を取得して画面に表示できることを確認します。
      
+
+  
      
+
+  
      Sorry about that. Here's a couple things to double check:
      • check that you are only reading the user's profile when isLoading is false
      • check that user resolves to an object and is not undefined
      
+
+  
      
diff --git a/ja-jp/articles/quickstart/native/ionic-react/01-login.md b/ja-jp/articles/quickstart/native/ionic-react/01-login.md
new file mode 100644
index 0000000000..1dd8536765
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-react/01-login.md
@@ -0,0 +1,228 @@
+---
+title: Login
+default: true
+description: This tutorial demonstrates how to add user login with Auth0 to an Ionic React & Capacitor application.
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - ionic
+  - react
+  - capacitor
+github:
+  path: react
+contentType: tutorial
+useCase: quickstart
+---
+
+
+
+<%= include('../_includes/ionic/_article_intro') %>
+
+<%= include('../_includes/_getting_started', { library: 'Ionic' }) %>
+
+<%= include('../_includes/ionic/_configure_urls') %>
+
+<%= include('../../_includes/_auth0-react-install.md') %>
+
+<%= include('../_includes/ionic/_install_plugins') %>
+
+### Configure the `Auth0Provider` component
+
+Under the hood, the Auth0 React SDK uses [React Context](https://reactjs.org/docs/context.html) to manage the authentication state of your users. One way to integrate Auth0 with your React app is to wrap your root component with an `Auth0Provider` that you can import from the SDK.
+
+Open `src/index.tsx` and wrap the `App` component in the `Auth0Provider` component.
+
+```javascript
+import React from 'react';
+import { createRoot } from 'react-dom/client';
+import { Auth0Provider } from '@auth0/auth0-react';
+import App from './App';
+
+const root = createRoot(document.getElementById('root'));
+
+root.render(
+  
+    
+  
+);
+```
+
+The `Auth0Provider` component takes the following props:
+
+- `domain`: The "domain" value present under the "Settings" of the application you created in your Auth0 dashboard, or your custom domain if using Auth0's [Custom Domains feature](http://localhost:3000/docs/custom-domains)
+- `clientId`: The "client ID" value present under the "Settings" of the application you created in your Auth0 dashboard
+- `useRefreshTokens`: To use auth0-react with Ionic on Android and iOS, it's required to enable refresh tokens.
+- `useRefreshTokensFallback`: To use auth0-react with Ionic on Android and iOS, it's required to disable the iframe fallback.
+- `authorizationParams.redirect_uri`: The URL to where you'd like to redirect your users after they authenticate with Auth0.
+
+<%= include('../_includes/ionic/_note_storage') %>
+
+:::panel Checkpoint
+Now that you have configured `Auth0Provider`, run your application to verify that the SDK is initializing correctly, and your application is not throwing any errors related to Auth0.
+:::
+
+## Add Login to Your Application
+
+<%= include('../_includes/ionic/_add_login_intro') %>
+
+Add a new file `LoginButton.tsx` with the following code:
+
+```js
+import { useAuth0 } from '@auth0/auth0-react';
+import { Browser } from '@capacitor/browser';
+import { IonButton } from '@ionic/react';
+
+const LoginButton: React.FC = () => {
+  const { loginWithRedirect } = useAuth0();
+
+  const login = async () => {
+    await loginWithRedirect({
+      async openUrl(url) {
+         // Redirect using Capacitor's Browser plugin
+        await Browser.open({
+          url,
+          windowName: "_self"
+        });
+      }
+    });
+  };
+
+  return Log in;
+};
+
+export default LoginButton;
+```
+
+This component:
+
+- defines a template with a simple button that logs the user in when clicked
+- uses `loginWithRedirect` to login using Auth0's Universal Login page
+- uses the `openUrl` callback to use Capacitor's Browser plugin to open the URL and show the login page to the user
+
+<%= include('../../_includes/_auth0-react-classes-info.md') %>
+
+### Handling the callback
+
+<%= include('../_includes/ionic/_handle_callback_intro') %>
+
+Add the following `useEffect` hook to your main `App` component:
+
+```js
+// Import Capacitor's app and browser plugins, giving us access to `addListener` and `appUrlOpen`,
+// as well as the bits needed for Auth0 and React
+import { App as CapApp } from '@capacitor/app';
+import { Browser } from '@capacitor/browser';
+import { useEffect } from 'react';
+import { useAuth0 } from '@auth0/auth0-react';
+
+// ...
+
+const App: React.FC = () => {
+  // Get the callback handler from the Auth0 React hook
+  const { handleRedirectCallback } = useAuth0();
+
+  useEffect(() => {
+    // Handle the 'appUrlOpen' event and call `handleRedirectCallback`
+    CapApp.addListener('appUrlOpen', async ({ url }) => {
+      if (url.includes('state') && (url.includes('code') || url.includes('error'))) {
+        await handleRedirectCallback(url);
+      }
+      // No-op on Android
+      await Browser.close();
+    });
+  }, [handleRedirectCallback]);
+
+  // ..
+};
+```
+
+<%= include('../_includes/ionic/_note_custom_schemes') %>
+
+:::panel Checkpoint
+Add the `LoginButton` component to your application, as well as the handler for the "appUrlOpen" event to your `App` component. When you click the login button, verify that your application redirects you to the Auth0 Universal Login Page and that you can now log in or sign up using a username and password or a social provider.
+
+Once that's complete, verify that Auth0 redirects you back to your application.
+:::
+
+## Add Logout to Your Application
+
+<%= include('../_includes/ionic/_add_logout_intro.md') %>
+
+Create a new file `LogoutButton.tsx` and add the following code to the file. Then, add the `LogoutButton` component to your app.
+
+```js
+import { useAuth0 } from '@auth0/auth0-react';
+import { Browser } from '@capacitor/browser';
+import { IonButton } from '@ionic/react';
+
+// This should reflect the URL added earlier to your "Allowed Logout URLs" setting
+// in the Auth0 dashboard.
+const logoutUri = 'YOUR_PACKAGE_ID://${account.namespace}/capacitor/YOUR_PACKAGE_ID/callback';
+
+const LogoutButton: React.FC = () => {
+  const { logout } = useAuth0();
+
+  const doLogout = async () => {
+    await logout({
+      logoutParams: {
+        returnTo: logoutUri,
+      },
+      async openUrl(url) {
+         // Redirect using Capacitor's Browser plugin
+        await Browser.open({
+          url,
+          windowName: "_self"
+        });
+      }
+    });
+  };
+
+  return Log out;
+};
+
+export default LogoutButton;
+```
+
+:::panel Checkpoint
+Add the `LogoutButton` component to your application. When you click it, verify that your Ionic application redirects you the address you specified as one of the "Allowed Logout URLs" in the "Settings" and that you are no longer logged in to your application.
+:::
+
+## Show User Profile Information
+
+The Auth0 React SDK helps you retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with logged-in users quickly in whatever component you need, such as their name or profile picture, to personalize the user interface. The profile information is available through the `user` property exposed by the `useAuth0()` hook. Take this `Profile` component as an example of how to use it:
+
+```js
+import { useAuth0 } from '@auth0/auth0-react';
+
+const Profile: React.FC = () => {
+  const { user, isLoading } = useAuth0();
+
+  // If the SDK is not ready, or a user is not authenticated, exit.
+  if (isLoading || !user) return null;
+
+  return (
+    
      
+      {user.name}
+      
      {user.name}
      
+      
      {user.email}
      
+    
      
+  );
+};
+
+export default Profile;
+```
+
+The `user` property contains sensitive information and artifacts related to the user's identity. As such, its availability depends on the user's authentication status. To prevent any render errors, use the `isAuthenticated` property from `useAuth0()` to check if Auth0 has authenticated the user before React renders any component that consumes the `user` property. Ensure that the SDK has completed loading before accessing the `isAuthenticated` property, by checking that `isLoading` is `false`.
+
+:::panel Checkpoint
+Add the `Profile` component to your application, and verify that you can display the `user.name` or [any other `user` property](https://auth0.com/docs/users/references/user-profile-structure#user-profile-attributes) within a component correctly after you have logged in.
+:::
diff --git a/ja-jp/articles/quickstart/native/ionic-react/download.md b/ja-jp/articles/quickstart/native/ionic-react/download.md
new file mode 100644
index 0000000000..dc7d46dcf4
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-react/download.md
@@ -0,0 +1,37 @@
+
+
+To run the sample follow these steps:
+
+1) Add the following URL to **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback
+```
+
+2) Add the following URL to **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback
+```
+
+3) Add the following to **Allowed Origins (CORS)s** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+capacitor://localhost, http://localhost
+```
+
+4) Check that mobile development environments for [Android](https://capacitorjs.com/docs/android) and [iOS](https://capacitorjs.com/docs/ios) are setup correctly. For iOS, [CocoaPods](https://cocoapods.org/) must be installed.
+
+5) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the sample directory:
+
+```bash
+npm install
+npm run build
+
+# to test it in iOS
+npx cap run ios
+# to test it in Android
+npx cap run android
+```
+
+Read more about the [Capacitor development workflow](https://capacitorjs.com/docs/basics/workflow) on Capacitor's docs site.
diff --git a/ja-jp/articles/quickstart/native/ionic-react/files/app.md b/ja-jp/articles/quickstart/native/ionic-react/files/app.md
new file mode 100644
index 0000000000..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..8400a620b8
--- /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: https://github.com/auth0-samples/auth0-ionic-samples/tree/main/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に関連したエラーを投入していないことを確認します。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## アプリケーションにログインを追加する {{{ 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のログインページにリダイレクトされ、エラーは一切受け取りません。
      
+
+  
      
+
+  
      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
      
+
+  
      
+
+## ログインコールバックを処理する {{{ 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を追加して、ログインします。ユーザーが認証して、アプリにログインすると、ブラウザーのウィンドウが閉じます。
      
+
+  
      
+
+  
      Sorry about that. Here's a couple things to double check:
      
+
+  
      
+
+## アプリケーションにログアウトを追加する {{{ 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 - ユーザープロファイルを表示する 
      ユーザーがアプリ内でユーザープロファイルの詳細を表示できる手段を提供し、ログインした後に自分のプロファイル情報を取得して画面に表示できることを確認します。
      
+
+  
      
+
+  
      Sorry about that. Here's a couple things to double check:
      • check that you are only reading the user's profile when isLoading is false
      • check that user resolves to an object and is not undefined
      
+
+  
      
diff --git a/ja-jp/articles/quickstart/native/ionic-vue/01-login.md b/ja-jp/articles/quickstart/native/ionic-vue/01-login.md
new file mode 100644
index 0000000000..f29168389b
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-vue/01-login.md
@@ -0,0 +1,271 @@
+---
+title: Login
+default: true
+description: This tutorial demonstrates how to add user login with Auth0 to an Ionic Vue & Capacitor application.
+budicon: 448
+topics:
+  - quickstarts
+  - native
+  - ionic
+  - vue
+  - capacitor
+github:
+  path: vue
+contentType: tutorial
+useCase: quickstart
+---
+
+
+
+<%= include('../_includes/ionic/_article_intro') %>
+
+<%= include('../_includes/_getting_started', { library: 'Ionic' }) %>
+
+<%= include('../_includes/ionic/_configure_urls') %>
+
+<%= include('../../_includes/_auth0-vue-install.md') %>
+
+<%= include('../_includes/ionic/_install_plugins') %>
+
+### Configure the `createAuth0` plugin
+
+The SDK exports `createAuth0`, a composable that contains all the services required for the SDK to function. To register this with your application:
+
+Open `src/main.ts` and install the plugin using `app.use`
+
+```javascript
+import { createApp } from "vue";
+import App from "./App.vue";
+import router from "./router";
+
+import { IonicVue } from "@ionic/vue";
+
+import { createAuth0 } from "@auth0/auth0-vue";
+import config from "./auth.config";
+
+// ..
+
+// Build the URL that Auth0 should redirect back to
+const redirect_uri = `<%= "${config.appId}" %>://${account.namespace}/capacitor/<%= "${config.appId}" %>/callback`;
+
+const app = createApp(App).use(IonicVue).use(router);
+
+app.use(
+  createAuth0({
+    domain: "${account.namespace}",
+    clientId: "${account.clientId}",
+    useRefreshTokens: true,
+    useRefreshTokensFallback: false,
+    authorizationParams: {
+      redirect_uri
+    }
+  })
+);
+
+router.isReady().then(() => {
+  app.mount("#app");
+});
+```
+
+The `createAuth0` plugin takes the following props:
+
+- `domain`: The "domain" value present under the "Settings" of the application you created in your Auth0 dashboard, or your custom domain if using Auth0's [Custom Domains feature](http://localhost:3000/docs/custom-domains)
+- `clientId`: The "client ID" value present under the "Settings" of the application you created in your Auth0 dashboard
+- `useRefreshTokens`: To use auth0-vue with Ionic on Android and iOS, it's required to enable refresh tokens.
+- `useRefreshTokensFallback`: To use auth0-vue with Ionic on Android and iOS, it's required to disable the iframe fallback.
+- `authorizationParams.redirect_uri`: The URL to where you'd like to redirect your users after they authenticate with Auth0.
+
+<%= include('../_includes/ionic/_note_storage') %>
+
+:::panel Checkpoint
+Now that you have configured `createAuth0` plugin, run your application to verify that the SDK is initializing correctly, and your application is not throwing any errors related to Auth0.
+:::
+
+## Add Login to Your Application
+
+<%= include('../_includes/ionic/_add_login_intro') %>
+
+Add a new file `LoginButton.vue` with the following code:
+
+```html
+
+
+
+```
+
+This component:
+
+- defines a template with a simple button that logs the user in when clicked
+- uses `loginWithRedirect` to login using Auth0's Universal Login page
+- uses the `openUrl` callback to use Capacitor's Browser plugin to open the URL and show the login page to the user
+
+### Handling the callback
+
+<%= include('../_includes/ionic/_handle_callback_intro') %>
+
+Add the following capacitor application listener to your main `App` component:
+
+```html
+
+
+
+```
+
+<%= include('../_includes/ionic/_note_custom_schemes') %>
+
+:::panel Checkpoint
+Add the `LoginButton` component to your application, as well as the handler for the "appUrlOpen" event to your `App` component. When you click the login button, verify that your application redirects you to the Auth0 Universal Login Page and that you can now log in or sign up using a username and password or a social provider.
+
+Once that's complete, verify that Auth0 redirects you back to your application.
+:::
+
+## Add Logout to Your Application
+
+<%= include('../_includes/ionic/_add_logout_intro.md') %>
+
+Create a new file `LogoutButton.vue` and add the following code to the file. Then, add the `LogoutButton` component to your app.
+
+```html
+
+
+
+```
+
+:::panel Checkpoint
+Add the `LogoutButton` component to your application. When you click it, verify that your Ionic application redirects you the address you specified as one of the "Allowed Logout URLs" in the "Settings" and that you are no longer logged in to your application.
+:::
+
+## Show User Profile Information
+
+The Auth0 Vue SDK helps you retrieve the [profile information](https://auth0.com/docs/users/concepts/overview-user-profile) associated with logged-in users quickly in whatever component you need, such as their name or profile picture, to personalize the user interface. The profile information is available through the `user` property exposed by the `useAuth0()` composable. Take this `UserProfile` component as an example of how to use it:
+
+```html
+
+
+
+```
+
+The `user` property contains sensitive information and artifacts related to the user's identity. As such, its availability depends on the user's authentication status. To prevent any render errors, use the `isAuthenticated` property from `useAuth0()` to check if Auth0 has authenticated the user before Vue renders any component that consumes the `user` property. Ensure that the SDK has completed loading before accessing the `isAuthenticated` property, by checking that `isLoading` is `false`.
+
+:::panel Checkpoint
+Add the `UserProfile` component to your application, and verify that you can display the `user.name` or [any other `user` property](https://auth0.com/docs/users/references/user-profile-structure#user-profile-attributes) within a component correctly after you have logged in.
+:::
diff --git a/ja-jp/articles/quickstart/native/ionic-vue/download.md b/ja-jp/articles/quickstart/native/ionic-vue/download.md
new file mode 100644
index 0000000000..a0589fcf12
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/ionic-vue/download.md
@@ -0,0 +1,38 @@
+
+
+To run the sample follow these steps:
+
+1) Add the following URL to **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback
+```
+
+2) Add the following URL to **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+com.auth0.samples://${account.namespace}/capacitor/com.auth0.samples/callback
+```
+
+3) Add the following to **Allowed Origins (CORS)s** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings)
+
+```text
+capacitor://localhost, http://localhost
+```
+
+4) Check that mobile development environments for [Android](https://capacitorjs.com/docs/android) and [iOS](https://capacitorjs.com/docs/ios) are setup correctly. For iOS, [CocoaPods](https://cocoapods.org/) must be installed.
+
+5) Make sure [Node.JS LTS](https://nodejs.org/en/download/) is installed and execute the following commands in the sample directory:
+
+```bash
+npm install
+npm run build
+
+# to test it in iOS
+npx cap run ios
+
+# to test it in Android
+npx cap run android
+```
+
+Read more about the [Capacitor development workflow](https://capacitorjs.com/docs/basics/workflow) on Capacitor's docs site.
diff --git a/ja-jp/articles/quickstart/native/ionic-vue/files/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..5c1e9b7a03
--- /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: https://github.com/auth0-samples/auth0-ionic-samples/tree/main/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がエラーなく初期化されること、そして、以前と同じように動作することを確認します。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## アプリケーションにログインを追加する {{{ 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のログインページにリダイレクトされ、エラーは一切受け取りません。
      
+
+  
      
+
+  
      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
      
+
+  
      
+
+## ログインコールバックを処理する {{{ 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を追加して、ログインします。ユーザーが認証して、アプリにログインすると、ブラウザーのウィンドウが閉じます。
      
+
+  
      
+
+  
      Sorry about that. Here's a couple things to double check:
      
+
+  
      
+
+## アプリケーションにログアウトを追加する {{{ 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パラメーターで指定したアドレスへ移動することを確認します。アプリケーションにログインしていないことを確認します。
      
+
+  
      
+
+  
      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
      
+
+  
      
+
+## ユーザープロファイルを表示する {{{ 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..411f08af56
--- /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: https://github.com/auth0-samples/auth0-ios-swift-sample/tree/master/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に関連したエラーを出していないことを確認します。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## アプリケーションにログインを追加する {{{ data-action="code" data-code="MainView.swift#20:31" }}}
+
+
+
      ログインページを提示したいファイルにAuth0モジュールをインポートします。それからログインボタンのアクションでユニバーサルログインページを提示します。
      コールバックに基づいたAPIの代わりにasync/awaitまたはCombineを使用できます。詳細はREADMEをご覧ください。
      iOSアプリのユニバーサルログイン画面の例
      iOS Swiftクイックスタート - 手順4「チェックポイント」 
      ログインボタンを押して次の点を確認します：
      • アラートボックスが表示され、同意を求める。
      • ［Continue（続行）］を選択するとSafariモーダルでユニバーサルログインページが開く。
      • ユーザー名とパスワード、またはソーシャルプロバイダーを使って、ログインまたはサインアップできる。
      • その後、Safariモーダルが自動的に閉じる。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="MainView.swift#34:45" }}}
+
+
+
      アプリにログインできるようになったら、ログアウトする方法が必要です。ログアウトボタンのアクションでclearSession()メソッドを呼び出し、ユニバーサルログインセッションのクッキーを消去します。
      iOS Swiftクイックスタート - 手順5「チェックポイント」 
      ログアウトボタンを押して次の点を確認します：
      • アラートボックスが表示され、同意を求める。
      • ［Continue（続行）］を選択するとSafariモーダルでページが開く。
      • その直後にSafariモーダルが自動的に閉じる。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## ユーザープロファイル情報にアクセスする {{{ 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、その他すべてのクレームにアクセスできることを確認します。
      
+
+  
      
+
+  
      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/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..38cd7899ea
--- /dev/null
+++ b/ja-jp/articles/quickstart/native/maui/interactive.md
@@ -0,0 +1,160 @@
+---
+title: MAUIアプリケーションにログインを追加する
+description: このチュートリアルは、Auth0を使用して、.NET MAUIアプリケーションにユーザーログインを追加する方法について説明します。
+interactive:  true
+files:
+ - files/MainPage.xaml
+github:
+  path: https://github.com/auth0-samples/auth0-maui-samples/tree/master/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に関連したエラーを投入していない。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## アプリケーションにログインを追加する {{{ 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によってアプリケーションにリダイレクトされる。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="MainPage.xaml.cs#32:32" }}}
+
+
+
      プロジェクトにログインしたユーザーには、ログアウトする方法も必要です。SDKのLogoutAsync()メソッドを使用してログアウトボタンを作成します。ユーザーはログアウトすると、Auth0ログアウトエンドポイントにリダイレクトされてから、即座に、このクイックスタートで先ほどセットアップしたログアウトURLにリダイレクトで戻されます。
      await client.LogoutAsync();
+
+
      
+
+
      MAUIクイックスタート - 手順6「チェックポイント」 
      アプリケーションを実行してログアウトボタンをクリックし、次の点を確認します：
      • アプリケーションによって、アプリケーションの設定で［Allowed Logout URLs（許可されているログアウトURL）］の1つに指定されているアドレスへリダイレクトされる。
      • アプリケーションにログインしていない。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## ユーザープロファイル情報を表示する {{{ 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..cb028d7b24
--- /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: https://github.com/auth0-samples/auth0-xamarin-oidc-samples/tree/master/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に関連したエラーを投入していない。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## 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によってアプリケーションにリダイレクトされる。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## アプリケーションにログアウトを追加する
+
+
+
      プロジェクトにログインしたユーザーには、ログアウトする方法も必要です。SDKのLogoutAsync()メソッドを使用してログアウトボタンを作成します。ユーザーはログアウトすると、Auth0ログアウトエンドポイントにリダイレクトされてから、即座に、このクイックスタートで先ほどセットアップしたログアウトURLにリダイレクトで戻されます。
      await client.LogoutAsync();
+
+
      
+
+
      .NET Android/iOSクイックスタート - 手順7「チェックポイント」 
      アプリケーションを実行して、ログアウトボタンをクリックします。以下の点を確認します：
      • AndroidまたはiOSアプリケーションによって、アプリケーションの設定で［Allowed Logout URLs（許可されているログアウトURL）］の1つに指定されているアドレスへリダイレクトされる。
      • アプリケーションにログインしていない。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## ユーザープロファイル情報を表示する
+
+
+
      ユーザーがログインやログアウトできるようになったら、認証済のユーザーに関連付けられたプロファイル情報を取得できるようにしたいと考えるはずです。たとえば、ログインしたユーザーの名前やプロフィール写真をプロジェクトに表示したいかもしれません。
      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..afef86ca0c
--- /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: https://github.com/auth0-samples/auth0-angular-samples/tree/main/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に関連したエラーを受け取らない。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## アプリケーションにログアウトを追加する {{{ 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に関連したエラーを受け取らない。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## ユーザープロファイル情報を表示する {{{ 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「チェックポイント」 
      ユーザープロファイル情報を表示することができるようになります。
      アプリケーションを実行して次の点を確認します：
      • ログイン後にユーザー情報が正しく表示される。
      • ログアウト後にユーザー情報が表示されない。
      
+
+  
      
+
+  
      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/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..0858faeac4
--- /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: https://github.com/auth0-samples/auth0-flutter-samples/tree/main/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とアクセストークンにアクセスできることを確認します。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## アプリケーションにログアウトを追加する
+
+
+
      ユーザーをログアウトさせるには、Auth0 Flutter SDKのlogout()を呼び出してログインセッションをクリアし、ユーザーをAuth0のログアウトエンドポイントにリダイレクトします。Auth0からのログアウトについて詳しい情報をお読みください。
      通常、logoutを呼び出すときにreturnToUrlを指定しますが、そうしない場合、Auth0は ［Allowed Logout URLs（許可されているログアウトURL）］リストの最初のURLにデフォルトで指定されます。
      Flutter web手順4「チェックポイント」 
      logout()を呼び出し、ユーザーをアプリケーションからログアウトするアプリにボタンを追加します。このボタンを選択すると、Flutterアプリがログアウトエンドポイントにリダイレクトしてからもう一度戻ることを確認します。アプリケーションにはログインされていないはずです。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## ユーザープロファイル情報を表示する {{{ data-action="code" data-code="profile_view.dart" }}}
+
+
+
      ユーザープロファイルは、ページが読み込まれるとユーザープロファイルプロパティを自動的に取得し、アプリケーション起動中にonLoadを呼び出すことでアクセス・保存することができます。onLoadから返されたオブジェクトには、すべてのユーザープロファイルプロパティのあるuserプロパティが含まれています。これらはIDトークンをデコードすることで内部で入力されます。
      Flutter web手順5「チェックポイント」 
      ログインして、結果のuserプロパティを調査します。emailや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/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..30c4053cfe
--- /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: https://github.com/auth0-samples/auth0-react-samples/tree/master/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に関連したエラーを投入していない。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## アプリケーションにログインを追加する {{{ 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の値を使用し、アプリケーションへリダイレクトする。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="logout.js" }}}
+
+
+
      プロジェクトにログインしたユーザーには、ログアウトする方法も必要です。SDKのlogout()メソッドを使用してログアウトボタンを作成します。ユーザーはログアウトすると、Auth0ログアウトエンドポイントにリダイレクトされてから、即座に、このクイックスタートで先ほどセットアップしたログアウトURLにリダイレクトで戻されます。
      ログアウトボタンコンポーネントのためにアプリケーションでlogout.jsという名前の新規ファイルを作成し、インタラクティブパネルからコードにコピーします。これにはログアウトに必要なロジックが含まれています。それからindex.jsファイルを更新して新しいログアウトボタンを含めます。
      Reactクイックスタート - 手順4「チェックポイント」 
      アプリケーションを実行してログアウトボタンをクリックし、次の点を検証します：
      • Reactアプリケーションによって、アプリケーションの設定で［Allowed Logout URLs（許可されているログアウトURL）］の一つに指定したアドレスへリダイレクトされる。
      • アプリケーションにログインしていない。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## ユーザープロファイル情報を表示する {{{ 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 やその他のユーザープロパティをすべて正しく表示できる。
      
+
+  
      
+
+  
      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/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..7d46244889
--- /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: https://github.com/auth0-samples/auth0-javascript-samples/tree/master/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に関連したエラーを受け取らない
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## Auth0からのコールバックを処理する {{{ data-action="code" data-code="app.js#16:21" }}}
+
+
+
      ブラウザーでアプリケーションプロセスへとリダイレクトで戻されると、アプリケーションはAuth0からのコールバックを検出した場合にのみ、Auth0クライアントでhandleRedirectCallback()関数を呼び出します。これを実行する1つの方法は、codeとstateのクエリパラメーターが検出されたときに、handleRedirectCallback()のみを呼び出すことです。
      コールバックの処理に成功すると、パラメーターはURLから削除されます。これによって、次回ページが読み込まれても、コールバックハンドラーがトリガーされることはありません。
      Javascriptクイックスタート手順5「チェックポイント」 
      Auth0からのコールバックが正しく処理されます。
      アプリケーションを実行し、ログインボタンをもう一度選択します。以下の点を確認します：
      • 認証した後、Auth0はアプリケーションにリダイレクトで戻される。
      • クエリパラメータが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.
      
+
+  
      
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="app.js#23:29" }}}
+
+
+
      プロジェクトにログインしたユーザーには、ログアウトする方法も必要です。Auth0クライアントには、アプリからユーザーをログアウトするのに使用できるlogout()メソッドが用意されています。ユーザーはログアウトすると、Auth0ログアウトエンドポイントにリダイレクトされてから、即座に、アプリケーションとこのクイックスタートで先ほどセットアップしたログアウトURLへとリダイレクトで戻されます。
      アプリケーションで選択時にlogout()を呼び出すログアウトボタンを作成します。
      SDKによってisAuthenticated()関数が公開されることで、ユーザーが認証されているかどうかを確認することができます。isAuthenticated()関数の値に基づいて、条件付きでログインボタンとログアウトボタンを表示することができます。または、シングルボタンを使って、ログインとログアウトの両方のボタンと条件付きレンダリングを組み合わせることができます。
      javascriptクイックスタート手順6「チェックポイント」 
      アプリケーションからログアウトできるようになります。
      アプリケーションを実行し、ログインし、ログアウトボタンを選択します。以下の点を確認します：
      • Auth0のログアウトエンドポイントにリダイレクトされている。
      • Auth0がアプリケーションと正しいログアウトURLへのリダイレクトで戻される。
      • アプリケーションにログインしていない。
      • コンソールで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.
      
+
+  
      
+
+## ユーザープロファイル情報を表示する {{{ data-action="code" data-code="app.js#31:45" }}}
+
+
+
      ユーザーがログインやログアウトできるようになったら、認証済みのユーザーに関連付けられたプロファイル情報を取得できるようにしたいと考えるはずです。たとえば、ログインしたユーザーの名前やプロフィール写真を表示することで、ユーザーインターフェイスをパーソナライズできるようになりたいかもしれません。
      Auth0 SPA SDKは、Auth0クライアントによって公開されたgetUser()関数を介してユーザー情報を提供します。Auth0クライアントは、ユーザーが認証されているかどうかを確認することができるisAuthenticated()関数も公開します。これを使って、たとえば、UI要素を表示・非表示にするかを判断することができます。インタラクティブパネルでコードを確認し、これらの関数の使用方法の例をチェックします。
      Javascriptクイックスタート手順7「チェックポイント」 
      ユーザープロファイル情報を表示することができるようになります。
      アプリケーションを実行して次の点を確認します：
      • ログイン後にユーザー情報が正しく表示される。
      • ログアウト後にユーザー情報が表示されない。
      
+
+  
      
+
+  
      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/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..d6b6ae9f1c
--- /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: https://github.com/auth0-samples/auth0-vue-samples/tree/master/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に関連したエラーを投入していない
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## アプリケーションにログインを追加する {{{ 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の値を使用し、アプリケーションへリダイレクトする。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## アプリケーションにログアウトを追加する {{{ 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アドレスにリダイレクトされる
      • アプリケーションにログインしていない
      
+
+  
      
+
+  
      
+
+  
      
+
+## ユーザープロファイル情報を表示する {{{ 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やその他のユーザープロパティをすべて正しく表示できる
      
+
+  
      
+
+  
      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/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..7fae55b15a
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/apache/interactive.md
@@ -0,0 +1,51 @@
+---
+title: Apache
+description: このチュートリアルでは、Webアプリに認証と認可を追加するために、Apacheを構成する方法について説明します。
+interactive:  true
+files:
+ - files/auth_openidc
+github:
+  path: https://github.com/zmartzone/mod_auth_openidc/releases
+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..e00b864dd9
--- /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: https://github.com/auth0-samples/auth0-aspnetcore-blazor-server-samples/tree/main/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にリダイレクトされる。
      • 資格情報を入力すると、リダイレクトでアプリケーションに戻る。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## ユーザープロファイルを表示する {{{ data-action="code" data-code="Profile.razor" }}}
+
+
+
      ミドルウェアはAuth0からトークンを取得すると、IDトークンからユーザー情報とクレームを抽出し、AuthenticationStateを介して利用できるようにします。これはCascadingParameterとして追加できます。
      ユーザーの名前や追加クレーム（メールアドレスや画像など）を表示するカスタムのユーザープロファイルページは、AuthenticationStateのUserプロパティから関連情報を取得し、Blazorコード内からビューに渡すことで作成できます。
      ASP.NET Core Blazor Server - 手順4 - チェックポイント 
      ユーザープロファイルを表示するようセットアップし終えたら、アプリケーションを実行して次の点を確認します：
      • ログイン成功後にプロファイルを含んだエンドポイントに移動すると、ユーザーのプロファイルが表示される。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## ログアウト {{{ 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にリダイレクトされ、即座にアプリケーションにリダイレクトで戻される。
      
+
+  
      
+
+  
      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/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..38b35b0620
--- /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: https://github.com/auth0-samples/auth0-aspnetcore-mvc-samples/tree/master/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にリダイレクトされる。
      • 資格情報を入力すると、リダイレクトでアプリケーションに戻る。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## ユーザープロファイルを表示する
+
+
+
      ミドルウェアはAuth0からトークンを取得すると、IDトークンからユーザー情報とクレームを抽出し、コントローラーでUser.Claimsプロパティとして利用できるようにします。
      ユーザーの名前、メールアドレス、プロファイル画像を表示するカスタムユーザープロファイルを作成するには、Userから関連する情報を取得し、コントローラー内からビューに渡します。
      ASP.NET MWC手順4「チェックポイント」 
      ユーザープロファイルを表示するようアクションをセットアップし終えたら、アプリケーションを実行して次の点を確認します：
      • ログイン成功後に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.
      
+
+  
      
+
+## ログアウト
+
+
+
      コントローラーのアクション内からHttpContext.SignOutAsyncをCookieAuthenticationDefaults.AuthenticationScheme認証スキームで呼び出すと、ユーザーをアプリケーションからログアウトさせられます。
      さらに、ユーザーをAuth0からもログアウトさせたい場合は（これによりシングルサインオンに依拠している他のアプリケーションからもログアウトさせる可能性があります）、HttpContext.SignOutAsyncをAuth0Constants.AuthenticationScheme認証スキームで呼び出します。また、LogoutAuthenticationPropertiesBuilderを使って構築できる適切なauthenticationPropertiesも同じ認証スキームで呼び出します。
      ASP.NET MWC手順5「チェックポイント」 
      Logoutの構成が完了したら、アプリケーションを実行して次の点を確認します：
      • Logoutアクションに移動すると、ユーザーが確実にログアウトする。
      • Auth0からもログアウトすると、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 are configured correctly
      Still having issues? Check out our documentation or visit our community page to get more help.
      
+
+  
      
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-owin/01-login.md b/ja-jp/articles/quickstart/webapp/aspnet-owin/01-login.md
new file mode 100644
index 0000000000..beb980dd2b
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-owin/01-login.md
@@ -0,0 +1,204 @@
+---
+title: Login
+description: This tutorial demonstrates how to add user login to an ASP.NET OWIN application.
+budicon: 448
+topics:
+  - quickstarts
+  - webapp
+  - aspnet-owin
+  - login
+github:
+  path: Quickstart/Sample
+contentType: tutorial
+useCase: quickstart
+sample_download_required_data:
+  - client
+---
+<%= include('../../../_includes/_new_app', { showClientSecret: true, isPublicClient: false }) %>
+
+<%= include('_includes/_setup') %>
+
+## Install and configure the OpenID Connect middleware
+
+::: note
+  This quickstart uses OWIN middleware and as such, you need to use OWIN in your application. If your application is not currently using OWIN, please refer to Microsoft's OWIN documentation to enable it in your application.
+:::
+
+The easiest way to enable authentication with Auth0 in your ASP.NET MVC application is to use the OWIN OpenID Connect middleware, so install the `Microsoft.Owin.Security.OpenIdConnect` NuGet package first:
+
+```bash
+Install-Package Microsoft.Owin.Security.OpenIdConnect
+```
+
+You must also install the following middleware library to enable cookie authentication in your project:
+
+```bash
+Install-Package Microsoft.Owin.Security.Cookies
+```
+
+::: note
+There are issues when configuring the OWIN cookie middleware and System.Web cookies at the same time. Please read about the [System.Web cookie integration issues doc](https://github.com/aspnet/AspNetKatana/wiki/System.Web-response-cookie-integration-issues) to learn about how to mitigate these problems
+:::
+
+Now go to the `Configuration` method of your `Startup` class and configure the cookie middleware as well as the Auth0 middleware.
+
+```cs
+// Startup.cs
+using Microsoft.IdentityModel.Protocols.OpenIdConnect;
+using Microsoft.IdentityModel.Tokens;
+using Microsoft.Owin;
+using Microsoft.Owin.Host.SystemWeb;
+using Microsoft.Owin.Security;
+using Microsoft.Owin.Security.Cookies;
+using Microsoft.Owin.Security.OpenIdConnect;
+using MvcApplication.Support;
+using Owin;
+
+public void Configuration(IAppBuilder app)
+{
+    // Configure Auth0 parameters
+    string auth0Domain = ConfigurationManager.AppSettings["auth0:Domain"];
+    string auth0ClientId = ConfigurationManager.AppSettings["auth0:ClientId"];
+    string auth0RedirectUri = ConfigurationManager.AppSettings["auth0:RedirectUri"];
+    string auth0PostLogoutRedirectUri = ConfigurationManager.AppSettings["auth0:PostLogoutRedirectUri"];
+
+    // Set Cookies as default authentication type
+    app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
+    app.UseCookieAuthentication(new CookieAuthenticationOptions
+    {
+        AuthenticationType = CookieAuthenticationDefaults.AuthenticationType,
+        LoginPath = new PathString("/Account/Login"),
+
+        // Configure SameSite as needed for your app. Lax works well for most scenarios here but
+        // you may want to set SameSiteMode.None for HTTPS
+        CookieSameSite = SameSiteMode.Lax,
+
+        // More information on why the CookieManager needs to be set can be found here: 
+        // https://github.com/aspnet/AspNetKatana/wiki/System.Web-response-cookie-integration-issues
+        CookieManager = new SameSiteCookieManager(new SystemWebCookieManager())
+    });
+
+    // Configure Auth0 authentication
+    app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
+    {
+        AuthenticationType = "Auth0",
+
+        Authority = $"https://{auth0Domain}",
+
+        ClientId = auth0ClientId,
+
+        RedirectUri = auth0RedirectUri,
+        PostLogoutRedirectUri = auth0PostLogoutRedirectUri,
+        Scope = "openid profile email",
+        TokenValidationParameters = new TokenValidationParameters
+        {
+            NameClaimType = "name"
+        },
+
+        // More information on why the CookieManager needs to be set can be found here: 
+        // https://docs.microsoft.com/en-us/aspnet/samesite/owin-samesite
+        CookieManager = new SameSiteCookieManager(new SystemWebCookieManager()),
+
+        // Configure Auth0's Logout URL by hooking into the RedirectToIdentityProvider notification, 
+        // which is getting triggered before any redirect to Auth0 happens.
+        Notifications = new OpenIdConnectAuthenticationNotifications
+        {
+            RedirectToIdentityProvider = notification =>
+            {
+                // Only when the RequestType is OpenIdConnectRequestType.Logout should we configure the logout URL.
+                // Any other RequestType means a different kind of interaction with Auth0 that isn't logging out.
+                if (notification.ProtocolMessage.RequestType == OpenIdConnectRequestType.Logout)
+                {
+                    var logoutUri = $"https://{auth0Domain}/v2/logout?client_id={auth0ClientId}";
+
+                    var postLogoutUri = notification.ProtocolMessage.PostLogoutRedirectUri;
+                    if (!string.IsNullOrEmpty(postLogoutUri))
+                    {
+                        if (postLogoutUri.StartsWith("/"))
+                        {
+                            // transform to absolute
+                            var request = notification.Request;
+                            postLogoutUri = request.Scheme + "://" + request.Host + request.PathBase + postLogoutUri;
+                        }
+                        logoutUri += $"&returnTo={ Uri.EscapeDataString(postLogoutUri)}";
+                    }
+
+                    notification.Response.Redirect(logoutUri);
+                    notification.HandleResponse();
+                }
+                return Task.FromResult(0);
+            }
+        }
+    });
+}
+```
+
+It is essential that you register both the cookie middleware and the OpenID Connect middleware, as they are required (in that order) for the authentication to work. The OpenID Connect middleware will handle the authentication with Auth0. Once the user has authenticated, their identity will be stored in the cookie middleware.
+
+In the code snippet above, note that the `AuthenticationType` is set to **Auth0**. This will be used in the next section to challenge the OpenID Connect middleware and start the authentication flow. Also note code in the `RedirectToIdentityProvider` notification event which constructs the correct [logout URL](/logout).
+
+
+
+
+## Add login to your ASP.NET OWIN application
+
+To allow users to login to your ASP.NET OWIN application, add a `Login` action to your controller.
+
+Call `HttpContext.GetOwinContext().Authentication.Challenge` and pass `"Auth0"` as the authentication scheme. This invokes the OIDC authentication handler that was registered earlier. Be sure to specify the corresponding `AuthenticationProperties`, including a `RedirectUri`.
+
+After successfully calling `HttpContext.GetOwinContext().Authentication.Challenge`, the user is redirected to Auth0 and signed in to both the OIDC middleware and the cookie middleware upon being redirected back to your application. This will allow users to be authenticated on subsequent requests.
+
+```cs
+public class AccountController : Controller
+{
+    public ActionResult Login(string returnUrl)
+    {
+        HttpContext.GetOwinContext().Authentication.Challenge(new AuthenticationProperties
+            {
+                RedirectUri = returnUrl ?? Url.Action("Index", "Home")
+            },
+            "Auth0");
+        return new HttpUnauthorizedResult();
+    }
+}
+```
+
+## Add logout to your ASP.NET OWIN application
+
+From your controller's action, call `HttpContext.GetOwinContext().Authentication.SignOut` with the `CookieAuthenticationDefaults.AuthenticationType` authentication scheme to log the user out of your application.
+
+Additionally, if you want to log the user out from Auth0 (this might also log them out of other applications that rely on Single Sign-On), call `HttpContext.GetOwinContext().Authentication.SignOut` with the `"Auth0"` authentication scheme.
+
+```cs
+public class AccountController : Controller
+{
+    [Authorize]
+    public void Logout()
+    {
+        HttpContext.GetOwinContext().Authentication.SignOut(CookieAuthenticationDefaults.AuthenticationType);
+        HttpContext.GetOwinContext().Authentication.SignOut("Auth0");
+    }
+}
+```
+
+## Display the user profile
+
+After the middleware successfully retrieves the tokens from Auth0, it extracts the user's information and claims from the ID token and makes them available as `ClaimsIdentity`. Access the extracted information by using the `User` property on the controller.
+
+To create a user profile, retrieve a user's name, email address, and profile image from `User.Identity` and pass it to the view from inside your controller.
+```csharp
+// Controllers/AccountController.cs
+
+[Authorize]
+public ActionResult UserProfile()
+{
+    var claimsIdentity = User.Identity as ClaimsIdentity;
+
+    return View(new
+    {
+        Name = claimsIdentity?.FindFirst(c => c.Type == claimsIdentity.NameClaimType)?.Value,
+        EmailAddress = claimsIdentity?.FindFirst(c => c.Type == ClaimTypes.Email)?.Value,
+        ProfileImage = claimsIdentity?.FindFirst(c => c.Type == "picture")?.Value
+    });
+}
+```
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-owin/_includes/_setup.md b/ja-jp/articles/quickstart/webapp/aspnet-owin/_includes/_setup.md
new file mode 100644
index 0000000000..5db5d77940
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-owin/_includes/_setup.md
@@ -0,0 +1,9 @@
+## Configure Callback URLs
+
+The Callback URL of your application is the URL where Auth0 will redirect to after the user has authenticated in order for the OWIN OpenID Connect middleware to complete the authentication process.
+
+You will need to add this URL to the list of Allowed URLs for your application. The Callback URL for the seed project is `http://localhost:3000/callback`, so be sure to add this to the **Allowed Callback URLs** section of your application. Also, add `http://localhost:3000/` to the **Allowed Logout URLs**.
+
+If you deploy your application to a different URL you will also need to ensure to add that URL to the **Allowed Callback URLs** and **Allowed Logout URLs**. The `web.config` in the sample projects also contain two keys named `auth0:RedirectUri` and `auth0:PostLogoutRedirectUri` with these URLs. Be sure to change those as well.
+
+That's all you need to start working with Auth0!
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-owin/download.md b/ja-jp/articles/quickstart/webapp/aspnet-owin/download.md
new file mode 100644
index 0000000000..5c9fea1bc1
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/aspnet-owin/download.md
@@ -0,0 +1,15 @@
+To run the sample follow these steps:
+
+1) Set the **Allowed Callback URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+```text
+http://localhost:3000/callback
+```
+
+2) Set the **Allowed Logout URLs** in the [Application Settings](${manage_url}/#/applications/${account.clientId}/settings) to:
+```text
+http://localhost:3000
+```
+
+3) Open the project in [Visual Studio](https://visualstudio.microsoft.com/vs/).
+
+4) Click the `Start` button or select the menu option `Debug | Start Debugging` or use the keyboard shortcut `F5`.
\ No newline at end of file
diff --git a/ja-jp/articles/quickstart/webapp/aspnet-owin/files/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..a661051242
--- /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: https://github.com/auth0-samples/auth0-aspnet-owin-mvc-samples/tree/master/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にリダイレクトされる。
      • 資格情報を入力すると、リダイレクトでアプリケーションに戻る。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## アプリケーションにログアウトを追加する {{{ 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にリダイレクトし、その後ログアウト中にただちにアプリケーションにリダイレクトで戻る。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## ユーザープロファイル情報を表示する {{{ data-action="code" data-code="AccountController.cs#18:32" }}}
+
+
+
      ミドルウェアはAuth0からトークンを取得すると、IDトークンからユーザー情報とクレームを抽出し、ClaimsIdentityとして利用できるようにします。抽出した情報にはコントローラーのUserプロパティを使ってアクセスします。
      ユーザープロファイルを作成するには、Userからユーザーの名前、メールアドレス、プロファイル画像を取得し、コントローラー内からビューに渡します。
      ASP.NET（OWIN） - 手順6 - チェックポイント 
      ユーザープロファイルを表示するようアクションをセットアップし終えたら、アプリケーションを実行して次の点を確認します：
      • ログイン成功後に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/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..9cca8afbb9
--- /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: https://github.com/auth0-samples/auth0-django-web-app/tree/master/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へルートするログインボタンがあり、ログイン後アプリケーションに戻るとプロファイル情報を確認できます。
      
+
+  
      
+
+  
      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/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..08a7e5ae5f
--- /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: https://github.com/auth0-samples/auth0-express-webapp-sample/tree/master/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です。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## ユーザープロファイルを表示する {{{ data-action="code" data-code="server.js#25:28" }}}
+
+
+
      ユーザーのプロファイルを表示するには、アプリケーションに保護されたルートがなければなりません。
      認証を必要とするルートにrequiresAuthミドルウェアを追加してください。このミドルウェアを使用するすべてのルートは有効なユーザーセッションをチェックし、ない場合にはユーザーをログインへリダイレクトします。
      Express - 手順3 - ユーザープロファイルを表示する - チェックポイント 
      ユーザーはライブラリーによって提供された/logoutルートを訪れることで、アプリケーションからログアウトできます。プロジェクトをlocalhost:3000で実行している場合のリンクは、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/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..d8a09b4395
--- /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: https://github.com/auth0-samples/auth0-golang-web-app/tree/master/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..f917f536ef
--- /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: https://github.com/auth0-samples/auth0-java-ee-sample/tree/master/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..15b40bb1aa
--- /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: https://github.com/auth0-samples/auth0-spring-boot-login-samples/tree/master/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..d4d967932d
--- /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: https://github.com/auth0-samples/auth0-servlet-sample/tree/master/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..a37d4e0bfa
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/laravel/interactive.md
@@ -0,0 +1,61 @@
+---
+title: Laravelアプリケーションにログインを追加する
+description: このガイドでは、新規（または既存）のLaravel 9または10アプリケーションにAuth0を統合する方法を説明します。
+interactive:  true
+files:
+ - files/routes/web
+github:
+  path: https://github.com/auth0-samples/laravel/tree/bf356d877b5dae566286fc8400da94b8b4b0ac76/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で新しいアプリケーションを作成します：
      また、新しいAPIも作成します：
      これで、SDKを構成するプロジェクトディレクトリ内に2つのファイルが作成されます。
      これらのファイルには資格情報が保管されているため、機密として扱うことが重要です。必ず、バージョン管理では、これらのファイルをコミットしないようにしてください。Gitを使用している場合は、必ず.gitignoreファイルに追加します：
      echo ".auth0.*.json" >> .gitignore
      
+
+## ログイン経路
+
+
+
      SDKは、アプリケーションのユーザーを認証するために必要なすべての経路を自動的に登録します。
      これらについて細かな制御が必要な場合や、アプリケーションで既存の経路と競合する場合には、SDKのコントローラーを手動で登録することができます。高度な統合について、SDKのREADMEを参照してください。
      
+
+## アクセス制御 {{{ data-action="code" data-code="routes/web.php#6:12" }}}
+
+
+
      Laravelの認証機能は「guards」を使用して、それぞれの要求でユーザーがどのように認証されるのかを定義します。アプリケーションの経路へのアクセスを制約するには、Auth0 SDKの認証ガードを使用することができます。
      経路へのアクセスに先だって、ユーザーの認証を要求するには、Laravelのauthミドルウェアを使用することができます。
      また、これをLaravelのcanミドルウェアと組み合わせると、認証済みのユーザーに特定の権限を要求することができます。
      
+
+## ユーザー情報 {{{ data-action="code" data-code="routes/web.php#14:24" }}}
+
+
+
      認証済みのユーザーについての情報は、LaravelのAuthファサードまたはauth()ヘルパー関数を介して利用できます。
      以下は、ユーザーの識別子とメールアドレスを取得する例です。
      
+
+## ユーザー管理 {{{ 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のドキュメントを参照してください。
      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..515f3b4950
--- /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_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/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..51cd00a4c9
--- /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: https://github.com/auth0-samples/auth0-nextjs-samples/tree/main/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はユーザーをアプリケーションにリダイレクトで戻します。
      次のリンティング ルールでは、アンカータグでなくLinkコンポーネントを使用することを提案する場合があります。Linkコンポーネントは、クライアント側のページ間の移行を実施するためのものです。リンクはページでなくAPIルートを指すため、アンカータグとして維持する必要があります。
      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手順7「チェックポイント」 
      アプリケーションにログアウトリンクを追加します。クリックすると、 Next.jsアプリケーションによって、［Settings（設定）］で［Allowed Logout URLs（許可されているログアウトURL）］の1つに指定されているアドレスへリダイレクトされます。
      
+
+  
      
+
+  
      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/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..d6cabecbd3
--- /dev/null
+++ b/ja-jp/articles/quickstart/webapp/nginx-plus/interactive.md
@@ -0,0 +1,73 @@
+---
+title: NGINX Plus
+description: このチュートリアルでは、nginx-openid-connectモジュールを使用して、NGINXサーバーに認証と認可を追加する方法について説明します。
+interactive:  true
+files:
+ - files/nginx
+ - files/openid_connection_configuration
+ - files/openid_connect
+ - files/frontend
+github:
+  path: https://github.com/nginxinc/nginx-openid-connect
+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..e07eb8b540
--- /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: https://github.com/auth0-samples/auth0-php-web-app/tree/main/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に関連したエラーを投入していない。
      
+
+  
      
+
+  
      
+
+  
      
+
+## ルートを作成する {{{ 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の値を使用し、アプリケーションへリダイレクトする。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## アプリケーションにログアウトを追加する {{{ data-action="code" data-code="logout.php" }}}
+
+
+
      プロジェクトにログインしたユーザーには、ログアウトする方法も必要です。SDKのlogout()メソッドを使用してログアウトボタンを処理します。ユーザーはログアウトすると、Auth0ログアウトエンドポイントにリダイレクトされてから、即座に、このクイックスタートで先ほどセットアップしたログアウトURLへとリダイレクトで戻されます。
      アプリケーションでlogout.phpという名前の新規ファイルを作成し、インタラクティブパネルからコードをコピーします。これにはログアウトに必要なロジックが含まれています。それからindex.phpファイルを更新して新しいログアウトボタンを含めます。
      PHPセクション5「チェックポイント」 
      アプリケーションを実行してログアウトボタンをクリックし、次の点を確認します：
      • アプリケーションによって、アプリケーションの設定で［Allowed Logout URLs（許可されているログアウトURL）］の1つに指定されているアドレスへリダイレクトされる。
      • アプリケーションにもうログインしていない。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## ユーザープロファイル情報を表示する {{{ data-action="code" data-code="profile.php" }}}
+
+
+
      ユーザーがログインやログアウトできるようになったら、認証済のユーザーに関連付けられたプロファイル情報を取得できるようにしたいと考えるはずです。たとえば、ログインしたユーザーの名前やプロフィール写真をプロジェクトに表示したいかもしれません。
      Auth0 PHP SDKではgetCredentials()メソッドからユーザー情報が提供されます。インタラクティブパネルでprofile.phpコードを確認し、使用方法の例をチェックします。
      このメソッドにはユーザーのアイデンティティに関する機密情報が含まれるため、この方法が使用できるかはユーザーの認証ステータスによります。エラーを防ぐため、getCredentials()メソッドがobjectまたはnullを返すかを必ず確認し、アプリケーションが結果を使用する前に、Auth0がユーザーを認証したかどうか判定します。
      Phpセクション6「チェックポイント」 
      以下の点を確認します：
      • ログイン後、nicknameやその他のユーザープロパティをすべて正しく表示できる。
      
+
+  
      
+
+  
      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/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..0c1194035f
--- /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: https://github.com/auth0-samples/auth0-python-web-app/tree/master/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へルートするログインボタンがあり、ログイン後アプリケーションに戻るとプロファイル情報を確認できます。
      
+
+  
      
+
+  
      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/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..2b12c9a50b
--- /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: https://github.com/auth0-samples/auth0-rubyonrails-sample/tree/master/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に関連したエラーを受け取らないことを確認します。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## アプリケーションにログインを追加する
+
+
+
      ユーザーが/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にリダイレクトされ、認証に成功するとアプリに戻されることを確認してください。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## アプリケーションにログアウトを追加する
+
+
+
      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にリダイレクトされた後即座にアプリケーションに戻り、ログインした状態ではないことを確認します。
      
+
+  
      
+
+  
      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.
      
+
+  
      
+
+## ユーザープロファイル情報を表示する {{{ 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
new file mode 100644
index 0000000000..1c080f81d4
Binary files /dev/null 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
new file mode 100644
index 0000000000..b60f04ff95
Binary files /dev/null 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/changing-actions.png b/media/articles/anomaly-detection/changing-actions.png
deleted file mode 100644
index 6931583410..0000000000
Binary files a/media/articles/anomaly-detection/changing-actions.png and /dev/null 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/api-dashboard.png b/media/articles/api-auth/api-dashboard.png
new file mode 100755
index 0000000000..c0e2408a86
Binary files /dev/null and b/media/articles/api-auth/api-dashboard.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/authorization-code-grant-pkce.png b/media/articles/api-auth/authorization-code-grant-pkce.png
old mode 100644
new mode 100755
index 02f0f18c1c..17f8d01c45
Binary files a/media/articles/api-auth/authorization-code-grant-pkce.png and b/media/articles/api-auth/authorization-code-grant-pkce.png differ
diff --git a/media/articles/api-auth/authorization-code-grant.png b/media/articles/api-auth/authorization-code-grant.png
index dc911a9f43..0094a712f2 100755
Binary files a/media/articles/api-auth/authorization-code-grant.png and b/media/articles/api-auth/authorization-code-grant.png differ
diff --git a/media/articles/api-auth/challenge-type-oob-no-binding-method.png b/media/articles/api-auth/challenge-type-oob-no-binding-method.png
new file mode 100644
index 0000000000..959930f077
Binary files /dev/null and b/media/articles/api-auth/challenge-type-oob-no-binding-method.png differ
diff --git a/media/articles/api-auth/challenge-type-oob-with-binding-method.png b/media/articles/api-auth/challenge-type-oob-with-binding-method.png
new file mode 100644
index 0000000000..b744754742
Binary files /dev/null and b/media/articles/api-auth/challenge-type-oob-with-binding-method.png differ
diff --git a/media/articles/api-auth/challenge-type-otp.png b/media/articles/api-auth/challenge-type-otp.png
new file mode 100644
index 0000000000..7b9d7fbf65
Binary files /dev/null and b/media/articles/api-auth/challenge-type-otp.png differ
diff --git a/media/articles/api-auth/client-auth-method.png b/media/articles/api-auth/client-auth-method.png
new file mode 100644
index 0000000000..dedb4e0d53
Binary files /dev/null and b/media/articles/api-auth/client-auth-method.png differ
diff --git a/media/articles/api-auth/client-credentials-grant.png b/media/articles/api-auth/client-credentials-grant.png
old mode 100755
new mode 100644
index f6735eb83d..c3ddf86957
Binary files a/media/articles/api-auth/client-credentials-grant.png and b/media/articles/api-auth/client-credentials-grant.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
new file mode 100644
index 0000000000..bad32c1053
Binary files /dev/null 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
new file mode 100644
index 0000000000..dc9a192d2c
Binary files /dev/null and b/media/articles/api-auth/create-scope.png differ
diff --git a/media/articles/api-auth/decode-jwt.png b/media/articles/api-auth/decode-jwt.png
new file mode 100644
index 0000000000..3ee20bdd24
Binary files /dev/null and b/media/articles/api-auth/decode-jwt.png differ
diff --git a/media/articles/api-auth/default-directory-setting.png b/media/articles/api-auth/default-directory-setting.png
index 644df7c108..1524d8ae4b 100644
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/enable-auth0-forwarded-for.png b/media/articles/api-auth/enable-auth0-forwarded-for.png
new file mode 100644
index 0000000000..777a99466e
Binary files /dev/null and b/media/articles/api-auth/enable-auth0-forwarded-for.png differ
diff --git a/media/articles/api-auth/enabling-auth0-forwarded-for.png b/media/articles/api-auth/enabling-auth0-forwarded-for.png
new file mode 100644
index 0000000000..b5114d9284
Binary files /dev/null and b/media/articles/api-auth/enabling-auth0-forwarded-for.png differ
diff --git a/media/articles/api-auth/hooks/cc-decode-token.png b/media/articles/api-auth/hooks/cc-decode-token.png
new file mode 100755
index 0000000000..c24c3a458f
Binary files /dev/null and b/media/articles/api-auth/hooks/cc-decode-token.png differ
diff --git a/media/articles/api-auth/hooks/cc-webtask-editor.png b/media/articles/api-auth/hooks/cc-webtask-editor.png
new file mode 100755
index 0000000000..11d8ca0df1
Binary files /dev/null and b/media/articles/api-auth/hooks/cc-webtask-editor.png differ
diff --git a/media/articles/api-auth/hooks/dashboard-hooks.png b/media/articles/api-auth/hooks/dashboard-hooks.png
new file mode 100755
index 0000000000..ffbb4146b7
Binary files /dev/null and b/media/articles/api-auth/hooks/dashboard-hooks.png differ
diff --git a/media/articles/api-auth/hooks/edit-cc-hook.png b/media/articles/api-auth/hooks/edit-cc-hook.png
new file mode 100755
index 0000000000..d05ca1182c
Binary files /dev/null and b/media/articles/api-auth/hooks/edit-cc-hook.png differ
diff --git a/media/articles/api-auth/hooks/new-cc-hook.png b/media/articles/api-auth/hooks/new-cc-hook.png
new file mode 100755
index 0000000000..208cfd1e3c
Binary files /dev/null and b/media/articles/api-auth/hooks/new-cc-hook.png differ
diff --git a/media/articles/api-auth/implicit-grant.png b/media/articles/api-auth/implicit-grant.png
index f8dee017f3..3f69d4cf60 100755
Binary files a/media/articles/api-auth/implicit-grant.png and b/media/articles/api-auth/implicit-grant.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/oidc-conformant-flag.png b/media/articles/api-auth/oidc-conformant-flag.png
new file mode 100755
index 0000000000..d2f40ec2b0
Binary files /dev/null and b/media/articles/api-auth/oidc-conformant-flag.png differ
diff --git a/media/articles/api-auth/password-grant.png b/media/articles/api-auth/password-grant.png
index 6854cb22d4..7cbbd0233f 100644
Binary files a/media/articles/api-auth/password-grant.png and b/media/articles/api-auth/password-grant.png differ
diff --git a/media/articles/api-auth/recovery-code.png b/media/articles/api-auth/recovery-code.png
new file mode 100644
index 0000000000..8343fb0fe6
Binary files /dev/null and b/media/articles/api-auth/recovery-code.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-auth/sample-jwt.png b/media/articles/api-auth/sample-jwt.png
new file mode 100644
index 0000000000..94f7074a6c
Binary files /dev/null and b/media/articles/api-auth/sample-jwt.png differ
diff --git a/media/articles/api-auth/tutorials/represent-multiple-apis/apis.png b/media/articles/api-auth/tutorials/represent-multiple-apis/apis.png
new file mode 100644
index 0000000000..16d1fe52a4
Binary files /dev/null and b/media/articles/api-auth/tutorials/represent-multiple-apis/apis.png differ
diff --git a/media/articles/api-auth/tutorials/represent-multiple-apis/consent-screen.png b/media/articles/api-auth/tutorials/represent-multiple-apis/consent-screen.png
new file mode 100644
index 0000000000..7ca5c7a8ca
Binary files /dev/null and b/media/articles/api-auth/tutorials/represent-multiple-apis/consent-screen.png differ
diff --git a/media/articles/api-auth/tutorials/represent-multiple-apis/create-new-api.png b/media/articles/api-auth/tutorials/represent-multiple-apis/create-new-api.png
new file mode 100644
index 0000000000..b116ba5393
Binary files /dev/null and b/media/articles/api-auth/tutorials/represent-multiple-apis/create-new-api.png differ
diff --git a/media/articles/api-auth/tutorials/represent-multiple-apis/dashboard-apis.png b/media/articles/api-auth/tutorials/represent-multiple-apis/dashboard-apis.png
new file mode 100644
index 0000000000..0dd50414ea
Binary files /dev/null and b/media/articles/api-auth/tutorials/represent-multiple-apis/dashboard-apis.png differ
diff --git a/media/articles/api-auth/tutorials/represent-multiple-apis/home.png b/media/articles/api-auth/tutorials/represent-multiple-apis/home.png
new file mode 100644
index 0000000000..b6065eb6e8
Binary files /dev/null and b/media/articles/api-auth/tutorials/represent-multiple-apis/home.png differ
diff --git a/media/articles/api-auth/tutorials/represent-multiple-apis/lock.png b/media/articles/api-auth/tutorials/represent-multiple-apis/lock.png
new file mode 100644
index 0000000000..ab3580339d
Binary files /dev/null and b/media/articles/api-auth/tutorials/represent-multiple-apis/lock.png differ
diff --git a/media/articles/api-auth/tutorials/represent-multiple-apis/new-scopes.png b/media/articles/api-auth/tutorials/represent-multiple-apis/new-scopes.png
new file mode 100644
index 0000000000..05af307d00
Binary files /dev/null and b/media/articles/api-auth/tutorials/represent-multiple-apis/new-scopes.png differ
diff --git a/media/articles/api-auth/tutorials/represent-multiple-apis/scopes-page.png b/media/articles/api-auth/tutorials/represent-multiple-apis/scopes-page.png
new file mode 100644
index 0000000000..e5b81ebecb
Binary files /dev/null and b/media/articles/api-auth/tutorials/represent-multiple-apis/scopes-page.png differ
diff --git a/media/articles/api/overview/enable-api-section.png b/media/articles/api/overview/enable-api-section.png
deleted file mode 100755
index 5e6772a56f..0000000000
Binary files a/media/articles/api/overview/enable-api-section.png and /dev/null differ
diff --git a/media/articles/api/postman/get-users-postman.png b/media/articles/api/postman/get-users-postman.png
index bdca9d625a..fedc196ed5 100644
Binary files a/media/articles/api/postman/get-users-postman.png and b/media/articles/api/postman/get-users-postman.png differ
diff --git a/media/articles/api/tokens/authorize-noninteractive.png b/media/articles/api/tokens/authorize-noninteractive.png
deleted file mode 100644
index 1a647a62dd..0000000000
Binary files a/media/articles/api/tokens/authorize-noninteractive.png and /dev/null differ
diff --git a/media/articles/api/tokens/choose-scopes.png b/media/articles/api/tokens/choose-scopes.png
deleted file mode 100644
index b10943db5c..0000000000
Binary files a/media/articles/api/tokens/choose-scopes.png and /dev/null differ
diff --git a/media/articles/api/tokens/copy-token.png b/media/articles/api/tokens/copy-token.png
new file mode 100644
index 0000000000..fab3684023
Binary files /dev/null and b/media/articles/api/tokens/copy-token.png differ
diff --git a/media/articles/api/tokens/create-authorize-client.png b/media/articles/api/tokens/create-authorize-client.png
new file mode 100755
index 0000000000..2eebb597e9
Binary files /dev/null and b/media/articles/api/tokens/create-authorize-client.png differ
diff --git a/media/articles/api/tokens/endpoint-scope.png b/media/articles/api/tokens/endpoint-scope.png
deleted file mode 100644
index 9d83ede856..0000000000
Binary files a/media/articles/api/tokens/endpoint-scope.png and /dev/null differ
diff --git a/media/articles/api/tokens/navigate-button.png b/media/articles/api/tokens/navigate-button.png
deleted file mode 100644
index 61e952c572..0000000000
Binary files a/media/articles/api/tokens/navigate-button.png and /dev/null differ
diff --git a/media/articles/api/tokens/noninteractive-client.png b/media/articles/api/tokens/noninteractive-client.png
deleted file mode 100644
index f62f7ce21c..0000000000
Binary files a/media/articles/api/tokens/noninteractive-client.png and /dev/null differ
diff --git a/media/articles/api/tokens/set-token.png b/media/articles/api/tokens/set-token.png
new file mode 100644
index 0000000000..01655edae7
Binary files /dev/null and b/media/articles/api/tokens/set-token.png differ
diff --git a/media/articles/api/tokens/test-client.png b/media/articles/api/tokens/test-client.png
deleted file mode 100644
index e6e80687f8..0000000000
Binary files a/media/articles/api/tokens/test-client.png and /dev/null differ
diff --git a/media/articles/api/tokens/token-generator.png b/media/articles/api/tokens/token-generator.png
deleted file mode 100644
index e23fc907ce..0000000000
Binary files a/media/articles/api/tokens/token-generator.png and /dev/null differ
diff --git a/media/articles/api/user-search-lucene.png b/media/articles/api/user-search-lucene.png
deleted file mode 100644
index 51b1d0152f..0000000000
Binary files a/media/articles/api/user-search-lucene.png and /dev/null differ
diff --git a/media/articles/appliance/Appliance-HA-Options.svg b/media/articles/appliance/Appliance-HA-Options.svg
new file mode 100644
index 0000000000..85ad7e253d
--- /dev/null
+++ b/media/articles/appliance/Appliance-HA-Options.svg
@@ -0,0 +1,79 @@
+
+
+    
+    Appliance - HA Options
+    Created with Sketch.
+    
+    
+        
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+            
+        
+    
+
\ No newline at end of file
diff --git a/media/articles/appliance/admin/rate-limiting-1.png b/media/articles/appliance/admin/rate-limiting-1.png
new file mode 100755
index 0000000000..2b3af759c0
Binary files /dev/null and b/media/articles/appliance/admin/rate-limiting-1.png differ
diff --git a/media/articles/appliance/admin/rate-limiting-2.png b/media/articles/appliance/admin/rate-limiting-2.png
new file mode 100755
index 0000000000..a3edc04c1d
Binary files /dev/null and b/media/articles/appliance/admin/rate-limiting-2.png differ
diff --git a/media/articles/appliance/admin/rate-limiting-3.png b/media/articles/appliance/admin/rate-limiting-3.png
new file mode 100755
index 0000000000..0b8f5bd2cc
Binary files /dev/null and b/media/articles/appliance/admin/rate-limiting-3.png differ
diff --git a/media/articles/appliance/api-keys/key.png b/media/articles/appliance/api-keys/key.png
index 05c8025c42..aa087bc804 100755
Binary files a/media/articles/appliance/api-keys/key.png and b/media/articles/appliance/api-keys/key.png differ
diff --git a/media/articles/appliance/api-keys/no-key.png b/media/articles/appliance/api-keys/no-key.png
index 48b3607cf7..dfde2115f4 100755
Binary files a/media/articles/appliance/api-keys/no-key.png and b/media/articles/appliance/api-keys/no-key.png differ
diff --git a/media/articles/appliance/appliance-infrastructure.png b/media/articles/appliance/appliance-infrastructure.png
deleted file mode 100644
index adbacd17d4..0000000000
Binary files a/media/articles/appliance/appliance-infrastructure.png and /dev/null differ
diff --git a/media/articles/appliance/cli/backup-available.png b/media/articles/appliance/cli/backup-available.png
new file mode 100644
index 0000000000..883a6eb1c9
Binary files /dev/null and b/media/articles/appliance/cli/backup-available.png differ
diff --git a/media/articles/appliance/cli/backup-in-progress.png b/media/articles/appliance/cli/backup-in-progress.png
new file mode 100644
index 0000000000..3336dd83c1
Binary files /dev/null and b/media/articles/appliance/cli/backup-in-progress.png differ
diff --git a/media/articles/appliance/cli/cli-config-with-key.png b/media/articles/appliance/cli/cli-config-with-key.png
index 07aa52f6a4..c97555b29e 100755
Binary files a/media/articles/appliance/cli/cli-config-with-key.png and b/media/articles/appliance/cli/cli-config-with-key.png differ
diff --git a/media/articles/appliance/cli/cli-create-key.png b/media/articles/appliance/cli/cli-create-key.png
index c9c7e2a485..f7edcbb53f 100755
Binary files a/media/articles/appliance/cli/cli-create-key.png and b/media/articles/appliance/cli/cli-create-key.png differ
diff --git a/media/articles/appliance/dashboard/activity.png b/media/articles/appliance/dashboard/activity.png
index c66b44e883..1594d244a7 100755
Binary files a/media/articles/appliance/dashboard/activity.png and b/media/articles/appliance/dashboard/activity.png differ
diff --git a/media/articles/appliance/dashboard/cli-keys-add.png b/media/articles/appliance/dashboard/cli-keys-add.png
index 50fd70ef4a..be28f85855 100644
Binary files a/media/articles/appliance/dashboard/cli-keys-add.png and b/media/articles/appliance/dashboard/cli-keys-add.png differ
diff --git a/media/articles/appliance/dashboard/cli-keys.png b/media/articles/appliance/dashboard/cli-keys.png
index 5592eb2fba..70ed1d562c 100755
Binary files a/media/articles/appliance/dashboard/cli-keys.png and b/media/articles/appliance/dashboard/cli-keys.png differ
diff --git a/media/articles/appliance/dashboard/dashboard.png b/media/articles/appliance/dashboard/dashboard.png
index 400661b370..31b95eb0a8 100755
Binary files a/media/articles/appliance/dashboard/dashboard.png and b/media/articles/appliance/dashboard/dashboard.png differ
diff --git a/media/articles/appliance/dashboard/debug-logs.png b/media/articles/appliance/dashboard/debug-logs.png
index 176a8422af..6b2d24dde5 100644
Binary files a/media/articles/appliance/dashboard/debug-logs.png and b/media/articles/appliance/dashboard/debug-logs.png differ
diff --git a/media/articles/appliance/dashboard/health-keys-api-service.png b/media/articles/appliance/dashboard/health-keys-api-service.png
index df3d846782..4b7c38d22e 100755
Binary files a/media/articles/appliance/dashboard/health-keys-api-service.png and b/media/articles/appliance/dashboard/health-keys-api-service.png differ
diff --git a/media/articles/appliance/dashboard/instrumentation-login.png b/media/articles/appliance/dashboard/instrumentation-login.png
new file mode 100644
index 0000000000..94c2bdacee
Binary files /dev/null and b/media/articles/appliance/dashboard/instrumentation-login.png differ
diff --git a/media/articles/appliance/dashboard/instrumentation-page.png b/media/articles/appliance/dashboard/instrumentation-page.png
new file mode 100644
index 0000000000..f1ee20751e
Binary files /dev/null and b/media/articles/appliance/dashboard/instrumentation-page.png differ
diff --git a/media/articles/appliance/dashboard/nodes.png b/media/articles/appliance/dashboard/nodes.png
index 56203b731a..0317a6e80a 100755
Binary files a/media/articles/appliance/dashboard/nodes.png and b/media/articles/appliance/dashboard/nodes.png differ
diff --git a/media/articles/appliance/dashboard/primary-dashboard.png b/media/articles/appliance/dashboard/primary-dashboard.png
index 508bbd9dde..cbd040d418 100644
Binary files a/media/articles/appliance/dashboard/primary-dashboard.png and b/media/articles/appliance/dashboard/primary-dashboard.png differ
diff --git a/media/articles/appliance/dashboard/rate-limiting.png b/media/articles/appliance/dashboard/rate-limiting.png
index 941a739fe8..8b3f086c4c 100644
Binary files a/media/articles/appliance/dashboard/rate-limiting.png and b/media/articles/appliance/dashboard/rate-limiting.png differ
diff --git a/media/articles/appliance/dashboard/settings.png b/media/articles/appliance/dashboard/settings.png
index 6964b80024..32e6383b86 100755
Binary files a/media/articles/appliance/dashboard/settings.png and b/media/articles/appliance/dashboard/settings.png differ
diff --git a/media/articles/appliance/dashboard/tenant-add-custom-domain.png b/media/articles/appliance/dashboard/tenant-add-custom-domain.png
index 47685fcc0f..b28a4fe9fb 100755
Binary files a/media/articles/appliance/dashboard/tenant-add-custom-domain.png and b/media/articles/appliance/dashboard/tenant-add-custom-domain.png differ
diff --git a/media/articles/appliance/dashboard/tenant-custom-domain.png b/media/articles/appliance/dashboard/tenant-custom-domain.png
index e54ec2b064..9aa7b19a29 100755
Binary files a/media/articles/appliance/dashboard/tenant-custom-domain.png and b/media/articles/appliance/dashboard/tenant-custom-domain.png differ
diff --git a/media/articles/appliance/dashboard/tenants.png b/media/articles/appliance/dashboard/tenants.png
index cdcccf262e..958692a731 100755
Binary files a/media/articles/appliance/dashboard/tenants.png and b/media/articles/appliance/dashboard/tenants.png differ
diff --git a/media/articles/appliance/dashboard/troubleshoot.png b/media/articles/appliance/dashboard/troubleshoot.png
index 9e2f419394..56121f0d57 100755
Binary files a/media/articles/appliance/dashboard/troubleshoot.png and b/media/articles/appliance/dashboard/troubleshoot.png differ
diff --git a/media/articles/appliance/dashboard/updates.png b/media/articles/appliance/dashboard/updates.png
index 61fe9b2a18..a524e5415e 100755
Binary files a/media/articles/appliance/dashboard/updates.png and b/media/articles/appliance/dashboard/updates.png differ
diff --git a/media/articles/appliance/infrastructure/overview.png b/media/articles/appliance/infrastructure/overview.png
new file mode 100644
index 0000000000..8dd1d2eecf
Binary files /dev/null and b/media/articles/appliance/infrastructure/overview.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/appliance/overview.png b/media/articles/appliance/overview.png
deleted file mode 100755
index 8b878cbdda..0000000000
Binary files a/media/articles/appliance/overview.png and /dev/null differ
diff --git a/media/articles/appliance/overview.svg b/media/articles/appliance/overview.svg
new file mode 100644
index 0000000000..f5e52fdfc4
--- /dev/null
+++ b/media/articles/appliance/overview.svg
@@ -0,0 +1 @@
+Appliance-2Firewall
\ No newline at end of file
diff --git a/media/articles/appliance/remote-access/jumpshot-fw-csjs.png b/media/articles/appliance/remote-access/jumpshot-fw-csjs.png
new file mode 100644
index 0000000000..0caa3426e2
Binary files /dev/null and b/media/articles/appliance/remote-access/jumpshot-fw-csjs.png differ
diff --git a/media/articles/appliance/remote-access/jumpshot-fw.png b/media/articles/appliance/remote-access/jumpshot-fw.png
new file mode 100644
index 0000000000..b5658d669d
Binary files /dev/null and b/media/articles/appliance/remote-access/jumpshot-fw.png differ
diff --git a/media/articles/appliance/remote-access/vpn.png b/media/articles/appliance/remote-access/vpn.png
new file mode 100644
index 0000000000..315525becd
Binary files /dev/null and b/media/articles/appliance/remote-access/vpn.png differ
diff --git a/media/articles/applications/addons-dashboard-list.png b/media/articles/applications/addons-dashboard-list.png
old mode 100755
new mode 100644
index 6788c081b0..2e9fddc2e9
Binary files a/media/articles/applications/addons-dashboard-list.png and b/media/articles/applications/addons-dashboard-list.png differ
diff --git a/media/articles/applications/advanced-settings.png b/media/articles/applications/advanced-settings.png
new file mode 100644
index 0000000000..ba638cd9b3
Binary files /dev/null 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/bundle-id.png b/media/articles/applications/bundle-id.png
new file mode 100755
index 0000000000..330d4ac0db
Binary files /dev/null and b/media/articles/applications/bundle-id.png differ
diff --git a/media/articles/applications/connections-dashboard-list.png b/media/articles/applications/connections-dashboard-list.png
old mode 100755
new mode 100644
index 3299f54b22..1f8f4a3c78
Binary files a/media/articles/applications/connections-dashboard-list.png and b/media/articles/applications/connections-dashboard-list.png differ
diff --git a/media/articles/applications/create-client-popup.png b/media/articles/applications/create-client-popup.png
index 8872ad96c6..6304b2fd0e 100644
Binary files a/media/articles/applications/create-client-popup.png and b/media/articles/applications/create-client-popup.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/settings.png b/media/articles/applications/settings.png
new file mode 100644
index 0000000000..e6a7cf066d
Binary files /dev/null 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-user-role.png b/media/articles/architecture-scenarios/mobile-api/add-user-role.png
new file mode 100644
index 0000000000..8b31d4a07a
Binary files /dev/null and b/media/articles/architecture-scenarios/mobile-api/add-user-role.png differ
diff --git a/media/articles/architecture-scenarios/mobile-api/authorization-code-grant-pkce.png b/media/articles/architecture-scenarios/mobile-api/authorization-code-grant-pkce.png
new file mode 100755
index 0000000000..17f8d01c45
Binary files /dev/null and b/media/articles/architecture-scenarios/mobile-api/authorization-code-grant-pkce.png differ
diff --git a/media/articles/architecture-scenarios/mobile-api/create-api.png b/media/articles/architecture-scenarios/mobile-api/create-api.png
new file mode 100755
index 0000000000..62d3592acc
Binary files /dev/null and b/media/articles/architecture-scenarios/mobile-api/create-api.png differ
diff --git a/media/articles/architecture-scenarios/mobile-api/create-client.png b/media/articles/architecture-scenarios/mobile-api/create-client.png
new file mode 100755
index 0000000000..d34ad2b195
Binary files /dev/null and b/media/articles/architecture-scenarios/mobile-api/create-client.png differ
diff --git a/media/articles/architecture-scenarios/mobile-api/create-employee-role.png b/media/articles/architecture-scenarios/mobile-api/create-employee-role.png
new file mode 100644
index 0000000000..da089e5715
Binary files /dev/null and b/media/articles/architecture-scenarios/mobile-api/create-employee-role.png differ
diff --git a/media/articles/architecture-scenarios/mobile-api/create-manager-role.png b/media/articles/architecture-scenarios/mobile-api/create-manager-role.png
new file mode 100644
index 0000000000..e885d2802a
Binary files /dev/null and b/media/articles/architecture-scenarios/mobile-api/create-manager-role.png differ
diff --git a/media/articles/architecture-scenarios/mobile-api/create-permission.png b/media/articles/architecture-scenarios/mobile-api/create-permission.png
new file mode 100644
index 0000000000..bac6faa816
Binary files /dev/null and b/media/articles/architecture-scenarios/mobile-api/create-permission.png differ
diff --git a/media/articles/architecture-scenarios/mobile-api/permissions.png b/media/articles/architecture-scenarios/mobile-api/permissions.png
new file mode 100644
index 0000000000..93b3357c91
Binary files /dev/null and b/media/articles/architecture-scenarios/mobile-api/permissions.png differ
diff --git a/media/articles/architecture-scenarios/mobile-api/publish-rule.png b/media/articles/architecture-scenarios/mobile-api/publish-rule.png
new file mode 100644
index 0000000000..1d9fc9a062
Binary files /dev/null and b/media/articles/architecture-scenarios/mobile-api/publish-rule.png differ
diff --git a/media/articles/architecture-scenarios/mobile-api/rules-1.png b/media/articles/architecture-scenarios/mobile-api/rules-1.png
new file mode 100644
index 0000000000..6f2ba24313
Binary files /dev/null and b/media/articles/architecture-scenarios/mobile-api/rules-1.png differ
diff --git a/media/articles/architecture-scenarios/mobile-api/rules-2.png b/media/articles/architecture-scenarios/mobile-api/rules-2.png
new file mode 100644
index 0000000000..6abb546e3a
Binary files /dev/null and b/media/articles/architecture-scenarios/mobile-api/rules-2.png differ
diff --git a/media/articles/architecture-scenarios/mobile-api/select-configuration.png b/media/articles/architecture-scenarios/mobile-api/select-configuration.png
new file mode 100644
index 0000000000..c42bd3836c
Binary files /dev/null and b/media/articles/architecture-scenarios/mobile-api/select-configuration.png 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/architecture-scenarios/server-api/add-scopes.png b/media/articles/architecture-scenarios/server-api/add-scopes.png
index fc95396ca2..e65703abd0 100755
Binary files a/media/articles/architecture-scenarios/server-api/add-scopes.png and b/media/articles/architecture-scenarios/server-api/add-scopes.png differ
diff --git a/media/articles/architecture-scenarios/server-api/assign-scopes.png b/media/articles/architecture-scenarios/server-api/assign-scopes.png
index 4585a258e1..73b103a445 100755
Binary files a/media/articles/architecture-scenarios/server-api/assign-scopes.png and b/media/articles/architecture-scenarios/server-api/assign-scopes.png differ
diff --git a/media/articles/architecture-scenarios/server-api/create-api.png b/media/articles/architecture-scenarios/server-api/create-api.png
old mode 100755
new mode 100644
index 8272f0cbf0..7abb5152a8
Binary files a/media/articles/architecture-scenarios/server-api/create-api.png and b/media/articles/architecture-scenarios/server-api/create-api.png differ
diff --git a/media/articles/architecture-scenarios/server-api/enable-apis-section.png b/media/articles/architecture-scenarios/server-api/enable-apis-section.png
deleted file mode 100755
index 21c8cfc386..0000000000
Binary files a/media/articles/architecture-scenarios/server-api/enable-apis-section.png and /dev/null differ
diff --git a/media/articles/architecture-scenarios/spa-api/add-scopes.png b/media/articles/architecture-scenarios/spa-api/add-scopes.png
new file mode 100755
index 0000000000..ce1f320662
Binary files /dev/null and b/media/articles/architecture-scenarios/spa-api/add-scopes.png differ
diff --git a/media/articles/architecture-scenarios/spa-api/add-user-role.png b/media/articles/architecture-scenarios/spa-api/add-user-role.png
new file mode 100644
index 0000000000..4640c4d3ef
Binary files /dev/null and b/media/articles/architecture-scenarios/spa-api/add-user-role.png differ
diff --git a/media/articles/architecture-scenarios/spa-api/create-api.png b/media/articles/architecture-scenarios/spa-api/create-api.png
new file mode 100644
index 0000000000..7abb5152a8
Binary files /dev/null and b/media/articles/architecture-scenarios/spa-api/create-api.png differ
diff --git a/media/articles/architecture-scenarios/spa-api/create-client.png b/media/articles/architecture-scenarios/spa-api/create-client.png
new file mode 100755
index 0000000000..5e2c7e31d2
Binary files /dev/null and b/media/articles/architecture-scenarios/spa-api/create-client.png differ
diff --git a/media/articles/architecture-scenarios/spa-api/create-employee-role.png b/media/articles/architecture-scenarios/spa-api/create-employee-role.png
new file mode 100644
index 0000000000..d0863f00dd
Binary files /dev/null and b/media/articles/architecture-scenarios/spa-api/create-employee-role.png differ
diff --git a/media/articles/architecture-scenarios/spa-api/create-manager-role.png b/media/articles/architecture-scenarios/spa-api/create-manager-role.png
new file mode 100644
index 0000000000..56c33d6616
Binary files /dev/null and b/media/articles/architecture-scenarios/spa-api/create-manager-role.png differ
diff --git a/media/articles/architecture-scenarios/spa-api/create-permission.png b/media/articles/architecture-scenarios/spa-api/create-permission.png
new file mode 100644
index 0000000000..095e746ac4
Binary files /dev/null and b/media/articles/architecture-scenarios/spa-api/create-permission.png differ
diff --git a/media/articles/architecture-scenarios/spa-api/permissions.png b/media/articles/architecture-scenarios/spa-api/permissions.png
new file mode 100644
index 0000000000..9e7e23cbd9
Binary files /dev/null and b/media/articles/architecture-scenarios/spa-api/permissions.png differ
diff --git a/media/articles/architecture-scenarios/spa-api/publish-rule.png b/media/articles/architecture-scenarios/spa-api/publish-rule.png
new file mode 100644
index 0000000000..1d9fc9a062
Binary files /dev/null and b/media/articles/architecture-scenarios/spa-api/publish-rule.png differ
diff --git a/media/articles/architecture-scenarios/spa-api/roles.png b/media/articles/architecture-scenarios/spa-api/roles.png
new file mode 100644
index 0000000000..c5e2385230
Binary files /dev/null and b/media/articles/architecture-scenarios/spa-api/roles.png differ
diff --git a/media/articles/architecture-scenarios/spa-api/rules-1.png b/media/articles/architecture-scenarios/spa-api/rules-1.png
new file mode 100644
index 0000000000..32f06f509e
Binary files /dev/null and b/media/articles/architecture-scenarios/spa-api/rules-1.png differ
diff --git a/media/articles/architecture-scenarios/spa-api/rules-2.png b/media/articles/architecture-scenarios/spa-api/rules-2.png
new file mode 100644
index 0000000000..c8682bb984
Binary files /dev/null and b/media/articles/architecture-scenarios/spa-api/rules-2.png differ
diff --git a/media/articles/architecture-scenarios/spa-api/select-configuration.png b/media/articles/architecture-scenarios/spa-api/select-configuration.png
new file mode 100644
index 0000000000..79fb6a1200
Binary files /dev/null and b/media/articles/architecture-scenarios/spa-api/select-configuration.png differ
diff --git a/media/articles/architecture-scenarios/web-app-sso/add-group-mapping.png b/media/articles/architecture-scenarios/web-app-sso/add-group-mapping.png
old mode 100755
new mode 100644
index 7178173e3c..a76b8b24bb
Binary files a/media/articles/architecture-scenarios/web-app-sso/add-group-mapping.png and b/media/articles/architecture-scenarios/web-app-sso/add-group-mapping.png differ
diff --git a/media/articles/architecture-scenarios/web-app-sso/enable-client-ad.png b/media/articles/architecture-scenarios/web-app-sso/enable-client-ad.png
old mode 100755
new mode 100644
index 5889955af5..fb2478f961
Binary files a/media/articles/architecture-scenarios/web-app-sso/enable-client-ad.png and b/media/articles/architecture-scenarios/web-app-sso/enable-client-ad.png differ
diff --git a/media/articles/architecture-scenarios/web-app-sso/enable-client-db.png b/media/articles/architecture-scenarios/web-app-sso/enable-client-db.png
old mode 100755
new mode 100644
index fb5a96872d..b3be1695e1
Binary files a/media/articles/architecture-scenarios/web-app-sso/enable-client-db.png and b/media/articles/architecture-scenarios/web-app-sso/enable-client-db.png differ
diff --git a/media/articles/architecture-scenarios/web-app-sso/solution-diagram.png b/media/articles/architecture-scenarios/web-app-sso/solution-diagram.png
old mode 100755
new mode 100644
index 369f63b7cd..be2ce31a17
Binary files a/media/articles/architecture-scenarios/web-app-sso/solution-diagram.png and b/media/articles/architecture-scenarios/web-app-sso/solution-diagram.png differ
diff --git a/media/articles/architecture-scenarios/web-app-sso/view-group-mapping.png b/media/articles/architecture-scenarios/web-app-sso/view-group-mapping.png
old mode 100755
new mode 100644
index b9aa1f8175..52ce2e7c99
Binary files a/media/articles/architecture-scenarios/web-app-sso/view-group-mapping.png and b/media/articles/architecture-scenarios/web-app-sso/view-group-mapping.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/client-auth/client-side-web/oidc-conformant.png b/media/articles/client-auth/client-side-web/oidc-conformant.png
new file mode 100644
index 0000000000..907f3464eb
Binary files /dev/null and b/media/articles/client-auth/client-side-web/oidc-conformant.png differ
diff --git a/media/articles/client-auth/server-side-web/oidc-conformant.png b/media/articles/client-auth/server-side-web/oidc-conformant.png
new file mode 100644
index 0000000000..add13590db
Binary files /dev/null and b/media/articles/client-auth/server-side-web/oidc-conformant.png differ
diff --git a/media/articles/clients/advanced-settings.png b/media/articles/clients/advanced-settings.png
new file mode 100644
index 0000000000..c50ec842e5
Binary files /dev/null and b/media/articles/clients/advanced-settings.png 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/clients/client-grant-types/client-advanced-settings.png b/media/articles/clients/client-grant-types/client-advanced-settings.png
new file mode 100644
index 0000000000..c50ec842e5
Binary files /dev/null and b/media/articles/clients/client-grant-types/client-advanced-settings.png differ
diff --git a/media/articles/clients/client-grant-types/client-settings.png b/media/articles/clients/client-grant-types/client-settings.png
new file mode 100644
index 0000000000..f4a86c19ea
Binary files /dev/null and b/media/articles/clients/client-grant-types/client-settings.png differ
diff --git a/media/articles/clients/client-grant-types/clients.png b/media/articles/clients/client-grant-types/clients.png
new file mode 100644
index 0000000000..f2538f8f72
Binary files /dev/null and b/media/articles/clients/client-grant-types/clients.png differ
diff --git a/media/articles/clients/client-grant-types/grant-types.png b/media/articles/clients/client-grant-types/grant-types.png
new file mode 100644
index 0000000000..0791e30b22
Binary files /dev/null and b/media/articles/clients/client-grant-types/grant-types.png differ
diff --git a/media/articles/clients/create-clients.png b/media/articles/clients/create-clients.png
new file mode 100644
index 0000000000..6304b2fd0e
Binary files /dev/null and b/media/articles/clients/create-clients.png differ
diff --git a/media/articles/clients/settings.png b/media/articles/clients/settings.png
new file mode 100644
index 0000000000..f4a86c19ea
Binary files /dev/null and b/media/articles/clients/settings.png differ
diff --git a/media/articles/clients/support-tenants-settings.png b/media/articles/clients/support-tenants-settings.png
new file mode 100755
index 0000000000..b34b0834fd
Binary files /dev/null and b/media/articles/clients/support-tenants-settings.png differ
diff --git a/media/articles/clients/support-tenants.png b/media/articles/clients/support-tenants.png
new file mode 100755
index 0000000000..7de1f8e191
Binary files /dev/null and b/media/articles/clients/support-tenants.png differ
diff --git a/media/articles/cms/joomla/configuration/joomla-1.png b/media/articles/cms/joomla/configuration/joomla-1.png
new file mode 100644
index 0000000000..dc4f32e135
Binary files /dev/null and b/media/articles/cms/joomla/configuration/joomla-1.png differ
diff --git a/media/articles/cms/joomla/configuration/joomla-2.png b/media/articles/cms/joomla/configuration/joomla-2.png
new file mode 100644
index 0000000000..3d9850b32d
Binary files /dev/null and b/media/articles/cms/joomla/configuration/joomla-2.png differ
diff --git a/media/articles/cms/joomla/configuration/joomla-3.png b/media/articles/cms/joomla/configuration/joomla-3.png
new file mode 100644
index 0000000000..dcf766b038
Binary files /dev/null and b/media/articles/cms/joomla/configuration/joomla-3.png differ
diff --git a/media/articles/cms/joomla/configuration/joomla-4.png b/media/articles/cms/joomla/configuration/joomla-4.png
new file mode 100644
index 0000000000..dcde6fdaf6
Binary files /dev/null and b/media/articles/cms/joomla/configuration/joomla-4.png differ
diff --git a/media/articles/cms/joomla/configuration/joomla-5.png b/media/articles/cms/joomla/configuration/joomla-5.png
new file mode 100644
index 0000000000..1b1f05aa3a
Binary files /dev/null and b/media/articles/cms/joomla/configuration/joomla-5.png differ
diff --git a/media/articles/cms/joomla/configuration/joomla-6.png b/media/articles/cms/joomla/configuration/joomla-6.png
new file mode 100644
index 0000000000..fc700c8d9e
Binary files /dev/null and b/media/articles/cms/joomla/configuration/joomla-6.png differ
diff --git a/media/articles/cms/joomla/configuration/joomla-7.png b/media/articles/cms/joomla/configuration/joomla-7.png
new file mode 100644
index 0000000000..241f9f759f
Binary files /dev/null and b/media/articles/cms/joomla/configuration/joomla-7.png differ
diff --git a/media/articles/cms/joomla/configuration/joomla-8.png b/media/articles/cms/joomla/configuration/joomla-8.png
new file mode 100644
index 0000000000..7a8f5a740f
Binary files /dev/null and b/media/articles/cms/joomla/configuration/joomla-8.png differ
diff --git a/media/articles/cms/joomla/installation/joomla1.png b/media/articles/cms/joomla/installation/joomla1.png
new file mode 100644
index 0000000000..4792349842
Binary files /dev/null and b/media/articles/cms/joomla/installation/joomla1.png differ
diff --git a/media/articles/cms/joomla/installation/joomla2.png b/media/articles/cms/joomla/installation/joomla2.png
new file mode 100644
index 0000000000..fe10278d51
Binary files /dev/null and b/media/articles/cms/joomla/installation/joomla2.png differ
diff --git a/media/articles/cms/joomla/installation/joomla3.png b/media/articles/cms/joomla/installation/joomla3.png
new file mode 100644
index 0000000000..cea97a4a31
Binary files /dev/null and b/media/articles/cms/joomla/installation/joomla3.png differ
diff --git a/media/articles/cms/wordpress/activate.png b/media/articles/cms/wordpress/activate.png
deleted file mode 100755
index 1ed0b5f928..0000000000
Binary files a/media/articles/cms/wordpress/activate.png and /dev/null 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-authorize-app.png b/media/articles/cms/wordpress/auth0-authorize-app.png
new file mode 100644
index 0000000000..6c500748a6
Binary files /dev/null and b/media/articles/cms/wordpress/auth0-authorize-app.png differ
diff --git a/media/articles/cms/wordpress/auth0-client-settings.png b/media/articles/cms/wordpress/auth0-client-settings.png
old mode 100755
new mode 100644
index 68d3b257db..3e9c5383b1
Binary files a/media/articles/cms/wordpress/auth0-client-settings.png and b/media/articles/cms/wordpress/auth0-client-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/auth0-plugin-settings-page.png b/media/articles/cms/wordpress/auth0-plugin-settings-page.png
deleted file mode 100755
index a6c97ef862..0000000000
Binary files a/media/articles/cms/wordpress/auth0-plugin-settings-page.png and /dev/null differ
diff --git a/media/articles/cms/wordpress/client-advanced-settings.png b/media/articles/cms/wordpress/client-advanced-settings.png
new file mode 100644
index 0000000000..7d5550d530
Binary files /dev/null and b/media/articles/cms/wordpress/client-advanced-settings.png differ
diff --git a/media/articles/cms/wordpress/client-allowed-callbacks.png b/media/articles/cms/wordpress/client-allowed-callbacks.png
new file mode 100755
index 0000000000..ecdc8d48a9
Binary files /dev/null and b/media/articles/cms/wordpress/client-allowed-callbacks.png differ
diff --git a/media/articles/cms/wordpress/client-grant-types.png b/media/articles/cms/wordpress/client-grant-types.png
new file mode 100644
index 0000000000..9a38e6602b
Binary files /dev/null and b/media/articles/cms/wordpress/client-grant-types.png differ
diff --git a/media/articles/cms/wordpress/client-listing.png b/media/articles/cms/wordpress/client-listing.png
new file mode 100644
index 0000000000..e2495de3d0
Binary files /dev/null and b/media/articles/cms/wordpress/client-listing.png 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-clients.png b/media/articles/cms/wordpress/db-connection-clients.png
new file mode 100644
index 0000000000..449f8c92fb
Binary files /dev/null and b/media/articles/cms/wordpress/db-connection-clients.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/grant-client-access-to-api.png b/media/articles/cms/wordpress/grant-client-access-to-api.png
new file mode 100644
index 0000000000..684ed32df4
Binary files /dev/null and b/media/articles/cms/wordpress/grant-client-access-to-api.png differ
diff --git a/media/articles/cms/wordpress/install-plugin.png b/media/articles/cms/wordpress/install-plugin.png
new file mode 100644
index 0000000000..c87249e018
Binary files /dev/null and b/media/articles/cms/wordpress/install-plugin.png differ
diff --git a/media/articles/cms/wordpress/installed.png b/media/articles/cms/wordpress/installed.png
deleted file mode 100755
index 4ed3f02505..0000000000
Binary files a/media/articles/cms/wordpress/installed.png and /dev/null 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/plugin-auth-page.png b/media/articles/cms/wordpress/plugin-auth-page.png
index 5bafdf88cb..a52d54bb63 100644
Binary files a/media/articles/cms/wordpress/plugin-auth-page.png and b/media/articles/cms/wordpress/plugin-auth-page.png differ
diff --git a/media/articles/cms/wordpress/plugin-settings.png b/media/articles/cms/wordpress/plugin-settings.png
old mode 100755
new mode 100644
index 6fa12d0a62..6b65bc1082
Binary files a/media/articles/cms/wordpress/plugin-settings.png and b/media/articles/cms/wordpress/plugin-settings.png differ
diff --git a/media/articles/cms/wordpress/search-and-install.png b/media/articles/cms/wordpress/search-and-install.png
deleted file mode 100755
index 9e943cacb2..0000000000
Binary files a/media/articles/cms/wordpress/search-and-install.png and /dev/null differ
diff --git a/media/articles/cms/wordpress/setup-wizard-complete.png b/media/articles/cms/wordpress/setup-wizard-complete.png
new file mode 100644
index 0000000000..f5734cab4d
Binary files /dev/null and b/media/articles/cms/wordpress/setup-wizard-complete.png differ
diff --git a/media/articles/cms/wordpress/setup-wizard-migrate-admin.png b/media/articles/cms/wordpress/setup-wizard-migrate-admin.png
new file mode 100644
index 0000000000..ee9b8c53b7
Binary files /dev/null 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
new file mode 100644
index 0000000000..3e0b96eeaa
Binary files /dev/null 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
new file mode 100644
index 0000000000..06e3b7c695
Binary files /dev/null and b/media/articles/cms/wordpress/setup-wizard-step-1.png differ
diff --git a/media/articles/compliance/auth0js-db-consent-flag.png b/media/articles/compliance/auth0js-db-consent-flag.png
new file mode 100755
index 0000000000..ff338254c7
Binary files /dev/null and b/media/articles/compliance/auth0js-db-consent-flag.png differ
diff --git a/media/articles/compliance/lock-consent-form-agree.png b/media/articles/compliance/lock-consent-form-agree.png
new file mode 100755
index 0000000000..2870361f8c
Binary files /dev/null and b/media/articles/compliance/lock-consent-form-agree.png differ
diff --git a/media/articles/compliance/lock-db-consent-flag-TC.png b/media/articles/compliance/lock-db-consent-flag-TC.png
new file mode 100755
index 0000000000..43c4b0d3e2
Binary files /dev/null and b/media/articles/compliance/lock-db-consent-flag-TC.png differ
diff --git a/media/articles/compliance/lock-db-consent-flag.png b/media/articles/compliance/lock-db-consent-flag.png
new file mode 100755
index 0000000000..eee27ff6eb
Binary files /dev/null and b/media/articles/compliance/lock-db-consent-flag.png differ
diff --git a/media/articles/compliance/lock-signup-new-field-TC.png b/media/articles/compliance/lock-signup-new-field-TC.png
new file mode 100755
index 0000000000..3d0f9762c8
Binary files /dev/null and b/media/articles/compliance/lock-signup-new-field-TC.png differ
diff --git a/media/articles/compliance/lock-signup-new-field.png b/media/articles/compliance/lock-signup-new-field.png
new file mode 100755
index 0000000000..1667b69682
Binary files /dev/null and b/media/articles/compliance/lock-signup-new-field.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
new file mode 100644
index 0000000000..b2a41479ec
Binary files /dev/null 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
new file mode 100644
index 0000000000..f97d85d09d
Binary files /dev/null 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
new file mode 100644
index 0000000000..769918ca32
Binary files /dev/null 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
new file mode 100644
index 0000000000..cefdb32126
Binary files /dev/null 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
new file mode 100644
index 0000000000..f1a5f9620b
Binary files /dev/null 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
new file mode 100644
index 0000000000..e6095dc043
Binary files /dev/null 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
new file mode 100644
index 0000000000..f8c7f9016a
Binary files /dev/null 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
new file mode 100644
index 0000000000..d4d5c994af
Binary files /dev/null and b/media/articles/connections/criipto/auth0-details.png differ
diff --git a/media/articles/connections/grean/bankid-no.png b/media/articles/connections/criipto/bankid-no.png
similarity index 100%
rename from media/articles/connections/grean/bankid-no.png
rename to media/articles/connections/criipto/bankid-no.png
diff --git a/media/articles/connections/grean/bankid-no.svg b/media/articles/connections/criipto/bankid-no.svg
similarity index 100%
rename from media/articles/connections/grean/bankid-no.svg
rename to media/articles/connections/criipto/bankid-no.svg
diff --git a/media/articles/connections/grean/bankid-se.png b/media/articles/connections/criipto/bankid-se.png
similarity index 100%
rename from media/articles/connections/grean/bankid-se.png
rename to media/articles/connections/criipto/bankid-se.png
diff --git a/media/articles/connections/grean/bankid-se.svg b/media/articles/connections/criipto/bankid-se.svg
similarity index 100%
rename from media/articles/connections/grean/bankid-se.svg
rename to media/articles/connections/criipto/bankid-se.svg
diff --git a/media/articles/connections/criipto/dk-nemid-prod.png b/media/articles/connections/criipto/dk-nemid-prod.png
new file mode 100644
index 0000000000..9572d703aa
Binary files /dev/null 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
new file mode 100644
index 0000000000..cd833bcf22
Binary files /dev/null and b/media/articles/connections/criipto/easyid-signup.png differ
diff --git a/media/articles/connections/grean/nemid_black.png b/media/articles/connections/criipto/nemid_black.png
similarity index 100%
rename from media/articles/connections/grean/nemid_black.png
rename to media/articles/connections/criipto/nemid_black.png
diff --git a/media/articles/connections/criipto/no-bankid-prod.png b/media/articles/connections/criipto/no-bankid-prod.png
new file mode 100644
index 0000000000..c6a811fa7d
Binary files /dev/null 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
new file mode 100644
index 0000000000..3292f7c3a1
Binary files /dev/null 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/change-password-email.png b/media/articles/connections/database/change-password-email.png
old mode 100644
new mode 100755
index 8c6451a41c..fe8f023b66
Binary files a/media/articles/connections/database/change-password-email.png and b/media/articles/connections/database/change-password-email.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 bc6e0f3ef6..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 35734a9e79..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 4ae0adad54..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 ae4034cc8b..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 7c0871861e..0000000000
Binary files a/media/articles/connections/database/lock-usernamestyle.png and /dev/null differ
diff --git a/media/articles/connections/database/lock_v9/lock_login_page.png b/media/articles/connections/database/lock_v9/lock_login_page.png
index 1881000e6c..ef6335fb42 100755
Binary files a/media/articles/connections/database/lock_v9/lock_login_page.png and b/media/articles/connections/database/lock_v9/lock_login_page.png differ
diff --git a/media/articles/connections/database/lock_v9/lock_pass_changed.png b/media/articles/connections/database/lock_v9/lock_pass_changed.png
index 5c590c289e..cc93c7c4ce 100755
Binary files a/media/articles/connections/database/lock_v9/lock_pass_changed.png and b/media/articles/connections/database/lock_v9/lock_pass_changed.png differ
diff --git a/media/articles/connections/database/lock_v9/lock_reset_pass_email.png b/media/articles/connections/database/lock_v9/lock_reset_pass_email.png
index 61fb224e67..3bb845f75d 100644
Binary files a/media/articles/connections/database/lock_v9/lock_reset_pass_email.png and b/media/articles/connections/database/lock_v9/lock_reset_pass_email.png differ
diff --git a/media/articles/connections/database/lock_v9/lock_set_new_pass.png b/media/articles/connections/database/lock_v9/lock_set_new_pass.png
index 36f4b42cc5..9e82a63d1e 100755
Binary files a/media/articles/connections/database/lock_v9/lock_set_new_pass.png and b/media/articles/connections/database/lock_v9/lock_set_new_pass.png differ
diff --git a/media/articles/connections/database/manual-password-change.png b/media/articles/connections/database/manual-password-change.png
old mode 100644
new mode 100755
index 516a40103c..971725466f
Binary files a/media/articles/connections/database/manual-password-change.png and b/media/articles/connections/database/manual-password-change.png 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/migrating-diagram.png b/media/articles/connections/database/migrating-diagram.png
index 16d311a562..e7fb4c5f35 100644
Binary files a/media/articles/connections/database/migrating-diagram.png and b/media/articles/connections/database/migrating-diagram.png 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 35ae686154..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 196e11bdea..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 a7c38edb61..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/mysql/db-connection-widget.png b/media/articles/connections/database/mysql/db-connection-widget.png
index 12d767493b..2e2a46c597 100644
Binary files a/media/articles/connections/database/mysql/db-connection-widget.png and b/media/articles/connections/database/mysql/db-connection-widget.png differ
diff --git a/media/articles/connections/database/okta/create-database-connection.png b/media/articles/connections/database/okta/create-database-connection.png
new file mode 100644
index 0000000000..3cd03a6323
Binary files /dev/null and b/media/articles/connections/database/okta/create-database-connection.png differ
diff --git a/media/articles/connections/database/okta/import-users.png b/media/articles/connections/database/okta/import-users.png
new file mode 100644
index 0000000000..99c3646005
Binary files /dev/null and b/media/articles/connections/database/okta/import-users.png differ
diff --git a/media/articles/connections/database/okta/own-database.png b/media/articles/connections/database/okta/own-database.png
new file mode 100644
index 0000000000..dc917baea9
Binary files /dev/null and b/media/articles/connections/database/okta/own-database.png differ
diff --git a/media/articles/connections/database/okta/try-connection-lock.png b/media/articles/connections/database/okta/try-connection-lock.png
new file mode 100644
index 0000000000..e4599f7456
Binary files /dev/null and b/media/articles/connections/database/okta/try-connection-lock.png differ
diff --git a/media/articles/connections/database/okta/try-connection-success.png b/media/articles/connections/database/okta/try-connection-success.png
new file mode 100644
index 0000000000..c9e5c00504
Binary files /dev/null and b/media/articles/connections/database/okta/try-connection-success.png differ
diff --git a/media/articles/connections/database/okta/try-connection.png b/media/articles/connections/database/okta/try-connection.png
new file mode 100644
index 0000000000..b4ffded36d
Binary files /dev/null and b/media/articles/connections/database/okta/try-connection.png differ
diff --git a/media/articles/connections/database/okta/user-imported.png b/media/articles/connections/database/okta/user-imported.png
new file mode 100644
index 0000000000..858bd74696
Binary files /dev/null and b/media/articles/connections/database/okta/user-imported.png differ
diff --git a/media/articles/connections/database/password-options.png b/media/articles/connections/database/password-options.png
deleted file mode 100644
index 30ef1368ea..0000000000
Binary files a/media/articles/connections/database/password-options.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 9a4b9cec16..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/jH0kabJPoi.png b/media/articles/connections/database/password-strength/jH0kabJPoi.png
index 81db88fc61..d1d2de644c 100644
Binary files a/media/articles/connections/database/password-strength/jH0kabJPoi.png and b/media/articles/connections/database/password-strength/jH0kabJPoi.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/requires-username-toggle.png b/media/articles/connections/database/requires-username-toggle.png
index f58937378e..a2906490ed 100644
Binary files a/media/articles/connections/database/requires-username-toggle.png and b/media/articles/connections/database/requires-username-toggle.png differ
diff --git a/media/articles/connections/database/reset-password-email.png b/media/articles/connections/database/reset-password-email.png
index 842b06189f..5f1fa9cea3 100644
Binary files a/media/articles/connections/database/reset-password-email.png and b/media/articles/connections/database/reset-password-email.png differ
diff --git a/media/articles/connections/database/reset-password.png b/media/articles/connections/database/reset-password.png
index f536e81f61..6d339e8b79 100644
Binary files a/media/articles/connections/database/reset-password.png and b/media/articles/connections/database/reset-password.png differ
diff --git a/media/articles/connections/database/username-length.png b/media/articles/connections/database/username-length.png
index 72e8b1b6af..1bfc664090 100644
Binary files a/media/articles/connections/database/username-length.png and b/media/articles/connections/database/username-length.png differ
diff --git a/media/articles/connections/database/username-lock.png b/media/articles/connections/database/username-lock.png
index 3b6e3c1b01..c9618ef44b 100644
Binary files a/media/articles/connections/database/username-lock.png and b/media/articles/connections/database/username-lock.png differ
diff --git a/media/articles/connections/enterprise/adfs/adfs-identifier.png b/media/articles/connections/enterprise/adfs/adfs-identifier.png
index 52e3602d9b..b631502faf 100644
Binary files a/media/articles/connections/enterprise/adfs/adfs-identifier.png and b/media/articles/connections/enterprise/adfs/adfs-identifier.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/add-azure-connection.png b/media/articles/connections/enterprise/azure-active-directory/add-azure-connection.png
deleted file mode 100644
index 81420a19cf..0000000000
Binary files a/media/articles/connections/enterprise/azure-active-directory/add-azure-connection.png and /dev/null differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-create-native-connection.png b/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-create-native-connection.png
index b262be2d5f..3430f12e91 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-create-native-connection.png and b/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-create-native-connection.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-login.png b/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-login.png
index 3d9632709f..78e2469939 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-login.png and b/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-login.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-native-app-permissions.png b/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-native-app-permissions.png
index eb8f179b84..4da1af8c02 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-native-app-permissions.png and b/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-native-app-permissions.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-new-api-properties.png b/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-new-api-properties.png
index 0096ee629c..ef005f484b 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-new-api-properties.png and b/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-new-api-properties.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-new-api.png b/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-new-api.png
index 0b91504560..c1ec53990e 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-new-api.png and b/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-new-api.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-new-native-app.png b/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-new-native-app.png
index a87f8235ae..bb14c99606 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-new-native-app.png and b/media/articles/connections/enterprise/azure-active-directory/azure-active-directory-new-native-app.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/azure-ad-1-1.png b/media/articles/connections/enterprise/azure-active-directory/azure-ad-1-1.png
index 5849d46899..38925cf77a 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/azure-ad-1-1.png and b/media/articles/connections/enterprise/azure-active-directory/azure-ad-1-1.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/azure-ad-1-2.png b/media/articles/connections/enterprise/azure-active-directory/azure-ad-1-2.png
index f5c5477f8f..9353ce7de2 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/azure-ad-1-2.png and b/media/articles/connections/enterprise/azure-active-directory/azure-ad-1-2.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/azure-ad-1-3.png b/media/articles/connections/enterprise/azure-active-directory/azure-ad-1-3.png
index 79b461b76e..5aca8914de 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/azure-ad-1-3.png and b/media/articles/connections/enterprise/azure-active-directory/azure-ad-1-3.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/azure-ad-1-3b.png b/media/articles/connections/enterprise/azure-active-directory/azure-ad-1-3b.png
new file mode 100644
index 0000000000..9fdc0afc13
Binary files /dev/null and b/media/articles/connections/enterprise/azure-active-directory/azure-ad-1-3b.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/azure-ad-3-1.png b/media/articles/connections/enterprise/azure-active-directory/azure-ad-3-1.png
old mode 100755
new mode 100644
index 5d091e5bcb..7390aa1d5f
Binary files a/media/articles/connections/enterprise/azure-active-directory/azure-ad-3-1.png and b/media/articles/connections/enterprise/azure-active-directory/azure-ad-3-1.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/azure-ad-3-2.png b/media/articles/connections/enterprise/azure-active-directory/azure-ad-3-2.png
old mode 100755
new mode 100644
index d4bd1c870c..f225cc5ed8
Binary files a/media/articles/connections/enterprise/azure-active-directory/azure-ad-3-2.png and b/media/articles/connections/enterprise/azure-active-directory/azure-ad-3-2.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/azure-ad-3-3.png b/media/articles/connections/enterprise/azure-active-directory/azure-ad-3-3.png
old mode 100755
new mode 100644
index ce7d6029af..ac119074d5
Binary files a/media/articles/connections/enterprise/azure-active-directory/azure-ad-3-3.png and b/media/articles/connections/enterprise/azure-active-directory/azure-ad-3-3.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/azure-ad-4-1.png b/media/articles/connections/enterprise/azure-active-directory/azure-ad-4-1.png
old mode 100755
new mode 100644
index 06627a988d..68feff812f
Binary files a/media/articles/connections/enterprise/azure-active-directory/azure-ad-4-1.png and b/media/articles/connections/enterprise/azure-active-directory/azure-ad-4-1.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/azure-ad-4-2.png b/media/articles/connections/enterprise/azure-active-directory/azure-ad-4-2.png
old mode 100755
new mode 100644
index b3582c5a89..905199c176
Binary files a/media/articles/connections/enterprise/azure-active-directory/azure-ad-4-2.png and b/media/articles/connections/enterprise/azure-active-directory/azure-ad-4-2.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/azure-ad-4-2b.png b/media/articles/connections/enterprise/azure-active-directory/azure-ad-4-2b.png
new file mode 100644
index 0000000000..5c10441ad2
Binary files /dev/null and b/media/articles/connections/enterprise/azure-active-directory/azure-ad-4-2b.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/azure-ad-5-1.png b/media/articles/connections/enterprise/azure-active-directory/azure-ad-5-1.png
old mode 100755
new mode 100644
index 6601f142af..25277b70e5
Binary files a/media/articles/connections/enterprise/azure-active-directory/azure-ad-5-1.png and b/media/articles/connections/enterprise/azure-active-directory/azure-ad-5-1.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/azure-ad-6-2.png b/media/articles/connections/enterprise/azure-active-directory/azure-ad-6-2.png
new file mode 100644
index 0000000000..87a32e0292
Binary files /dev/null and b/media/articles/connections/enterprise/azure-active-directory/azure-ad-6-2.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/azure-ad-native-app.png b/media/articles/connections/enterprise/azure-active-directory/azure-ad-native-app.png
index 4d1d1e2a4d..fca5b03609 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/azure-ad-native-app.png and b/media/articles/connections/enterprise/azure-active-directory/azure-ad-native-app.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/azure-ad-native-permissions.png b/media/articles/connections/enterprise/azure-active-directory/azure-ad-native-permissions.png
index 581ce15a7a..5ee7b16231 100644
Binary files a/media/articles/connections/enterprise/azure-active-directory/azure-ad-native-permissions.png and b/media/articles/connections/enterprise/azure-active-directory/azure-ad-native-permissions.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/connection-settings.png b/media/articles/connections/enterprise/azure-active-directory/connection-settings.png
new file mode 100644
index 0000000000..e84bdf0a1f
Binary files /dev/null and b/media/articles/connections/enterprise/azure-active-directory/connection-settings.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/create-azure-ad-connection.png b/media/articles/connections/enterprise/azure-active-directory/create-azure-ad-connection.png
new file mode 100644
index 0000000000..6efeddb734
Binary files /dev/null and b/media/articles/connections/enterprise/azure-active-directory/create-azure-ad-connection.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/enable-multi-tenanted.png b/media/articles/connections/enterprise/azure-active-directory/enable-multi-tenanted.png
new file mode 100644
index 0000000000..7edb13f04a
Binary files /dev/null and b/media/articles/connections/enterprise/azure-active-directory/enable-multi-tenanted.png differ
diff --git a/media/articles/connections/enterprise/azure-active-directory/enterprise-connections.png b/media/articles/connections/enterprise/azure-active-directory/enterprise-connections.png
new file mode 100644
index 0000000000..6f17f55378
Binary files /dev/null and b/media/articles/connections/enterprise/azure-active-directory/enterprise-connections.png 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 654a2ee085..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 8cbe5ca70b..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 35dd5e740c..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 9b0fbc54ba..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 628676729e..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 c3c2965fd6..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 64398e5d92..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 a7acabd2d7..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 7c7b5fc1a0..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 2fbeac37a2..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 5ae25dbacf..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/google/client-connection.png b/media/articles/connections/enterprise/google/client-connection.png
new file mode 100644
index 0000000000..d8494cbb51
Binary files /dev/null and b/media/articles/connections/enterprise/google/client-connection.png differ
diff --git a/media/articles/connections/enterprise/google/config-settings.png b/media/articles/connections/enterprise/google/config-settings.png
new file mode 100644
index 0000000000..4e6bbed8cc
Binary files /dev/null and b/media/articles/connections/enterprise/google/config-settings.png differ
diff --git a/media/articles/connections/enterprise/google/create-connection.png b/media/articles/connections/enterprise/google/create-connection.png
new file mode 100644
index 0000000000..9d1fe81b7e
Binary files /dev/null and b/media/articles/connections/enterprise/google/create-connection.png differ
diff --git a/media/articles/connections/enterprise/google/enterprise-connections.png b/media/articles/connections/enterprise/google/enterprise-connections.png
new file mode 100644
index 0000000000..6f17f55378
Binary files /dev/null and b/media/articles/connections/enterprise/google/enterprise-connections.png differ
diff --git a/media/articles/connections/enterprise/google/google-apps-connection-settings.png b/media/articles/connections/enterprise/google/google-apps-connection-settings.png
new file mode 100644
index 0000000000..6e93d4faa8
Binary files /dev/null and b/media/articles/connections/enterprise/google/google-apps-connection-settings.png differ
diff --git a/media/articles/connections/enterprise/ldap/settings.png b/media/articles/connections/enterprise/ldap/settings.png
new file mode 100755
index 0000000000..e6a35ff7c6
Binary files /dev/null and b/media/articles/connections/enterprise/ldap/settings.png differ
diff --git a/media/articles/connections/enterprise/ldap/setup-connector.png b/media/articles/connections/enterprise/ldap/setup-connector.png
new file mode 100755
index 0000000000..4ee7119359
Binary files /dev/null and b/media/articles/connections/enterprise/ldap/setup-connector.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/enterprise/ping-federate/settings.png b/media/articles/connections/enterprise/ping-federate/settings.png
new file mode 100755
index 0000000000..2251df35fa
Binary files /dev/null and b/media/articles/connections/enterprise/ping-federate/settings.png differ
diff --git a/media/articles/connections/enterprise/samlp/admin-url.png b/media/articles/connections/enterprise/samlp/admin-url.png
new file mode 100644
index 0000000000..41f83e8f6a
Binary files /dev/null and b/media/articles/connections/enterprise/samlp/admin-url.png differ
diff --git a/media/articles/connections/enterprise/samlp/config-instructions.png b/media/articles/connections/enterprise/samlp/config-instructions.png
new file mode 100644
index 0000000000..d99dd0cedf
Binary files /dev/null and b/media/articles/connections/enterprise/samlp/config-instructions.png differ
diff --git a/media/articles/connections/enterprise/samlp/create-new-connection.png b/media/articles/connections/enterprise/samlp/create-new-connection.png
new file mode 100644
index 0000000000..b570b64ff1
Binary files /dev/null and b/media/articles/connections/enterprise/samlp/create-new-connection.png differ
diff --git a/media/articles/connections/enterprise/samlp/enterprise-connection.png b/media/articles/connections/enterprise/samlp/enterprise-connection.png
new file mode 100644
index 0000000000..ba2be5298c
Binary files /dev/null and b/media/articles/connections/enterprise/samlp/enterprise-connection.png differ
diff --git a/media/articles/connections/enterprise/ws-fed/connections-enterprise.png b/media/articles/connections/enterprise/ws-fed/connections-enterprise.png
new file mode 100755
index 0000000000..9c258eff43
Binary files /dev/null and b/media/articles/connections/enterprise/ws-fed/connections-enterprise.png differ
diff --git a/media/articles/connections/enterprise/ws-fed/new.png b/media/articles/connections/enterprise/ws-fed/new.png
new file mode 100755
index 0000000000..0e66d1bd97
Binary files /dev/null and b/media/articles/connections/enterprise/ws-fed/new.png differ
diff --git a/media/articles/connections/grean/adfs-connections-dk.png b/media/articles/connections/grean/adfs-connections-dk.png
deleted file mode 100644
index 9c284fd7a5..0000000000
Binary files a/media/articles/connections/grean/adfs-connections-dk.png and /dev/null differ
diff --git a/media/articles/connections/grean/adfs-connections-no.png b/media/articles/connections/grean/adfs-connections-no.png
deleted file mode 100644
index 44e46b1216..0000000000
Binary files a/media/articles/connections/grean/adfs-connections-no.png and /dev/null differ
diff --git a/media/articles/connections/grean/adfs-connections-se.png b/media/articles/connections/grean/adfs-connections-se.png
deleted file mode 100644
index 3197baf476..0000000000
Binary files a/media/articles/connections/grean/adfs-connections-se.png and /dev/null differ
diff --git a/media/articles/connections/grean/auth0-app-dk.png b/media/articles/connections/grean/auth0-app-dk.png
deleted file mode 100644
index 2a263c5385..0000000000
Binary files a/media/articles/connections/grean/auth0-app-dk.png and /dev/null differ
diff --git a/media/articles/connections/grean/auth0-app-no.png b/media/articles/connections/grean/auth0-app-no.png
deleted file mode 100644
index b89d3b3fb2..0000000000
Binary files a/media/articles/connections/grean/auth0-app-no.png and /dev/null differ
diff --git a/media/articles/connections/grean/auth0-app-se.png b/media/articles/connections/grean/auth0-app-se.png
deleted file mode 100644
index 48a775d1ea..0000000000
Binary files a/media/articles/connections/grean/auth0-app-se.png and /dev/null differ
diff --git a/media/articles/connections/grean/auth0-consent.png b/media/articles/connections/grean/auth0-consent.png
deleted file mode 100644
index 245c21c163..0000000000
Binary files a/media/articles/connections/grean/auth0-consent.png and /dev/null differ
diff --git a/media/articles/connections/grean/auth0-details.png b/media/articles/connections/grean/auth0-details.png
deleted file mode 100644
index adb80c048d..0000000000
Binary files a/media/articles/connections/grean/auth0-details.png and /dev/null differ
diff --git a/media/articles/connections/grean/dk-nemid-prod.png b/media/articles/connections/grean/dk-nemid-prod.png
deleted file mode 100644
index a9f970f955..0000000000
Binary files a/media/articles/connections/grean/dk-nemid-prod.png and /dev/null differ
diff --git a/media/articles/connections/grean/easyid-signup.png b/media/articles/connections/grean/easyid-signup.png
deleted file mode 100644
index 275c9245bd..0000000000
Binary files a/media/articles/connections/grean/easyid-signup.png and /dev/null differ
diff --git a/media/articles/connections/grean/no-bankid-prod.png b/media/articles/connections/grean/no-bankid-prod.png
deleted file mode 100644
index ec9114a683..0000000000
Binary files a/media/articles/connections/grean/no-bankid-prod.png and /dev/null differ
diff --git a/media/articles/connections/grean/se-bankid-prod.png b/media/articles/connections/grean/se-bankid-prod.png
deleted file mode 100644
index bbc6397947..0000000000
Binary files a/media/articles/connections/grean/se-bankid-prod.png and /dev/null 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/associated-domains.png b/media/articles/connections/passwordless/associated-domains.png
new file mode 100644
index 0000000000..7c14305c3e
Binary files /dev/null and b/media/articles/connections/passwordless/associated-domains.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 6be731fe54..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 148938f828..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/docomo/connect-top.png b/media/articles/connections/social/docomo/connect-top.png
new file mode 100755
index 0000000000..3fb942c679
Binary files /dev/null and b/media/articles/connections/social/docomo/connect-top.png differ
diff --git a/media/articles/connections/social/docomo/enter-keys.png b/media/articles/connections/social/docomo/enter-keys.png
new file mode 100755
index 0000000000..5759d78578
Binary files /dev/null and b/media/articles/connections/social/docomo/enter-keys.png differ
diff --git a/media/articles/connections/social/docomo/rp-info-1.png b/media/articles/connections/social/docomo/rp-info-1.png
new file mode 100755
index 0000000000..859d3e277a
Binary files /dev/null and b/media/articles/connections/social/docomo/rp-info-1.png differ
diff --git a/media/articles/connections/social/docomo/rp-info-2.png b/media/articles/connections/social/docomo/rp-info-2.png
new file mode 100755
index 0000000000..2fb1000b48
Binary files /dev/null and b/media/articles/connections/social/docomo/rp-info-2.png differ
diff --git a/media/articles/connections/social/docomo/rp-register.png b/media/articles/connections/social/docomo/rp-register.png
new file mode 100755
index 0000000000..c129bf68aa
Binary files /dev/null and b/media/articles/connections/social/docomo/rp-register.png differ
diff --git a/media/articles/connections/social/docomo/service-details.png b/media/articles/connections/social/docomo/service-details.png
new file mode 100755
index 0000000000..3092f0e37f
Binary files /dev/null and b/media/articles/connections/social/docomo/service-details.png differ
diff --git a/media/articles/connections/social/docomo/try-connection.png b/media/articles/connections/social/docomo/try-connection.png
new file mode 100755
index 0000000000..22acdfb9c0
Binary files /dev/null and b/media/articles/connections/social/docomo/try-connection.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-1.png b/media/articles/connections/social/facebook/facebook-1.png
index cb48fc30e2..fec3ccb429 100644
Binary files a/media/articles/connections/social/facebook/facebook-1.png and b/media/articles/connections/social/facebook/facebook-1.png differ
diff --git a/media/articles/connections/social/facebook/facebook-2.png b/media/articles/connections/social/facebook/facebook-2.png
index a39b43676f..fce0a68fbb 100644
Binary files a/media/articles/connections/social/facebook/facebook-2.png and b/media/articles/connections/social/facebook/facebook-2.png differ
diff --git a/media/articles/connections/social/facebook/facebook-3.png b/media/articles/connections/social/facebook/facebook-3.png
index 7f3ef9b434..4331fb126d 100644
Binary files a/media/articles/connections/social/facebook/facebook-3.png and b/media/articles/connections/social/facebook/facebook-3.png differ
diff --git a/media/articles/connections/social/facebook/facebook-3b.png b/media/articles/connections/social/facebook/facebook-3b.png
index 208babc902..827fdb6905 100644
Binary files a/media/articles/connections/social/facebook/facebook-3b.png and b/media/articles/connections/social/facebook/facebook-3b.png differ
diff --git a/media/articles/connections/social/facebook/facebook-4.png b/media/articles/connections/social/facebook/facebook-4.png
deleted file mode 100644
index 04f860aadc..0000000000
Binary files a/media/articles/connections/social/facebook/facebook-4.png and /dev/null differ
diff --git a/media/articles/connections/social/facebook/facebook-5.png b/media/articles/connections/social/facebook/facebook-5.png
new file mode 100644
index 0000000000..1fddde10ca
Binary files /dev/null and b/media/articles/connections/social/facebook/facebook-5.png differ
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/facebook/oauth-settings.png b/media/articles/connections/social/facebook/oauth-settings.png
index dee885c184..c62abefac5 100644
Binary files a/media/articles/connections/social/facebook/oauth-settings.png and b/media/articles/connections/social/facebook/oauth-settings.png differ
diff --git a/media/articles/connections/social/fitbit/auth-page.png b/media/articles/connections/social/fitbit/auth-page.png
new file mode 100644
index 0000000000..fcf8a80073
Binary files /dev/null and b/media/articles/connections/social/fitbit/auth-page.png differ
diff --git a/media/articles/connections/social/fitbit/fitbit-register-1.png b/media/articles/connections/social/fitbit/fitbit-register-1.png
deleted file mode 100644
index 0194f64d9f..0000000000
Binary files a/media/articles/connections/social/fitbit/fitbit-register-1.png and /dev/null differ
diff --git a/media/articles/connections/social/fitbit/fitbit-register-2.png b/media/articles/connections/social/fitbit/fitbit-register-2.png
deleted file mode 100644
index bce682717b..0000000000
Binary files a/media/articles/connections/social/fitbit/fitbit-register-2.png and /dev/null differ
diff --git a/media/articles/connections/social/fitbit/fitbit-register-3.png b/media/articles/connections/social/fitbit/fitbit-register-3.png
deleted file mode 100644
index 861c0bd9f6..0000000000
Binary files a/media/articles/connections/social/fitbit/fitbit-register-3.png and /dev/null differ
diff --git a/media/articles/connections/social/fitbit/fitbit-register-oauth2.png b/media/articles/connections/social/fitbit/fitbit-register-oauth2.png
deleted file mode 100644
index aa87ff8636..0000000000
Binary files a/media/articles/connections/social/fitbit/fitbit-register-oauth2.png and /dev/null differ
diff --git a/media/articles/connections/social/fitbit/register-an-app.png b/media/articles/connections/social/fitbit/register-an-app.png
new file mode 100644
index 0000000000..52abc18dba
Binary files /dev/null and b/media/articles/connections/social/fitbit/register-an-app.png differ
diff --git a/media/articles/connections/social/fitbit/registration-form.png b/media/articles/connections/social/fitbit/registration-form.png
new file mode 100644
index 0000000000..0fa9327dc9
Binary files /dev/null and b/media/articles/connections/social/fitbit/registration-form.png differ
diff --git a/media/articles/connections/social/fitbit/try-button.png b/media/articles/connections/social/fitbit/try-button.png
new file mode 100644
index 0000000000..fcb6b8200b
Binary files /dev/null and b/media/articles/connections/social/fitbit/try-button.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
new file mode 100644
index 0000000000..d8fa1436eb
Binary files /dev/null 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
new file mode 100644
index 0000000000..cbc50df964
Binary files /dev/null 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
new file mode 100644
index 0000000000..2d4109039c
Binary files /dev/null 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
new file mode 100644
index 0000000000..977b2683f7
Binary files /dev/null and b/media/articles/connections/social/github/github-add-app-4.png differ
diff --git a/media/articles/connections/social/github/github-addapp-1.png b/media/articles/connections/social/github/github-addapp-1.png
deleted file mode 100644
index 1c1d2f85dd..0000000000
Binary files a/media/articles/connections/social/github/github-addapp-1.png and /dev/null differ
diff --git a/media/articles/connections/social/github/github-addapp-2.png b/media/articles/connections/social/github/github-addapp-2.png
deleted file mode 100644
index 927ed447d8..0000000000
Binary files a/media/articles/connections/social/github/github-addapp-2.png and /dev/null differ
diff --git a/media/articles/connections/social/github/github-addapp-3.png b/media/articles/connections/social/github/github-addapp-3.png
deleted file mode 100644
index 05a375d652..0000000000
Binary files a/media/articles/connections/social/github/github-addapp-3.png and /dev/null differ
diff --git a/media/articles/connections/social/github/github-addapp-4.png b/media/articles/connections/social/github/github-addapp-4.png
deleted file mode 100644
index e078490545..0000000000
Binary files a/media/articles/connections/social/github/github-addapp-4.png and /dev/null differ
diff --git a/media/articles/connections/social/google/Archive/goog-api-admin-enable.png b/media/articles/connections/social/google/Archive/goog-api-admin-enable.png
deleted file mode 100644
index 8b198c3a86..0000000000
Binary files a/media/articles/connections/social/google/Archive/goog-api-admin-enable.png and /dev/null differ
diff --git a/media/articles/connections/social/google/Archive/goog-api-admin-sdk.png b/media/articles/connections/social/google/Archive/goog-api-admin-sdk.png
deleted file mode 100644
index ee17b45cac..0000000000
Binary files a/media/articles/connections/social/google/Archive/goog-api-admin-sdk.png and /dev/null differ
diff --git a/media/articles/connections/social/google/Archive/goog-api-aoth0-try.png b/media/articles/connections/social/google/Archive/goog-api-aoth0-try.png
deleted file mode 100644
index a5c17221e8..0000000000
Binary files a/media/articles/connections/social/google/Archive/goog-api-aoth0-try.png and /dev/null differ
diff --git a/media/articles/connections/social/google/Archive/goog-api-app-empty.png b/media/articles/connections/social/google/Archive/goog-api-app-empty.png
deleted file mode 100644
index 8cc81ee6c9..0000000000
Binary files a/media/articles/connections/social/google/Archive/goog-api-app-empty.png and /dev/null differ
diff --git a/media/articles/connections/social/google/Archive/goog-api-app-new.png b/media/articles/connections/social/google/Archive/goog-api-app-new.png
deleted file mode 100644
index 878b82c983..0000000000
Binary files a/media/articles/connections/social/google/Archive/goog-api-app-new.png and /dev/null differ
diff --git a/media/articles/connections/social/google/Archive/goog-api-client-creation.png b/media/articles/connections/social/google/Archive/goog-api-client-creation.png
deleted file mode 100644
index 758a450101..0000000000
Binary files a/media/articles/connections/social/google/Archive/goog-api-client-creation.png and /dev/null differ
diff --git a/media/articles/connections/social/google/Archive/goog-api-client-settings.png b/media/articles/connections/social/google/Archive/goog-api-client-settings.png
deleted file mode 100644
index 60b3a21a29..0000000000
Binary files a/media/articles/connections/social/google/Archive/goog-api-client-settings.png and /dev/null differ
diff --git a/media/articles/connections/social/google/Archive/goog-api-creation-activity.png b/media/articles/connections/social/google/Archive/goog-api-creation-activity.png
deleted file mode 100644
index 314aa67548..0000000000
Binary files a/media/articles/connections/social/google/Archive/goog-api-creation-activity.png and /dev/null differ
diff --git a/media/articles/connections/social/google/Archive/goog-api-credentials.png b/media/articles/connections/social/google/Archive/goog-api-credentials.png
deleted file mode 100644
index 2ca310926f..0000000000
Binary files a/media/articles/connections/social/google/Archive/goog-api-credentials.png and /dev/null differ
diff --git a/media/articles/connections/social/google/Archive/goog-api-plus-off.png b/media/articles/connections/social/google/Archive/goog-api-plus-off.png
deleted file mode 100644
index c33b2b5de7..0000000000
Binary files a/media/articles/connections/social/google/Archive/goog-api-plus-off.png and /dev/null differ
diff --git a/media/articles/connections/social/google/Archive/goog-api-plus-on.png b/media/articles/connections/social/google/Archive/goog-api-plus-on.png
deleted file mode 100644
index cace9da0a1..0000000000
Binary files a/media/articles/connections/social/google/Archive/goog-api-plus-on.png and /dev/null differ
diff --git a/media/articles/connections/social/google/Archive/goog-api-product-name.png b/media/articles/connections/social/google/Archive/goog-api-product-name.png
deleted file mode 100644
index f7289c95f6..0000000000
Binary files a/media/articles/connections/social/google/Archive/goog-api-product-name.png and /dev/null differ
diff --git a/media/articles/connections/social/google/api-manager-library.png b/media/articles/connections/social/google/api-manager-library.png
old mode 100755
new mode 100644
index e15365963e..ce87201801
Binary files a/media/articles/connections/social/google/api-manager-library.png and b/media/articles/connections/social/google/api-manager-library.png differ
diff --git a/media/articles/connections/social/google/create-client-id-config.png b/media/articles/connections/social/google/create-client-id-config.png
old mode 100755
new mode 100644
index c4c1a4c94b..028d274f59
Binary files a/media/articles/connections/social/google/create-client-id-config.png and b/media/articles/connections/social/google/create-client-id-config.png differ
diff --git a/media/articles/connections/social/google/create-new-credentials.png b/media/articles/connections/social/google/create-new-credentials.png
new file mode 100644
index 0000000000..a57b62f842
Binary files /dev/null and b/media/articles/connections/social/google/create-new-credentials.png differ
diff --git a/media/articles/connections/social/google/create-new-project.png b/media/articles/connections/social/google/create-new-project.png
deleted file mode 100644
index 6ffb8ff7c9..0000000000
Binary files a/media/articles/connections/social/google/create-new-project.png and /dev/null differ
diff --git a/media/articles/connections/social/google/credentials.png b/media/articles/connections/social/google/credentials.png
index c235e142e7..5aa2926c31 100644
Binary files a/media/articles/connections/social/google/credentials.png and b/media/articles/connections/social/google/credentials.png differ
diff --git a/media/articles/connections/social/google/enable-admin-sdk.png b/media/articles/connections/social/google/enable-admin-sdk.png
old mode 100755
new mode 100644
index 9a5cfc0222..7141a86fdc
Binary files a/media/articles/connections/social/google/enable-admin-sdk.png and b/media/articles/connections/social/google/enable-admin-sdk.png differ
diff --git a/media/articles/connections/social/google/oauth-client-info.png b/media/articles/connections/social/google/oauth-client-info.png
old mode 100755
new mode 100644
index 43dabeb829..9cf0a04a9e
Binary files a/media/articles/connections/social/google/oauth-client-info.png and b/media/articles/connections/social/google/oauth-client-info.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/linkedin/linkedin-devportal-6.png b/media/articles/connections/social/linkedin/linkedin-devportal-6.png
index d0a784ca2c..d713352bf8 100644
Binary files a/media/articles/connections/social/linkedin/linkedin-devportal-6.png and b/media/articles/connections/social/linkedin/linkedin-devportal-6.png differ
diff --git a/media/articles/connections/social/linkedin/linkedin-devportal-8a.png b/media/articles/connections/social/linkedin/linkedin-devportal-8a.png
index e33b6ceb38..cbd76b7348 100644
Binary files a/media/articles/connections/social/linkedin/linkedin-devportal-8a.png and b/media/articles/connections/social/linkedin/linkedin-devportal-8a.png differ
diff --git a/media/articles/connections/social/microsoft-account/ma-portal-4a.png b/media/articles/connections/social/microsoft-account/ma-portal-4a.png
index bd5d233c0a..07363d57a8 100644
Binary files a/media/articles/connections/social/microsoft-account/ma-portal-4a.png and b/media/articles/connections/social/microsoft-account/ma-portal-4a.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/salesforce/salesforce-register-1a.png b/media/articles/connections/social/salesforce/salesforce-register-1a.png
new file mode 100644
index 0000000000..b430793765
Binary files /dev/null and b/media/articles/connections/social/salesforce/salesforce-register-1a.png differ
diff --git a/media/articles/connections/social/salesforce/salesforce-register-1b.png b/media/articles/connections/social/salesforce/salesforce-register-1b.png
new file mode 100644
index 0000000000..556d1f86b4
Binary files /dev/null and b/media/articles/connections/social/salesforce/salesforce-register-1b.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/soundcloud/soundcloud-google-doc.png b/media/articles/connections/social/soundcloud/soundcloud-google-doc.png
new file mode 100644
index 0000000000..c56b72b6f4
Binary files /dev/null and b/media/articles/connections/social/soundcloud/soundcloud-google-doc.png 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-11.png b/media/articles/connections/social/twitter/twitter-api-11.png
deleted file mode 100644
index 448f1547e3..0000000000
Binary files a/media/articles/connections/social/twitter/twitter-api-11.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/wordpress/allow-connection.png b/media/articles/connections/social/wordpress/allow-connection.png
new file mode 100644
index 0000000000..850fc8f943
Binary files /dev/null and b/media/articles/connections/social/wordpress/allow-connection.png differ
diff --git a/media/articles/connections/social/wordpress/enable-clients.png b/media/articles/connections/social/wordpress/enable-clients.png
new file mode 100644
index 0000000000..d4c36b429a
Binary files /dev/null and b/media/articles/connections/social/wordpress/enable-clients.png differ
diff --git a/media/articles/connections/social/wordpress/settings.png b/media/articles/connections/social/wordpress/settings.png
new file mode 100644
index 0000000000..7789f56e41
Binary files /dev/null and b/media/articles/connections/social/wordpress/settings.png differ
diff --git a/media/articles/connections/social/wordpress/try-button.png b/media/articles/connections/social/wordpress/try-button.png
new file mode 100644
index 0000000000..11ccf15678
Binary files /dev/null and b/media/articles/connections/social/wordpress/try-button.png 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/cross-origin-authentication/cross-origin-settings.png b/media/articles/cross-origin-authentication/cross-origin-settings.png
new file mode 100644
index 0000000000..e238787fc1
Binary files /dev/null and b/media/articles/cross-origin-authentication/cross-origin-settings.png differ
diff --git a/media/articles/custom-domains/api-key.png b/media/articles/custom-domains/api-key.png
new file mode 100644
index 0000000000..3e50751374
Binary files /dev/null and b/media/articles/custom-domains/api-key.png differ
diff --git a/media/articles/custom-domains/auth0-managed.png b/media/articles/custom-domains/auth0-managed.png
new file mode 100644
index 0000000000..26c5344cb0
Binary files /dev/null and b/media/articles/custom-domains/auth0-managed.png differ
diff --git a/media/articles/custom-domains/aws/cloudfront.png b/media/articles/custom-domains/aws/cloudfront.png
new file mode 100644
index 0000000000..7bcdf70a35
Binary files /dev/null and b/media/articles/custom-domains/aws/cloudfront.png differ
diff --git a/media/articles/custom-domains/aws/create-distribution.png b/media/articles/custom-domains/aws/create-distribution.png
new file mode 100644
index 0000000000..6cf17f4ca8
Binary files /dev/null and b/media/articles/custom-domains/aws/create-distribution.png differ
diff --git a/media/articles/custom-domains/aws/delivery-method.png b/media/articles/custom-domains/aws/delivery-method.png
new file mode 100644
index 0000000000..fe31baf082
Binary files /dev/null and b/media/articles/custom-domains/aws/delivery-method.png differ
diff --git a/media/articles/custom-domains/aws/distributions.png b/media/articles/custom-domains/aws/distributions.png
new file mode 100644
index 0000000000..5ea6ea5381
Binary files /dev/null and b/media/articles/custom-domains/aws/distributions.png differ
diff --git a/media/articles/custom-domains/aws/origin-custom-headers.png b/media/articles/custom-domains/aws/origin-custom-headers.png
new file mode 100644
index 0000000000..72fa59f2a4
Binary files /dev/null and b/media/articles/custom-domains/aws/origin-custom-headers.png differ
diff --git a/media/articles/custom-domains/azure/azure-dashboard.png b/media/articles/custom-domains/azure/azure-dashboard.png
new file mode 100644
index 0000000000..7017a068fe
Binary files /dev/null and b/media/articles/custom-domains/azure/azure-dashboard.png differ
diff --git a/media/articles/custom-domains/azure/cdn-endpoints.png b/media/articles/custom-domains/azure/cdn-endpoints.png
new file mode 100644
index 0000000000..b99e4f13dd
Binary files /dev/null and b/media/articles/custom-domains/azure/cdn-endpoints.png differ
diff --git a/media/articles/custom-domains/azure/cdn-home.png b/media/articles/custom-domains/azure/cdn-home.png
new file mode 100644
index 0000000000..94f0d8ea58
Binary files /dev/null and b/media/articles/custom-domains/azure/cdn-home.png differ
diff --git a/media/articles/custom-domains/azure/cdn-options.png b/media/articles/custom-domains/azure/cdn-options.png
new file mode 100644
index 0000000000..a7d2e9bd06
Binary files /dev/null and b/media/articles/custom-domains/azure/cdn-options.png differ
diff --git a/media/articles/custom-domains/azure/cdn-profile-1.png b/media/articles/custom-domains/azure/cdn-profile-1.png
new file mode 100644
index 0000000000..65b17a9fdf
Binary files /dev/null and b/media/articles/custom-domains/azure/cdn-profile-1.png differ
diff --git a/media/articles/custom-domains/azure/cdn-profile-2.png b/media/articles/custom-domains/azure/cdn-profile-2.png
new file mode 100644
index 0000000000..609d093466
Binary files /dev/null and b/media/articles/custom-domains/azure/cdn-profile-2.png differ
diff --git a/media/articles/custom-domains/azure/cdn.png b/media/articles/custom-domains/azure/cdn.png
new file mode 100644
index 0000000000..de6cdb6851
Binary files /dev/null and b/media/articles/custom-domains/azure/cdn.png differ
diff --git a/media/articles/custom-domains/azure/configure-rule.png b/media/articles/custom-domains/azure/configure-rule.png
new file mode 100644
index 0000000000..e96cc096f6
Binary files /dev/null and b/media/articles/custom-domains/azure/configure-rule.png differ
diff --git a/media/articles/custom-domains/azure/creating-profile.png b/media/articles/custom-domains/azure/creating-profile.png
new file mode 100644
index 0000000000..4c7a179529
Binary files /dev/null and b/media/articles/custom-domains/azure/creating-profile.png differ
diff --git a/media/articles/custom-domains/azure/disable-http.png b/media/articles/custom-domains/azure/disable-http.png
new file mode 100644
index 0000000000..e1b8c7e472
Binary files /dev/null and b/media/articles/custom-domains/azure/disable-http.png differ
diff --git a/media/articles/custom-domains/azure/endpoint-origin.png b/media/articles/custom-domains/azure/endpoint-origin.png
new file mode 100644
index 0000000000..4c61a942de
Binary files /dev/null and b/media/articles/custom-domains/azure/endpoint-origin.png differ
diff --git a/media/articles/custom-domains/azure/endpoint.png b/media/articles/custom-domains/azure/endpoint.png
new file mode 100644
index 0000000000..d65002a740
Binary files /dev/null and b/media/articles/custom-domains/azure/endpoint.png differ
diff --git a/media/articles/custom-domains/azure/manage-cdn-profile.png b/media/articles/custom-domains/azure/manage-cdn-profile.png
new file mode 100644
index 0000000000..651573cde3
Binary files /dev/null and b/media/articles/custom-domains/azure/manage-cdn-profile.png differ
diff --git a/media/articles/custom-domains/azure/new-cdn-profile.png b/media/articles/custom-domains/azure/new-cdn-profile.png
new file mode 100644
index 0000000000..d747e3b51e
Binary files /dev/null and b/media/articles/custom-domains/azure/new-cdn-profile.png differ
diff --git a/media/articles/custom-domains/azure/provide-custom-hostname.png b/media/articles/custom-domains/azure/provide-custom-hostname.png
new file mode 100644
index 0000000000..95458f905b
Binary files /dev/null and b/media/articles/custom-domains/azure/provide-custom-hostname.png differ
diff --git a/media/articles/custom-domains/azure/resources.png b/media/articles/custom-domains/azure/resources.png
new file mode 100644
index 0000000000..e67f714890
Binary files /dev/null and b/media/articles/custom-domains/azure/resources.png differ
diff --git a/media/articles/custom-domains/azure/select-endpoint.png b/media/articles/custom-domains/azure/select-endpoint.png
new file mode 100644
index 0000000000..9ad6f3c4c8
Binary files /dev/null and b/media/articles/custom-domains/azure/select-endpoint.png differ
diff --git a/media/articles/custom-domains/azure/select-rules-engine.png b/media/articles/custom-domains/azure/select-rules-engine.png
new file mode 100644
index 0000000000..84a1dbf487
Binary files /dev/null and b/media/articles/custom-domains/azure/select-rules-engine.png differ
diff --git a/media/articles/custom-domains/cd_email_toggle.png b/media/articles/custom-domains/cd_email_toggle.png
new file mode 100644
index 0000000000..eaebe39e68
Binary files /dev/null and b/media/articles/custom-domains/cd_email_toggle.png differ
diff --git a/media/articles/custom-domains/custom-domains-self-managed.png b/media/articles/custom-domains/custom-domains-self-managed.png
new file mode 100644
index 0000000000..e8bcc9b2dd
Binary files /dev/null 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
new file mode 100644
index 0000000000..9e5c1d7ba7
Binary files /dev/null and b/media/articles/custom-domains/custom-domains.png differ
diff --git a/media/articles/custom-domains/domain-verification.png b/media/articles/custom-domains/domain-verification.png
new file mode 100644
index 0000000000..1a92961031
Binary files /dev/null and b/media/articles/custom-domains/domain-verification.png differ
diff --git a/media/articles/custom-domains/self-managed.png b/media/articles/custom-domains/self-managed.png
new file mode 100644
index 0000000000..01c1259be0
Binary files /dev/null and b/media/articles/custom-domains/self-managed.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/oidc_conformant.png b/media/articles/dashboard/oidc_conformant.png
new file mode 100644
index 0000000000..3b5a9dfef1
Binary files /dev/null and b/media/articles/dashboard/oidc_conformant.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/index/email-notification.png b/media/articles/email/index/email-notification.png
new file mode 100644
index 0000000000..d63f6abce4
Binary files /dev/null and b/media/articles/email/index/email-notification.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 cd38ae1b3d..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/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/error-pages/account-settings.png b/media/articles/error-pages/account-settings.png
old mode 100644
new mode 100755
index 50c897cf36..f905e0798c
Binary files a/media/articles/error-pages/account-settings.png and b/media/articles/error-pages/account-settings.png differ
diff --git a/media/articles/error-pages/redirect-error-page.png b/media/articles/error-pages/redirect-error-page.png
old mode 100644
new mode 100755
index 3526074f3a..3091a8bcab
Binary files a/media/articles/error-pages/redirect-error-page.png and b/media/articles/error-pages/redirect-error-page.png differ
diff --git a/media/articles/errors/depnotes-mgt-api-legacy-lock.png b/media/articles/errors/depnotes-mgt-api-legacy-lock.png
new file mode 100755
index 0000000000..c899b8c9d8
Binary files /dev/null and b/media/articles/errors/depnotes-mgt-api-legacy-lock.png differ
diff --git a/media/articles/errors/depnotes-ssodata-context-data.png b/media/articles/errors/depnotes-ssodata-context-data.png
new file mode 100755
index 0000000000..e67ba66bd3
Binary files /dev/null and b/media/articles/errors/depnotes-ssodata-context-data.png differ
diff --git a/media/articles/errors/libraries/dashboard-logs.png b/media/articles/errors/libraries/dashboard-logs.png
new file mode 100755
index 0000000000..c893115945
Binary files /dev/null and b/media/articles/errors/libraries/dashboard-logs.png differ
diff --git a/media/articles/errors/libraries/management-api-logs-results.png b/media/articles/errors/libraries/management-api-logs-results.png
new file mode 100755
index 0000000000..14034d04e3
Binary files /dev/null and b/media/articles/errors/libraries/management-api-logs-results.png 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/account-link/extension-page-example.png b/media/articles/extensions/account-link/extension-page-example.png
new file mode 100644
index 0000000000..3954cc6120
Binary files /dev/null and b/media/articles/extensions/account-link/extension-page-example.png differ
diff --git a/media/articles/extensions/account-link/hosted-page-code.png b/media/articles/extensions/account-link/hosted-page-code.png
new file mode 100644
index 0000000000..5e6361f161
Binary files /dev/null and b/media/articles/extensions/account-link/hosted-page-code.png differ
diff --git a/media/articles/extensions/account-link/hosted-page-example.png b/media/articles/extensions/account-link/hosted-page-example.png
new file mode 100644
index 0000000000..c95abdd2d2
Binary files /dev/null and b/media/articles/extensions/account-link/hosted-page-example.png differ
diff --git a/media/articles/extensions/account-link/html-editor.png b/media/articles/extensions/account-link/html-editor.png
new file mode 100644
index 0000000000..f1107d421d
Binary files /dev/null and b/media/articles/extensions/account-link/html-editor.png differ
diff --git a/media/articles/extensions/account-link/install-extension.png b/media/articles/extensions/account-link/install-extension.png
new file mode 100644
index 0000000000..01b490f301
Binary files /dev/null and b/media/articles/extensions/account-link/install-extension.png differ
diff --git a/media/articles/extensions/account-link/installed-extensions.png b/media/articles/extensions/account-link/installed-extensions.png
new file mode 100644
index 0000000000..188a7bc3dc
Binary files /dev/null and b/media/articles/extensions/account-link/installed-extensions.png differ
diff --git a/media/articles/extensions/account-link/widget-settings.png b/media/articles/extensions/account-link/widget-settings.png
new file mode 100644
index 0000000000..985ba77e0c
Binary files /dev/null and b/media/articles/extensions/account-link/widget-settings.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/adv-settings-link.png b/media/articles/extensions/authorization/adv-settings-link.png
new file mode 100644
index 0000000000..fcc50c9cfd
Binary files /dev/null and b/media/articles/extensions/authorization/adv-settings-link.png differ
diff --git a/media/articles/extensions/authorization/api-access-enabled.png b/media/articles/extensions/authorization/api-access-enabled.png
new file mode 100644
index 0000000000..a2249f2f9f
Binary files /dev/null and b/media/articles/extensions/authorization/api-access-enabled.png 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/authorization/app-install-v2.png b/media/articles/extensions/authorization/app-install-v2.png
index 072343b617..9d8a8f8b08 100644
Binary files a/media/articles/extensions/authorization/app-install-v2.png and b/media/articles/extensions/authorization/app-install-v2.png differ
diff --git a/media/articles/extensions/authorization/auth-ext-rule-list.png b/media/articles/extensions/authorization/auth-ext-rule-list.png
new file mode 100644
index 0000000000..6aad1d1238
Binary files /dev/null and b/media/articles/extensions/authorization/auth-ext-rule-list.png differ
diff --git a/media/articles/extensions/authorization/client-quick-start.png b/media/articles/extensions/authorization/client-quick-start.png
new file mode 100644
index 0000000000..7e43a1e7c9
Binary files /dev/null and b/media/articles/extensions/authorization/client-quick-start.png differ
diff --git a/media/articles/extensions/authorization/client-scopes.png b/media/articles/extensions/authorization/client-scopes.png
new file mode 100644
index 0000000000..c605f375c4
Binary files /dev/null and b/media/articles/extensions/authorization/client-scopes.png differ
diff --git a/media/articles/extensions/authorization/clients-for-api.png b/media/articles/extensions/authorization/clients-for-api.png
new file mode 100644
index 0000000000..89b16d551d
Binary files /dev/null and b/media/articles/extensions/authorization/clients-for-api.png differ
diff --git a/media/articles/extensions/authorization/corporation.png b/media/articles/extensions/authorization/corporation.png
new file mode 100644
index 0000000000..4a5769b0e1
Binary files /dev/null and b/media/articles/extensions/authorization/corporation.png differ
diff --git a/media/articles/extensions/authorization/edit-rule.png b/media/articles/extensions/authorization/edit-rule.png
new file mode 100644
index 0000000000..b691acbd17
Binary files /dev/null and b/media/articles/extensions/authorization/edit-rule.png differ
diff --git a/media/articles/extensions/authorization/enable-api-access.png b/media/articles/extensions/authorization/enable-api-access.png
new file mode 100644
index 0000000000..bc8e25607a
Binary files /dev/null and b/media/articles/extensions/authorization/enable-api-access.png differ
diff --git a/media/articles/extensions/authorization/group-mapping-v2.png b/media/articles/extensions/authorization/group-mapping-v2.png
index 7a9a6718ff..515d8d95b0 100644
Binary files a/media/articles/extensions/authorization/group-mapping-v2.png and b/media/articles/extensions/authorization/group-mapping-v2.png differ
diff --git a/media/articles/extensions/authorization/groups-roles-permissions.png b/media/articles/extensions/authorization/groups-roles-permissions.png
new file mode 100644
index 0000000000..219d0b1043
Binary files /dev/null and b/media/articles/extensions/authorization/groups-roles-permissions.png differ
diff --git a/media/articles/extensions/authorization/passthrough.png b/media/articles/extensions/authorization/passthrough.png
new file mode 100644
index 0000000000..1cf62713cf
Binary files /dev/null and b/media/articles/extensions/authorization/passthrough.png differ
diff --git a/media/articles/extensions/authorization/persistence.png b/media/articles/extensions/authorization/persistence.png
new file mode 100644
index 0000000000..d384eba5c6
Binary files /dev/null and b/media/articles/extensions/authorization/persistence.png differ
diff --git a/media/articles/extensions/authorization/required-roles.png b/media/articles/extensions/authorization/required-roles.png
new file mode 100644
index 0000000000..e3a83109b6
Binary files /dev/null and b/media/articles/extensions/authorization/required-roles.png differ
diff --git a/media/articles/extensions/authorization/roles-permissions.png b/media/articles/extensions/authorization/roles-permissions.png
new file mode 100644
index 0000000000..2416dbbcf8
Binary files /dev/null and b/media/articles/extensions/authorization/roles-permissions.png differ
diff --git a/media/articles/extensions/authorization/user-info.png b/media/articles/extensions/authorization/user-info.png
new file mode 100644
index 0000000000..4ee825b02a
Binary files /dev/null and b/media/articles/extensions/authorization/user-info.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/delegated-admin/oauth-settings.png b/media/articles/extensions/delegated-admin/oauth-settings.png
new file mode 100755
index 0000000000..de080e4545
Binary files /dev/null and b/media/articles/extensions/delegated-admin/oauth-settings.png differ
diff --git a/media/articles/extensions/delegated-admin/set-rs256.png b/media/articles/extensions/delegated-admin/set-rs256.png
deleted file mode 100755
index becd7e7824..0000000000
Binary files a/media/articles/extensions/delegated-admin/set-rs256.png and /dev/null 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/logstash/slack-message.png b/media/articles/extensions/logstash/slack-message.png
new file mode 100644
index 0000000000..fef6d38a5a
Binary files /dev/null and b/media/articles/extensions/logstash/slack-message.png differ
diff --git a/media/articles/extensions/logstash/slack-settings.png b/media/articles/extensions/logstash/slack-settings.png
new file mode 100644
index 0000000000..0913ccb29a
Binary files /dev/null and b/media/articles/extensions/logstash/slack-settings.png 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/default-columns.png b/media/articles/extensions/user-import-export/default-columns.png
new file mode 100644
index 0000000000..37a61c721a
Binary files /dev/null and b/media/articles/extensions/user-import-export/default-columns.png differ
diff --git a/media/articles/extensions/user-import-export/export-complete.png b/media/articles/extensions/user-import-export/export-complete.png
new file mode 100644
index 0000000000..3244821932
Binary files /dev/null and b/media/articles/extensions/user-import-export/export-complete.png differ
diff --git a/media/articles/extensions/user-import-export/export-users.png b/media/articles/extensions/user-import-export/export-users.png
new file mode 100644
index 0000000000..c5252f8006
Binary files /dev/null and b/media/articles/extensions/user-import-export/export-users.png differ
diff --git a/media/articles/extensions/user-import-export/import-complete.png b/media/articles/extensions/user-import-export/import-complete.png
new file mode 100644
index 0000000000..459286f292
Binary files /dev/null and b/media/articles/extensions/user-import-export/import-complete.png differ
diff --git a/media/articles/extensions/user-import-export/import.png b/media/articles/extensions/user-import-export/import.png
new file mode 100644
index 0000000000..d4e325ea4e
Binary files /dev/null and b/media/articles/extensions/user-import-export/import.png differ
diff --git a/media/articles/extensions/user-import-export/install-extension.png b/media/articles/extensions/user-import-export/install-extension.png
new file mode 100644
index 0000000000..f4dcbb307e
Binary files /dev/null and b/media/articles/extensions/user-import-export/install-extension.png differ
diff --git a/media/articles/extensions/user-import-export/installed-extensions-list.png b/media/articles/extensions/user-import-export/installed-extensions-list.png
new file mode 100644
index 0000000000..c2b7c886e5
Binary files /dev/null and b/media/articles/extensions/user-import-export/installed-extensions-list.png differ
diff --git a/media/articles/extensions/user-import-export/permissions.png b/media/articles/extensions/user-import-export/permissions.png
new file mode 100644
index 0000000000..ef269bfcd5
Binary files /dev/null and b/media/articles/extensions/user-import-export/permissions.png differ
diff --git a/media/articles/extensions/user-import-export/ready-for-import.png b/media/articles/extensions/user-import-export/ready-for-import.png
new file mode 100644
index 0000000000..fff3e34334
Binary files /dev/null and b/media/articles/extensions/user-import-export/ready-for-import.png differ
diff --git a/media/articles/extensions/user-import-export/settings.png b/media/articles/extensions/user-import-export/settings.png
new file mode 100644
index 0000000000..9515949e4d
Binary files /dev/null and b/media/articles/extensions/user-import-export/settings.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
new file mode 100644
index 0000000000..d9fa504a66
Binary files /dev/null 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
new file mode 100644
index 0000000000..be03becef8
Binary files /dev/null and b/media/articles/getting-started/client-types.png differ
diff --git a/media/articles/guides/login/centralized-embedded-flow.svg b/media/articles/guides/login/centralized-embedded-flow.svg
new file mode 100644
index 0000000000..2125563790
--- /dev/null
+++ b/media/articles/guides/login/centralized-embedded-flow.svg
@@ -0,0 +1,148 @@
+
+
+    
+    centralized-embedded-login-svg
+    Created with Sketch.
+    
+    
+        
+            
+                
+                
+                    
+                    
+                        
+                        
+                        
+                        
+                    
+                
+                
+                    
+                        
+                        
+                    
+                    
+                
+                
+                    
+                        
+                        
+                        
+                        
+                    
+                    
+                
+                
+                    
+                        
+                        
+                    
+                    
+                
+                
+                    
+                    
+                        
+                        
+                        
+                        
+                    
+                
+                
+                    
+                        
+                        
+                    
+                    
+                
+                
+                    
+                    
+                        
+                        
+                        
+                        
+                    
+                
+                
+                    
+                        
+                        
+                    
+                    
+                
+                
+                    
+                    
+                        
+                        
+                        
+                        
+                    
+                
+            
+            
+                
+                    
+                    
+                        
+                        
+                    
+                
+                
+                    
+                    
+                        
+                        
+                        
+                        
+                    
+                
+                
+                    
+                    
+                        
+                        
+                        
+                        
+                    
+                
+                
+                    
+                        
+                        
+                    
+                    
+                
+                
+                    
+                    
+                        
+                        
+                        
+                        
+                    
+                
+                
+                    
+                    
+                        
+                        
+                        
+                        
+                    
+                
+                
+                    
+                        
+                        
+                    
+                    
+                
+                
+            
+            
+        
+    
+
\ No newline at end of file
diff --git a/media/articles/guides/login/centralized-embedded-ux.jpg b/media/articles/guides/login/centralized-embedded-ux.jpg
new file mode 100644
index 0000000000..0201bd4b64
Binary files /dev/null and b/media/articles/guides/login/centralized-embedded-ux.jpg differ
diff --git a/media/articles/guides/login/google-login.jpg b/media/articles/guides/login/google-login.jpg
new file mode 100644
index 0000000000..5eede03004
Binary files /dev/null and b/media/articles/guides/login/google-login.jpg differ
diff --git a/media/articles/har/ss-2015-01-19T11-32-15.png b/media/articles/har/ss-2015-01-19T11-32-15.png
deleted file mode 100644
index 4391e31346..0000000000
Binary files a/media/articles/har/ss-2015-01-19T11-32-15.png and /dev/null differ
diff --git a/media/articles/hooks/confirm-enable-hook.png b/media/articles/hooks/confirm-enable-hook.png
new file mode 100755
index 0000000000..a4b0d6a728
Binary files /dev/null and b/media/articles/hooks/confirm-enable-hook.png differ
diff --git a/media/articles/hooks/create-new-hook.png b/media/articles/hooks/create-new-hook.png
new file mode 100755
index 0000000000..29172bf746
Binary files /dev/null and b/media/articles/hooks/create-new-hook.png differ
diff --git a/media/articles/hooks/delete-hook.png b/media/articles/hooks/delete-hook.png
new file mode 100755
index 0000000000..8476c57d3c
Binary files /dev/null and b/media/articles/hooks/delete-hook.png differ
diff --git a/media/articles/hooks/disable-hook.png b/media/articles/hooks/disable-hook.png
new file mode 100755
index 0000000000..309b29704b
Binary files /dev/null and b/media/articles/hooks/disable-hook.png 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/hooks/hooks-dashboard.png b/media/articles/hooks/hooks-dashboard.png
new file mode 100755
index 0000000000..ecb282d37c
Binary files /dev/null and b/media/articles/hooks/hooks-dashboard.png differ
diff --git a/media/articles/hooks/hooks-list.png b/media/articles/hooks/hooks-list.png
new file mode 100755
index 0000000000..b26622e19e
Binary files /dev/null and b/media/articles/hooks/hooks-list.png differ
diff --git a/media/articles/hooks/mgmt-dashboard-webtasks.png b/media/articles/hooks/mgmt-dashboard-webtasks.png
new file mode 100755
index 0000000000..7215c8aa53
Binary files /dev/null and b/media/articles/hooks/mgmt-dashboard-webtasks.png differ
diff --git a/media/articles/hooks/rename-hook.png b/media/articles/hooks/rename-hook.png
new file mode 100755
index 0000000000..1e8770ec25
Binary files /dev/null and b/media/articles/hooks/rename-hook.png differ
diff --git a/media/articles/hooks/select-hook-to-enable.png b/media/articles/hooks/select-hook-to-enable.png
new file mode 100644
index 0000000000..44a1cb831b
Binary files /dev/null and b/media/articles/hooks/select-hook-to-enable.png differ
diff --git a/media/articles/hooks/webtask-editor-secrets.png b/media/articles/hooks/webtask-editor-secrets.png
new file mode 100755
index 0000000000..065cba0f28
Binary files /dev/null and b/media/articles/hooks/webtask-editor-secrets.png differ
diff --git a/media/articles/hooks/webtask-editor.png b/media/articles/hooks/webtask-editor.png
new file mode 100755
index 0000000000..8a49d8504e
Binary files /dev/null and b/media/articles/hooks/webtask-editor.png differ
diff --git a/media/articles/hooks/webtask-runner.png b/media/articles/hooks/webtask-runner.png
new file mode 100644
index 0000000000..099ffa75e4
Binary files /dev/null and b/media/articles/hooks/webtask-runner.png differ
diff --git a/media/articles/hooks/webtask-runner2.png b/media/articles/hooks/webtask-runner2.png
new file mode 100644
index 0000000000..bfb1bb38c1
Binary files /dev/null and b/media/articles/hooks/webtask-runner2.png differ
diff --git a/media/articles/hooks/webtask-runner3.png b/media/articles/hooks/webtask-runner3.png
new file mode 100644
index 0000000000..a80b86571b
Binary files /dev/null and b/media/articles/hooks/webtask-runner3.png differ
diff --git a/media/articles/hooks/webtask-runner4.png b/media/articles/hooks/webtask-runner4.png
new file mode 100644
index 0000000000..6dcc056a87
Binary files /dev/null and b/media/articles/hooks/webtask-runner4.png differ
diff --git a/media/articles/hosted-pages/consent-dialog.png b/media/articles/hosted-pages/consent-dialog.png
new file mode 100644
index 0000000000..71a2a7fba2
Binary files /dev/null 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
new file mode 100644
index 0000000000..d3b81524db
Binary files /dev/null and b/media/articles/hosted-pages/create-new-tenant.png differ
diff --git a/media/articles/hosted-pages/error-pages.png b/media/articles/hosted-pages/error-pages.png
index 18983b9a25..1acb9bed0b 100755
Binary files a/media/articles/hosted-pages/error-pages.png and b/media/articles/hosted-pages/error-pages.png differ
diff --git a/media/articles/hosted-pages/hlp-customui.png b/media/articles/hosted-pages/hlp-customui.png
new file mode 100755
index 0000000000..a7737b3f90
Binary files /dev/null and b/media/articles/hosted-pages/hlp-customui.png differ
diff --git a/media/articles/hosted-pages/hlp-lock-passwordless.png b/media/articles/hosted-pages/hlp-lock-passwordless.png
new file mode 100644
index 0000000000..819fa72761
Binary files /dev/null and b/media/articles/hosted-pages/hlp-lock-passwordless.png differ
diff --git a/media/articles/hosted-pages/hlp-lock.png b/media/articles/hosted-pages/hlp-lock.png
new file mode 100755
index 0000000000..d92da56f4a
Binary files /dev/null and b/media/articles/hosted-pages/hlp-lock.png differ
diff --git a/media/articles/hosted-pages/hlp-preview-customui.png b/media/articles/hosted-pages/hlp-preview-customui.png
new file mode 100755
index 0000000000..8705332d2a
Binary files /dev/null and b/media/articles/hosted-pages/hlp-preview-customui.png differ
diff --git a/media/articles/hosted-pages/hlp-preview-lock-passwordless.png b/media/articles/hosted-pages/hlp-preview-lock-passwordless.png
new file mode 100755
index 0000000000..6795d78c84
Binary files /dev/null and b/media/articles/hosted-pages/hlp-preview-lock-passwordless.png differ
diff --git a/media/articles/hosted-pages/hlp-preview-lock.png b/media/articles/hosted-pages/hlp-preview-lock.png
new file mode 100755
index 0000000000..77d4597b85
Binary files /dev/null and b/media/articles/hosted-pages/hlp-preview-lock.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-api-gateway-2/api-1.png b/media/articles/integrations/aws-api-gateway-2/api-1.png
new file mode 100644
index 0000000000..3316970720
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/api-1.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/api-2.png b/media/articles/integrations/aws-api-gateway-2/api-2.png
new file mode 100644
index 0000000000..b2f9fcf022
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/api-2.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/api-3.png b/media/articles/integrations/aws-api-gateway-2/api-3.png
new file mode 100644
index 0000000000..fa51e50844
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/api-3.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-1.png b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-1.png
new file mode 100644
index 0000000000..acab73e6bb
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-1.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-10.png b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-10.png
new file mode 100644
index 0000000000..c2a11876c3
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-10.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-3.png b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-3.png
new file mode 100644
index 0000000000..49050a95ae
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-3.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-4.png b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-4.png
new file mode 100644
index 0000000000..e53b22ef6b
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-4.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5.png b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5.png
new file mode 100644
index 0000000000..de99011ac6
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5a.png b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5a.png
new file mode 100644
index 0000000000..25a7cfce29
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5a.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5b.png b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5b.png
new file mode 100644
index 0000000000..a318fd0f29
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5b.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5c.png b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5c.png
new file mode 100644
index 0000000000..5cca31c435
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5c.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5d.png b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5d.png
new file mode 100644
index 0000000000..dfa5a01ac6
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5d.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5e.png b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5e.png
new file mode 100644
index 0000000000..edfa99bd48
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-5e.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-6.png b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-6.png
new file mode 100644
index 0000000000..9a705efbd2
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-6.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-7.png b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-7.png
new file mode 100644
index 0000000000..4da6f9379d
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-7.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-8.png b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-8.png
new file mode 100644
index 0000000000..af71f4cdec
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-8.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-9.png b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-9.png
new file mode 100644
index 0000000000..8877bcc378
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-1/aws-pt1-9.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-1.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-1.png
new file mode 100644
index 0000000000..de12554b9d
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-1.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-10.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-10.png
new file mode 100644
index 0000000000..ae7c1f15df
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-10.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-11.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-11.png
new file mode 100644
index 0000000000..025dab0a55
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-11.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-12.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-12.png
new file mode 100644
index 0000000000..2a33f80713
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-12.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-13.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-13.png
new file mode 100644
index 0000000000..28f57cd146
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-13.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-14.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-14.png
new file mode 100644
index 0000000000..d54c716f30
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-14.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-15.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-15.png
new file mode 100644
index 0000000000..ca6e7f7736
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-15.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-16.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-16.png
new file mode 100644
index 0000000000..f71d3d94b8
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-16.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-17.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-17.png
new file mode 100644
index 0000000000..35dfa52dd7
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-17.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-18.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-18.png
new file mode 100644
index 0000000000..3529156674
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-18.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-19.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-19.png
new file mode 100644
index 0000000000..b54e11b314
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-19.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-2.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-2.png
new file mode 100644
index 0000000000..adc3a5f2db
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-2.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-21.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-21.png
new file mode 100644
index 0000000000..da6dd71a3c
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-21.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-22.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-22.png
new file mode 100644
index 0000000000..fd67bb9dc8
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-22.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-23.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-23.png
new file mode 100644
index 0000000000..865c75a483
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-23.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-24.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-24.png
new file mode 100644
index 0000000000..efbff06485
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-24.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-25.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-25.png
new file mode 100644
index 0000000000..c93a3d1ba9
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-25.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-26.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-26.png
new file mode 100644
index 0000000000..e2233f4277
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-26.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-4.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-4.png
new file mode 100644
index 0000000000..53a0be3c03
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-4.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-5.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-5.png
new file mode 100644
index 0000000000..43f45b5023
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-5.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-6.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-6.png
new file mode 100644
index 0000000000..f65e4c3301
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-6.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-8.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-8.png
new file mode 100644
index 0000000000..a561ddc4c7
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-8.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-2/pt2-9.png b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-9.png
new file mode 100644
index 0000000000..c2b5bee041
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-2/pt2-9.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-3/pt3-1.png b/media/articles/integrations/aws-api-gateway-2/part-3/pt3-1.png
new file mode 100644
index 0000000000..f060d9134e
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-3/pt3-1.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-3/pt3-2.png b/media/articles/integrations/aws-api-gateway-2/part-3/pt3-2.png
new file mode 100644
index 0000000000..44cce656b7
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-3/pt3-2.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-3/pt3-3.png b/media/articles/integrations/aws-api-gateway-2/part-3/pt3-3.png
new file mode 100644
index 0000000000..747ef5942e
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-3/pt3-3.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-3/pt3-4.png b/media/articles/integrations/aws-api-gateway-2/part-3/pt3-4.png
new file mode 100644
index 0000000000..13742a8695
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-3/pt3-4.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-3/pt3-5.png b/media/articles/integrations/aws-api-gateway-2/part-3/pt3-5.png
new file mode 100644
index 0000000000..83b37d76e2
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-3/pt3-5.png differ
diff --git a/media/articles/integrations/aws-api-gateway-2/part-3/pt3-8.png b/media/articles/integrations/aws-api-gateway-2/part-3/pt3-8.png
new file mode 100644
index 0000000000..75f0f58e56
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway-2/part-3/pt3-8.png differ
diff --git a/media/articles/integrations/aws-api-gateway/auth-flow.png b/media/articles/integrations/aws-api-gateway/auth-flow.png
index f0edec72d7..7bed9e222e 100755
Binary files a/media/articles/integrations/aws-api-gateway/auth-flow.png and b/media/articles/integrations/aws-api-gateway/auth-flow.png differ
diff --git a/media/articles/integrations/aws-api-gateway/aws-api-gateway-key.png b/media/articles/integrations/aws-api-gateway/aws-api-gateway-key.png
index ddf4546b4c..72e8a875ae 100644
Binary files a/media/articles/integrations/aws-api-gateway/aws-api-gateway-key.png and b/media/articles/integrations/aws-api-gateway/aws-api-gateway-key.png differ
diff --git a/media/articles/integrations/aws-api-gateway/aws-api-gateway-project.png b/media/articles/integrations/aws-api-gateway/aws-api-gateway-project.png
index 0d6073f25d..b663e8ec4d 100644
Binary files a/media/articles/integrations/aws-api-gateway/aws-api-gateway-project.png and b/media/articles/integrations/aws-api-gateway/aws-api-gateway-project.png differ
diff --git a/media/articles/integrations/aws-api-gateway/config-authorizer.png b/media/articles/integrations/aws-api-gateway/config-authorizer.png
index a1f8834b76..304736a285 100755
Binary files a/media/articles/integrations/aws-api-gateway/config-authorizer.png and b/media/articles/integrations/aws-api-gateway/config-authorizer.png differ
diff --git a/media/articles/integrations/aws-api-gateway/create-user-pool-authorizer.png b/media/articles/integrations/aws-api-gateway/create-user-pool-authorizer.png
index 624ab06632..1e06543552 100755
Binary files a/media/articles/integrations/aws-api-gateway/create-user-pool-authorizer.png and b/media/articles/integrations/aws-api-gateway/create-user-pool-authorizer.png differ
diff --git a/media/articles/integrations/aws-api-gateway/identity-flow.png b/media/articles/integrations/aws-api-gateway/identity-flow.png
index 3836e795aa..3c0f553002 100755
Binary files a/media/articles/integrations/aws-api-gateway/identity-flow.png and b/media/articles/integrations/aws-api-gateway/identity-flow.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/configure-function.png b/media/articles/integrations/aws-api-gateway/part-1/configure-function.png
old mode 100755
new mode 100644
index d206561c45..0db9a0629e
Binary files a/media/articles/integrations/aws-api-gateway/part-1/configure-function.png and b/media/articles/integrations/aws-api-gateway/part-1/configure-function.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/configure-function2.png b/media/articles/integrations/aws-api-gateway/part-1/configure-function2.png
new file mode 100644
index 0000000000..b5602f11cf
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway/part-1/configure-function2.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/configure-newly-created-table.png b/media/articles/integrations/aws-api-gateway/part-1/configure-newly-created-table.png
index f0d4ebaf6b..06c281742a 100644
Binary files a/media/articles/integrations/aws-api-gateway/part-1/configure-newly-created-table.png and b/media/articles/integrations/aws-api-gateway/part-1/configure-newly-created-table.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/create-example-api.png b/media/articles/integrations/aws-api-gateway/part-1/create-example-api.png
old mode 100755
new mode 100644
index 0b1bf87d77..dab18097ed
Binary files a/media/articles/integrations/aws-api-gateway/part-1/create-example-api.png and b/media/articles/integrations/aws-api-gateway/part-1/create-example-api.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/create-inline-policies.png b/media/articles/integrations/aws-api-gateway/part-1/create-inline-policies.png
old mode 100755
new mode 100644
index 3f937c9316..69a8b6579a
Binary files a/media/articles/integrations/aws-api-gateway/part-1/create-inline-policies.png and b/media/articles/integrations/aws-api-gateway/part-1/create-inline-policies.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/create-new-api.png b/media/articles/integrations/aws-api-gateway/part-1/create-new-api.png
old mode 100755
new mode 100644
index 04b4fa3bb0..12508ddad2
Binary files a/media/articles/integrations/aws-api-gateway/part-1/create-new-api.png and b/media/articles/integrations/aws-api-gateway/part-1/create-new-api.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/create-pets-method.png b/media/articles/integrations/aws-api-gateway/part-1/create-pets-method.png
old mode 100755
new mode 100644
index f684d56900..53fd2b15ea
Binary files a/media/articles/integrations/aws-api-gateway/part-1/create-pets-method.png and b/media/articles/integrations/aws-api-gateway/part-1/create-pets-method.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/create-resource.png b/media/articles/integrations/aws-api-gateway/part-1/create-resource.png
old mode 100755
new mode 100644
index 5cb5724b54..39f11f1347
Binary files a/media/articles/integrations/aws-api-gateway/part-1/create-resource.png and b/media/articles/integrations/aws-api-gateway/part-1/create-resource.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/custom-policy.png b/media/articles/integrations/aws-api-gateway/part-1/custom-policy.png
old mode 100755
new mode 100644
index d97cdc18f3..64c145484c
Binary files a/media/articles/integrations/aws-api-gateway/part-1/custom-policy.png and b/media/articles/integrations/aws-api-gateway/part-1/custom-policy.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/dynamodb-create-table.png b/media/articles/integrations/aws-api-gateway/part-1/dynamodb-create-table.png
old mode 100755
new mode 100644
index e5e7f08e22..25c64ba2f2
Binary files a/media/articles/integrations/aws-api-gateway/part-1/dynamodb-create-table.png and b/media/articles/integrations/aws-api-gateway/part-1/dynamodb-create-table.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/execution-result-update.png b/media/articles/integrations/aws-api-gateway/part-1/execution-result-update.png
new file mode 100644
index 0000000000..31352eeecb
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway/part-1/execution-result-update.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/execution-result.png b/media/articles/integrations/aws-api-gateway/part-1/execution-result.png
old mode 100755
new mode 100644
index db4f9a3933..0efc84fdc5
Binary files a/media/articles/integrations/aws-api-gateway/part-1/execution-result.png and b/media/articles/integrations/aws-api-gateway/part-1/execution-result.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/get-method-request-test2.png b/media/articles/integrations/aws-api-gateway/part-1/get-method-request-test2.png
new file mode 100644
index 0000000000..429e7abb67
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway/part-1/get-method-request-test2.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/get-started-with-api-gateway.png b/media/articles/integrations/aws-api-gateway/part-1/get-started-with-api-gateway.png
old mode 100755
new mode 100644
index 9a758ce869..95947bf34f
Binary files a/media/articles/integrations/aws-api-gateway/part-1/get-started-with-api-gateway.png and b/media/articles/integrations/aws-api-gateway/part-1/get-started-with-api-gateway.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/iam-roles-list.png b/media/articles/integrations/aws-api-gateway/part-1/iam-roles-list.png
old mode 100755
new mode 100644
index 977871fc7e..8a726b184a
Binary files a/media/articles/integrations/aws-api-gateway/part-1/iam-roles-list.png and b/media/articles/integrations/aws-api-gateway/part-1/iam-roles-list.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/lambda-blank-function.png b/media/articles/integrations/aws-api-gateway/part-1/lambda-blank-function.png
new file mode 100644
index 0000000000..2c7d086b99
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway/part-1/lambda-blank-function.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/lambda-create-new.png b/media/articles/integrations/aws-api-gateway/part-1/lambda-create-new.png
index ec30f1b082..61213aff1b 100755
Binary files a/media/articles/integrations/aws-api-gateway/part-1/lambda-create-new.png and b/media/articles/integrations/aws-api-gateway/part-1/lambda-create-new.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/lambda-get-started-now.png b/media/articles/integrations/aws-api-gateway/part-1/lambda-get-started-now.png
old mode 100755
new mode 100644
index 01493beac7..4c5420fc66
Binary files a/media/articles/integrations/aws-api-gateway/part-1/lambda-get-started-now.png and b/media/articles/integrations/aws-api-gateway/part-1/lambda-get-started-now.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/lambda-handler-role.png b/media/articles/integrations/aws-api-gateway/part-1/lambda-handler-role.png
deleted file mode 100755
index 52970642e2..0000000000
Binary files a/media/articles/integrations/aws-api-gateway/part-1/lambda-handler-role.png and /dev/null differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/lambda-permissions.png b/media/articles/integrations/aws-api-gateway/part-1/lambda-permissions.png
old mode 100755
new mode 100644
index 9b74a675bc..d4cf3deb0f
Binary files a/media/articles/integrations/aws-api-gateway/part-1/lambda-permissions.png and b/media/articles/integrations/aws-api-gateway/part-1/lambda-permissions.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/method-execution-results.png b/media/articles/integrations/aws-api-gateway/part-1/method-execution-results.png
old mode 100755
new mode 100644
index bd583e77ab..d04a78178b
Binary files a/media/articles/integrations/aws-api-gateway/part-1/method-execution-results.png and b/media/articles/integrations/aws-api-gateway/part-1/method-execution-results.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/method-execution.png b/media/articles/integrations/aws-api-gateway/part-1/method-execution.png
old mode 100755
new mode 100644
index 2ef14a96f9..fbc2d5c781
Binary files a/media/articles/integrations/aws-api-gateway/part-1/method-execution.png and b/media/articles/integrations/aws-api-gateway/part-1/method-execution.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/name-resource.png b/media/articles/integrations/aws-api-gateway/part-1/name-resource.png
old mode 100755
new mode 100644
index 8c031a3af2..6ce763f32c
Binary files a/media/articles/integrations/aws-api-gateway/part-1/name-resource.png and b/media/articles/integrations/aws-api-gateway/part-1/name-resource.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/options-method.png b/media/articles/integrations/aws-api-gateway/part-1/options-method.png
index 0d300946c1..a9d64822a8 100644
Binary files a/media/articles/integrations/aws-api-gateway/part-1/options-method.png and b/media/articles/integrations/aws-api-gateway/part-1/options-method.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/options-test.png b/media/articles/integrations/aws-api-gateway/part-1/options-test.png
new file mode 100644
index 0000000000..96f32c844e
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway/part-1/options-test.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/pets-get-method-setup.png b/media/articles/integrations/aws-api-gateway/part-1/pets-get-method-setup.png
old mode 100755
new mode 100644
index f9641045af..bf1724c88c
Binary files a/media/articles/integrations/aws-api-gateway/part-1/pets-get-method-setup.png and b/media/articles/integrations/aws-api-gateway/part-1/pets-get-method-setup.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/pets-method-get.png b/media/articles/integrations/aws-api-gateway/part-1/pets-method-get.png
deleted file mode 100755
index 22b9e88741..0000000000
Binary files a/media/articles/integrations/aws-api-gateway/part-1/pets-method-get.png and /dev/null differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/post-method-request-test.png b/media/articles/integrations/aws-api-gateway/part-1/post-method-request-test.png
old mode 100755
new mode 100644
index b971131a19..f9763b9db3
Binary files a/media/articles/integrations/aws-api-gateway/part-1/post-method-request-test.png and b/media/articles/integrations/aws-api-gateway/part-1/post-method-request-test.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/roles.png b/media/articles/integrations/aws-api-gateway/part-1/roles.png
old mode 100755
new mode 100644
index f30f25098c..17416cf6aa
Binary files a/media/articles/integrations/aws-api-gateway/part-1/roles.png and b/media/articles/integrations/aws-api-gateway/part-1/roles.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/select-role-type.png b/media/articles/integrations/aws-api-gateway/part-1/select-role-type.png
old mode 100755
new mode 100644
index f135003b33..96f69592da
Binary files a/media/articles/integrations/aws-api-gateway/part-1/select-role-type.png and b/media/articles/integrations/aws-api-gateway/part-1/select-role-type.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/set-role-name.png b/media/articles/integrations/aws-api-gateway/part-1/set-role-name.png
old mode 100755
new mode 100644
index 88b8c73845..1ee54606b3
Binary files a/media/articles/integrations/aws-api-gateway/part-1/set-role-name.png and b/media/articles/integrations/aws-api-gateway/part-1/set-role-name.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/table-arn.png b/media/articles/integrations/aws-api-gateway/part-1/table-arn.png
old mode 100755
new mode 100644
index 57fba5808d..c0e8b9d0f3
Binary files a/media/articles/integrations/aws-api-gateway/part-1/table-arn.png and b/media/articles/integrations/aws-api-gateway/part-1/table-arn.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-1/test-result-one-pet.png b/media/articles/integrations/aws-api-gateway/part-1/test-result-one-pet.png
old mode 100755
new mode 100644
index 7b886535ef..c5edb07d81
Binary files a/media/articles/integrations/aws-api-gateway/part-1/test-result-one-pet.png and b/media/articles/integrations/aws-api-gateway/part-1/test-result-one-pet.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/add-headers.png b/media/articles/integrations/aws-api-gateway/part-2/add-headers.png
old mode 100755
new mode 100644
index e432ffe05e..9581ed3982
Binary files a/media/articles/integrations/aws-api-gateway/part-2/add-headers.png and b/media/articles/integrations/aws-api-gateway/part-2/add-headers.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/add-response-headers.png b/media/articles/integrations/aws-api-gateway/part-2/add-response-headers.png
deleted file mode 100755
index d91470baf1..0000000000
Binary files a/media/articles/integrations/aws-api-gateway/part-2/add-response-headers.png and /dev/null differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/attach-policy.png b/media/articles/integrations/aws-api-gateway/part-2/attach-policy.png
old mode 100755
new mode 100644
index c786bb0e46..a066f6ea89
Binary files a/media/articles/integrations/aws-api-gateway/part-2/attach-policy.png and b/media/articles/integrations/aws-api-gateway/part-2/attach-policy.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/auth-settings.png b/media/articles/integrations/aws-api-gateway/part-2/auth-settings.png
old mode 100755
new mode 100644
index d77550683e..a20c50e177
Binary files a/media/articles/integrations/aws-api-gateway/part-2/auth-settings.png and b/media/articles/integrations/aws-api-gateway/part-2/auth-settings.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/choose-deploy-stage.png b/media/articles/integrations/aws-api-gateway/part-2/choose-deploy-stage.png
old mode 100755
new mode 100644
index cf321f6686..4b48dadd62
Binary files a/media/articles/integrations/aws-api-gateway/part-2/choose-deploy-stage.png and b/media/articles/integrations/aws-api-gateway/part-2/choose-deploy-stage.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/config-options-method.png b/media/articles/integrations/aws-api-gateway/part-2/config-options-method.png
old mode 100755
new mode 100644
index f1f9ad870b..4f7f7315ba
Binary files a/media/articles/integrations/aws-api-gateway/part-2/config-options-method.png and b/media/articles/integrations/aws-api-gateway/part-2/config-options-method.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/create-new-client.png b/media/articles/integrations/aws-api-gateway/part-2/create-new-client.png
index 5fa27f2d04..d19941c0a2 100755
Binary files a/media/articles/integrations/aws-api-gateway/part-2/create-new-client.png and b/media/articles/integrations/aws-api-gateway/part-2/create-new-client.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/create-options-method.png b/media/articles/integrations/aws-api-gateway/part-2/create-options-method.png
old mode 100755
new mode 100644
index 8429b87916..e82f8b8901
Binary files a/media/articles/integrations/aws-api-gateway/part-2/create-options-method.png and b/media/articles/integrations/aws-api-gateway/part-2/create-options-method.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/custom-policy.png b/media/articles/integrations/aws-api-gateway/part-2/custom-policy.png
old mode 100755
new mode 100644
index 2a844c9fbb..26b29c560b
Binary files a/media/articles/integrations/aws-api-gateway/part-2/custom-policy.png and b/media/articles/integrations/aws-api-gateway/part-2/custom-policy.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/customize-trust-policy-doc.png b/media/articles/integrations/aws-api-gateway/part-2/customize-trust-policy-doc.png
deleted file mode 100755
index d711f1ffea..0000000000
Binary files a/media/articles/integrations/aws-api-gateway/part-2/customize-trust-policy-doc.png and /dev/null differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/deploy-api.png b/media/articles/integrations/aws-api-gateway/part-2/deploy-api.png
old mode 100755
new mode 100644
index e06dda2e3b..aadf8a9f7a
Binary files a/media/articles/integrations/aws-api-gateway/part-2/deploy-api.png and b/media/articles/integrations/aws-api-gateway/part-2/deploy-api.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/edit-custom-policy.png b/media/articles/integrations/aws-api-gateway/part-2/edit-custom-policy.png
old mode 100755
new mode 100644
index 830e92e935..cc1a918022
Binary files a/media/articles/integrations/aws-api-gateway/part-2/edit-custom-policy.png and b/media/articles/integrations/aws-api-gateway/part-2/edit-custom-policy.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/edit-trust-policy.png b/media/articles/integrations/aws-api-gateway/part-2/edit-trust-policy.png
new file mode 100644
index 0000000000..493519dcd5
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway/part-2/edit-trust-policy.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/edit-trust.png b/media/articles/integrations/aws-api-gateway/part-2/edit-trust.png
deleted file mode 100755
index 16b6da501a..0000000000
Binary files a/media/articles/integrations/aws-api-gateway/part-2/edit-trust.png and /dev/null differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/enable-aws-addon.png b/media/articles/integrations/aws-api-gateway/part-2/enable-aws-addon.png
index a5a446c063..f6e3194533 100755
Binary files a/media/articles/integrations/aws-api-gateway/part-2/enable-aws-addon.png and b/media/articles/integrations/aws-api-gateway/part-2/enable-aws-addon.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/integration-response.png b/media/articles/integrations/aws-api-gateway/part-2/integration-response.png
old mode 100755
new mode 100644
index 93e055aded..58005fa6d5
Binary files a/media/articles/integrations/aws-api-gateway/part-2/integration-response.png and b/media/articles/integrations/aws-api-gateway/part-2/integration-response.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/method-response.png b/media/articles/integrations/aws-api-gateway/part-2/method-response.png
old mode 100755
new mode 100644
index 02f21fd802..d1365639ad
Binary files a/media/articles/integrations/aws-api-gateway/part-2/method-response.png and b/media/articles/integrations/aws-api-gateway/part-2/method-response.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/mgmt-dashboard.png b/media/articles/integrations/aws-api-gateway/part-2/mgmt-dashboard.png
index 1e535d227f..ccd4937d67 100755
Binary files a/media/articles/integrations/aws-api-gateway/part-2/mgmt-dashboard.png and b/media/articles/integrations/aws-api-gateway/part-2/mgmt-dashboard.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/permissions.png b/media/articles/integrations/aws-api-gateway/part-2/permissions.png
old mode 100755
new mode 100644
index 842961dccb..093669fecb
Binary files a/media/articles/integrations/aws-api-gateway/part-2/permissions.png and b/media/articles/integrations/aws-api-gateway/part-2/permissions.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/post-method-request.png b/media/articles/integrations/aws-api-gateway/part-2/post-method-request.png
old mode 100755
new mode 100644
index 16466cbd35..0871d91d86
Binary files a/media/articles/integrations/aws-api-gateway/part-2/post-method-request.png and b/media/articles/integrations/aws-api-gateway/part-2/post-method-request.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/sdk-generation.png b/media/articles/integrations/aws-api-gateway/part-2/sdk-generation.png
deleted file mode 100755
index c595cf758c..0000000000
Binary files a/media/articles/integrations/aws-api-gateway/part-2/sdk-generation.png and /dev/null differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/select-iam-role.png b/media/articles/integrations/aws-api-gateway/part-2/select-iam-role.png
old mode 100755
new mode 100644
index 6a10ecfb7c..44e8cfc322
Binary files a/media/articles/integrations/aws-api-gateway/part-2/select-iam-role.png and b/media/articles/integrations/aws-api-gateway/part-2/select-iam-role.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/test-stage-editor.png b/media/articles/integrations/aws-api-gateway/part-2/test-stage-editor.png
old mode 100755
new mode 100644
index 1b26bec613..c32e0daed5
Binary files a/media/articles/integrations/aws-api-gateway/part-2/test-stage-editor.png and b/media/articles/integrations/aws-api-gateway/part-2/test-stage-editor.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-2/trust-relationship.png b/media/articles/integrations/aws-api-gateway/part-2/trust-relationship.png
new file mode 100644
index 0000000000..b0823ead4a
Binary files /dev/null and b/media/articles/integrations/aws-api-gateway/part-2/trust-relationship.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-3/add-frog-success.png b/media/articles/integrations/aws-api-gateway/part-3/add-frog-success.png
index aac76f803c..47f7c61274 100755
Binary files a/media/articles/integrations/aws-api-gateway/part-3/add-frog-success.png and b/media/articles/integrations/aws-api-gateway/part-3/add-frog-success.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-3/get-success.png b/media/articles/integrations/aws-api-gateway/part-3/get-success.png
index e9f31baf7c..7c594bcd95 100644
Binary files a/media/articles/integrations/aws-api-gateway/part-3/get-success.png and b/media/articles/integrations/aws-api-gateway/part-3/get-success.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-3/log-in-popup.png b/media/articles/integrations/aws-api-gateway/part-3/log-in-popup.png
index 74c2bd5c6b..2d0e1528a1 100755
Binary files a/media/articles/integrations/aws-api-gateway/part-3/log-in-popup.png and b/media/articles/integrations/aws-api-gateway/part-3/log-in-popup.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-3/log-in-success.png b/media/articles/integrations/aws-api-gateway/part-3/log-in-success.png
index 5457a2b6c2..065118a937 100755
Binary files a/media/articles/integrations/aws-api-gateway/part-3/log-in-success.png and b/media/articles/integrations/aws-api-gateway/part-3/log-in-success.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-4/aws-connections.png b/media/articles/integrations/aws-api-gateway/part-4/aws-connections.png
index 00d241a2b9..4d9560e48b 100755
Binary files a/media/articles/integrations/aws-api-gateway/part-4/aws-connections.png and b/media/articles/integrations/aws-api-gateway/part-4/aws-connections.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-4/configure-amazon.png b/media/articles/integrations/aws-api-gateway/part-4/configure-amazon.png
index 6b91bf741d..ffa8ad354f 100755
Binary files a/media/articles/integrations/aws-api-gateway/part-4/configure-amazon.png and b/media/articles/integrations/aws-api-gateway/part-4/configure-amazon.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-4/create-empty-rule.png b/media/articles/integrations/aws-api-gateway/part-4/create-empty-rule.png
index e948de2dd7..f3f7d307a6 100755
Binary files a/media/articles/integrations/aws-api-gateway/part-4/create-empty-rule.png and b/media/articles/integrations/aws-api-gateway/part-4/create-empty-rule.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-4/create-resource.png b/media/articles/integrations/aws-api-gateway/part-4/create-resource.png
old mode 100755
new mode 100644
index bbf03ae028..ca74249f5f
Binary files a/media/articles/integrations/aws-api-gateway/part-4/create-resource.png and b/media/articles/integrations/aws-api-gateway/part-4/create-resource.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-4/dashboard-rules-page.png b/media/articles/integrations/aws-api-gateway/part-4/dashboard-rules-page.png
index aa02b43674..20c956c6da 100755
Binary files a/media/articles/integrations/aws-api-gateway/part-4/dashboard-rules-page.png and b/media/articles/integrations/aws-api-gateway/part-4/dashboard-rules-page.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-4/enable-amazon.png b/media/articles/integrations/aws-api-gateway/part-4/enable-amazon.png
index 17aae3330b..2e26a638fb 100755
Binary files a/media/articles/integrations/aws-api-gateway/part-4/enable-amazon.png and b/media/articles/integrations/aws-api-gateway/part-4/enable-amazon.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-4/login-using-amazon.png b/media/articles/integrations/aws-api-gateway/part-4/login-using-amazon.png
index a55248df78..735bc9ad83 100755
Binary files a/media/articles/integrations/aws-api-gateway/part-4/login-using-amazon.png and b/media/articles/integrations/aws-api-gateway/part-4/login-using-amazon.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-4/new-child-resource.png b/media/articles/integrations/aws-api-gateway/part-4/new-child-resource.png
old mode 100755
new mode 100644
index 3f3b84bd5c..9d94f5f0a7
Binary files a/media/articles/integrations/aws-api-gateway/part-4/new-child-resource.png and b/media/articles/integrations/aws-api-gateway/part-4/new-child-resource.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-4/pets-rule.png b/media/articles/integrations/aws-api-gateway/part-4/pets-rule.png
index d422db59fa..f98eb449e5 100755
Binary files a/media/articles/integrations/aws-api-gateway/part-4/pets-rule.png and b/media/articles/integrations/aws-api-gateway/part-4/pets-rule.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-4/pick-empty-rules-template.png b/media/articles/integrations/aws-api-gateway/part-4/pick-empty-rules-template.png
index c51ddc89d8..b7b47c614f 100755
Binary files a/media/articles/integrations/aws-api-gateway/part-4/pick-empty-rules-template.png and b/media/articles/integrations/aws-api-gateway/part-4/pick-empty-rules-template.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-4/try-button.png b/media/articles/integrations/aws-api-gateway/part-4/try-button.png
old mode 100755
new mode 100644
index 4f296c2f10..0c53b38502
Binary files a/media/articles/integrations/aws-api-gateway/part-4/try-button.png and b/media/articles/integrations/aws-api-gateway/part-4/try-button.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-4/try-rule-script.png b/media/articles/integrations/aws-api-gateway/part-4/try-rule-script.png
index 8e58105f5d..75147865ac 100755
Binary files a/media/articles/integrations/aws-api-gateway/part-4/try-rule-script.png and b/media/articles/integrations/aws-api-gateway/part-4/try-rule-script.png differ
diff --git a/media/articles/integrations/aws-api-gateway/part-4/try-rules-output.png b/media/articles/integrations/aws-api-gateway/part-4/try-rules-output.png
index b82db93a5a..37f577a1ea 100755
Binary files a/media/articles/integrations/aws-api-gateway/part-4/try-rules-output.png and b/media/articles/integrations/aws-api-gateway/part-4/try-rules-output.png differ
diff --git a/media/articles/integrations/aws-api-gateway/roles-in-use.png b/media/articles/integrations/aws-api-gateway/roles-in-use.png
index 61f1f0084e..af478509c6 100755
Binary files a/media/articles/integrations/aws-api-gateway/roles-in-use.png and b/media/articles/integrations/aws-api-gateway/roles-in-use.png differ
diff --git a/media/articles/integrations/aws-api-gateway/set-authorizer.png b/media/articles/integrations/aws-api-gateway/set-authorizer.png
index 9b00e25adc..67d487cf1b 100755
Binary files a/media/articles/integrations/aws-api-gateway/set-authorizer.png and b/media/articles/integrations/aws-api-gateway/set-authorizer.png differ
diff --git a/media/articles/integrations/aws/addons.png b/media/articles/integrations/aws/addons.png
deleted file mode 100644
index 5ca2b76cb5..0000000000
Binary files a/media/articles/integrations/aws/addons.png and /dev/null differ
diff --git a/media/articles/integrations/aws/aws-addon.png b/media/articles/integrations/aws/aws-addon.png
index e7b300e036..47170423a7 100644
Binary files a/media/articles/integrations/aws/aws-addon.png and b/media/articles/integrations/aws/aws-addon.png 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 68f17be60e..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/aws-sts.png b/media/articles/integrations/aws/aws-sts.png
index ef22c502d2..dfeff98e43 100644
Binary files a/media/articles/integrations/aws/aws-sts.png and b/media/articles/integrations/aws/aws-sts.png differ
diff --git a/media/articles/integrations/aws/configure.png b/media/articles/integrations/aws/configure.png
index d6bbcaa90f..aa9f724b0e 100644
Binary files a/media/articles/integrations/aws/configure.png and b/media/articles/integrations/aws/configure.png 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 b590ecf693..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 2fc4012dee..0000000000
Binary files a/media/articles/integrations/aws/iam-review-role.png and /dev/null differ
diff --git a/media/articles/integrations/aws/iam-role-type.png b/media/articles/integrations/aws/iam-role-type.png
deleted file mode 100644
index 447d4c406d..0000000000
Binary files a/media/articles/integrations/aws/iam-role-type.png and /dev/null differ
diff --git a/media/articles/integrations/aws/idp-download.png b/media/articles/integrations/aws/idp-download.png
index 9dcd2de398..8cef0b230b 100644
Binary files a/media/articles/integrations/aws/idp-download.png and b/media/articles/integrations/aws/idp-download.png differ
diff --git a/media/articles/integrations/aws/idp-url.png b/media/articles/integrations/aws/idp-url.png
deleted file mode 100644
index 8afede7056..0000000000
Binary files a/media/articles/integrations/aws/idp-url.png and /dev/null differ
diff --git a/media/articles/integrations/aws/verify-role-trust.png b/media/articles/integrations/aws/verify-role-trust.png
new file mode 100644
index 0000000000..b0adc3bef0
Binary files /dev/null and b/media/articles/integrations/aws/verify-role-trust.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/auth0/api-config.png b/media/articles/integrations/azure-api-mgmt/auth0/api-config.png
new file mode 100644
index 0000000000..e0fdf1e551
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/auth0/api-config.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/auth0/api-nic.png b/media/articles/integrations/azure-api-mgmt/auth0/api-nic.png
new file mode 100644
index 0000000000..13e47de4ef
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/auth0/api-nic.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/auth0/apis.png b/media/articles/integrations/azure-api-mgmt/auth0/apis.png
new file mode 100644
index 0000000000..7acf9055f9
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/auth0/apis.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/auth0/connection-client.png b/media/articles/integrations/azure-api-mgmt/auth0/connection-client.png
new file mode 100644
index 0000000000..10463f18fe
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/auth0/connection-client.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/auth0/create-user.png b/media/articles/integrations/azure-api-mgmt/auth0/create-user.png
new file mode 100644
index 0000000000..f72b1dde31
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/auth0/create-user.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/auth0/db-connections.png b/media/articles/integrations/azure-api-mgmt/auth0/db-connections.png
new file mode 100644
index 0000000000..5624afcbcc
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/auth0/db-connections.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/auth0/new-api-config.png b/media/articles/integrations/azure-api-mgmt/auth0/new-api-config.png
new file mode 100644
index 0000000000..f1e1de21de
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/auth0/new-api-config.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/auth0/new-db-connection-config.png b/media/articles/integrations/azure-api-mgmt/auth0/new-db-connection-config.png
new file mode 100644
index 0000000000..21843ae6ea
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/auth0/new-db-connection-config.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/auth0/user.png b/media/articles/integrations/azure-api-mgmt/auth0/user.png
new file mode 100644
index 0000000000..a4b9f271cb
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/auth0/user.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/api-list.png b/media/articles/integrations/azure-api-mgmt/azure/api-list.png
new file mode 100644
index 0000000000..f072117481
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/api-list.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/api-mgmt-service-config.png b/media/articles/integrations/azure-api-mgmt/azure/api-mgmt-service-config.png
new file mode 100644
index 0000000000..e898d19935
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/api-mgmt-service-config.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/api-mgmt-service-home.png b/media/articles/integrations/azure-api-mgmt/azure/api-mgmt-service-home.png
new file mode 100644
index 0000000000..7637bbe0e3
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/api-mgmt-service-home.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/azure-portal-api-management.png b/media/articles/integrations/azure-api-mgmt/azure/azure-portal-api-management.png
new file mode 100644
index 0000000000..f375f3ff22
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/azure-portal-api-management.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/basic-calc-api.png b/media/articles/integrations/azure-api-mgmt/azure/basic-calc-api.png
new file mode 100644
index 0000000000..4755418a04
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/basic-calc-api.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/deployment-in-progress.png b/media/articles/integrations/azure-api-mgmt/azure/deployment-in-progress.png
new file mode 100644
index 0000000000..f616fca311
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/deployment-in-progress.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/dev-portal-200-response.png b/media/articles/integrations/azure-api-mgmt/azure/dev-portal-200-response.png
new file mode 100644
index 0000000000..a7fcd17adb
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/dev-portal-200-response.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/dev-portal-apis.png b/media/articles/integrations/azure-api-mgmt/azure/dev-portal-apis.png
new file mode 100644
index 0000000000..2ee5591c9a
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/dev-portal-apis.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/dev-portal-auth.png b/media/articles/integrations/azure-api-mgmt/azure/dev-portal-auth.png
new file mode 100644
index 0000000000..98514f284c
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/dev-portal-auth.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/dev-portal-calculator.png b/media/articles/integrations/azure-api-mgmt/azure/dev-portal-calculator.png
new file mode 100644
index 0000000000..e2bed3de83
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/dev-portal-calculator.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/dev-portal-token.png b/media/articles/integrations/azure-api-mgmt/azure/dev-portal-token.png
new file mode 100644
index 0000000000..f8ca3e1690
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/dev-portal-token.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/dev-portal-try-it.png b/media/articles/integrations/azure-api-mgmt/azure/dev-portal-try-it.png
new file mode 100644
index 0000000000..d24800ed19
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/dev-portal-try-it.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/developer-portal.png b/media/articles/integrations/azure-api-mgmt/azure/developer-portal.png
new file mode 100644
index 0000000000..bf6830db87
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/developer-portal.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/import-api-config.png b/media/articles/integrations/azure-api-mgmt/azure/import-api-config.png
new file mode 100644
index 0000000000..e1bcb5e2ef
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/import-api-config.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/import-api.png b/media/articles/integrations/azure-api-mgmt/azure/import-api.png
new file mode 100644
index 0000000000..cf132032fd
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/import-api.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/new-oauth2-server-config.png b/media/articles/integrations/azure-api-mgmt/azure/new-oauth2-server-config.png
new file mode 100644
index 0000000000..9b70db6e26
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/new-oauth2-server-config.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/new-server-saved.png b/media/articles/integrations/azure-api-mgmt/azure/new-server-saved.png
new file mode 100644
index 0000000000..0e8e4183c5
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/new-server-saved.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/oauth2-servers.png b/media/articles/integrations/azure-api-mgmt/azure/oauth2-servers.png
new file mode 100644
index 0000000000..1e9ddcdf48
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/oauth2-servers.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/publisher-portal.png b/media/articles/integrations/azure-api-mgmt/azure/publisher-portal.png
new file mode 100644
index 0000000000..b810714adb
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/publisher-portal.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/security.png b/media/articles/integrations/azure-api-mgmt/azure/security.png
new file mode 100644
index 0000000000..21f2f6af8d
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/security.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/set-auth0-as-authserver.png b/media/articles/integrations/azure-api-mgmt/azure/set-auth0-as-authserver.png
new file mode 100644
index 0000000000..78911ccb76
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/set-auth0-as-authserver.png differ
diff --git a/media/articles/integrations/azure-api-mgmt/azure/set-callback-url.png b/media/articles/integrations/azure-api-mgmt/azure/set-callback-url.png
new file mode 100644
index 0000000000..8a2365bc89
Binary files /dev/null and b/media/articles/integrations/azure-api-mgmt/azure/set-callback-url.png differ
diff --git a/media/articles/integrations/disqus/config-confirm.png b/media/articles/integrations/disqus/config-confirm.png
new file mode 100755
index 0000000000..361944881b
Binary files /dev/null and b/media/articles/integrations/disqus/config-confirm.png differ
diff --git a/media/articles/integrations/disqus/config-settings.png b/media/articles/integrations/disqus/config-settings.png
new file mode 100755
index 0000000000..7e492f1b8e
Binary files /dev/null and b/media/articles/integrations/disqus/config-settings.png differ
diff --git a/media/articles/integrations/disqus/create-new-site.png b/media/articles/integrations/disqus/create-new-site.png
new file mode 100755
index 0000000000..253b58fb53
Binary files /dev/null and b/media/articles/integrations/disqus/create-new-site.png differ
diff --git a/media/articles/integrations/disqus/disqus-app-settings.png b/media/articles/integrations/disqus/disqus-app-settings.png
new file mode 100755
index 0000000000..e014209c54
Binary files /dev/null and b/media/articles/integrations/disqus/disqus-app-settings.png differ
diff --git a/media/articles/integrations/disqus/disqus-on-site.png b/media/articles/integrations/disqus/disqus-on-site.png
new file mode 100755
index 0000000000..cad4a758c7
Binary files /dev/null and b/media/articles/integrations/disqus/disqus-on-site.png differ
diff --git a/media/articles/integrations/disqus/platforms.png b/media/articles/integrations/disqus/platforms.png
new file mode 100755
index 0000000000..8de9f7a9dd
Binary files /dev/null and b/media/articles/integrations/disqus/platforms.png differ
diff --git a/media/articles/integrations/disqus/register-api-app.png b/media/articles/integrations/disqus/register-api-app.png
new file mode 100755
index 0000000000..fa00395850
Binary files /dev/null and b/media/articles/integrations/disqus/register-api-app.png differ
diff --git a/media/articles/integrations/disqus/register.png b/media/articles/integrations/disqus/register.png
new file mode 100755
index 0000000000..c122fd3acd
Binary files /dev/null and b/media/articles/integrations/disqus/register.png differ
diff --git a/media/articles/integrations/disqus/registered-apps.png b/media/articles/integrations/disqus/registered-apps.png
new file mode 100755
index 0000000000..f93a1dafba
Binary files /dev/null and b/media/articles/integrations/disqus/registered-apps.png differ
diff --git a/media/articles/integrations/disqus/sso-config.png b/media/articles/integrations/disqus/sso-config.png
new file mode 100755
index 0000000000..90d46d7e8d
Binary files /dev/null and b/media/articles/integrations/disqus/sso-config.png differ
diff --git a/media/articles/integrations/marketing/adobe-campaign/field-mapping.png b/media/articles/integrations/marketing/adobe-campaign/field-mapping.png
new file mode 100755
index 0000000000..f8870c81de
Binary files /dev/null and b/media/articles/integrations/marketing/adobe-campaign/field-mapping.png differ
diff --git a/media/articles/integrations/marketing/adobe-campaign/import-execution.png b/media/articles/integrations/marketing/adobe-campaign/import-execution.png
new file mode 100755
index 0000000000..0d32bd47b2
Binary files /dev/null and b/media/articles/integrations/marketing/adobe-campaign/import-execution.png differ
diff --git a/media/articles/integrations/marketing/adobe-campaign/template-selection.png b/media/articles/integrations/marketing/adobe-campaign/template-selection.png
new file mode 100755
index 0000000000..e0117b2187
Binary files /dev/null and b/media/articles/integrations/marketing/adobe-campaign/template-selection.png differ
diff --git a/media/articles/integrations/marketing/alterian/new-data-imports.png b/media/articles/integrations/marketing/alterian/new-data-imports.png
new file mode 100755
index 0000000000..f248476796
Binary files /dev/null and b/media/articles/integrations/marketing/alterian/new-data-imports.png differ
diff --git a/media/articles/integrations/marketing/import-export-fields.png b/media/articles/integrations/marketing/import-export-fields.png
new file mode 100644
index 0000000000..8675651a86
Binary files /dev/null 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
new file mode 100644
index 0000000000..e5bf75ae14
Binary files /dev/null and b/media/articles/integrations/marketing/import-export-set-format.png differ
diff --git a/media/articles/integrations/marketing/mailchimp/import-column-match.png b/media/articles/integrations/marketing/mailchimp/import-column-match.png
new file mode 100755
index 0000000000..23c36386a7
Binary files /dev/null and b/media/articles/integrations/marketing/mailchimp/import-column-match.png differ
diff --git a/media/articles/integrations/marketing/mailchimp/import-contacts.png b/media/articles/integrations/marketing/mailchimp/import-contacts.png
new file mode 100755
index 0000000000..fb364942dc
Binary files /dev/null and b/media/articles/integrations/marketing/mailchimp/import-contacts.png differ
diff --git a/media/articles/integrations/marketing/mailchimp/import-source.png b/media/articles/integrations/marketing/mailchimp/import-source.png
new file mode 100755
index 0000000000..b7a05f2e8c
Binary files /dev/null and b/media/articles/integrations/marketing/mailchimp/import-source.png differ
diff --git a/media/articles/integrations/marketing/mailchimp/import-start.png b/media/articles/integrations/marketing/mailchimp/import-start.png
new file mode 100755
index 0000000000..f192388e0d
Binary files /dev/null and b/media/articles/integrations/marketing/mailchimp/import-start.png differ
diff --git a/media/articles/integrations/office-365/office-365-app-key.png b/media/articles/integrations/office-365/office-365-app-key.png
index 2e7d3ec6e9..5f0e5eade0 100644
Binary files a/media/articles/integrations/office-365/office-365-app-key.png and b/media/articles/integrations/office-365/office-365-app-key.png differ
diff --git a/media/articles/integrations/sharepoint/sharepoint-login-page-windows-auth.png b/media/articles/integrations/sharepoint/sharepoint-login-page-windows-auth.png
new file mode 100644
index 0000000000..c6d2bebeb9
Binary files /dev/null and b/media/articles/integrations/sharepoint/sharepoint-login-page-windows-auth.png differ
diff --git a/media/articles/integrations/sharepoint/sharepoint-login-page.png b/media/articles/integrations/sharepoint/sharepoint-login-page.png
index 38b2acea3f..9a6c96db76 100644
Binary files a/media/articles/integrations/sharepoint/sharepoint-login-page.png and b/media/articles/integrations/sharepoint/sharepoint-login-page.png differ
diff --git a/media/articles/invite-only/invite-only-app.png b/media/articles/invite-only/invite-only-app.png
index 42e4b0cb04..e54f70444a 100644
Binary files a/media/articles/invite-only/invite-only-app.png and b/media/articles/invite-only/invite-only-app.png differ
diff --git a/media/articles/invite-only/invite-only-authorize-client.png b/media/articles/invite-only/invite-only-authorize-client.png
new file mode 100644
index 0000000000..6a2bbe1aec
Binary files /dev/null and b/media/articles/invite-only/invite-only-authorize-client.png differ
diff --git a/media/articles/invite-only/invite-only-connections.png b/media/articles/invite-only/invite-only-connections.png
index b6703b0577..c027087990 100644
Binary files a/media/articles/invite-only/invite-only-connections.png and b/media/articles/invite-only/invite-only-connections.png differ
diff --git a/media/articles/invite-only/invite-only-disable-email.png b/media/articles/invite-only/invite-only-disable-email.png
index ad94e1cbd7..22a3efd4da 100644
Binary files a/media/articles/invite-only/invite-only-disable-email.png and b/media/articles/invite-only/invite-only-disable-email.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/java/callback_error.png b/media/articles/java/callback_error.png
old mode 100755
new mode 100644
index f104282168..0fdd8b50ba
Binary files a/media/articles/java/callback_error.png and b/media/articles/java/callback_error.png differ
diff --git a/media/articles/java/display-token.png b/media/articles/java/display-token.png
new file mode 100644
index 0000000000..c70f4a8969
Binary files /dev/null and b/media/articles/java/display-token.png differ
diff --git a/media/articles/java/login-with-lock.png b/media/articles/java/login-with-lock.png
old mode 100755
new mode 100644
index ae9e780b3e..3bf4437f5f
Binary files a/media/articles/java/login-with-lock.png and b/media/articles/java/login-with-lock.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-android.png b/media/articles/libraries/lock-android.png
new file mode 100644
index 0000000000..bf83f60e1e
Binary files /dev/null and b/media/articles/libraries/lock-android.png differ
diff --git a/media/articles/libraries/lock-ios.png b/media/articles/libraries/lock-ios.png
new file mode 100644
index 0000000000..78890e0e80
Binary files /dev/null and b/media/articles/libraries/lock-ios.png differ
diff --git a/media/articles/libraries/lock-ios/Lock-UI-Parts.png b/media/articles/libraries/lock-ios/Lock-UI-Parts.png
new file mode 100644
index 0000000000..71fdd9bafb
Binary files /dev/null and b/media/articles/libraries/lock-ios/Lock-UI-Parts.png differ
diff --git a/media/articles/libraries/lock-ios/customization/lock_2_ui.png b/media/articles/libraries/lock-ios/customization/lock_2_ui.png
new file mode 100644
index 0000000000..8ed949a995
Binary files /dev/null and b/media/articles/libraries/lock-ios/customization/lock_2_ui.png differ
diff --git a/media/articles/libraries/lock-ios/xcode_add_language.png b/media/articles/libraries/lock-ios/xcode_add_language.png
new file mode 100644
index 0000000000..1b0813b107
Binary files /dev/null and b/media/articles/libraries/lock-ios/xcode_add_language.png differ
diff --git a/media/articles/libraries/lock-ios/xcode_add_language_step_2.png b/media/articles/libraries/lock-ios/xcode_add_language_step_2.png
new file mode 100755
index 0000000000..f3e9a421fb
Binary files /dev/null and b/media/articles/libraries/lock-ios/xcode_add_language_step_2.png differ
diff --git a/media/articles/libraries/lock-ios/xcode_localize.png b/media/articles/libraries/lock-ios/xcode_localize.png
new file mode 100644
index 0000000000..85f88a9702
Binary files /dev/null and b/media/articles/libraries/lock-ios/xcode_localize.png differ
diff --git a/media/articles/libraries/lock-ios/xcode_localize_english.png b/media/articles/libraries/lock-ios/xcode_localize_english.png
new file mode 100755
index 0000000000..dc68f512db
Binary files /dev/null and b/media/articles/libraries/lock-ios/xcode_localize_english.png differ
diff --git a/media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-default.png b/media/articles/libraries/lock-web.png
old mode 100755
new mode 100644
similarity index 100%
rename from media/articles/libraries/lock/v10/customization/lock-socialbuttonstyle-default.png
rename to media/articles/libraries/lock-web.png
diff --git a/media/articles/libraries/lock/allowed-origins.png b/media/articles/libraries/lock/allowed-origins.png
new file mode 100644
index 0000000000..ddb7655301
Binary files /dev/null and b/media/articles/libraries/lock/allowed-origins.png 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/enterprise-connection.png b/media/articles/libraries/lock/enterprise-connection.png
new file mode 100644
index 0000000000..39720f8a39
Binary files /dev/null and b/media/articles/libraries/lock/enterprise-connection.png differ
diff --git a/media/articles/libraries/lock/hrd-sso.png b/media/articles/libraries/lock/hrd-sso.png
new file mode 100755
index 0000000000..88b485aaf7
Binary files /dev/null and b/media/articles/libraries/lock/hrd-sso.png 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/lock-11-windows-authentication.png b/media/articles/libraries/lock/lock-11-windows-authentication.png
new file mode 100755
index 0000000000..2e67e3b1c0
Binary files /dev/null and b/media/articles/libraries/lock/lock-11-windows-authentication.png differ
diff --git a/media/articles/libraries/lock/migration-toggles.png b/media/articles/libraries/lock/migration-toggles.png
new file mode 100644
index 0000000000..5562a1c8c7
Binary files /dev/null and b/media/articles/libraries/lock/migration-toggles.png 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-allowshowpassword.png b/media/articles/libraries/lock/v10/customization/lock-allowshowpassword.png
new file mode 100644
index 0000000000..4ba0a50841
Binary files /dev/null and b/media/articles/libraries/lock/v10/customization/lock-allowshowpassword.png 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-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/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
new file mode 100755
index 0000000000..a0ef91b32a
Binary files /dev/null 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 100644
index b407104c13..0000000000
Binary files a/media/articles/link-accounts/spa-initial-login.png and /dev/null differ
diff --git a/media/articles/login-widget/widget-customized-reset.png b/media/articles/login-widget/widget-customized-reset.png
deleted file mode 100644
index 1defecaab9..0000000000
Binary files a/media/articles/login-widget/widget-customized-reset.png and /dev/null differ
diff --git a/media/articles/login-widget/widget-customized-signup.png b/media/articles/login-widget/widget-customized-signup.png
deleted file mode 100644
index 0dab8e2fb5..0000000000
Binary files a/media/articles/login-widget/widget-customized-signup.png and /dev/null differ
diff --git a/media/articles/login-widget/widget-customized.png b/media/articles/login-widget/widget-customized.png
deleted file mode 100644
index a6158a2241..0000000000
Binary files a/media/articles/login-widget/widget-customized.png and /dev/null differ
diff --git a/media/articles/login-widget/widget-error.png b/media/articles/login-widget/widget-error.png
deleted file mode 100644
index e34945925a..0000000000
Binary files a/media/articles/login-widget/widget-error.png and /dev/null differ
diff --git a/media/articles/login-widget/widget-numbered.png b/media/articles/login-widget/widget-numbered.png
deleted file mode 100644
index cee4162a7d..0000000000
Binary files a/media/articles/login-widget/widget-numbered.png and /dev/null differ
diff --git a/media/articles/login-widget2/9AfFb-pbwm.png b/media/articles/login-widget2/9AfFb-pbwm.png
deleted file mode 100644
index d4b60926d7..0000000000
Binary files a/media/articles/login-widget2/9AfFb-pbwm.png and /dev/null differ
diff --git a/media/articles/login-widget2/W9rpHdyIwf.png b/media/articles/login-widget2/W9rpHdyIwf.png
deleted file mode 100644
index 7ffff5014c..0000000000
Binary files a/media/articles/login-widget2/W9rpHdyIwf.png and /dev/null differ
diff --git a/media/articles/login-widget2/y2iG3mE8Ll.png b/media/articles/login-widget2/y2iG3mE8Ll.png
deleted file mode 100644
index 2d99fee638..0000000000
Binary files a/media/articles/login-widget2/y2iG3mE8Ll.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/account-level-logout.png b/media/articles/logout/account-level-logout.png
index 2daf466d49..6163f7db13 100644
Binary files a/media/articles/logout/account-level-logout.png and b/media/articles/logout/account-level-logout.png differ
diff --git a/media/articles/logout/app-level-logout.png b/media/articles/logout/app-level-logout.png
deleted file mode 100644
index 023775c15a..0000000000
Binary files a/media/articles/logout/app-level-logout.png and /dev/null differ
diff --git a/media/articles/logout/client-level-logout.png b/media/articles/logout/client-level-logout.png
new file mode 100644
index 0000000000..fa63043b82
Binary files /dev/null and b/media/articles/logout/client-level-logout.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/logout/tenant-level-logout.png b/media/articles/logout/tenant-level-logout.png
new file mode 100755
index 0000000000..18251aa398
Binary files /dev/null and b/media/articles/logout/tenant-level-logout.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 44095498ac..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/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 febb82a3d5..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 95284777da..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-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/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/reset-mfa.png b/media/articles/mfa/reset-mfa.png
old mode 100644
new mode 100755
index ee730bac68..ed197ab58f
Binary files a/media/articles/mfa/reset-mfa.png and b/media/articles/mfa/reset-mfa.png 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 965d55e5e2..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/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
new file mode 100644
index 0000000000..4872733e1e
Binary files /dev/null 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
new file mode 100644
index 0000000000..1849261efb
Binary files /dev/null and b/media/articles/migrations/node-runtime2.png differ
diff --git a/media/articles/monitoring/segment/segment-14.png b/media/articles/monitoring/segment/segment-14.png
new file mode 100644
index 0000000000..928d846227
Binary files /dev/null and b/media/articles/monitoring/segment/segment-14.png differ
diff --git a/media/articles/monitoring/segment/segment-3.png b/media/articles/monitoring/segment/segment-3.png
new file mode 100644
index 0000000000..d28ad763c4
Binary files /dev/null and b/media/articles/monitoring/segment/segment-3.png differ
diff --git a/media/articles/monitoring/segment/segment-io-dataflow.png b/media/articles/monitoring/segment/segment-io-dataflow.png
new file mode 100644
index 0000000000..3654c71091
Binary files /dev/null and b/media/articles/monitoring/segment/segment-io-dataflow.png differ
diff --git a/media/articles/native-platforms/android/login-android.png b/media/articles/native-platforms/android/login-android.png
new file mode 100644
index 0000000000..7eb0456117
Binary files /dev/null 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_2_login.png b/media/articles/native-platforms/ios-swift/lock_2_login.png
new file mode 100644
index 0000000000..78890e0e80
Binary files /dev/null and b/media/articles/native-platforms/ios-swift/lock_2_login.png differ
diff --git a/media/articles/native-platforms/ios-swift/lock_2_style.png b/media/articles/native-platforms/ios-swift/lock_2_style.png
new file mode 100644
index 0000000000..7e592028f2
Binary files /dev/null and b/media/articles/native-platforms/ios-swift/lock_2_style.png 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/legacy/lock-widget-screenshot.png
similarity index 100%
rename from media/articles/native-platforms/windows-uwp-csharp/lock-widget-screenshot.png
rename to media/articles/native-platforms/windows-uwp-csharp/legacy/lock-widget-screenshot.png
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/windows-uwp-javascript/lock-widget-screenshot.png b/media/articles/native-platforms/windows-uwp-javascript/lock-widget-screenshot.png
deleted file mode 100644
index 0785e72af8..0000000000
Binary files a/media/articles/native-platforms/windows-uwp-javascript/lock-widget-screenshot.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 23388d5ced..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/xamarin.auth0client.png b/media/articles/native-platforms/xamarin/xamarin.auth0client.png
deleted file mode 100644
index f3b1863bb0..0000000000
Binary files a/media/articles/native-platforms/xamarin/xamarin.auth0client.png and /dev/null differ
diff --git a/media/articles/oidc/identity-providers/okta/config-info.png b/media/articles/oidc/identity-providers/okta/config-info.png
new file mode 100755
index 0000000000..2f91e97a7b
Binary files /dev/null and b/media/articles/oidc/identity-providers/okta/config-info.png differ
diff --git a/media/articles/oidc/identity-providers/okta/create-new-app.png b/media/articles/oidc/identity-providers/okta/create-new-app.png
new file mode 100755
index 0000000000..3414b02d4b
Binary files /dev/null and b/media/articles/oidc/identity-providers/okta/create-new-app.png differ
diff --git a/media/articles/oidc/identity-providers/okta/extensions.png b/media/articles/oidc/identity-providers/okta/extensions.png
new file mode 100755
index 0000000000..e5cd9fa7b9
Binary files /dev/null and b/media/articles/oidc/identity-providers/okta/extensions.png differ
diff --git a/media/articles/oidc/identity-providers/okta/new-app-integration.png b/media/articles/oidc/identity-providers/okta/new-app-integration.png
new file mode 100755
index 0000000000..bea35c2964
Binary files /dev/null and b/media/articles/oidc/identity-providers/okta/new-app-integration.png differ
diff --git a/media/articles/oidc/identity-providers/okta/oidc-general-settings.png b/media/articles/oidc/identity-providers/okta/oidc-general-settings.png
new file mode 100755
index 0000000000..b4b91637c0
Binary files /dev/null and b/media/articles/oidc/identity-providers/okta/oidc-general-settings.png differ
diff --git a/media/articles/oidc/identity-providers/okta/oidc-settings.png b/media/articles/oidc/identity-providers/okta/oidc-settings.png
new file mode 100755
index 0000000000..ced8ed3b22
Binary files /dev/null and b/media/articles/oidc/identity-providers/okta/oidc-settings.png differ
diff --git a/media/articles/oidc/identity-providers/okta/okta-admin-dashboard.png b/media/articles/oidc/identity-providers/okta/okta-admin-dashboard.png
new file mode 100755
index 0000000000..74379e255e
Binary files /dev/null and b/media/articles/oidc/identity-providers/okta/okta-admin-dashboard.png differ
diff --git a/media/articles/oidc/identity-providers/okta/okta-app-dashboard.png b/media/articles/oidc/identity-providers/okta/okta-app-dashboard.png
new file mode 100755
index 0000000000..c5df1bad06
Binary files /dev/null and b/media/articles/oidc/identity-providers/okta/okta-app-dashboard.png differ
diff --git a/media/articles/oidc/identity-providers/okta/okta-create-app-platform.png b/media/articles/oidc/identity-providers/okta/okta-create-app-platform.png
new file mode 100755
index 0000000000..6f928110e0
Binary files /dev/null and b/media/articles/oidc/identity-providers/okta/okta-create-app-platform.png differ
diff --git a/media/articles/oidc/identity-providers/okta/okta-create-app-settings.png b/media/articles/oidc/identity-providers/okta/okta-create-app-settings.png
new file mode 100755
index 0000000000..890ae1f892
Binary files /dev/null and b/media/articles/oidc/identity-providers/okta/okta-create-app-settings.png differ
diff --git a/media/articles/oidc/identity-providers/okta/okta-dashboard-api-menu.png b/media/articles/oidc/identity-providers/okta/okta-dashboard-api-menu.png
new file mode 100755
index 0000000000..e1a642a09c
Binary files /dev/null and b/media/articles/oidc/identity-providers/okta/okta-dashboard-api-menu.png differ
diff --git a/media/articles/oidc/identity-providers/okta/okta-dashboard.png b/media/articles/oidc/identity-providers/okta/okta-dashboard.png
new file mode 100755
index 0000000000..281d638a45
Binary files /dev/null and b/media/articles/oidc/identity-providers/okta/okta-dashboard.png differ
diff --git a/media/articles/overview/overview.png b/media/articles/overview/overview.png
deleted file mode 100755
index dde3732450..0000000000
Binary files a/media/articles/overview/overview.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/CSRF_Diagram.png b/media/articles/protocols/CSRF_Diagram.png
new file mode 100644
index 0000000000..23a4715a2c
Binary files /dev/null and b/media/articles/protocols/CSRF_Diagram.png differ
diff --git a/media/articles/protocols/create-adfs-connection.png b/media/articles/protocols/create-adfs-connection.png
new file mode 100644
index 0000000000..af38915c80
Binary files /dev/null and b/media/articles/protocols/create-adfs-connection.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-adfs/saml1.png b/media/articles/protocols/saml-adfs/saml1.png
new file mode 100644
index 0000000000..574e6a53b0
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml1.png differ
diff --git a/media/articles/protocols/saml-adfs/saml10.png b/media/articles/protocols/saml-adfs/saml10.png
new file mode 100644
index 0000000000..31c8297e5d
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml10.png differ
diff --git a/media/articles/protocols/saml-adfs/saml11.png b/media/articles/protocols/saml-adfs/saml11.png
new file mode 100644
index 0000000000..15bdbf107f
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml11.png differ
diff --git a/media/articles/protocols/saml-adfs/saml12.png b/media/articles/protocols/saml-adfs/saml12.png
new file mode 100644
index 0000000000..f184d01ba8
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml12.png differ
diff --git a/media/articles/protocols/saml-adfs/saml13.png b/media/articles/protocols/saml-adfs/saml13.png
new file mode 100644
index 0000000000..80a4dfb72a
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml13.png differ
diff --git a/media/articles/protocols/saml-adfs/saml14.png b/media/articles/protocols/saml-adfs/saml14.png
new file mode 100644
index 0000000000..940c7612c2
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml14.png differ
diff --git a/media/articles/protocols/saml-adfs/saml15.png b/media/articles/protocols/saml-adfs/saml15.png
new file mode 100644
index 0000000000..3a4c824417
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml15.png differ
diff --git a/media/articles/protocols/saml-adfs/saml16.png b/media/articles/protocols/saml-adfs/saml16.png
new file mode 100644
index 0000000000..5371b6e551
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml16.png differ
diff --git a/media/articles/protocols/saml-adfs/saml17.png b/media/articles/protocols/saml-adfs/saml17.png
new file mode 100644
index 0000000000..3b1922fe64
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml17.png differ
diff --git a/media/articles/protocols/saml-adfs/saml18.png b/media/articles/protocols/saml-adfs/saml18.png
new file mode 100644
index 0000000000..57ba64f9c8
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml18.png differ
diff --git a/media/articles/protocols/saml-adfs/saml19.png b/media/articles/protocols/saml-adfs/saml19.png
new file mode 100644
index 0000000000..0f527056fd
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml19.png differ
diff --git a/media/articles/protocols/saml-adfs/saml2.png b/media/articles/protocols/saml-adfs/saml2.png
new file mode 100644
index 0000000000..ac3cd31caa
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml2.png differ
diff --git a/media/articles/protocols/saml-adfs/saml20.png b/media/articles/protocols/saml-adfs/saml20.png
new file mode 100644
index 0000000000..de36a3960a
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml20.png differ
diff --git a/media/articles/protocols/saml-adfs/saml21.png b/media/articles/protocols/saml-adfs/saml21.png
new file mode 100755
index 0000000000..a1df2d9a04
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml21.png differ
diff --git a/media/articles/protocols/saml-adfs/saml22.png b/media/articles/protocols/saml-adfs/saml22.png
new file mode 100644
index 0000000000..314efe4027
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml22.png differ
diff --git a/media/articles/protocols/saml-adfs/saml23.png b/media/articles/protocols/saml-adfs/saml23.png
new file mode 100644
index 0000000000..602d34ce4b
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml23.png differ
diff --git a/media/articles/protocols/saml-adfs/saml24.png b/media/articles/protocols/saml-adfs/saml24.png
new file mode 100644
index 0000000000..5abb5aa9db
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml24.png differ
diff --git a/media/articles/protocols/saml-adfs/saml25.png b/media/articles/protocols/saml-adfs/saml25.png
new file mode 100644
index 0000000000..1cea69f385
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml25.png differ
diff --git a/media/articles/protocols/saml-adfs/saml3.png b/media/articles/protocols/saml-adfs/saml3.png
new file mode 100644
index 0000000000..8c84c2ec69
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml3.png differ
diff --git a/media/articles/protocols/saml-adfs/saml4.png b/media/articles/protocols/saml-adfs/saml4.png
new file mode 100644
index 0000000000..7dd045054d
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml4.png differ
diff --git a/media/articles/protocols/saml-adfs/saml5.png b/media/articles/protocols/saml-adfs/saml5.png
new file mode 100644
index 0000000000..147419d4f0
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml5.png differ
diff --git a/media/articles/protocols/saml-adfs/saml6.png b/media/articles/protocols/saml-adfs/saml6.png
new file mode 100644
index 0000000000..3bf58d115a
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml6.png differ
diff --git a/media/articles/protocols/saml-adfs/saml7.png b/media/articles/protocols/saml-adfs/saml7.png
new file mode 100644
index 0000000000..f168502a73
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml7.png differ
diff --git a/media/articles/protocols/saml-adfs/saml8.png b/media/articles/protocols/saml-adfs/saml8.png
new file mode 100644
index 0000000000..d7c5780f66
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml8.png differ
diff --git a/media/articles/protocols/saml-adfs/saml9.png b/media/articles/protocols/saml-adfs/saml9.png
new file mode 100644
index 0000000000..219611fa49
Binary files /dev/null and b/media/articles/protocols/saml-adfs/saml9.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/protocols/saml/idp-init-sso.png b/media/articles/protocols/saml/idp-init-sso.png
new file mode 100644
index 0000000000..b99030b069
Binary files /dev/null and b/media/articles/protocols/saml/idp-init-sso.png differ
diff --git a/media/articles/protocols/saml/saml-configuration/add-ons.png b/media/articles/protocols/saml/saml-configuration/add-ons.png
new file mode 100644
index 0000000000..dc86199eba
Binary files /dev/null and b/media/articles/protocols/saml/saml-configuration/add-ons.png differ
diff --git a/media/articles/protocols/saml/saml-configuration/check-connection-settings.png b/media/articles/protocols/saml/saml-configuration/check-connection-settings.png
new file mode 100644
index 0000000000..b563a77aef
Binary files /dev/null and b/media/articles/protocols/saml/saml-configuration/check-connection-settings.png differ
diff --git a/media/articles/protocols/saml/saml-configuration/clients.png b/media/articles/protocols/saml/saml-configuration/clients.png
new file mode 100644
index 0000000000..2ddc47b31e
Binary files /dev/null and b/media/articles/protocols/saml/saml-configuration/clients.png differ
diff --git a/media/articles/protocols/saml/saml-configuration/configure-app.png b/media/articles/protocols/saml/saml-configuration/configure-app.png
new file mode 100644
index 0000000000..c511ca92de
Binary files /dev/null and b/media/articles/protocols/saml/saml-configuration/configure-app.png differ
diff --git a/media/articles/protocols/saml/saml-configuration/debug-connection.png b/media/articles/protocols/saml/saml-configuration/debug-connection.png
new file mode 100644
index 0000000000..dae62b4886
Binary files /dev/null and b/media/articles/protocols/saml/saml-configuration/debug-connection.png differ
diff --git a/media/articles/protocols/saml/saml-configuration/mappings.png b/media/articles/protocols/saml/saml-configuration/mappings.png
new file mode 100644
index 0000000000..273acd64a0
Binary files /dev/null and b/media/articles/protocols/saml/saml-configuration/mappings.png differ
diff --git a/media/articles/protocols/saml/saml-configuration/name-sso-integration.png b/media/articles/protocols/saml/saml-configuration/name-sso-integration.png
new file mode 100644
index 0000000000..a6a80d7dfc
Binary files /dev/null and b/media/articles/protocols/saml/saml-configuration/name-sso-integration.png differ
diff --git a/media/articles/protocols/saml/saml-configuration/saml-rules.png b/media/articles/protocols/saml/saml-configuration/saml-rules.png
new file mode 100644
index 0000000000..aec7f4c1de
Binary files /dev/null and b/media/articles/protocols/saml/saml-configuration/saml-rules.png differ
diff --git a/media/articles/protocols/saml/saml-configuration/sso-integrations-supported.png b/media/articles/protocols/saml/saml-configuration/sso-integrations-supported.png
new file mode 100644
index 0000000000..5db5847a9d
Binary files /dev/null and b/media/articles/protocols/saml/saml-configuration/sso-integrations-supported.png differ
diff --git a/media/articles/protocols/saml/saml-configuration/sso-integrations.png b/media/articles/protocols/saml/saml-configuration/sso-integrations.png
new file mode 100644
index 0000000000..ef2917a8fa
Binary files /dev/null and b/media/articles/protocols/saml/saml-configuration/sso-integrations.png differ
diff --git a/media/articles/protocols/saml/saml-configuration/test-connection.png b/media/articles/protocols/saml/saml-configuration/test-connection.png
new file mode 100644
index 0000000000..a3ffa21d55
Binary files /dev/null and b/media/articles/protocols/saml/saml-configuration/test-connection.png differ
diff --git a/media/articles/protocols/saml/saml2-web-app/configure-addon.png b/media/articles/protocols/saml/saml2-web-app/configure-addon.png
new file mode 100644
index 0000000000..cd1ae93653
Binary files /dev/null and b/media/articles/protocols/saml/saml2-web-app/configure-addon.png differ
diff --git a/media/articles/protocols/saml/saml2-web-app/mgmt-dshbrd-clients.png b/media/articles/protocols/saml/saml2-web-app/mgmt-dshbrd-clients.png
new file mode 100644
index 0000000000..6492ab9805
Binary files /dev/null and b/media/articles/protocols/saml/saml2-web-app/mgmt-dshbrd-clients.png differ
diff --git a/media/articles/protocols/saml/saml2-web-app/select-addon.png b/media/articles/protocols/saml/saml2-web-app/select-addon.png
new file mode 100644
index 0000000000..dda9687871
Binary files /dev/null and b/media/articles/protocols/saml/saml2-web-app/select-addon.png differ
diff --git a/media/articles/protocols/saml/saml2-web-app/usage.png b/media/articles/protocols/saml/saml2-web-app/usage.png
new file mode 100644
index 0000000000..47642f3804
Binary files /dev/null and b/media/articles/protocols/saml/saml2-web-app/usage.png differ
diff --git a/media/articles/protocols/ws-fed-endpoints.png b/media/articles/protocols/ws-fed-endpoints.png
new file mode 100644
index 0000000000..fccea976e3
Binary files /dev/null and b/media/articles/protocols/ws-fed-endpoints.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/flow.png b/media/articles/rules/flow.png
index 5832e93085..7c4160daf2 100644
Binary files a/media/articles/rules/flow.png and b/media/articles/rules/flow.png differ
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/rules/rules-configuration.png b/media/articles/rules/rules-configuration.png
new file mode 100644
index 0000000000..ea384f8c0d
Binary files /dev/null and b/media/articles/rules/rules-configuration.png differ
diff --git a/media/articles/saml/identity-providers/okta/okta-1.png b/media/articles/saml/identity-providers/okta/okta-1.png
deleted file mode 100644
index 351a691e08..0000000000
Binary files a/media/articles/saml/identity-providers/okta/okta-1.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/okta-2.png b/media/articles/saml/identity-providers/okta/okta-2.png
deleted file mode 100644
index c272bd22d0..0000000000
Binary files a/media/articles/saml/identity-providers/okta/okta-2.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/okta-3.png b/media/articles/saml/identity-providers/okta/okta-3.png
deleted file mode 100644
index 8e4602edb2..0000000000
Binary files a/media/articles/saml/identity-providers/okta/okta-3.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/okta-4.png b/media/articles/saml/identity-providers/okta/okta-4.png
deleted file mode 100644
index 72eb6aaa7e..0000000000
Binary files a/media/articles/saml/identity-providers/okta/okta-4.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/okta-5.png b/media/articles/saml/identity-providers/okta/okta-5.png
deleted file mode 100644
index c0ce605c7b..0000000000
Binary files a/media/articles/saml/identity-providers/okta/okta-5.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/okta-6.png b/media/articles/saml/identity-providers/okta/okta-6.png
deleted file mode 100644
index e177712d4d..0000000000
Binary files a/media/articles/saml/identity-providers/okta/okta-6.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/okta-7.png b/media/articles/saml/identity-providers/okta/okta-7.png
deleted file mode 100644
index 167de5715a..0000000000
Binary files a/media/articles/saml/identity-providers/okta/okta-7.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/okta-8.png b/media/articles/saml/identity-providers/okta/okta-8.png
deleted file mode 100644
index 70c0c8e5a2..0000000000
Binary files a/media/articles/saml/identity-providers/okta/okta-8.png and /dev/null differ
diff --git a/media/articles/saml/identity-providers/okta/okta-9.png b/media/articles/saml/identity-providers/okta/okta-9.png
deleted file mode 100644
index 4f2b666083..0000000000
Binary files a/media/articles/saml/identity-providers/okta/okta-9.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/saml/saml-apps/heroku/auth0-dashboard-saml-usage.png b/media/articles/saml/saml-apps/heroku/auth0-dashboard-saml-usage.png
old mode 100755
new mode 100644
index e447dd19cb..cbee2eb639
Binary files a/media/articles/saml/saml-apps/heroku/auth0-dashboard-saml-usage.png and b/media/articles/saml/saml-apps/heroku/auth0-dashboard-saml-usage.png differ
diff --git a/media/articles/saml/saml-apps/heroku/auth0-dashboard-saml.png b/media/articles/saml/saml-apps/heroku/auth0-dashboard-saml.png
old mode 100755
new mode 100644
index f15eefdb11..c9808608c1
Binary files a/media/articles/saml/saml-apps/heroku/auth0-dashboard-saml.png and b/media/articles/saml/saml-apps/heroku/auth0-dashboard-saml.png differ
diff --git a/media/articles/saml/saml-apps/heroku/auth0-dashboard.png b/media/articles/saml/saml-apps/heroku/auth0-dashboard.png
old mode 100755
new mode 100644
index 680eefb8ac..566ff2f1bd
Binary files a/media/articles/saml/saml-apps/heroku/auth0-dashboard.png and b/media/articles/saml/saml-apps/heroku/auth0-dashboard.png differ
diff --git a/media/articles/saml/saml-apps/heroku/heroku-dashboard-metadata.png b/media/articles/saml/saml-apps/heroku/heroku-dashboard-metadata.png
deleted file mode 100755
index 2195d9099a..0000000000
Binary files a/media/articles/saml/saml-apps/heroku/heroku-dashboard-metadata.png and /dev/null differ
diff --git a/media/articles/saml/saml-apps/heroku/heroku-dashboard.png b/media/articles/saml/saml-apps/heroku/heroku-dashboard.png
old mode 100755
new mode 100644
index 1722f44132..1aaf9d6ad4
Binary files a/media/articles/saml/saml-apps/heroku/heroku-dashboard.png and b/media/articles/saml/saml-apps/heroku/heroku-dashboard.png differ
diff --git a/media/articles/saml/saml-configuration/saml-case1.png b/media/articles/saml/saml-configuration/saml-case1.png
index 22e5bbd441..17d6b1eadf 100644
Binary files a/media/articles/saml/saml-configuration/saml-case1.png and b/media/articles/saml/saml-configuration/saml-case1.png differ
diff --git a/media/articles/saml/saml-configuration/saml-case2.png b/media/articles/saml/saml-configuration/saml-case2.png
index 9b93381edb..62d662a443 100644
Binary files a/media/articles/saml/saml-configuration/saml-case2.png and b/media/articles/saml/saml-configuration/saml-case2.png differ
diff --git a/media/articles/saml/saml-configuration/saml-case3.png b/media/articles/saml/saml-configuration/saml-case3.png
index 43fc7add35..dda68c187a 100644
Binary files a/media/articles/saml/saml-configuration/saml-case3.png and b/media/articles/saml/saml-configuration/saml-case3.png differ
diff --git a/media/articles/scenarios/amazon-cognito/CognitoSample.gif b/media/articles/scenarios/amazon-cognito/CognitoSample.gif
deleted file mode 100644
index 167af0f739..0000000000
Binary files a/media/articles/scenarios/amazon-cognito/CognitoSample.gif and /dev/null differ
diff --git a/media/articles/scenarios/amazon-cognito/IDPCognito.gif b/media/articles/scenarios/amazon-cognito/IDPCognito.gif
deleted file mode 100644
index 0a9405de43..0000000000
Binary files a/media/articles/scenarios/amazon-cognito/IDPCognito.gif and /dev/null differ
diff --git a/media/articles/scenarios/amazon-cognito/IDPCreation.gif b/media/articles/scenarios/amazon-cognito/IDPCreation.gif
deleted file mode 100644
index 2bba857aa8..0000000000
Binary files a/media/articles/scenarios/amazon-cognito/IDPCreation.gif and /dev/null differ
diff --git a/media/articles/scenarios/amazon-cognito/Roles.gif b/media/articles/scenarios/amazon-cognito/Roles.gif
deleted file mode 100644
index 7a54cd0410..0000000000
Binary files a/media/articles/scenarios/amazon-cognito/Roles.gif and /dev/null differ
diff --git a/media/articles/scenarios/amazon-cognito/allow-role.png b/media/articles/scenarios/amazon-cognito/allow-role.png
new file mode 100755
index 0000000000..c7a45d33fc
Binary files /dev/null and b/media/articles/scenarios/amazon-cognito/allow-role.png differ
diff --git a/media/articles/scenarios/amazon-cognito/cdn-amazon-cognito-rs256.png b/media/articles/scenarios/amazon-cognito/cdn-amazon-cognito-rs256.png
deleted file mode 100644
index 9fc80cec2a..0000000000
Binary files a/media/articles/scenarios/amazon-cognito/cdn-amazon-cognito-rs256.png and /dev/null differ
diff --git a/media/articles/scenarios/amazon-cognito/configure-provider.png b/media/articles/scenarios/amazon-cognito/configure-provider.png
new file mode 100755
index 0000000000..a7fc91ba86
Binary files /dev/null and b/media/articles/scenarios/amazon-cognito/configure-provider.png differ
diff --git a/media/articles/scenarios/amazon-cognito/create-provider.png b/media/articles/scenarios/amazon-cognito/create-provider.png
new file mode 100755
index 0000000000..529f88079e
Binary files /dev/null and b/media/articles/scenarios/amazon-cognito/create-provider.png differ
diff --git a/media/articles/scenarios/amazon-cognito/identity-pool.png b/media/articles/scenarios/amazon-cognito/identity-pool.png
new file mode 100755
index 0000000000..3a02ea9812
Binary files /dev/null and b/media/articles/scenarios/amazon-cognito/identity-pool.png differ
diff --git a/media/articles/scenarios/amazon-cognito/jwt-algorithm.png b/media/articles/scenarios/amazon-cognito/jwt-algorithm.png
new file mode 100755
index 0000000000..57328e28ea
Binary files /dev/null and b/media/articles/scenarios/amazon-cognito/jwt-algorithm.png differ
diff --git a/media/articles/scenarios/amazon-cognito/pool-id.png b/media/articles/scenarios/amazon-cognito/pool-id.png
new file mode 100755
index 0000000000..f2547ea6bc
Binary files /dev/null and b/media/articles/scenarios/amazon-cognito/pool-id.png differ
diff --git a/media/articles/scenarios/amazon-cognito/role-arn.png b/media/articles/scenarios/amazon-cognito/role-arn.png
new file mode 100755
index 0000000000..9be9b8ef77
Binary files /dev/null and b/media/articles/scenarios/amazon-cognito/role-arn.png differ
diff --git a/media/articles/scenarios/amazon-cognito/verify-provider.png b/media/articles/scenarios/amazon-cognito/verify-provider.png
new file mode 100755
index 0000000000..287679d073
Binary files /dev/null and b/media/articles/scenarios/amazon-cognito/verify-provider.png 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/scenarios/multi-tenant-saas-azure-ad/azure-ad-mt-single-tenant-example.png b/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-ad-mt-single-tenant-example.png
index 5425910611..53742fcc8b 100644
Binary files a/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-ad-mt-single-tenant-example.png and b/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-ad-mt-single-tenant-example.png differ
diff --git a/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-ad-multi-tenant-example.png b/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-ad-multi-tenant-example.png
index c3254de40d..dff639c2f9 100644
Binary files a/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-ad-multi-tenant-example.png and b/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-ad-multi-tenant-example.png differ
diff --git a/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-conn-comm-endpoint.png b/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-conn-comm-endpoint.png
deleted file mode 100644
index 2ba74a9a7c..0000000000
Binary files a/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-conn-comm-endpoint.png and /dev/null differ
diff --git a/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-consent-page.png b/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-consent-page.png
index fa2a12a314..560540176c 100644
Binary files a/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-consent-page.png and b/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-consent-page.png differ
diff --git a/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-login-popup.png b/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-login-popup.png
index 6905f3bfd5..e468790d30 100644
Binary files a/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-login-popup.png and b/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-login-popup.png differ
diff --git a/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-new-conn.png b/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-new-conn.png
index 5ce102b7e2..077b49f74a 100644
Binary files a/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-new-conn.png and b/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-new-conn.png differ
diff --git a/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-profile.png b/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-profile.png
index d1ddaec251..27a13719aa 100644
Binary files a/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-profile.png and b/media/articles/scenarios/multi-tenant-saas-azure-ad/azure-mt-profile.png differ
diff --git a/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-app-config.png b/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-app-config.png
index 84270be1bc..538dd5eb0e 100644
Binary files a/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-app-config.png and b/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-app-config.png differ
diff --git a/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-app-perm.png b/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-app-perm.png
index adaf95486d..6d441ef3d7 100644
Binary files a/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-app-perm.png and b/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-app-perm.png differ
diff --git a/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-app-perm2.png b/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-app-perm2.png
new file mode 100644
index 0000000000..c8b5e850bb
Binary files /dev/null and b/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-app-perm2.png differ
diff --git a/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-create-directory.png b/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-create-directory.png
index 92588969cc..dcd7b5b8da 100644
Binary files a/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-create-directory.png and b/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-create-directory.png differ
diff --git a/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-domain-name.png b/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-domain-name.png
index 77554cdc5a..f8ae85de69 100644
Binary files a/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-domain-name.png and b/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-domain-name.png differ
diff --git a/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-domain-verified.png b/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-domain-verified.png
index 21212f5d0a..d00b8643e7 100644
Binary files a/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-domain-verified.png and b/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-domain-verified.png differ
diff --git a/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-new-a0-app.png b/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-new-a0-app.png
index f75de16537..537f73aa03 100644
Binary files a/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-new-a0-app.png and b/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-new-a0-app.png differ
diff --git a/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-new-app-name.png b/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-new-app-name.png
index 8d7ef2d495..065ed2bed7 100644
Binary files a/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-new-app-name.png and b/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-new-app-name.png differ
diff --git a/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-new-app-prop.png b/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-new-app-prop.png
index cca54c28ae..18a1a0a750 100644
Binary files a/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-new-app-prop.png and b/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-new-app-prop.png differ
diff --git a/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-new-app.png b/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-new-app.png
index 5992514e65..16916e0b86 100644
Binary files a/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-new-app.png and b/media/articles/scenarios/multi-tenant-saas-azure-ad/azuread-mt-new-app.png differ
diff --git a/media/articles/scopes/api-scopes.png b/media/articles/scopes/api-scopes.png
new file mode 100644
index 0000000000..b5b7f35a35
Binary files /dev/null and b/media/articles/scopes/api-scopes.png differ
diff --git a/media/articles/server-apis/aspnet-core-webapi/jwt-io-debugger-hs256.png b/media/articles/server-apis/aspnet-core-webapi/jwt-io-debugger-hs256.png
new file mode 100644
index 0000000000..8e9ee26ca6
Binary files /dev/null and b/media/articles/server-apis/aspnet-core-webapi/jwt-io-debugger-hs256.png differ
diff --git a/media/articles/server-apis/aspnet-core-webapi/jwt-io-debugger-rs256.png b/media/articles/server-apis/aspnet-core-webapi/jwt-io-debugger-rs256.png
new file mode 100644
index 0000000000..75a33db09b
Binary files /dev/null and b/media/articles/server-apis/aspnet-core-webapi/jwt-io-debugger-rs256.png differ
diff --git a/media/articles/server-apis/aspnet-core-webapi/troubleshoot-audience-validation-failed.png b/media/articles/server-apis/aspnet-core-webapi/troubleshoot-audience-validation-failed.png
new file mode 100644
index 0000000000..7658f3d143
Binary files /dev/null and b/media/articles/server-apis/aspnet-core-webapi/troubleshoot-audience-validation-failed.png differ
diff --git a/media/articles/server-apis/aspnet-core-webapi/troubleshoot-issuer-validation-failed.png b/media/articles/server-apis/aspnet-core-webapi/troubleshoot-issuer-validation-failed.png
new file mode 100644
index 0000000000..8d8f9364e2
Binary files /dev/null and b/media/articles/server-apis/aspnet-core-webapi/troubleshoot-issuer-validation-failed.png differ
diff --git a/media/articles/server-apis/aspnet-core-webapi/troubleshoot-no-authorization-header.png b/media/articles/server-apis/aspnet-core-webapi/troubleshoot-no-authorization-header.png
new file mode 100644
index 0000000000..8dea45de5c
Binary files /dev/null and b/media/articles/server-apis/aspnet-core-webapi/troubleshoot-no-authorization-header.png differ
diff --git a/media/articles/server-apis/aspnet-core-webapi/troubleshoot-token-expired.png b/media/articles/server-apis/aspnet-core-webapi/troubleshoot-token-expired.png
new file mode 100644
index 0000000000..fac1594f39
Binary files /dev/null and b/media/articles/server-apis/aspnet-core-webapi/troubleshoot-token-expired.png differ
diff --git a/media/articles/server-apis/aspnet-core-webapi/troubleshoot-wrong-signature-hs256.png b/media/articles/server-apis/aspnet-core-webapi/troubleshoot-wrong-signature-hs256.png
new file mode 100644
index 0000000000..46fb24edcf
Binary files /dev/null and b/media/articles/server-apis/aspnet-core-webapi/troubleshoot-wrong-signature-hs256.png differ
diff --git a/media/articles/server-apis/aspnet-core-webapi/troubleshoot-wrong-signature-rs256.png b/media/articles/server-apis/aspnet-core-webapi/troubleshoot-wrong-signature-rs256.png
new file mode 100644
index 0000000000..caa2a0a55a
Binary files /dev/null and b/media/articles/server-apis/aspnet-core-webapi/troubleshoot-wrong-signature-rs256.png 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/create-api.png b/media/articles/server-apis/create-api.png
new file mode 100644
index 0000000000..bad32c1053
Binary files /dev/null and b/media/articles/server-apis/create-api.png differ
diff --git a/media/articles/server-apis/java-spring-security/add-api-scopes.png b/media/articles/server-apis/java-spring-security/add-api-scopes.png
new file mode 100644
index 0000000000..506ab524c7
Binary files /dev/null and b/media/articles/server-apis/java-spring-security/add-api-scopes.png differ
diff --git a/media/articles/server-apis/using/private-scoped-forbidden.png b/media/articles/server-apis/using/private-scoped-forbidden.png
new file mode 100644
index 0000000000..4ae201b42b
Binary files /dev/null and b/media/articles/server-apis/using/private-scoped-forbidden.png differ
diff --git a/media/articles/server-apis/using/private-scoped.png b/media/articles/server-apis/using/private-scoped.png
new file mode 100644
index 0000000000..26f2a23955
Binary files /dev/null and b/media/articles/server-apis/using/private-scoped.png differ
diff --git a/media/articles/server-apis/using/private-unauthorized.png b/media/articles/server-apis/using/private-unauthorized.png
new file mode 100644
index 0000000000..c760464736
Binary files /dev/null and b/media/articles/server-apis/using/private-unauthorized.png differ
diff --git a/media/articles/server-apis/using/private.png b/media/articles/server-apis/using/private.png
new file mode 100644
index 0000000000..9a6ce92d4f
Binary files /dev/null and b/media/articles/server-apis/using/private.png differ
diff --git a/media/articles/server-apis/webapi-owin/request-access-token.png b/media/articles/server-apis/webapi-owin/request-access-token.png
new file mode 100644
index 0000000000..46eef6161d
Binary files /dev/null and b/media/articles/server-apis/webapi-owin/request-access-token.png differ
diff --git a/media/articles/server-apis/webapi-owin/troubleshoot-audience-validation-failed.png b/media/articles/server-apis/webapi-owin/troubleshoot-audience-validation-failed.png
new file mode 100644
index 0000000000..3a2aef1293
Binary files /dev/null and b/media/articles/server-apis/webapi-owin/troubleshoot-audience-validation-failed.png differ
diff --git a/media/articles/server-apis/webapi-owin/troubleshoot-issuer-validation-failed.png b/media/articles/server-apis/webapi-owin/troubleshoot-issuer-validation-failed.png
new file mode 100644
index 0000000000..08a67d1ab0
Binary files /dev/null and b/media/articles/server-apis/webapi-owin/troubleshoot-issuer-validation-failed.png differ
diff --git a/media/articles/server-apis/webapi-owin/troubleshoot-token-expired.png b/media/articles/server-apis/webapi-owin/troubleshoot-token-expired.png
new file mode 100644
index 0000000000..bbf834fef1
Binary files /dev/null and b/media/articles/server-apis/webapi-owin/troubleshoot-token-expired.png differ
diff --git a/media/articles/server-apis/webapi-owin/troubleshoot-wrong-signature-hs256.png b/media/articles/server-apis/webapi-owin/troubleshoot-wrong-signature-hs256.png
new file mode 100644
index 0000000000..c3fca2ea62
Binary files /dev/null and b/media/articles/server-apis/webapi-owin/troubleshoot-wrong-signature-hs256.png differ
diff --git a/media/articles/server-apis/webapi-owin/troubleshoot-wrong-signature-rs256.png b/media/articles/server-apis/webapi-owin/troubleshoot-wrong-signature-rs256.png
new file mode 100644
index 0000000000..3d6a0b6ae4
Binary files /dev/null and b/media/articles/server-apis/webapi-owin/troubleshoot-wrong-signature-rs256.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/ad-rms.png b/media/articles/sso/integrations/ad-rms.png
new file mode 100755
index 0000000000..c59110e488
Binary files /dev/null and b/media/articles/sso/integrations/ad-rms.png differ
diff --git a/media/articles/sso/integrations/box.png b/media/articles/sso/integrations/box.png
new file mode 100755
index 0000000000..375b893196
Binary files /dev/null and b/media/articles/sso/integrations/box.png differ
diff --git a/media/articles/sso/integrations/cloudbees.png b/media/articles/sso/integrations/cloudbees.png
new file mode 100755
index 0000000000..1dbf424729
Binary files /dev/null and b/media/articles/sso/integrations/cloudbees.png differ
diff --git a/media/articles/sso/integrations/concur.png b/media/articles/sso/integrations/concur.png
new file mode 100755
index 0000000000..fb64adda93
Binary files /dev/null and b/media/articles/sso/integrations/concur.png differ
diff --git a/media/articles/sso/integrations/dropbox.png b/media/articles/sso/integrations/dropbox.png
new file mode 100755
index 0000000000..9e21d5d97a
Binary files /dev/null and b/media/articles/sso/integrations/dropbox.png differ
diff --git a/media/articles/sso/integrations/dynamics-crm.png b/media/articles/sso/integrations/dynamics-crm.png
new file mode 100755
index 0000000000..bf93683533
Binary files /dev/null and b/media/articles/sso/integrations/dynamics-crm.png differ
diff --git a/media/articles/sso/integrations/echosign.png b/media/articles/sso/integrations/echosign.png
new file mode 100755
index 0000000000..61def723ee
Binary files /dev/null and b/media/articles/sso/integrations/echosign.png differ
diff --git a/media/articles/sso/integrations/egnyte.png b/media/articles/sso/integrations/egnyte.png
new file mode 100755
index 0000000000..d85b5bb3f0
Binary files /dev/null and b/media/articles/sso/integrations/egnyte.png differ
diff --git a/media/articles/sso/integrations/name.png b/media/articles/sso/integrations/name.png
new file mode 100755
index 0000000000..f994b2cd5a
Binary files /dev/null and b/media/articles/sso/integrations/name.png differ
diff --git a/media/articles/sso/integrations/new-relic.png b/media/articles/sso/integrations/new-relic.png
new file mode 100755
index 0000000000..13dce13996
Binary files /dev/null and b/media/articles/sso/integrations/new-relic.png differ
diff --git a/media/articles/sso/integrations/new.png b/media/articles/sso/integrations/new.png
new file mode 100755
index 0000000000..c6ca5dd446
Binary files /dev/null and b/media/articles/sso/integrations/new.png differ
diff --git a/media/articles/sso/integrations/office-365.png b/media/articles/sso/integrations/office-365.png
new file mode 100755
index 0000000000..5b186a3ddc
Binary files /dev/null and b/media/articles/sso/integrations/office-365.png differ
diff --git a/media/articles/sso/integrations/options.png b/media/articles/sso/integrations/options.png
new file mode 100755
index 0000000000..444ff8a634
Binary files /dev/null and b/media/articles/sso/integrations/options.png differ
diff --git a/media/articles/sso/integrations/salesforce.png b/media/articles/sso/integrations/salesforce.png
new file mode 100755
index 0000000000..650abf95e0
Binary files /dev/null and b/media/articles/sso/integrations/salesforce.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/integrations/sharepoint.png b/media/articles/sso/integrations/sharepoint.png
new file mode 100755
index 0000000000..e97cf48518
Binary files /dev/null and b/media/articles/sso/integrations/sharepoint.png differ
diff --git a/media/articles/sso/integrations/slack.png b/media/articles/sso/integrations/slack.png
new file mode 100644
index 0000000000..69fe1f73ea
Binary files /dev/null and b/media/articles/sso/integrations/slack.png differ
diff --git a/media/articles/sso/integrations/springcm.png b/media/articles/sso/integrations/springcm.png
new file mode 100755
index 0000000000..8c93c537f7
Binary files /dev/null and b/media/articles/sso/integrations/springcm.png differ
diff --git a/media/articles/sso/integrations/zendesk.png b/media/articles/sso/integrations/zendesk.png
new file mode 100755
index 0000000000..77759a666c
Binary files /dev/null and b/media/articles/sso/integrations/zendesk.png differ
diff --git a/media/articles/sso/integrations/zoom.png b/media/articles/sso/integrations/zoom.png
new file mode 100755
index 0000000000..62267da626
Binary files /dev/null and b/media/articles/sso/integrations/zoom.png differ
diff --git a/media/articles/sso/single-sign-on/accountsettings-ssotimeout.png b/media/articles/sso/single-sign-on/accountsettings-ssotimeout.png
new file mode 100644
index 0000000000..def04c31a8
Binary files /dev/null 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/sso/v2/spa/before-login.png b/media/articles/sso/v2/spa/before-login.png
new file mode 100644
index 0000000000..c59bab5231
Binary files /dev/null and b/media/articles/sso/v2/spa/before-login.png differ
diff --git a/media/articles/sso/v2/spa/begin-silent-auth.png b/media/articles/sso/v2/spa/begin-silent-auth.png
new file mode 100644
index 0000000000..b01b07e0cf
Binary files /dev/null and b/media/articles/sso/v2/spa/begin-silent-auth.png differ
diff --git a/media/articles/sso/v2/spa/lock.png b/media/articles/sso/v2/spa/lock.png
new file mode 100644
index 0000000000..0225179527
Binary files /dev/null and b/media/articles/sso/v2/spa/lock.png differ
diff --git a/media/articles/sso/v2/spa/logged-in.png b/media/articles/sso/v2/spa/logged-in.png
new file mode 100644
index 0000000000..5ca9eea8cf
Binary files /dev/null and b/media/articles/sso/v2/spa/logged-in.png differ
diff --git a/media/articles/step-up-authentication/customers-page.png b/media/articles/step-up-authentication/customers-page.png
deleted file mode 100644
index 84668c7fd0..0000000000
Binary files a/media/articles/step-up-authentication/customers-page.png and /dev/null differ
diff --git a/media/articles/step-up-authentication/employees-page.png b/media/articles/step-up-authentication/employees-page.png
deleted file mode 100644
index 48a666e782..0000000000
Binary files a/media/articles/step-up-authentication/employees-page.png and /dev/null differ
diff --git a/media/articles/step-up-authentication/flow.png b/media/articles/step-up-authentication/flow.png
deleted file mode 100644
index 965d55e5e2..0000000000
Binary files a/media/articles/step-up-authentication/flow.png and /dev/null differ
diff --git a/media/articles/step-up-authentication/home-page.png b/media/articles/step-up-authentication/home-page.png
deleted file mode 100644
index 74cfa359b3..0000000000
Binary files a/media/articles/step-up-authentication/home-page.png and /dev/null differ
diff --git a/media/articles/step-up-authentication/login-page.png b/media/articles/step-up-authentication/login-page.png
deleted file mode 100644
index f55579e7fa..0000000000
Binary files a/media/articles/step-up-authentication/login-page.png and /dev/null differ
diff --git a/media/articles/step-up-authentication/mfa-authentication-level.png b/media/articles/step-up-authentication/mfa-authentication-level.png
deleted file mode 100644
index 030c3c759c..0000000000
Binary files a/media/articles/step-up-authentication/mfa-authentication-level.png and /dev/null differ
diff --git a/media/articles/step-up-authentication/mfa.png b/media/articles/step-up-authentication/mfa.png
deleted file mode 100644
index 5a89cbaa34..0000000000
Binary files a/media/articles/step-up-authentication/mfa.png and /dev/null differ
diff --git a/media/articles/step-up-authentication/normal-authentication-level.png b/media/articles/step-up-authentication/normal-authentication-level.png
deleted file mode 100644
index c18d0fb9f2..0000000000
Binary files a/media/articles/step-up-authentication/normal-authentication-level.png and /dev/null differ
diff --git a/media/articles/subscriptions/advanced.png b/media/articles/subscriptions/advanced.png
index 12ca4e963b..bfd0946c40 100755
Binary files a/media/articles/subscriptions/advanced.png and b/media/articles/subscriptions/advanced.png differ
diff --git a/media/articles/subscriptions/danger-zone.png b/media/articles/subscriptions/danger-zone.png
index 79b8d11572..bb3e49201c 100755
Binary files a/media/articles/subscriptions/danger-zone.png and b/media/articles/subscriptions/danger-zone.png differ
diff --git a/media/articles/subscriptions/dashboard.png b/media/articles/subscriptions/dashboard.png
index c06d59cb23..f6d31f6db5 100755
Binary files a/media/articles/subscriptions/dashboard.png and b/media/articles/subscriptions/dashboard.png differ
diff --git a/media/articles/subscriptions/free-subscription.png b/media/articles/subscriptions/free-subscription.png
index a7a6dbd70e..7d4af92ece 100755
Binary files a/media/articles/subscriptions/free-subscription.png and b/media/articles/subscriptions/free-subscription.png differ
diff --git a/media/articles/subscriptions/subscription.png b/media/articles/subscriptions/subscription.png
index f96f557a17..309864e3fb 100755
Binary files a/media/articles/subscriptions/subscription.png and b/media/articles/subscriptions/subscription.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/invite-users.png b/media/articles/support/invite-users.png
new file mode 100755
index 0000000000..ee9e5e13d2
Binary files /dev/null and b/media/articles/support/invite-users.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/manage-users.png b/media/articles/support/manage-users.png
new file mode 100755
index 0000000000..7799301823
Binary files /dev/null and b/media/articles/support/manage-users.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 7cd0b9af16..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/detailed-results.png b/media/articles/support/pre-deployment-tests/detailed-results.png
new file mode 100644
index 0000000000..060d965383
Binary files /dev/null and b/media/articles/support/pre-deployment-tests/detailed-results.png differ
diff --git a/media/articles/support/pre-deployment-tests/reading-results.png b/media/articles/support/pre-deployment-tests/reading-results.png
new file mode 100644
index 0000000000..b425e235b2
Binary files /dev/null and b/media/articles/support/pre-deployment-tests/reading-results.png differ
diff --git a/media/articles/support/pre-deployment-tests/results.png b/media/articles/support/pre-deployment-tests/results.png
new file mode 100644
index 0000000000..86fb83a45f
Binary files /dev/null and b/media/articles/support/pre-deployment-tests/results.png differ
diff --git a/media/articles/support/pre-deployment-tests/support-home.png b/media/articles/support/pre-deployment-tests/support-home.png
new file mode 100644
index 0000000000..ef11883083
Binary files /dev/null and b/media/articles/support/pre-deployment-tests/support-home.png differ
diff --git a/media/articles/support/pre-deployment-tests/tenants-tests.png b/media/articles/support/pre-deployment-tests/tenants-tests.png
new file mode 100644
index 0000000000..96a8f364ee
Binary files /dev/null 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
new file mode 100644
index 0000000000..10b292166c
Binary files /dev/null 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
new file mode 100755
index 0000000000..b827a4a725
Binary files /dev/null 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
new file mode 100755
index 0000000000..82cbf31eaf
Binary files /dev/null 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
new file mode 100755
index 0000000000..c9a6e97b89
Binary files /dev/null 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
new file mode 100755
index 0000000000..68b3e7c387
Binary files /dev/null and b/media/articles/support/subscriptions/upgrades.png differ
diff --git a/media/articles/support/support-center-users.png b/media/articles/support/support-center-users.png
new file mode 100755
index 0000000000..48619d1f2b
Binary files /dev/null and b/media/articles/support/support-center-users.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/dashboard-revoke-refresh-token.png b/media/articles/tokens/dashboard-revoke-refresh-token.png
old mode 100644
new mode 100755
index 22a02efa2e..1b9bcb2ffc
Binary files a/media/articles/tokens/dashboard-revoke-refresh-token.png and b/media/articles/tokens/dashboard-revoke-refresh-token.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/legacy/dashboard-revoke-refresh-token.png b/media/articles/tokens/legacy/dashboard-revoke-refresh-token.png
new file mode 100644
index 0000000000..22a02efa2e
Binary files /dev/null and b/media/articles/tokens/legacy/dashboard-revoke-refresh-token.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/tokens/tokens-expiration-api.png b/media/articles/tokens/tokens-expiration-api.png
new file mode 100644
index 0000000000..d64c812d2a
Binary files /dev/null and b/media/articles/tokens/tokens-expiration-api.png differ
diff --git a/media/articles/tokens/tokens-offlineaccess-api.png b/media/articles/tokens/tokens-offlineaccess-api.png
new file mode 100644
index 0000000000..2b6b9f5454
Binary files /dev/null and b/media/articles/tokens/tokens-offlineaccess-api.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/admin-mfa.png b/media/articles/tutorials/admin-mfa.png
new file mode 100644
index 0000000000..7c27985d1d
Binary files /dev/null and b/media/articles/tutorials/admin-mfa.png differ
diff --git a/media/articles/tutorials/aws/establish-trust.png b/media/articles/tutorials/aws/establish-trust.png
new file mode 100644
index 0000000000..f4907c1f81
Binary files /dev/null and b/media/articles/tutorials/aws/establish-trust.png differ
diff --git a/media/articles/tutorials/aws/provider-summary.png b/media/articles/tutorials/aws/provider-summary.png
new file mode 100644
index 0000000000..6bca1c7b77
Binary files /dev/null and b/media/articles/tutorials/aws/provider-summary.png differ
diff --git a/media/articles/tutorials/aws/review-policy.png b/media/articles/tutorials/aws/review-policy.png
new file mode 100644
index 0000000000..de98ca3c8f
Binary files /dev/null and b/media/articles/tutorials/aws/review-policy.png differ
diff --git a/media/articles/tutorials/aws/review-validate-policy.png b/media/articles/tutorials/aws/review-validate-policy.png
new file mode 100644
index 0000000000..34151215ad
Binary files /dev/null and b/media/articles/tutorials/aws/review-validate-policy.png differ
diff --git a/media/articles/tutorials/aws/role-summary.png b/media/articles/tutorials/aws/role-summary.png
new file mode 100644
index 0000000000..aee4b908cf
Binary files /dev/null and b/media/articles/tutorials/aws/role-summary.png differ
diff --git a/media/articles/tutorials/aws/role-summary2.png b/media/articles/tutorials/aws/role-summary2.png
new file mode 100644
index 0000000000..73763b37cb
Binary files /dev/null and b/media/articles/tutorials/aws/role-summary2.png differ
diff --git a/media/articles/tutorials/aws/roles1.png b/media/articles/tutorials/aws/roles1.png
new file mode 100644
index 0000000000..e6a049ae65
Binary files /dev/null and b/media/articles/tutorials/aws/roles1.png differ
diff --git a/media/articles/tutorials/aws/roles11.png b/media/articles/tutorials/aws/roles11.png
new file mode 100644
index 0000000000..46bf7d4f39
Binary files /dev/null and b/media/articles/tutorials/aws/roles11.png differ
diff --git a/media/articles/tutorials/aws/roles12.png b/media/articles/tutorials/aws/roles12.png
new file mode 100644
index 0000000000..369088d9fd
Binary files /dev/null and b/media/articles/tutorials/aws/roles12.png differ
diff --git a/media/articles/tutorials/aws/roles13.png b/media/articles/tutorials/aws/roles13.png
new file mode 100644
index 0000000000..56949ac851
Binary files /dev/null and b/media/articles/tutorials/aws/roles13.png differ
diff --git a/media/articles/tutorials/aws/roles3.png b/media/articles/tutorials/aws/roles3.png
new file mode 100644
index 0000000000..8caf8d8648
Binary files /dev/null and b/media/articles/tutorials/aws/roles3.png differ
diff --git a/media/articles/tutorials/aws/roles4.png b/media/articles/tutorials/aws/roles4.png
new file mode 100644
index 0000000000..3a0af00aa3
Binary files /dev/null and b/media/articles/tutorials/aws/roles4.png differ
diff --git a/media/articles/tutorials/aws/roles5.png b/media/articles/tutorials/aws/roles5.png
new file mode 100644
index 0000000000..b37352db87
Binary files /dev/null and b/media/articles/tutorials/aws/roles5.png differ
diff --git a/media/articles/tutorials/aws/roles6.png b/media/articles/tutorials/aws/roles6.png
new file mode 100644
index 0000000000..2cfa9d8102
Binary files /dev/null and b/media/articles/tutorials/aws/roles6.png differ
diff --git a/media/articles/tutorials/aws/roles7.png b/media/articles/tutorials/aws/roles7.png
new file mode 100644
index 0000000000..80567e059b
Binary files /dev/null and b/media/articles/tutorials/aws/roles7.png differ
diff --git a/media/articles/tutorials/aws/roles8.png b/media/articles/tutorials/aws/roles8.png
new file mode 100644
index 0000000000..25e5f2e881
Binary files /dev/null and b/media/articles/tutorials/aws/roles8.png differ
diff --git a/media/articles/tutorials/aws/roles9.png b/media/articles/tutorials/aws/roles9.png
new file mode 100644
index 0000000000..51cadae683
Binary files /dev/null and b/media/articles/tutorials/aws/roles9.png differ
diff --git a/media/articles/tutorials/aws/verify-role-trust.png b/media/articles/tutorials/aws/verify-role-trust.png
new file mode 100644
index 0000000000..bb850ce91f
Binary files /dev/null and b/media/articles/tutorials/aws/verify-role-trust.png differ
diff --git a/media/articles/tutorials/calling-an-external-idp-api/api.png b/media/articles/tutorials/calling-an-external-idp-api/api.png
deleted file mode 100755
index 2d3ddae33b..0000000000
Binary files a/media/articles/tutorials/calling-an-external-idp-api/api.png and /dev/null differ
diff --git a/media/articles/tutorials/calling-an-external-idp-api/authorize-client.png b/media/articles/tutorials/calling-an-external-idp-api/authorize-client.png
deleted file mode 100755
index 77eadac2f9..0000000000
Binary files a/media/articles/tutorials/calling-an-external-idp-api/authorize-client.png and /dev/null differ
diff --git a/media/articles/tutorials/calling-an-external-idp-api/client-id-secret.png b/media/articles/tutorials/calling-an-external-idp-api/client-id-secret.png
deleted file mode 100755
index 3654eb95b2..0000000000
Binary files a/media/articles/tutorials/calling-an-external-idp-api/client-id-secret.png and /dev/null differ
diff --git a/media/articles/tutorials/calling-an-external-idp-api/create-client.png b/media/articles/tutorials/calling-an-external-idp-api/create-client.png
deleted file mode 100755
index a092d29a2e..0000000000
Binary files a/media/articles/tutorials/calling-an-external-idp-api/create-client.png and /dev/null differ
diff --git a/media/articles/tutorials/calling-an-external-idp-api/select-ni-client.png b/media/articles/tutorials/calling-an-external-idp-api/select-ni-client.png
deleted file mode 100755
index 62d5a7341c..0000000000
Binary files a/media/articles/tutorials/calling-an-external-idp-api/select-ni-client.png and /dev/null differ
diff --git a/media/articles/tutorials/dashboard-admins.png b/media/articles/tutorials/dashboard-admins.png
new file mode 100644
index 0000000000..7c3ea8bdb8
Binary files /dev/null and b/media/articles/tutorials/dashboard-admins.png differ
diff --git a/media/articles/tutorials/data-scenarios/3-home.png b/media/articles/tutorials/data-scenarios/3-home.png
index 9fab7a3861..d923b60bd0 100644
Binary files a/media/articles/tutorials/data-scenarios/3-home.png and b/media/articles/tutorials/data-scenarios/3-home.png differ
diff --git a/media/articles/tutorials/data-scenarios/4-settings.png b/media/articles/tutorials/data-scenarios/4-settings.png
index 5625291884..cfdacbe9d7 100644
Binary files a/media/articles/tutorials/data-scenarios/4-settings.png and b/media/articles/tutorials/data-scenarios/4-settings.png differ
diff --git a/media/articles/tutorials/enter-firebase-settings.png b/media/articles/tutorials/enter-firebase-settings.png
deleted file mode 100644
index 9923e1ec3a..0000000000
Binary files a/media/articles/tutorials/enter-firebase-settings.png and /dev/null differ
diff --git a/media/articles/tutorials/firebase-generate-key.png b/media/articles/tutorials/firebase-generate-key.png
deleted file mode 100644
index 3b6f6a5d79..0000000000
Binary files a/media/articles/tutorials/firebase-generate-key.png and /dev/null differ
diff --git a/media/articles/tutorials/firebase-secret-sdkv2.png b/media/articles/tutorials/firebase-secret-sdkv2.png
deleted file mode 100644
index a53d401a48..0000000000
Binary files a/media/articles/tutorials/firebase-secret-sdkv2.png and /dev/null differ
diff --git a/media/articles/tutorials/gce-copy-token.png b/media/articles/tutorials/gce-copy-token.png
new file mode 100755
index 0000000000..767466da1a
Binary files /dev/null and b/media/articles/tutorials/gce-copy-token.png differ
diff --git a/media/articles/tutorials/gce-create-api.png b/media/articles/tutorials/gce-create-api.png
new file mode 100755
index 0000000000..8da3dd6cdb
Binary files /dev/null and b/media/articles/tutorials/gce-create-api.png differ
diff --git a/media/articles/tutorials/keen-io-dataflow.png b/media/articles/tutorials/keen-io-dataflow.png
index 5deedc832b..7d85274c31 100644
Binary files a/media/articles/tutorials/keen-io-dataflow.png and b/media/articles/tutorials/keen-io-dataflow.png differ
diff --git a/media/articles/tutorials/manage-admins.png b/media/articles/tutorials/manage-admins.png
old mode 100644
new mode 100755
index 2d52f8a351..2320fbaf58
Binary files a/media/articles/tutorials/manage-admins.png and b/media/articles/tutorials/manage-admins.png differ
diff --git a/media/articles/tutorials/mobile-ux.png b/media/articles/tutorials/mobile-ux.png
new file mode 100644
index 0000000000..612eb4806d
Binary files /dev/null and b/media/articles/tutorials/mobile-ux.png differ
diff --git a/media/articles/tutorials/mvc-tutorial-enterprise/enterprise-login.png b/media/articles/tutorials/mvc-tutorial-enterprise/enterprise-login.png
index 9b8bdccf5b..9a7f044e75 100644
Binary files a/media/articles/tutorials/mvc-tutorial-enterprise/enterprise-login.png and b/media/articles/tutorials/mvc-tutorial-enterprise/enterprise-login.png differ
diff --git a/media/articles/tutorials/rapleaf-salesforce.png b/media/articles/tutorials/rapleaf-salesforce.png
index c4187fa583..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/reset-password/login-screen.png b/media/articles/tutorials/reset-password/login-screen.png
new file mode 100644
index 0000000000..1787feb245
Binary files /dev/null and b/media/articles/tutorials/reset-password/login-screen.png differ
diff --git a/media/articles/tutorials/reset-password/logout.png b/media/articles/tutorials/reset-password/logout.png
new file mode 100644
index 0000000000..04663b9e34
Binary files /dev/null and b/media/articles/tutorials/reset-password/logout.png differ
diff --git a/media/articles/tutorials/reset-password/message-sent.png b/media/articles/tutorials/reset-password/message-sent.png
new file mode 100644
index 0000000000..d915b85c38
Binary files /dev/null and b/media/articles/tutorials/reset-password/message-sent.png differ
diff --git a/media/articles/tutorials/reset-password/provide-email.png b/media/articles/tutorials/reset-password/provide-email.png
new file mode 100644
index 0000000000..e4e4c7ff79
Binary files /dev/null and b/media/articles/tutorials/reset-password/provide-email.png differ
diff --git a/media/articles/tutorials/segment-io-dataflow.png b/media/articles/tutorials/segment-io-dataflow.png
deleted file mode 100644
index c1ce4444e8..0000000000
Binary files a/media/articles/tutorials/segment-io-dataflow.png and /dev/null differ
diff --git a/media/articles/tutorials/signups.png b/media/articles/tutorials/signups.png
index 1b3a5e4537..27ade29a6d 100644
Binary files a/media/articles/tutorials/signups.png and b/media/articles/tutorials/signups.png differ
diff --git a/media/articles/tutorials/splunk-dataflow.png b/media/articles/tutorials/splunk-dataflow.png
index 162291435d..f7ae6d012c 100644
Binary files a/media/articles/tutorials/splunk-dataflow.png and b/media/articles/tutorials/splunk-dataflow.png differ
diff --git a/media/articles/tutorials/tenant-settings/billing.png b/media/articles/tutorials/tenant-settings/billing.png
new file mode 100644
index 0000000000..65a0db38c4
Binary files /dev/null and b/media/articles/tutorials/tenant-settings/billing.png differ
diff --git a/media/articles/tutorials/tenant-settings/dashboard-admins.png b/media/articles/tutorials/tenant-settings/dashboard-admins.png
new file mode 100644
index 0000000000..236c2142e8
Binary files /dev/null and b/media/articles/tutorials/tenant-settings/dashboard-admins.png 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/error-pages.png b/media/articles/tutorials/tenant-settings/error-pages.png
new file mode 100644
index 0000000000..dd5c5265ca
Binary files /dev/null and b/media/articles/tutorials/tenant-settings/error-pages.png differ
diff --git a/media/articles/tutorials/tenant-settings/global-client-information.png b/media/articles/tutorials/tenant-settings/global-client-information.png
new file mode 100644
index 0000000000..3a3afcb3ea
Binary files /dev/null and b/media/articles/tutorials/tenant-settings/global-client-information.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/multifactor.png b/media/articles/tutorials/tenant-settings/multifactor.png
new file mode 100644
index 0000000000..6c3b985d5b
Binary files /dev/null and b/media/articles/tutorials/tenant-settings/multifactor.png differ
diff --git a/media/articles/tutorials/tenant-settings/session-timeout.png b/media/articles/tutorials/tenant-settings/session-timeout.png
new file mode 100644
index 0000000000..100aade8ff
Binary files /dev/null and b/media/articles/tutorials/tenant-settings/session-timeout.png differ
diff --git a/media/articles/tutorials/tenant-settings/settings.png b/media/articles/tutorials/tenant-settings/settings.png
new file mode 100644
index 0000000000..0015430731
Binary files /dev/null and b/media/articles/tutorials/tenant-settings/settings.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/tutorials/tenant-settings/your-profile.png b/media/articles/tutorials/tenant-settings/your-profile.png
new file mode 100644
index 0000000000..574decea0f
Binary files /dev/null and b/media/articles/tutorials/tenant-settings/your-profile.png differ
diff --git a/media/articles/tutorials/your-profile.png b/media/articles/tutorials/your-profile.png
new file mode 100644
index 0000000000..f43dc9cc96
Binary files /dev/null and b/media/articles/tutorials/your-profile.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/block-user.png b/media/articles/user-profile/block-user.png
deleted file mode 100755
index 3796e2ff8f..0000000000
Binary files a/media/articles/user-profile/block-user.png and /dev/null differ
diff --git a/media/articles/user-profile/delete-user.png b/media/articles/user-profile/delete-user.png
deleted file mode 100755
index d6cb594099..0000000000
Binary files a/media/articles/user-profile/delete-user.png and /dev/null differ
diff --git a/media/articles/user-profile/global-client-info.png b/media/articles/user-profile/global-client-info.png
new file mode 100755
index 0000000000..4285aadfd5
Binary files /dev/null and b/media/articles/user-profile/global-client-info.png differ
diff --git a/media/articles/user-profile/impersonation-adv.png b/media/articles/user-profile/impersonation-adv.png
new file mode 100644
index 0000000000..5530207d07
Binary files /dev/null and b/media/articles/user-profile/impersonation-adv.png differ
diff --git a/media/articles/user-profile/progressive-profiling-example.png b/media/articles/user-profile/progressive-profiling-example.png
index 3fa3abb59e..ce9ee1f5c7 100644
Binary files a/media/articles/user-profile/progressive-profiling-example.png and b/media/articles/user-profile/progressive-profiling-example.png differ
diff --git a/media/articles/user-profile/progressive-profiling.png b/media/articles/user-profile/progressive-profiling.png
index 23f741a07c..f316030ceb 100644
Binary files a/media/articles/user-profile/progressive-profiling.png and b/media/articles/user-profile/progressive-profiling.png differ
diff --git a/media/articles/user-profile/signin-as-user-01.png b/media/articles/user-profile/signin-as-user-01.png
index 7b760c793b..1c8f6077ba 100755
Binary files a/media/articles/user-profile/signin-as-user-01.png and b/media/articles/user-profile/signin-as-user-01.png differ
diff --git a/media/articles/user-profile/signin-as-user-02.png b/media/articles/user-profile/signin-as-user-02.png
index f5265969d0..b9e75bfe50 100755
Binary files a/media/articles/user-profile/signin-as-user-02.png and b/media/articles/user-profile/signin-as-user-02.png differ
diff --git a/media/articles/user-profile/unblock-user.png b/media/articles/user-profile/unblock-user.png
deleted file mode 100755
index 57f364df50..0000000000
Binary files a/media/articles/user-profile/unblock-user.png and /dev/null differ
diff --git a/media/articles/user-profile/user-picture.png b/media/articles/user-profile/user-picture.png
new file mode 100644
index 0000000000..e67ff59a48
Binary files /dev/null and b/media/articles/user-profile/user-picture.png differ
diff --git a/media/articles/user-profile/user-profile-dashboard.png b/media/articles/user-profile/user-profile-dashboard.png
deleted file mode 100644
index 07f46c1399..0000000000
Binary files a/media/articles/user-profile/user-profile-dashboard.png and /dev/null differ
diff --git a/media/articles/user-profile/user1.png b/media/articles/user-profile/user1.png
new file mode 100644
index 0000000000..0881f7d734
Binary files /dev/null and b/media/articles/user-profile/user1.png differ
diff --git a/media/articles/user-profile/user2.png b/media/articles/user-profile/user2.png
new file mode 100644
index 0000000000..61c2a57a24
Binary files /dev/null and b/media/articles/user-profile/user2.png differ
diff --git a/media/articles/user-profile/user3.png b/media/articles/user-profile/user3.png
new file mode 100644
index 0000000000..d07b62154a
Binary files /dev/null and b/media/articles/user-profile/user3.png differ
diff --git a/media/articles/user-profile/user4.png b/media/articles/user-profile/user4.png
new file mode 100644
index 0000000000..6a1d47b417
Binary files /dev/null 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/data.png b/media/articles/users/data.png
new file mode 100644
index 0000000000..2412cfbc99
Binary files /dev/null and b/media/articles/users/data.png differ
diff --git a/media/articles/users/migrations/create-database-connection.png b/media/articles/users/migrations/create-database-connection.png
new file mode 100755
index 0000000000..15d275080b
Binary files /dev/null and b/media/articles/users/migrations/create-database-connection.png differ
diff --git a/media/articles/users/migrations/enable-clients.png b/media/articles/users/migrations/enable-clients.png
new file mode 100755
index 0000000000..821755085b
Binary files /dev/null and b/media/articles/users/migrations/enable-clients.png differ
diff --git a/media/articles/users/migrations/import-users.png b/media/articles/users/migrations/import-users.png
new file mode 100755
index 0000000000..889a1a9ab1
Binary files /dev/null and b/media/articles/users/migrations/import-users.png differ
diff --git a/media/articles/users/migrations/own-database.png b/media/articles/users/migrations/own-database.png
new file mode 100755
index 0000000000..19b945dc0e
Binary files /dev/null and b/media/articles/users/migrations/own-database.png differ
diff --git a/media/articles/users/migrations/try-connection-lock.png b/media/articles/users/migrations/try-connection-lock.png
new file mode 100755
index 0000000000..f0373e8362
Binary files /dev/null and b/media/articles/users/migrations/try-connection-lock.png differ
diff --git a/media/articles/users/migrations/try-connection-success.png b/media/articles/users/migrations/try-connection-success.png
new file mode 100755
index 0000000000..86daee7d2b
Binary files /dev/null and b/media/articles/users/migrations/try-connection-success.png differ
diff --git a/media/articles/users/migrations/try-connection.png b/media/articles/users/migrations/try-connection.png
new file mode 100755
index 0000000000..d265b662f5
Binary files /dev/null and b/media/articles/users/migrations/try-connection.png differ
diff --git a/media/articles/users/migrations/user-imported.png b/media/articles/users/migrations/user-imported.png
new file mode 100755
index 0000000000..7e79178d0c
Binary files /dev/null and b/media/articles/users/migrations/user-imported.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/articles/web/embedded-login.png b/media/articles/web/embedded-login.png
new file mode 100644
index 0000000000..85f323a8e3
Binary files /dev/null and b/media/articles/web/embedded-login.png differ
diff --git a/media/articles/web/hosted-login.png b/media/articles/web/hosted-login.png
new file mode 100644
index 0000000000..d81e717073
Binary files /dev/null and b/media/articles/web/hosted-login.png differ
diff --git a/media/articles/what-to-do-once-the-user-is-logged-in/adding-scopes-for-an-external-idp/scopes.png b/media/articles/what-to-do-once-the-user-is-logged-in/adding-scopes-for-an-external-idp/scopes.png
new file mode 100644
index 0000000000..caa193df03
Binary files /dev/null and b/media/articles/what-to-do-once-the-user-is-logged-in/adding-scopes-for-an-external-idp/scopes.png differ
diff --git a/media/auth0-catalog/application-addon.png b/media/auth0-catalog/application-addon.png
deleted file mode 100644
index 4f1e8c0c14..0000000000
Binary files a/media/auth0-catalog/application-addon.png and /dev/null differ
diff --git a/media/auth0-catalog/application-create.png b/media/auth0-catalog/application-create.png
deleted file mode 100644
index 5b69108ad0..0000000000
Binary files a/media/auth0-catalog/application-create.png and /dev/null differ
diff --git a/media/auth0-catalog/client-addon.png b/media/auth0-catalog/client-addon.png
new file mode 100644
index 0000000000..2bcbf81b74
Binary files /dev/null and b/media/auth0-catalog/client-addon.png differ
diff --git a/media/auth0-catalog/client-create.png b/media/auth0-catalog/client-create.png
new file mode 100644
index 0000000000..fb0aa9713f
Binary files /dev/null and b/media/auth0-catalog/client-create.png differ
diff --git a/media/auth0-catalog/connection-database.png b/media/auth0-catalog/connection-database.png
index c5d5c41c93..d707d0fa8b 100644
Binary files a/media/auth0-catalog/connection-database.png and b/media/auth0-catalog/connection-database.png differ
diff --git a/media/auth0-catalog/connection-enterprise.png b/media/auth0-catalog/connection-enterprise.png
deleted file mode 100644
index 0009723072..0000000000
Binary files a/media/auth0-catalog/connection-enterprise.png and /dev/null differ
diff --git a/media/auth0-catalog/connection-passwordless.png b/media/auth0-catalog/connection-passwordless.png
deleted file mode 100644
index d465ca8abb..0000000000
Binary files a/media/auth0-catalog/connection-passwordless.png and /dev/null differ
diff --git a/media/auth0-catalog/connection-social.png b/media/auth0-catalog/connection-social.png
deleted file mode 100644
index 2868a74029..0000000000
Binary files a/media/auth0-catalog/connection-social.png and /dev/null differ
diff --git a/media/auth0-catalog/connections-enterprise.png b/media/auth0-catalog/connections-enterprise.png
new file mode 100644
index 0000000000..07779544ff
Binary files /dev/null and b/media/auth0-catalog/connections-enterprise.png differ
diff --git a/media/auth0-catalog/connections-passwordless.png b/media/auth0-catalog/connections-passwordless.png
new file mode 100644
index 0000000000..dea02ed209
Binary files /dev/null and b/media/auth0-catalog/connections-passwordless.png differ
diff --git a/media/auth0-catalog/connections-social.png b/media/auth0-catalog/connections-social.png
new file mode 100644
index 0000000000..32f96b5c9b
Binary files /dev/null and b/media/auth0-catalog/connections-social.png differ
diff --git a/media/auth0-catalog/dashboard.png b/media/auth0-catalog/dashboard.png
index 9c4184cda2..db67fdc78b 100644
Binary files a/media/auth0-catalog/dashboard.png and b/media/auth0-catalog/dashboard.png differ
diff --git a/media/auth0-catalog/sso-integrations.png b/media/auth0-catalog/sso-integrations.png
new file mode 100644
index 0000000000..939eaa10a6
Binary files /dev/null and b/media/auth0-catalog/sso-integrations.png differ
diff --git a/media/auth0-catalog/thirdpartyapp-create.png b/media/auth0-catalog/thirdpartyapp-create.png
deleted file mode 100644
index a280e4f0a1..0000000000
Binary files a/media/auth0-catalog/thirdpartyapp-create.png and /dev/null 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/daccount.png b/media/connections/daccount.png
new file mode 100644
index 0000000000..093d9a34fa
Binary files /dev/null and b/media/connections/daccount.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/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/jquery.svg b/media/platforms/jquery.svg
new file mode 100644
index 0000000000..901dd8c8c3
--- /dev/null
+++ b/media/platforms/jquery.svg
@@ -0,0 +1,68 @@
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
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/media/readme/alert-version.png b/media/readme/alert-version.png
deleted file mode 100755
index 30cc8aa35b..0000000000
Binary files a/media/readme/alert-version.png and /dev/null differ
diff --git a/media/readme/structure.png b/media/readme/structure.png
new file mode 100644
index 0000000000..9d36b50ec2
Binary files /dev/null and b/media/readme/structure.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 195f63d448..620ba339e3 100644
--- a/package.json
+++ b/package.json
@@ -5,14 +5,27 @@
   "author": "Auth0 Inc.",
   "scripts": {
     "heroku-prebuild": "bash prebuild.sh",
-    "heroku-postbuild": "bash postbuild.sh"
+    "heroku-postbuild": "bash postbuild.sh",
+    "precommit": "lint-staged",
+    "clean-redirects": "npx jscodeshift -t codemods/clean-redirects-config.js config/redirects.js"
+  },
+  "lint-staged": {
+    "*.md": "markdownlint"
   },
   "engines": {
-    "node": "4.5"
+    "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"
-  }
+    "imagemin-optipng": "^4.3.0",
+    "jscodeshift": "^0.13.0",
+    "lint-staged": "^3.4.2",
+    "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 1e47169839..3280c62311 100644
--- a/prebuild.sh
+++ b/prebuild.sh
@@ -29,17 +29,34 @@ fi
 
 
 echo "Moving content into docs folder"
+rm -rf "./docs/"
 mkdir -p "./docs/"
 shopt -s extglob
 mv !(docs) docs
 shopt -u extglob
 
-git clone https://$GITHUB_USER_NAME:$GITHUB_ACCESS_TOKEN@github.com/auth0/auth0-docs.git auth0-docs-repo
+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 06181923d2..de552c9b9d 100644
--- a/snippets/api-auth/hs256/csharp.md
+++ b/snippets/api-auth/hs256/csharp.md
@@ -5,22 +5,46 @@ title: C#
 ```cs
 public class Startup
 {
-  public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
-  {
-    var keyAsBytes = Encoding.ASCII.GetBytes("${'<%= api.signing_secret %>'}");
+  public void ConfigureServices(IServiceCollection services)
+  { 
+    // 1. Add Authentication Services
+    services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
+      .AddJwtBearer(options =>
+      {
+        options.TokenValidationParameters = new TokenValidationParameters
+        {
+            ValidIssuer = "https://${'<%= tenantDomain %>'}/",
+            ValidAudience = "${'<%= api.identifier %>'}",
+            IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("${'<%= api.signing_secret %>'}"))
+        };
+      });
+
+    services.AddControllers();
+  }
 
-    var options = new JwtBearerOptions
+  public void Configure(IApplicationBuilder app, IHostingEnvironment env)
+  {
+    if (env.IsDevelopment())
     {
-      Audience = "${'<%= api.identifier %>'}",
-      Authority = "${'https://<%= tenantDomain %>'}/",
-      TokenValidationParameters =
-      {
-        IssuerSigningKey = new SymmetricSecurityKey(keyAsBytes)
-      }
-    };
-    app.UseJwtBearerAuthentication(options);
+        app.UseDeveloperExceptionPage();
+    }
+    else
+    {
+        app.UseExceptionHandler("/Home/Error");
+    }
+
+    app.UseStaticFiles();
+
+    app.UseRouting();
 
-    app.UseMvc();
+    // 2. Enable authentication and authorization middleware
+    app.UseAuthentication();
+    app.UseAuthorization();
+
+    app.UseEndpoints(endpoints =>
+    {
+        endpoints.MapControllers();
+    });
   }
 }
 ```
diff --git a/snippets/api-auth/rs256/csharp.md b/snippets/api-auth/rs256/csharp.md
index c0e5184011..5d48ed19b6 100644
--- a/snippets/api-auth/rs256/csharp.md
+++ b/snippets/api-auth/rs256/csharp.md
@@ -5,16 +5,45 @@ title: C#
 ```cs
 public class Startup
 {
-  public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
+  public void ConfigureServices(IServiceCollection services)
   {
-    var options = new JwtBearerOptions
+    services.AddMvc();
+    
+    // 1. Add Authentication Services
+    services.AddAuthentication(options =>
     {
-      Audience = "${'<%= api.identifier %>'}",
-      Authority = "https://${'<%= tenantDomain %>'}/"
-    };
-    app.UseJwtBearerAuthentication(options);
+        options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
+        options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
 
-    app.UseMvc();
+    }).AddJwtBearer(options =>
+    {
+        options.Authority = "https://${'<%= tenantDomain %>'}/";
+        options.Audience = "${'<%= api.identifier %>'}";
+    });
+  }
+
+  public void Configure(IApplicationBuilder app, IHostingEnvironment env)
+  {
+    if (env.IsDevelopment())
+    {
+        app.UseDeveloperExceptionPage();
+    }
+    else
+    {
+        app.UseExceptionHandler("/Home/Error");
+    }
+
+    app.UseStaticFiles();
+
+    // 2. Enable authentication middleware
+    app.UseAuthentication();
+
+    app.UseMvc(routes =>
+    {
+        routes.MapRoute(
+            name: "default",
+            template: "{controller=Home}/{action=Index}/{id?}");
+    });
   }
 }
 ```
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/client-platforms/angular2/dependencies.md b/snippets/client-platforms/angular2/dependencies.md
deleted file mode 100644
index 93a90f5394..0000000000
--- a/snippets/client-platforms/angular2/dependencies.md
+++ /dev/null
@@ -1,7 +0,0 @@
-```html
-
-
-
-
-
-```
diff --git a/snippets/client-platforms/angular2/install.md b/snippets/client-platforms/angular2/install.md
deleted file mode 100644
index b472996871..0000000000
--- a/snippets/client-platforms/angular2/install.md
+++ /dev/null
@@ -1,3 +0,0 @@
-```bash
-npm install angular2-jwt
-```
\ No newline at end of file
diff --git a/snippets/client-platforms/angular2/observable.md b/snippets/client-platforms/angular2/observable.md
deleted file mode 100644
index de42346ef8..0000000000
--- a/snippets/client-platforms/angular2/observable.md
+++ /dev/null
@@ -1,11 +0,0 @@
-```js
-// app.ts
-
-tokenSubscription() {
-  this.authHttp.tokenStream.subscribe(
-      data => console.log(data),
-      err => console.log(err),
-      () => console.log('Complete')
-    );
-}
-```
\ No newline at end of file
diff --git a/snippets/client-platforms/angular2/request.md b/snippets/client-platforms/angular2/request.md
deleted file mode 100644
index 1f90fe5399..0000000000
--- a/snippets/client-platforms/angular2/request.md
+++ /dev/null
@@ -1,27 +0,0 @@
-```js
-// app.ts
-
-...
-
-constructor(public authHttp:AuthHttp) {}
-
-getSecretThing() {
-  this.authHttp.get('http://example.com/api/secretthing')
-    .subscribe(
-      data => console.log(data.json()),
-      err => console.log(err),
-      () => console.log('Complete')
-    );
-  );
-}
-
-
-...
-
-bootstrap(AuthApp, [
-  HTTP_PROVIDERS,
-  provide(AuthHttp, { useFactory: () => {
-    return new AuthHttp();
-  }})
-])
-```
diff --git a/snippets/client-platforms/angular2/router.md b/snippets/client-platforms/angular2/router.md
deleted file mode 100644
index f121f0e1eb..0000000000
--- a/snippets/client-platforms/angular2/router.md
+++ /dev/null
@@ -1,60 +0,0 @@
-```js
-// app.ts
-
-@Component({
-  selector: 'public-route'
-})
-@View({
-  template: `
      Hello from a public route
      `
-})
-class PublicRoute {}
-
-@Component({
-  selector: 'private-route'
-})
-
-@View({
-  template: `
      Hello from private route
      `
-})
-
-@CanActivate(() => tokenNotExpired())
-
-class PrivateRoute {}
-
-@Component({
-  directives: [ ROUTER_DIRECTIVES ],
-  selector: 'app',
-  template: `
-    
      Welcome to Angular2 with Auth0
      
-    
-    
-    
      
-    
      
-      
-      
-      
-    
      
-
-  `
-})
-
-@RouteConfig([
-  { path: '/public-route', component: PublicRoute, as: 'PublicRoute' }
-  { path: '/private-route', component: PrivateRoute, as: 'PrivateRoute' }
-])
-
-export class AuthApp {
-
-...
-
-}
-
-bootstrap(AuthApp, [
-  HTTP_PROVIDERS,
-  ROUTER_PROVIDERS, 
-  provide(AuthHttp, { useFactory: () => {
-    return new AuthHttp();
-  }}),
-  provide(APP_BASE_HREF, {useValue:'/'})
-])
-```
\ No newline at end of file
diff --git a/snippets/client-platforms/angular2/setup.md b/snippets/client-platforms/angular2/setup.md
deleted file mode 100644
index 43f1af45be..0000000000
--- a/snippets/client-platforms/angular2/setup.md
+++ /dev/null
@@ -1,9 +0,0 @@
-```js
-// app.ts
-
-import { bootstrap } from '@angular/platform-browser-dynamic';
-import { Component, View, provide } from '@angular/core';
-import { RouteConfig, Router, APP_BASE_HREF, ROUTER_PROVIDERS, ROUTER_DIRECTIVES, CanActivate } from 'angular2/router-deprecated';
-import { HTTP_PROVIDERS, Http } from '@angular/http';
-import { AuthHttp, tokenNotExpired } from 'angular2-jwt';
-```
diff --git a/snippets/client-platforms/angular2/system-map.md b/snippets/client-platforms/angular2/system-map.md
deleted file mode 100644
index 6d6cbc0f27..0000000000
--- a/snippets/client-platforms/angular2/system-map.md
+++ /dev/null
@@ -1,18 +0,0 @@
-```html
-  
-  
-  
-```
diff --git a/snippets/client-platforms/angular2/use.md b/snippets/client-platforms/angular2/use.md
deleted file mode 100644
index 9efedbdcb7..0000000000
--- a/snippets/client-platforms/angular2/use.md
+++ /dev/null
@@ -1,48 +0,0 @@
-```js
-// app.ts
-
-declare var Auth0Lock;
-
-@Component({
-  selector: 'app',
-  template: `
-    
      Welcome to Angular2 with Auth0
      
-    
-    
-  `
-})
-
-export class AuthApp {
-
-  lock = new Auth0Lock('<%= account.clientId %>', '<%= account.namespace %>');
-
-  constructor() {}
-
-  login() {
-    var hash = this.lock.parseHash();
-    if (hash) {
-      if (hash.error)
-        console.log('There was an error logging in', hash.error);
-      else
-        this.lock.getProfile(hash.id_token, function(err, profile) {
-          if (err) {
-            console.log(err);
-            return;
-          }
-          localStorage.setItem('profile', JSON.stringify(profile));
-          localStorage.setItem('id_token', hash.id_token);
-        });
-    }
-  }
-
-  logout() {
-    localStorage.removeItem('profile');
-    localStorage.removeItem('id_token');
-  }
-
-  loggedIn() {
-    return tokenNotExpired();
-  }
-
-}
-```
diff --git a/snippets/client-platforms/angularjs/dependencies.md b/snippets/client-platforms/angularjs/dependencies.md
deleted file mode 100644
index 773d151623..0000000000
--- a/snippets/client-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/client-platforms/angularjs/setup.md b/snippets/client-platforms/angularjs/setup.md
deleted file mode 100644
index 67a53e5a75..0000000000
--- a/snippets/client-platforms/angularjs/setup.md
+++ /dev/null
@@ -1,8 +0,0 @@
-```js
-// app.js
-authProvider.init({
-    domain: '<%= account.namespace %>',
-    clientID: '<%= account.clientId %>',
-    loginUrl: '/login'
-});
-```
diff --git a/snippets/client-platforms/angularjs/use.md b/snippets/client-platforms/angularjs/use.md
deleted file mode 100644
index 4f69658d75..0000000000
--- a/snippets/client-platforms/angularjs/use.md
+++ /dev/null
@@ -1,15 +0,0 @@
-```js
-// LoginCtrl.js
-angular.module('YOUR-APP-NAME').controller( 'LoginCtrl', function ( $scope, auth) {
-
-  $scope.auth = auth;
-
-});
-```
-
-```html
-
-
-
-
-```
diff --git a/snippets/client-platforms/aurelia/configurehttp.md b/snippets/client-platforms/aurelia/configurehttp.md
deleted file mode 100644
index e1b5aaab88..0000000000
--- a/snippets/client-platforms/aurelia/configurehttp.md
+++ /dev/null
@@ -1,15 +0,0 @@
-```js
-// app.js
-
-constructor(http) {
-  this.http = http;
-  this.http.configure(config => {
-    config.withDefaults({
-      headers: {
-        'Authorization': 'Bearer ' + localStorage.getItem('id_token')
-      }
-    });
-  });
-  ...
-}
-```
\ No newline at end of file
diff --git a/snippets/client-platforms/aurelia/constructorexpiry.md b/snippets/client-platforms/aurelia/constructorexpiry.md
deleted file mode 100644
index 6b5af98f66..0000000000
--- a/snippets/client-platforms/aurelia/constructorexpiry.md
+++ /dev/null
@@ -1,18 +0,0 @@
-```js
-// app.js
-
-import {tokenIsExpired} from './utils/tokenUtils';
-
-constructor(http) {
-  this.http = http;
-  
-  ...
-  
-  if(tokenIsExpired())  {
-    this.isAuthenticated = false;
-  }
-  else {
-    this.isAuthenticated = true;
-  }
-}
-```
\ No newline at end of file
diff --git a/snippets/client-platforms/aurelia/dependencies.md b/snippets/client-platforms/aurelia/dependencies.md
deleted file mode 100644
index c449bb50c9..0000000000
--- a/snippets/client-platforms/aurelia/dependencies.md
+++ /dev/null
@@ -1,7 +0,0 @@
-```html
-
-
-
-
-
-```
\ No newline at end of file
diff --git a/snippets/client-platforms/aurelia/http.md b/snippets/client-platforms/aurelia/http.md
deleted file mode 100644
index ed5c39b55a..0000000000
--- a/snippets/client-platforms/aurelia/http.md
+++ /dev/null
@@ -1,13 +0,0 @@
-```js
-// app.js
-
-getSecretThing() {
-  this.http.fetch('/api/protected-route', {
-    headers: {
-      'Authorization': 'Bearer ' + localStorage.getItem('id_token')
-    }
-  })
-  .then(response => response.json())
-  .then(data => this.secretThing = data.text);
-}
-```
\ No newline at end of file
diff --git a/snippets/client-platforms/aurelia/jwtdecode.md b/snippets/client-platforms/aurelia/jwtdecode.md
deleted file mode 100644
index fbbf6d74e6..0000000000
--- a/snippets/client-platforms/aurelia/jwtdecode.md
+++ /dev/null
@@ -1,3 +0,0 @@
-```bash
-npm install jwt-decode --save
-```
\ No newline at end of file
diff --git a/snippets/client-platforms/aurelia/login.md b/snippets/client-platforms/aurelia/login.md
deleted file mode 100644
index 9c36fd2674..0000000000
--- a/snippets/client-platforms/aurelia/login.md
+++ /dev/null
@@ -1,7 +0,0 @@
-```js
-// app.js
-
-login() {
-  this.lock.show();   
-}
-```
\ No newline at end of file
diff --git a/snippets/client-platforms/aurelia/logout.md b/snippets/client-platforms/aurelia/logout.md
deleted file mode 100644
index 476fe69790..0000000000
--- a/snippets/client-platforms/aurelia/logout.md
+++ /dev/null
@@ -1,9 +0,0 @@
-```js
-// app.js
-
-logout() {
-  localStorage.removeItem('profile');
-  localStorage.removeItem('id_token');
-  this.isAuthenticated = false;   
-}
-```
\ No newline at end of file
diff --git a/snippets/client-platforms/aurelia/routing.md b/snippets/client-platforms/aurelia/routing.md
deleted file mode 100644
index f9455586b8..0000000000
--- a/snippets/client-platforms/aurelia/routing.md
+++ /dev/null
@@ -1,19 +0,0 @@
-```js
-// private-route.js
-
-import {Redirect} from 'aurelia-router';
-import {tokenIsExpired} from './utils/tokenUtils';
-
-export class Private {
-  message = "Hello from a private route.";
-  
-  canActivate() {
-    if(tokenIsExpired()) {
-      return new Redirect('public');
-    }
-    else {
-      return true;
-    }
-  }
-}
-```
\ No newline at end of file
diff --git a/snippets/client-platforms/aurelia/setup.md b/snippets/client-platforms/aurelia/setup.md
deleted file mode 100644
index 0ca1c68e11..0000000000
--- a/snippets/client-platforms/aurelia/setup.md
+++ /dev/null
@@ -1,31 +0,0 @@
-```js
-// app.js
-
-import {inject} from 'aurelia-framework';
-import {HttpClient} from 'aurelia-fetch-client';
-
-@inject(HttpClient)
-
-export class App {
-  lock = new Auth0Lock('<%= account.clientId %>', '<%= account.namespace %>');
-  isAuthenticated = false;
-  
-  constructor(http) {
-    this.http = http;
-    var self = this;
-    this.lock.on("authenticated", (authResult) => {
-      self.lock.getProfile(authResult.idToken, (error, profile) => {
-        if (error) {
-          // Handle error
-          return;
-        }
-
-        localStorage.setItem('id_token', authResult.idToken);
-        localStorage.setItem('profile', JSON.stringify(profile));
-        self.isAuthenticated = true;
-        self.lock.hide();
-      });
-    });
-  }
-}
-```
\ No newline at end of file
diff --git a/snippets/client-platforms/aurelia/template.md b/snippets/client-platforms/aurelia/template.md
deleted file mode 100644
index 03b8ebdf83..0000000000
--- a/snippets/client-platforms/aurelia/template.md
+++ /dev/null
@@ -1,10 +0,0 @@
-```html
-
-
-```
\ No newline at end of file
diff --git a/snippets/client-platforms/aurelia/tokenisexpired.md b/snippets/client-platforms/aurelia/tokenisexpired.md
deleted file mode 100644
index 4ad762c13c..0000000000
--- a/snippets/client-platforms/aurelia/tokenisexpired.md
+++ /dev/null
@@ -1,18 +0,0 @@
-```js
-// utils/tokenUtils.js
-
-export function tokenIsExpired() {
-  let jwt = localStorage.getItem('id_token')
-  if(jwt) {
-    let jwtExp = jwt_decode(jwt).exp;
-    let expiryDate = new Date(0);
-    expiryDate.setUTCSeconds(jwtExp);
-    
-    if(new Date() < expiryDate) {
-      return false;
-    }
-  }
-
-  return true;
-}
-```
\ No newline at end of file
diff --git a/snippets/client-platforms/cyclejs/configure.md b/snippets/client-platforms/cyclejs/configure.md
deleted file mode 100644
index e2906f2d54..0000000000
--- a/snippets/client-platforms/cyclejs/configure.md
+++ /dev/null
@@ -1,8 +0,0 @@
-```js
-const ProtectedComponent = protect(Component, {
-    auth0ShowParams: {
-        authParams: { scope: "openid nickname" },
-        responseType: "token"
-    }
-});
-```
diff --git a/snippets/client-platforms/cyclejs/dependencies.md b/snippets/client-platforms/cyclejs/dependencies.md
deleted file mode 100644
index 7476459c76..0000000000
--- a/snippets/client-platforms/cyclejs/dependencies.md
+++ /dev/null
@@ -1,3 +0,0 @@
-```bash
-npm install cyclejs-auth0 cyclic-router
-```
diff --git a/snippets/client-platforms/cyclejs/logout.md b/snippets/client-platforms/cyclejs/logout.md
deleted file mode 100644
index e529720ca8..0000000000
--- a/snippets/client-platforms/cyclejs/logout.md
+++ /dev/null
@@ -1,12 +0,0 @@
-```js
-function main(sources) {
-    const logoutAction$ = sources
-        .DOM
-        .select(".logout")
-        .events("click")
-
-    return {
-        auth0: logoutAction$.mapTo({ action: "logout" })
-    }
-}
-```
diff --git a/snippets/client-platforms/cyclejs/query.md b/snippets/client-platforms/cyclejs/query.md
deleted file mode 100644
index bd44a022da..0000000000
--- a/snippets/client-platforms/cyclejs/query.md
+++ /dev/null
@@ -1,22 +0,0 @@
-```js
-function Component(sources) {
-    const token$ = sources.props.token$; //the token$ added by the protect function
-
-    const userProfile$ = sources
-        .auth0
-        .select("getProfile") //read to response of the lock to the getProfile method call
-
-    return {
-        auth0: token$
-            .filter(token => !!token) //filter empty tokens
-            //send the getProfile action to the auth0 driver
-            .map(token => ({ action: "getProfile", params: token })),
-
-        DOM: userProfile$ //displays the user profile once fetched
-            .map(user => p([
-                "Welcome",
-                span(".nickname", user.nickname)
-            ]))
-    };
-}
-```
diff --git a/snippets/client-platforms/cyclejs/securize.md b/snippets/client-platforms/cyclejs/securize.md
deleted file mode 100644
index 160180af15..0000000000
--- a/snippets/client-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/client-platforms/cyclejs/setup.md b/snippets/client-platforms/cyclejs/setup.md
deleted file mode 100644
index d8c56d0e7f..0000000000
--- a/snippets/client-platforms/cyclejs/setup.md
+++ /dev/null
@@ -1,14 +0,0 @@
-```js
-import {createHistory} from "history";
-import {makeRouterDriver} from 'cyclic-router'
-import {makeAuth0Driver, protect} from "cyclejs-auth0";
-
-function main(sources) {
-    //your application's code
-}
-
-const drivers = {
-    auth0: makeAuth0Driver('<%= account.clientId %>', '<%= account.namespace %>'),
-    router: makeRouterDriver(createHistory())
-}
-```
diff --git a/snippets/client-platforms/cyclejs/use.md b/snippets/client-platforms/cyclejs/use.md
deleted file mode 100644
index 40a118e459..0000000000
--- a/snippets/client-platforms/cyclejs/use.md
+++ /dev/null
@@ -1,12 +0,0 @@
-```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/client-platforms/jquery/dependencies.md b/snippets/client-platforms/jquery/dependencies.md
deleted file mode 100644
index d8f54c2761..0000000000
--- a/snippets/client-platforms/jquery/dependencies.md
+++ /dev/null
@@ -1,7 +0,0 @@
-```html
-
-
-
-
-
-```
diff --git a/snippets/client-platforms/jquery/setup.md b/snippets/client-platforms/jquery/setup.md
deleted file mode 100644
index a111604787..0000000000
--- a/snippets/client-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/client-platforms/jquery/use.md b/snippets/client-platforms/jquery/use.md
deleted file mode 100644
index f9d1a62530..0000000000
--- a/snippets/client-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/client-platforms/react/dependencies.md b/snippets/client-platforms/react/dependencies.md
deleted file mode 100644
index 1003dd9769..0000000000
--- a/snippets/client-platforms/react/dependencies.md
+++ /dev/null
@@ -1,7 +0,0 @@
-```html
-
-
-
-
-
-```
diff --git a/snippets/client-platforms/react/setup.md b/snippets/client-platforms/react/setup.md
deleted file mode 100644
index d96f82d759..0000000000
--- a/snippets/client-platforms/react/setup.md
+++ /dev/null
@@ -1,9 +0,0 @@
-```js
-var App = React.createClass({
-  // ...
-  componentWillMount: function() {
-      this.lock = new Auth0Lock('${account.clientId}', '${account.namespace}');
-  },
-  // ...
-});
-```
diff --git a/snippets/client-platforms/react/use.md b/snippets/client-platforms/react/use.md
deleted file mode 100644
index 8c8a868a35..0000000000
--- a/snippets/client-platforms/react/use.md
+++ /dev/null
@@ -1,17 +0,0 @@
-```js
-var Home = React.createClass({
-  // ...
-  showLock: function() {
-    // We receive lock from the parent component in this case
-    // If you instantiate it in this component, just do this.lock.show()
-    this.props.lock.show();
-  },
-
-  render: function() {
-    return (
-    
      
-      Sign In
-    
      );
-  }
-});
-```
diff --git a/snippets/client-platforms/socket-io/dependencies.md b/snippets/client-platforms/socket-io/dependencies.md
deleted file mode 100644
index 4b4db9befc..0000000000
--- a/snippets/client-platforms/socket-io/dependencies.md
+++ /dev/null
@@ -1,7 +0,0 @@
-```html
-
-
-
-
-
-```
diff --git a/snippets/client-platforms/socket-io/setup.md b/snippets/client-platforms/socket-io/setup.md
deleted file mode 100644
index 65467dcab9..0000000000
--- a/snippets/client-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/client-platforms/socket-io/use.md b/snippets/client-platforms/socket-io/use.md
deleted file mode 100644
index ef1d7fadb7..0000000000
--- a/snippets/client-platforms/socket-io/use.md
+++ /dev/null
@@ -1,30 +0,0 @@
-```js
-var userProfile;
-var userToken = localStorage.getItem('userToken');;
-
-lock.on('authenticated', function(authResult) {
-    lock.getProfile(authResult.idToken, function(error, profile) {
-        if (error) {
-            // Handle error
-            return;
-        }
-        localStorage.setItem('userToken', authResult.idToken);
-        userProfile = profile;
-        userToken = authResult.idToken;
-    });
-});
-
-if (userToken) {
-    lock.getProfile(userToken, 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/client-platforms/vanillajs/dependencies.md b/snippets/client-platforms/vanillajs/dependencies.md
deleted file mode 100644
index 1003dd9769..0000000000
--- a/snippets/client-platforms/vanillajs/dependencies.md
+++ /dev/null
@@ -1,7 +0,0 @@
-```html
-
-
-
-
-
-```
diff --git a/snippets/client-platforms/vanillajs/setup.md b/snippets/client-platforms/vanillajs/setup.md
deleted file mode 100644
index 877cd988fa..0000000000
--- a/snippets/client-platforms/vanillajs/setup.md
+++ /dev/null
@@ -1,8 +0,0 @@
-```js
-var lock = new Auth0Lock('${account.clientId}', '${account.namespace}', {
-    auth: { 
-        params: { scope: 'openid email' } //Details: https:///scopes
-    }
-}
-);
-```
diff --git a/snippets/client-platforms/vanillajs/use.md b/snippets/client-platforms/vanillajs/use.md
deleted file mode 100644
index 64f529706c..0000000000
--- a/snippets/client-platforms/vanillajs/use.md
+++ /dev/null
@@ -1,5 +0,0 @@
-```js
-document.getElementById('btn-login').addEventListener('click', function() {
-  lock.show();
-});
-```
diff --git a/snippets/client-platforms/vuejs/dependencies.md b/snippets/client-platforms/vuejs/dependencies.md
deleted file mode 100644
index a94a0ace9a..0000000000
--- a/snippets/client-platforms/vuejs/dependencies.md
+++ /dev/null
@@ -1,7 +0,0 @@
-```html
-
-
-
-
-
-```
\ No newline at end of file
diff --git a/snippets/client-platforms/vuejs/http.md b/snippets/client-platforms/vuejs/http.md
deleted file mode 100644
index 8cb94e4a5e..0000000000
--- a/snippets/client-platforms/vuejs/http.md
+++ /dev/null
@@ -1,17 +0,0 @@
-```js
-// app.js
-
-methods: {
-  // Make a secure call to the server by attaching
-  // the user's JWT as an Authorization header
-  getSecretThing() {
-    var jwtHeader = { 'Authorization': 'Bearer ' + localStorage.getItem('id_token') };
-    this.$http.get('http://localhost:3001/secured/ping', (data) => {
-      console.log(data);
-      this.secretThing = data.text;
-    }, {
-      headers: jwtHeader
-    }).error((err) => console.log(err));
-  }
-}
-```
\ No newline at end of file
diff --git a/snippets/client-platforms/vuejs/httpcall.md b/snippets/client-platforms/vuejs/httpcall.md
deleted file mode 100644
index 965bb8ba54..0000000000
--- a/snippets/client-platforms/vuejs/httpcall.md
+++ /dev/null
@@ -1,5 +0,0 @@
-```html
-  
-  
-  
-```
\ No newline at end of file
diff --git a/snippets/client-platforms/vuejs/interceptors.md b/snippets/client-platforms/vuejs/interceptors.md
deleted file mode 100644
index 59b604da34..0000000000
--- a/snippets/client-platforms/vuejs/interceptors.md
+++ /dev/null
@@ -1,17 +0,0 @@
-```js
-// app.js
-
-// Intercept responses and check for anything
-// unauthorized. If there is an unauthorized response,
-// log the user out and redirect to the home route
-Vue.http.interceptors.push({
-  response: function (response) {
-    if(response.status === 401) {
-      this.logout();
-      this.authenticated = false;
-      router.go('/');
-    }
-    return response;
-  }
-});
-```
\ No newline at end of file
diff --git a/snippets/client-platforms/vuejs/login.md b/snippets/client-platforms/vuejs/login.md
deleted file mode 100644
index b1a1fb6255..0000000000
--- a/snippets/client-platforms/vuejs/login.md
+++ /dev/null
@@ -1,43 +0,0 @@
-```js
-// app.js
-
-new Vue({
-  el: '#app',
-  data() {
-    return {
-      authenticated: false,
-      secretThing: '',
-      lock: new Auth0Lock('<%= account.clientId %>', '<%= account.namespace %>')
-    }
-  },
-  ready() {
-    var self = this;
-    
-    this.authenticated = checkAuth();
-    
-    this.lock.on('authenticated', (authResult) => {
-      console.log('authenticated');
-      localStorage.setItem('id_token', authResult.idToken);
-      this.lock.getProfile(authResult.idToken, (error, profile) => {
-        if (error) {
-          // Handle error
-          return;
-        }
-        // Set the token and user profile in local storage
-        localStorage.setItem('profile', JSON.stringify(profile));
-
-        this.authenticated = true;
-      });
-    });
-
-    this.lock.on('authorization_error', (error) => {
-      // handle error when authorizaton fails
-    });
-  },
-  methods: {
-    login() {
-      this.lock.show();
-    }
-  }
-});
-```
diff --git a/snippets/client-platforms/vuejs/loginlogout.md b/snippets/client-platforms/vuejs/loginlogout.md
deleted file mode 100644
index 0ab4adc995..0000000000
--- a/snippets/client-platforms/vuejs/loginlogout.md
+++ /dev/null
@@ -1,6 +0,0 @@
-```html
-  
-  
-  
-    
-```
\ No newline at end of file
diff --git a/snippets/client-platforms/vuejs/logout.md b/snippets/client-platforms/vuejs/logout.md
deleted file mode 100644
index 6c456c97e9..0000000000
--- a/snippets/client-platforms/vuejs/logout.md
+++ /dev/null
@@ -1,14 +0,0 @@
-```js
-// app.js
-
-methods: {
-  logout() {
-    // To log out, we just need to remove the token and profile
-    // from local storage
-    localStorage.removeItem('id_token');
-    localStorage.removeItem('profile');
-    this.authenticated = false;
-  },
-}
-
-```
\ No newline at end of file
diff --git a/snippets/client-platforms/vuejs/routing.md b/snippets/client-platforms/vuejs/routing.md
deleted file mode 100644
index 2781b4f07c..0000000000
--- a/snippets/client-platforms/vuejs/routing.md
+++ /dev/null
@@ -1,110 +0,0 @@
-```js
-// app.js
-
-// The public route can be viewed at any time
-var Public = Vue.extend({
-  template: `
      This is a public route
      `
-});
-
-// The private route can only be viewed when
-// the user is authenticated. The canActivate hook
-// uses checkAuth to return true if the user is authenticated
-// or false if not.
-var Private = Vue.extend({
-  template: `
      This is a private route. If you are reading this, you are authenticated.
      `,
-  route: {
-    canActivate() {
-      return checkAuth();
-    }
-  }
-});
-
-var App = Vue.extend({
-  template: `
-    
      Vue.js with Auth0
      
-    
-    
-    
      
-    
-    
-    
-    
      
-    
      
-      
-      
      {{secretThing}}
      
-    
      
-  `,
-  data() {
-    return {
-      authenticated: false,
-      secretThing: '',
-      lock: new Auth0Lock('<%= account.clientId %>', '<%= account.namespace %>')
-    }
-  },
-  // Check the user's auth status when the app
-  // loads to account for page refreshing
-  ready() {
-    this.authenticated = checkAuth();
-    this.lock.on('authenticated', (authResult) => {
-      console.log('authenticated');
-      localStorage.setItem('id_token', authResult.idToken);
-      this.lock.getProfile(authResult.idToken, (error, profile) => {
-        if (error) {
-          // Handle error
-          return;
-        }
-        // Set the token and user profile in local storage
-        localStorage.setItem('profile', JSON.stringify(profile));
-
-        this.authenticated = true;
-      });
-    });
-    this.lock.on('authorizaton_error', (error) => {
-      // handle error when authorizaton fails
-    });
-  },
-  methods: {
-    login() {
-      this.lock.show();
-    },
-    logout() {
-      // To log out, we just need to remove the token and profile
-      // from local storage
-      localStorage.removeItem('id_token');
-      localStorage.removeItem('profile');
-      this.authenticated = false;
-    },
-    // Make a secure call to the server by attaching
-    // the user's JWT as an Authorization header
-    getSecretThing() {
-      var jwtHeader = { 'Authorization': 'Bearer ' + localStorage.getItem('id_token') };
-      this.$http.get('http://localhost:3001/secured/ping', (data) => {
-        console.log(data);
-        this.secretThing = data.text;
-      }, {
-        headers: jwtHeader
-      }).error((err) => console.log(err));
-    }
-  }
-});
-
-// Utility to check auth status
-function checkAuth() {
-  return !!localStorage.getItem('id_token');
-}
-
-var router = new VueRouter({
-  history: true
-});
-
-router.map({
-  '/public': {
-    component: Public
-  },
-  '/private': {
-    component: Private
-  }
-});
-
-router.start(App, '#app');
-```
\ No newline at end of file
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/android/dependencies.md b/snippets/native-platforms/android/dependencies.md
deleted file mode 100644
index 22935a3eb2..0000000000
--- a/snippets/native-platforms/android/dependencies.md
+++ /dev/null
@@ -1,5 +0,0 @@
-```gradle
-compile 'com.auth0.android:lock:1.13.+'
-compile 'com.auth0.android:lock-facebook:2.0.+'
-compile 'com.auth0.android:lock-googleplus:2.0.+'
-```
diff --git a/snippets/native-platforms/android/setup.md b/snippets/native-platforms/android/setup.md
deleted file mode 100644
index 9952979adc..0000000000
--- a/snippets/native-platforms/android/setup.md
+++ /dev/null
@@ -1,20 +0,0 @@
-```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;
-  }
-}
-```
diff --git a/snippets/native-platforms/android/use.md b/snippets/native-platforms/android/use.md
deleted file mode 100644
index ed9d221075..0000000000
--- a/snippets/native-platforms/android/use.md
+++ /dev/null
@@ -1,4 +0,0 @@
-```java
-Intent lockIntent = new Intent(this, LockActivity.class);
-startActivity(lockIntent);
-```
diff --git a/snippets/native-platforms/cordova/dependencies.md b/snippets/native-platforms/cordova/dependencies.md
index 40299dff3f..0d5cafa0c9 100644
--- a/snippets/native-platforms/cordova/dependencies.md
+++ b/snippets/native-platforms/cordova/dependencies.md
@@ -1,3 +1,11 @@
+## Install the Dependencies
+
+The required dependencies for using Auth0 in a Cordova application are **auth0.js** and **auth0-cordova**. Install them with npm or yarn.
+
 ```bash
-cordova plugin add cordova-plugin-inappbrowser
-```
+# installation with npm
+npm install auth0-js @auth0/cordova --save
+
+# installation with yarn
+yarn add auth0-js @auth0/cordova
+```
\ No newline at end of file
diff --git a/snippets/native-platforms/cordova/setup.md b/snippets/native-platforms/cordova/setup.md
new file mode 100644
index 0000000000..8f08cdba8b
--- /dev/null
+++ b/snippets/native-platforms/cordova/setup.md
@@ -0,0 +1,20 @@
+### 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.
+
+```bash
+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
+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
+```
+
+## 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
new file mode 100644
index 0000000000..4df23083f6
--- /dev/null
+++ b/snippets/native-platforms/cordova/use.md
@@ -0,0 +1,169 @@
+
+```js
+// src/App.js
+
+var Auth0 = require('auth0-js');
+var Auth0Cordova = require('@auth0/cordova');
+
+function getBySelector(arg) {
+  return document.querySelector(arg);
+}
+
+function getById(id) {
+  return document.getElementById(id);
+}
+
+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() {
+  this.auth0 = new Auth0.Authentication({
+    domain: '${account.namespace}',
+    clientID: '${account.clientId}'
+  });
+  this.login = this.login.bind(this);
+  this.logout = this.logout.bind(this);
+}
+
+App.prototype.state = {
+  authenticated: false,
+  accessToken: false,
+  currentRoute: '/',
+  routes: {
+    '/': {
+      id: 'loading',
+      onMount: function(page) {
+        if (this.state.authenticated === true) {
+          return this.redirectTo('/home');
+        }
+        return this.redirectTo('/login');
+      }
+    },
+    '/login': {
+      id: 'login',
+      onMount: function(page) {
+        if (this.state.authenticated === true) {
+          return this.redirectTo('/home');
+        }
+        var loginButton = page.querySelector('.btn-login');
+        loginButton.addEventListener('click', this.login);
+      }
+    },
+    '/home': {
+      id: 'profile',
+      onMount: function(page) {
+        if (this.state.authenticated === false) {
+          return this.redirectTo('/login');
+        }
+        var logoutButton = page.querySelector('.btn-logout');
+        var avatar = page.querySelector('#avatar');
+        var profileCodeContainer = page.querySelector('.profile-json');
+        logoutButton.addEventListener('click', this.logout);
+        this.loadProfile(function(err, profile) {
+          if (err) {
+            profileCodeContainer.textContent = 'Error ' + err.message;
+          }
+          profileCodeContainer.textContent = JSON.stringify(profile, null, 4);
+          avatar.src = profile.picture;
+        });
+      }
+    }
+  }
+};
+
+App.prototype.run = function(id) {
+  this.container = getBySelector(id);
+  this.resumeApp();
+};
+
+App.prototype.loadProfile = function(cb) {
+  this.auth0.userInfo(this.state.accessToken, cb);
+};
+
+App.prototype.login = function(e) {
+  e.target.disabled = true;
+
+  var client = new Auth0Cordova({
+    domain: '${account.namespace}',
+    clientId: '${account.clientId}',
+    packageIdentifier: 'YOUR_PACKAGE_ID' // found in config.xml
+  });
+
+  var options = {
+    scope: 'openid profile',
+    audience: 'https://${account.namespace}/userinfo'
+  };
+  var self = this;
+  client.authorize(options, function(err, authResult) {
+    if (err) {
+      console.log(err);
+      return (e.target.disabled = false);
+    }
+    localStorage.setItem('access_token', authResult.accessToken);
+    self.resumeApp();
+  });
+};
+
+App.prototype.logout = function(e) {
+  localStorage.removeItem('access_token');
+  var url = getRedirectUrl();
+  openUrl(url);
+  this.resumeApp();
+};
+
+App.prototype.redirectTo = function(route) {
+  if (!this.state.routes[route]) {
+    throw new Error('Unknown route ' + route + '.');
+  }
+  this.state.currentRoute = route;
+  this.render();
+};
+
+App.prototype.resumeApp = function() {
+  var accessToken = localStorage.getItem('access_token');
+
+  if (accessToken) {
+    this.state.authenticated = true;
+    this.state.accessToken = accessToken;
+  } else {
+    this.state.authenticated = false;
+    this.state.accessToken = null;
+  }
+
+  this.render();
+};
+
+App.prototype.render = function() {
+  var currRoute = this.state.routes[this.state.currentRoute];
+  var currRouteEl = getById(currRoute.id);
+  var element = document.importNode(currRouteEl.content, true);
+  this.container.innerHTML = '';
+  this.container.appendChild(element);
+  currRoute.onMount.call(this, this.container);
+};
+
+module.exports = App;
+```
diff --git a/snippets/native-platforms/electron/dependencies.md b/snippets/native-platforms/electron/dependencies.md
deleted file mode 100644
index 93a90f5394..0000000000
--- a/snippets/native-platforms/electron/dependencies.md
+++ /dev/null
@@ -1,7 +0,0 @@
-```html
-
-
-
-
-
-```
diff --git a/snippets/native-platforms/ionic/appsetup.md b/snippets/native-platforms/ionic/appsetup.md
deleted file mode 100644
index b9bbac4401..0000000000
--- a/snippets/native-platforms/ionic/appsetup.md
+++ /dev/null
@@ -1,45 +0,0 @@
-```js
-// app.js
-angular.module('app', ['ionic', 'auth0', 'angular-storage', 'angular-jwt'])
-
-  .run(function ($ionicPlatform, $rootScope, auth, store, jwtHelper, $location) {
-
-    $ionicPlatform.ready(function () {
-      // Hide the accessory bar by default (remove this to show the accessory bar above the keyboard
-      // for form inputs)
-      if (window.cordova && window.cordova.plugins && window.cordova.plugins.Keyboard) {
-        cordova.plugins.Keyboard.hideKeyboardAccessoryBar(true);
-        cordova.plugins.Keyboard.disableScroll(true);
-
-      }
-      if (window.StatusBar) {
-        // org.apache.cordova.statusbar required
-        StatusBar.styleDefault();
-      }
-    });
-
-    // This hooks all auth events to check everything as soon as the app starts
-    auth.hookEvents();
-
-  })
-
-  .config(function ($stateProvider, $urlRouterProvider, authProvider, $httpProvider, jwtInterceptorProvider) {
-
-    $stateProvider
-      .state('home', {
-        url: '/',
-        templateUrl: 'app/home/home.html'
-      });
-
-    // if none of the above states are matched, use this as the fallback
-    $urlRouterProvider.otherwise('/');
-
-    // Initialized the Auth0 provider
-    authProvider.init({
-      domain: AUTH0_DOMAIN,
-      clientID: AUTH0_CLIENT_ID,
-      loginState: 'login'
-    });
-
-  });
-  ```
diff --git a/snippets/native-platforms/ionic/autologin.md b/snippets/native-platforms/ionic/autologin.md
deleted file mode 100644
index c4d4f11260..0000000000
--- a/snippets/native-platforms/ionic/autologin.md
+++ /dev/null
@@ -1,46 +0,0 @@
-```js
-angular.module('app', ['ionic', 'auth0', 'angular-storage', 'angular-jwt'])
-
-  .run(function ($ionicPlatform, $rootScope, auth, store, jwtHelper, $location) {
-    $ionicPlatform.ready(function () {
-      // Code omitted for brevity
-    });
-
-    // This hooks all auth events to check everything as soon as the app starts
-    auth.hookEvents();
-
-    //This event gets triggered on URL change
-    var refreshingToken = null;
-    $rootScope.$on('$locationChangeStart', function () {
-      var token = store.get('token');
-      var refreshToken = store.get('refreshToken');
-      if (token) {
-        if (!jwtHelper.isTokenExpired(token)) {
-          if (!auth.isAuthenticated) {
-            auth.authenticate(store.get('profile'), token);
-          }
-        } else {
-          if (refreshToken) {
-            if (refreshingToken === null) {
-              refreshingToken = auth.refreshIdToken(refreshToken).then(function (idToken) {
-                store.set('token', idToken);
-                auth.authenticate(store.get('profile'), idToken);
-              }).finally(function () {
-                refreshingToken = null;
-              });
-            }
-            return refreshingToken;
-          } else {
-            $location.path('/login');
-          }                          
-        }
-      }
-    });
-  })
-
-  .config(function ($stateProvider, $urlRouterProvider, authProvider, $httpProvider, jwtInterceptorProvider) {
-
-    // Code omitted for brevity
-
-  });
-```
\ No newline at end of file
diff --git a/snippets/native-platforms/ionic/bower.md b/snippets/native-platforms/ionic/bower.md
deleted file mode 100644
index 89c240208f..0000000000
--- a/snippets/native-platforms/ionic/bower.md
+++ /dev/null
@@ -1,3 +0,0 @@
-```bash
-bower install --save auth0-angular auth0-lock#9.2.2 a0-angular-storage angular-jwt
-```
diff --git a/snippets/native-platforms/ionic/dependencies.md b/snippets/native-platforms/ionic/dependencies.md
deleted file mode 100644
index 916865c6f6..0000000000
--- a/snippets/native-platforms/ionic/dependencies.md
+++ /dev/null
@@ -1,7 +0,0 @@
-```json
-"dependencies" : {
-  "auth0-angular": "4.*",
-  "a0-angular-storage": ">= 0.0.13",
-  "angular-jwt": ">= 0.0.9"
-},
-```
diff --git a/snippets/native-platforms/ionic/login-custom.md b/snippets/native-platforms/ionic/login-custom.md
deleted file mode 100644
index cdbe227349..0000000000
--- a/snippets/native-platforms/ionic/login-custom.md
+++ /dev/null
@@ -1,58 +0,0 @@
-```js
-(function () {
-  'use strict';
-
-  angular
-    .module('app')
-    .controller('LoginController', LoginController)
-
-  LoginController.$inject = ['$state', '$ionicPopup', 'auth', 'store'];
-
-  function LoginController($state, $ionicPopup, auth, store) {
-    var vm = this;
-
-    vm.login = login;
-    vm.loginWithGoogle = loginWithGoogle;
-
-    // Log in with username and password
-    function login() {
-      auth.signin({
-        connection: 'Username-Password-Authentication',  // The name of your database connection
-        username: vm.username,
-        password: vm.password,
-        authParams: {
-          scope: 'openid name email' //Details: https:///scopes
-        }
-      }, onLoginSuccess, onLoginFailed);
-    }
-
-    // Log in with Google
-    function loginWithGoogle() {
-      auth.signin({
-        popup: true,
-        connection: 'google-oauth2',
-        scope: 'openid name email' //Details: https:///scopes
-      }, onLoginSuccess, onLoginFailed);
-    }
-
-    // Login success callback which saves the user's tokens and redirects back to home 
-    function onLoginSuccess(profile, token, accessToken, state, refreshToken) {
-      store.set('profile', profile);
-      store.set('token', token);
-      store.set('accessToken', accessToken);
-      store.set('refreshToken', refreshToken);
-
-      $state.go("home");
-    }
-
-    // Login fall callback which displays error message
-    function onLoginFailed() {
-      var alertPopup = $ionicPopup.alert({
-        title: 'Login failed!',
-        template: 'Please check your credentials!'
-      });
-    }
-  }
-
-} ());
-```
diff --git a/snippets/native-platforms/ionic/login.md b/snippets/native-platforms/ionic/login.md
deleted file mode 100644
index dda0b5a294..0000000000
--- a/snippets/native-platforms/ionic/login.md
+++ /dev/null
@@ -1,38 +0,0 @@
-```js
-(function () {
-  'use strict';
-
-  angular
-    .module('app')
-    .controller('LoginController', LoginController)
-
-  LoginController.$inject = ['$scope', '$state', 'auth', 'store'];
-
-  function LoginController($scope, $state, auth, store) {
-    var vm = this;
-
-    function doLogin() {
-      auth.signin({
-        container: 'lock-container',
-        authParams: {
-          scope: 'openid offline_access',
-          device: 'Mobile device'
-        }
-      }, function (profile, token, accessToken, state, refreshToken) {
-        // Success callback
-        store.set('profile', profile);
-        store.set('token', token);
-        store.set('accessToken', accessToken);
-        store.set('refreshToken', refreshToken);
-        
-         $state.go("home");
-      }, function () {
-        // Error callback
-      });
-    }
-
-    doLogin();
-  }
-  
-} ());
-```
\ No newline at end of file
diff --git a/snippets/native-platforms/ionic/loginroute.md b/snippets/native-platforms/ionic/loginroute.md
deleted file mode 100644
index bdbb664d67..0000000000
--- a/snippets/native-platforms/ionic/loginroute.md
+++ /dev/null
@@ -1,32 +0,0 @@
-```js
-angular.module('app', ['ionic', 'auth0', 'angular-storage', 'angular-jwt'])
-  .run(function ($ionicPlatform, $rootScope, auth, store, jwtHelper, $location) {
-    // Code omitted for brevity
-  )
-  .config(function ($stateProvider, $urlRouterProvider, authProvider, $httpProvider, jwtInterceptorProvider) {
-
-    $stateProvider
-
-      // setup an abstract state for the tabs directive
-      .state('home', {
-        url: '/',
-        templateUrl: 'app/home/home.html'
-      })
-
-      .state('login', { // Notice: this state name matches the loginState property value to set in authProvider.init({...}) below...
-        url: '/login',
-        templateUrl: 'app/account/login.html'
-      })
-      ;
-
-    authProvider.init({
-      domain: AUTH0_DOMAIN,
-      clientID: AUTH0_CLIENT_ID,
-      loginState: 'login'
-    });
-
-    // if none of the above states are matched, use this as the fallback
-    $urlRouterProvider.otherwise('/');
-
-  });
-```  
\ No newline at end of file
diff --git a/snippets/native-platforms/ionic/loginview-custom.md b/snippets/native-platforms/ionic/loginview-custom.md
deleted file mode 100644
index 06d2a27e26..0000000000
--- a/snippets/native-platforms/ionic/loginview-custom.md
+++ /dev/null
@@ -1,18 +0,0 @@
-```html
-
-  
-      
      
-          
-          
-      
      
-      
-      
-        
-      
-```
\ No newline at end of file
diff --git a/snippets/native-platforms/ionic/loginview.md b/snippets/native-platforms/ionic/loginview.md
deleted file mode 100644
index f9b9428aae..0000000000
--- a/snippets/native-platforms/ionic/loginview.md
+++ /dev/null
@@ -1,11 +0,0 @@
-```html
-
-  
-    
      
-      
      
-          
      
-      
      
-    
      
-  
-
-```
\ No newline at end of file
diff --git a/snippets/native-platforms/ionic/logout.md b/snippets/native-platforms/ionic/logout.md
deleted file mode 100644
index b2627b4b79..0000000000
--- a/snippets/native-platforms/ionic/logout.md
+++ /dev/null
@@ -1,35 +0,0 @@
-```js
-(function () {
-    'use strict';
-
-    angular
-        .module('app')
-        .controller('HomeController', HomeController)
-
-    HomeController.$inject = ['$state', 'auth', 'store'];
-
-    function HomeController($state, auth, store) {
-        var vm = this;
-
-        vm.auth = auth;
-
-        vm.login = login;
-        vm.logout = logout;
-
-        function login() {
-            $state.go("login");
-        }
-
-        function logout() {
-            auth.signout();
-
-            store.remove('profile');
-            store.remove('token');
-            store.remove('accessToken');
-            store.remove('refreshToken');
-        }
-
-    }
-
-} ());
-```
\ No newline at end of file
diff --git a/snippets/native-platforms/ionic/references-custom.md b/snippets/native-platforms/ionic/references-custom.md
deleted file mode 100644
index e033df26d0..0000000000
--- a/snippets/native-platforms/ionic/references-custom.md
+++ /dev/null
@@ -1,10 +0,0 @@
-```html
-
-
-
-
-
-
-
-
-```
\ No newline at end of file
diff --git a/snippets/native-platforms/ionic/references.md b/snippets/native-platforms/ionic/references.md
deleted file mode 100644
index 4b455221e0..0000000000
--- a/snippets/native-platforms/ionic/references.md
+++ /dev/null
@@ -1,10 +0,0 @@
-```html
-
-
-
-
-
-
-
-
-```
\ No newline at end of file
diff --git a/snippets/native-platforms/ionic/use.md b/snippets/native-platforms/ionic/use.md
deleted file mode 100644
index 46c14131bb..0000000000
--- a/snippets/native-platforms/ionic/use.md
+++ /dev/null
@@ -1,29 +0,0 @@
-```js
-angular.module('starter.controllers', [])
-
-.controller('LoginCtrl', function(store, $scope, $location, auth) {
-  $scope.login = function() {
-    auth.signin({
-      authParams: {
-        scope: 'openid offline_access', //Details: https:///scopes
-        device: 'Mobile device'
-      }
-    }, function(profile, token, accessToken, state, refreshToken) {
-      // Success callback
-      store.set('profile', profile);
-      store.set('token', token);
-      store.set('refreshToken', refreshToken);
-      $location.path('/');
-    }, function() {
-      // Error callback
-    });
-  }
-}
-```
-
-```html
-
-
-
-
-```
diff --git a/snippets/native-platforms/ionic2/configure.md b/snippets/native-platforms/ionic2/configure.md
deleted file mode 100644
index 17a037f00c..0000000000
--- a/snippets/native-platforms/ionic2/configure.md
+++ /dev/null
@@ -1,51 +0,0 @@
-```js
-// src/app/app.module.ts
-
-import { NgModule } from '@angular/core';
-import { IonicApp, IonicModule } from 'ionic-angular';
-import { AuthApp } from './app.component';
-import { TabsPage } from '../pages/tabs/tabs';
-import { ProfilePage } from '../pages/profile/profile';
-import { PingPage } from '../pages/ping/ping';
-import { AuthConfig, AuthHttp } from 'angular2-jwt';
-import { AuthService } from '../services/auth/auth.service';
-import { Http } from '@angular/http';
-import { Storage } from '@ionic/storage';
-
-let storage: Storage = new Storage();
-
-export function getAuthHttp(http) {
-  return new AuthHttp(new AuthConfig({
-    globalHeaders: [{'Accept': 'application/json'}],
-    tokenGetter: (() => storage.get('id_token'))
-  }), http);
-}
-
-@NgModule({
-  declarations: [
-    AuthApp,
-    ProfilePage,
-    PingPage,
-    TabsPage
-  ],
-  imports: [
-    IonicModule.forRoot(AuthApp)
-  ],
-  bootstrap: [IonicApp],
-  entryComponents: [
-    AuthApp,
-    ProfilePage,
-    PingPage,
-    TabsPage
-  ],
-  providers: [
-    AuthService,
-    {
-      provide: AuthHttp,
-      useFactory: getAuthHttp,
-      deps: [Http]
-    }
-  ]
-})
-export class AppModule {}
-```
\ No newline at end of file
diff --git a/snippets/native-platforms/ionic2/configurerefresh.md b/snippets/native-platforms/ionic2/configurerefresh.md
deleted file mode 100644
index 19b60aed56..0000000000
--- a/snippets/native-platforms/ionic2/configurerefresh.md
+++ /dev/null
@@ -1,20 +0,0 @@
-```js
-// src/app/app.component.ts
-
-...
-
-export class AuthApp {
-  rootPage = TabsPage;
-
-  constructor(platform: Platform, private auth: AuthService) {
-    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();
-
-      // Schedule a token refresh on app start up
-      auth.startupTokenRefresh();
-    });
-  }
-}
-```
\ No newline at end of file
diff --git a/snippets/native-platforms/ionic2/dependencies.md b/snippets/native-platforms/ionic2/dependencies.md
deleted file mode 100644
index 9a36daa881..0000000000
--- a/snippets/native-platforms/ionic2/dependencies.md
+++ /dev/null
@@ -1,3 +0,0 @@
-```bash
-npm install angular2-jwt@0.1.27 --save
-```
diff --git a/snippets/native-platforms/ionic2/http.md b/snippets/native-platforms/ionic2/http.md
deleted file mode 100644
index cb611a85df..0000000000
--- a/snippets/native-platforms/ionic2/http.md
+++ /dev/null
@@ -1,43 +0,0 @@
-```js
-// src/pages/ping/ping.ts
-
-import {Component} from '@angular/core';
-import {Http} from '@angular/http';
-import {AuthHttp} from 'angular2-jwt';
-import {AuthService} from '../../services/auth/auth.service';
-import 'rxjs/add/operator/map';
-
-@Component({
-  templateUrl: 'ping.html',
-})
-export class PingPage {
-  message: string;
-  error: string;
-  
-  constructor(private http: Http, private authHttp: AuthHttp, public auth: AuthService) {}
-  
-  ping() {
-    // Change the endpoint up for
-    // one that points to your own server.
-    this.http.get('http://localhost:3001/ping')
-      .map(res => res.json())
-      .subscribe(
-        data => this.message = data.text,
-        err => this.error = err
-      );
-  }
-  
-  securedPing() {
-    // Here we use authHttp to make an authenticated
-    // request to the server. Change the endpoint up for
-    // one that points to your own server.
-    this.authHttp.get('http://localhost:3001/secured/ping')
-      .map(res => res.json())
-      .subscribe(
-        data => this.message = data.text,
-        err => this.error = err
-      );
-  }
-  
-}
-```
\ No newline at end of file
diff --git a/snippets/native-platforms/ionic2/profile.md b/snippets/native-platforms/ionic2/profile.md
deleted file mode 100644
index 83c08216a5..0000000000
--- a/snippets/native-platforms/ionic2/profile.md
+++ /dev/null
@@ -1,16 +0,0 @@
-```js
-// src/pages/profile/profile.ts
-
-import {Component} from '@angular/core';
-import {AuthService} from '../../services/auth/auth.service';
-
-@Component({
-  templateUrl: 'profile.html',
-})
-export class ProfilePage {
-  
-  // We need to inject AuthService so that we can
-  // use it in the view
-  constructor(public auth: AuthService) {}
-}
-```
\ No newline at end of file
diff --git a/snippets/native-platforms/ionic2/profiletemplate.md b/snippets/native-platforms/ionic2/profiletemplate.md
deleted file mode 100644
index fa9014eea5..0000000000
--- a/snippets/native-platforms/ionic2/profiletemplate.md
+++ /dev/null
@@ -1,33 +0,0 @@
-```html
-
-  
-
-  
-    Profile
-  
-
-
-
-  
-  
-  
-
-
-
-  
-  
-
-    
-      
-        
-      
-      
      {{ auth.user.nickname }}
      
-      
      {{ auth.user.email }}
      
-          
-  
-        
-  
-  
-  
-      
-```
\ No newline at end of file
diff --git a/snippets/native-platforms/ionic2/refresh.md b/snippets/native-platforms/ionic2/refresh.md
deleted file mode 100644
index 26f093a26f..0000000000
--- a/snippets/native-platforms/ionic2/refresh.md
+++ /dev/null
@@ -1,84 +0,0 @@
-```js
-// src/services/auth/auth.ts
-
-...
-
-public scheduleRefresh() {
-  // If the user is authenticated, use the token stream
-  // provided by angular2-jwt and flatMap the token
-
-  let source = Observable.of(this.idToken).flatMap(
-    token => {
-      console.log('token here', token);
-      // The delay to generate in this case is the difference
-      // between the expiry time and the issued at time
-      let jwtIat = this.jwtHelper.decodeToken(token).iat;
-      let jwtExp = this.jwtHelper.decodeToken(token).exp;
-      let iat = new Date(0);
-      let exp = new Date(0);
-      
-      let delay = (exp.setUTCSeconds(jwtExp) - iat.setUTCSeconds(jwtIat));
-      
-      return Observable.interval(delay);
-    });
-    
-  this.refreshSubscription = source.subscribe(() => {
-    this.getNewJwt();
-  });
-}
-
-public startupTokenRefresh() {
-  // If the user is authenticated, use the token stream
-  // provided by angular2-jwt and flatMap the token
-  if (this.authenticated()) {
-    let source = Observable.of(this.idToken).flatMap(
-      token => {
-        // Get the expiry time to generate
-        // a delay in milliseconds
-        let now: number = new Date().valueOf();
-        let jwtExp: number = this.jwtHelper.decodeToken(token).exp;
-        let exp: Date = new Date(0);
-        exp.setUTCSeconds(jwtExp);
-        let delay: number = exp.valueOf() - now;
-        
-        // Use the delay in a timer to
-        // run the refresh at the proper time
-        return Observable.timer(delay);
-      });
-    
-      // Once the delay time from above is
-      // reached, get a new JWT and schedule
-      // additional refreshes
-      source.subscribe(() => {
-        this.getNewJwt();
-        this.scheduleRefresh();
-      });
-  }
-}
-
-public unscheduleRefresh() {
-  // Unsubscribe fromt the refresh
-  if (this.refreshSubscription) {
-    this.refreshSubscription.unsubscribe();
-  }
-}
-
-public getNewJwt() {
-  // Get a new JWT from Auth0 using the refresh token saved
-  // in local storage
-  this.storage.get('refresh_token').then(token => {
-    this.auth0.refreshToken(token, (err, delegationRequest) => {
-      if (err) {
-        alert(err);
-      }
-      this.storage.set('id_token', delegationRequest.id_token);
-      this.idToken = delegationRequest.id_token;
-    });
-  }).catch(error => {
-    console.log(error);
-  });
-  
-}
-
-...  
-```
\ No newline at end of file
diff --git a/snippets/native-platforms/ionic2/setup.md b/snippets/native-platforms/ionic2/setup.md
deleted file mode 100644
index dac0498db7..0000000000
--- a/snippets/native-platforms/ionic2/setup.md
+++ /dev/null
@@ -1,10 +0,0 @@
-```html
-
-
-
-
-
-
-
-
-```
diff --git a/snippets/native-platforms/ionic2/use.md b/snippets/native-platforms/ionic2/use.md
deleted file mode 100644
index b9acf94041..0000000000
--- a/snippets/native-platforms/ionic2/use.md
+++ /dev/null
@@ -1,91 +0,0 @@
-```js
-// src/services/auth/auth.service.ts
-
-import { Storage } from '@ionic/storage';
-import { AuthHttp, JwtHelper, tokenNotExpired } from 'angular2-jwt';
-import { Injectable, NgZone } from '@angular/core';
-import { Observable } from 'rxjs/Rx';
-import { Auth0Vars } from '../../auth0-variables';
-
-// Avoid name not found warnings
-declare var Auth0: any;
-declare var Auth0Lock: any;
-
-@Injectable()
-export class AuthService {
-
-  jwtHelper: JwtHelper = new JwtHelper();
-  auth0 = new Auth0({clientID: '<%= account.clientId %>', domain: '<%= account.namespace %>' });
-  lock = new Auth0Lock('<%= account.clientId %>', '<%= account.namespace %>', {
-    auth: {
-      redirect: false,
-      params: {
-        scope: 'openid offline_access',
-      }
-    }
-  });
-  storage: Storage = new Storage();
-  refreshSubscription: any;
-  user: Object;
-  zoneImpl: NgZone;
-  idToken: string;
-  
-  constructor(private authHttp: AuthHttp, zone: NgZone) {
-    this.zoneImpl = zone;
-    // Check if there is a profile saved in local storage
-    this.storage.get('profile').then(profile => {
-      this.user = JSON.parse(profile);
-    }).catch(error => {
-      console.log(error);
-    });
-
-    this.storage.get('id_token').then(token => {
-      this.idToken = token;
-    });
-
-    this.lock.on('authenticated', authResult => {
-      this.storage.set('id_token', authResult.idToken);
-      this.idToken = authResult.idToken;
-
-      // Fetch profile information
-      this.lock.getProfile(authResult.idToken, (error, profile) => {
-        if (error) {
-          // Handle error
-          alert(error);
-          return;
-        }
-
-        profile.user_metadata = profile.user_metadata || {};
-        this.storage.set('profile', JSON.stringify(profile));
-        this.user = profile;
-      });
-
-      this.lock.hide();
-
-      this.storage.set('refresh_token', authResult.refreshToken);
-      this.zoneImpl.run(() => this.user = authResult.profile);
-      // Schedule a token refresh
-      this.scheduleRefresh();
-
-    });    
-  }
-
-  public authenticated() { 
-    return tokenNotExpired('id_token', this.idToken);
-  }
-  
-  public login() {
-    // Show the Auth0 Lock widget
-    this.lock.show();
-  }
-  
-  public logout() {
-    this.storage.remove('profile');
-    this.storage.remove('id_token');
-    this.idToken = null;
-    this.storage.remove('refresh_token');
-    this.zoneImpl.run(() => this.user = null);
-    // Unschedule the token refresh
-    this.unscheduleRefresh();
-  }
-```
\ No newline at end of file
diff --git a/snippets/native-platforms/ionic3/use.md b/snippets/native-platforms/ionic3/use.md
new file mode 100644
index 0000000000..b7a3b28554
--- /dev/null
+++ b/snippets/native-platforms/ionic3/use.md
@@ -0,0 +1,81 @@
+```js
+// src/services/auth.service.ts
+import { Injectable, NgZone } from '@angular/core';
+import { Storage } from '@ionic/storage';
+
+// Import Auth0Cordova and auth0.js
+import Auth0Cordova from '@auth0/cordova';
+import * as auth0 from 'auth0-js';
+
+const AUTH_CONFIG = {
+  // Needed for Auth0 (capitalization: ID):
+  clientID: '${account.clientId}',
+  // Needed for Auth0Cordova (capitalization: Id):
+  clientId: '${account.clientId}',
+  domain: '${account.namespace}',
+  callbackURL: location.href,
+  packageIdentifier: 'YOUR_PACKAGE_ID' // config.xml widget ID
+};
+
+@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;
+  }
+}
+```
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-objc/dependencies.md b/snippets/native-platforms/ios-objc/dependencies.md
index dbbc87d2de..0c6618483a 100644
--- a/snippets/native-platforms/ios-objc/dependencies.md
+++ b/snippets/native-platforms/ios-objc/dependencies.md
@@ -1,3 +1,3 @@
 ```ruby
-pod 'Lock', '~> 1.24'
+pod 'Lock', '~> 1.28'
 ```
diff --git a/snippets/native-platforms/ios-objc/setup_wrapper.md b/snippets/native-platforms/ios-objc/setup_wrapper.md
new file mode 100644
index 0000000000..2887ea363d
--- /dev/null
+++ b/snippets/native-platforms/ios-objc/setup_wrapper.md
@@ -0,0 +1,6 @@
+Import the Swift wrapper and Auth0 library:
+
+```objc
+#import "Auth0Sample-Swift.h"
+@import Auth0;
+```
diff --git a/snippets/native-platforms/ios-swift/dependencies.md b/snippets/native-platforms/ios-swift/dependencies.md
deleted file mode 100644
index f8bbac461c..0000000000
--- a/snippets/native-platforms/ios-swift/dependencies.md
+++ /dev/null
@@ -1,4 +0,0 @@
-```ruby
-use_frameworks!
-pod 'Lock', '~> 1.24'
-```
diff --git a/snippets/native-platforms/ios-swift/setup.md b/snippets/native-platforms/ios-swift/setup.md
index 91d474ab65..3da6e59719 100644
--- a/snippets/native-platforms/ios-swift/setup.md
+++ b/snippets/native-platforms/ios-swift/setup.md
@@ -1,5 +1,3 @@
 ```swift
-import Lock
-
-let lock = A0Lock.sharedLock()
+import Auth0
 ```
diff --git a/snippets/native-platforms/ios-swift/use.md b/snippets/native-platforms/ios-swift/use.md
index 33184477df..1fa4783242 100644
--- a/snippets/native-platforms/ios-swift/use.md
+++ b/snippets/native-platforms/ios-swift/use.md
@@ -1,13 +1,19 @@
 ```swift
-import Lock
+// HomeViewController.swift
 
-let controller = A0Lock.sharedLock().newLockViewController()
-controller.closable = true
-controller.onAuthenticationBlock = { (profile, token) in
-  // Do something with token & profile. e.g.: save them.
-  // Lock will not save the Token and the profile for you.
-  // And dismiss the ViewController
-  self.dismissViewControllerAnimated(true, completion: nil)
+Auth0
+    .webAuth()
+    .scope("openid profile")
+    .audience("https://${account.namespace}/userinfo")
+    .start { result in
+        switch result {
+        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 login page
+            print("Credentials: \(credentials)")
+        }
 }
-self.presentViewController(controller, animated: true, completion: nil)
 ```
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/windows-phone/dependencies.md b/snippets/native-platforms/windows-phone/dependencies.md
deleted file mode 100644
index 6152ab8a67..0000000000
--- a/snippets/native-platforms/windows-phone/dependencies.md
+++ /dev/null
@@ -1,3 +0,0 @@
-```Powershell
-Install-Package Auth0.WindowsPhone
-```
diff --git a/snippets/native-platforms/windows-phone/setup.md b/snippets/native-platforms/windows-phone/setup.md
deleted file mode 100644
index a1a3338a3d..0000000000
--- a/snippets/native-platforms/windows-phone/setup.md
+++ /dev/null
@@ -1,32 +0,0 @@
-Add `static` property to `App` class to save your authentication client
-
-```cs
-public static Auth0Client Auth0 { get; private set; }
-```
-
-Provide your domain and application's **Client ID** as parameters when creating the client instance and save to that property:
-
-For Windows Phone XAML add initialization code to the end of `App` constructor
-
-```cs
-public App()
-{
-    this.InitializeComponent();
-    this.Suspending += this.OnSuspending;
-
-    Auth0 auth0Client = new Auth0Client("<%= account.namespace %>", "<%= account.clientId %>");
-}
-```
-
-For Windows Phone Silverlight add initialization code to the end of `InitializePhoneApplication` method before `phoneApplicationInitialized = true;`
-
-```cs
-private void InitializePhoneApplication()
-{
-    ...
-    Auth0 Auth0Client auth0Client = new Auth0Client("<%= account.namespace %>", "<%= account.clientId %>");
-
-    // Ensure we don't initialize again
-    phoneApplicationInitialized = true;
-}
-```
diff --git a/snippets/native-platforms/windows-phone/use.md b/snippets/native-platforms/windows-phone/use.md
deleted file mode 100644
index ec34e3137f..0000000000
--- a/snippets/native-platforms/windows-phone/use.md
+++ /dev/null
@@ -1,30 +0,0 @@
-The simplest way is to simply call:
-```cs
-try
-{
-    var user = await App.Auth0.LoginAsync();
-    // Do whatever you need with a user
-}
-catch (AuthenticationCancelException)
-{
-    // Handle case when user canceled authentication
-}
-catch (AuthenticationErrorException)
-{
-    // Handle case when some error happen while authentication
-}
-catch (AuthenticationException)
-{
-    // Handle all Auth0 Authentication error cases
-}
-```
-
-If you want to specify a particular connection you can do that using:
-```cs
-var user = await App.Auth0.LoginAsync("{CONNECTION_NAME}");
-```
-
-Alternatively, if you want to allow database users to sign in and you have their credentials in memory:
-```cs
-var user = await App.Auth0.LoginAsync("{CONNECTION_NAME}", "{USER_NAME}", "{PASSWORD}");
-```
diff --git a/snippets/native-platforms/windows-uwp-csharp/dependencies.md b/snippets/native-platforms/windows-uwp-csharp/dependencies.md
index ba1bd72c5e..6d343b6463 100644
--- a/snippets/native-platforms/windows-uwp-csharp/dependencies.md
+++ b/snippets/native-platforms/windows-uwp-csharp/dependencies.md
@@ -1,3 +1,3 @@
 ```powershell
-Install-Package Auth0.Windows.UWP
+Install-Package Auth0.OidcClient.UWP
 ```
diff --git a/snippets/native-platforms/windows-uwp-csharp/setup.md b/snippets/native-platforms/windows-uwp-csharp/setup.md
index 4acb1627d7..a473bb85a0 100644
--- a/snippets/native-platforms/windows-uwp-csharp/setup.md
+++ b/snippets/native-platforms/windows-uwp-csharp/setup.md
@@ -1,7 +1,11 @@
 ```cs
-using Auth0.LoginClient;
+// MainPage.xaml.cs
 
-var auth0 = new Auth0Client(
-  "${account.namespace}",
-  "${account.clientId}");
+using Auth0.OidcClient;
+
+var client = new Auth0Client(new Auth0ClientOptions
+{
+    Domain = "${account.namespace}",
+    ClientId = "${account.clientId}"
+});
 ```
diff --git a/snippets/native-platforms/windows-uwp-csharp/use.md b/snippets/native-platforms/windows-uwp-csharp/use.md
index c11348a332..c624b31bb9 100644
--- a/snippets/native-platforms/windows-uwp-csharp/use.md
+++ b/snippets/native-platforms/windows-uwp-csharp/use.md
@@ -1,9 +1,3 @@
 ```cs
-var user = await auth0.LoginAsync();
-/*
-    Use this object to do wonderful things, e.g.:
-      - get user email => user.Profile["email"].ToString()
-      - get Windows Azure AD groups => user.Profile["groups"]
-      - etc.
-*/
+var loginResult = await client.LoginAsync();
 ```
diff --git a/snippets/native-platforms/windows-uwp-javascript/dependencies.md b/snippets/native-platforms/windows-uwp-javascript/dependencies.md
deleted file mode 100644
index bdbd1c797f..0000000000
--- a/snippets/native-platforms/windows-uwp-javascript/dependencies.md
+++ /dev/null
@@ -1,3 +0,0 @@
-```powershell
-Install-Package Auth0.Windows.UWP.JavaScript
-```
diff --git a/snippets/native-platforms/windows-uwp-javascript/setup.md b/snippets/native-platforms/windows-uwp-javascript/setup.md
deleted file mode 100644
index cf517672d7..0000000000
--- a/snippets/native-platforms/windows-uwp-javascript/setup.md
+++ /dev/null
@@ -1,3 +0,0 @@
-```html
-
-```
diff --git a/snippets/native-platforms/windows-uwp-javascript/use.md b/snippets/native-platforms/windows-uwp-javascript/use.md
deleted file mode 100644
index f6bbc8c050..0000000000
--- a/snippets/native-platforms/windows-uwp-javascript/use.md
+++ /dev/null
@@ -1,16 +0,0 @@
-```javascript
-
-var auth0 = new Auth0Client(
-  "${account.namespace}",
-  "${account.clientId}");
-
-auth0.Login(function (err, result) {
-  if (err) return err;
-  /*
-  Use result to do wonderful things, e.g.:
-    - get user email => result.Profile.email
-    - get Windows Azure AD groups => result.Profile.groups
-    - etc.
-  */
-});
-```
diff --git a/snippets/native-platforms/wpf-winforms/dependencies.md b/snippets/native-platforms/wpf-winforms/dependencies.md
index 52b31c3f10..eabef4f03b 100644
--- a/snippets/native-platforms/wpf-winforms/dependencies.md
+++ b/snippets/native-platforms/wpf-winforms/dependencies.md
@@ -1,3 +1,8 @@
-```powershell
-Install-Package Auth0.WinformsOrWPF
+```text
+Auth0.OidcClient.WPF
 ```
+or 
+
+```text
+Auth0.OidcClient.WinForms
+```
\ No newline at end of file
diff --git a/snippets/native-platforms/wpf-winforms/setup.md b/snippets/native-platforms/wpf-winforms/setup.md
index f07a6b7907..8191bcc18a 100644
--- a/snippets/native-platforms/wpf-winforms/setup.md
+++ b/snippets/native-platforms/wpf-winforms/setup.md
@@ -1,7 +1,13 @@
 ```cs
-using Auth0.Windows;
+// Form1.cs
 
-var auth0 = new Auth0Client(
-  "${account.namespace}",
-  "${account.clientId}");
+using Auth0.OidcClient;
+
+Auth0ClientOptions clientOptions = new Auth0ClientOptions
+{
+    Domain = "${account.namespace}",
+    ClientId = "${account.clientId}"
+};
+client = new Auth0Client(clientOptions);
+clientOptions.PostLogoutRedirectUri = clientOptions.RedirectUri;
 ```
diff --git a/snippets/native-platforms/wpf-winforms/use.md b/snippets/native-platforms/wpf-winforms/use.md
index 08a1ef7888..c624b31bb9 100644
--- a/snippets/native-platforms/wpf-winforms/use.md
+++ b/snippets/native-platforms/wpf-winforms/use.md
@@ -1,9 +1,3 @@
 ```cs
-var user = await auth0.LoginAsync(this);
-/*
-    Use this object to do wonderful things, e.g.:
-      - get user email => user.Profile["email"].ToString()
-      - get Windows Azure AD groups => user.Profile["groups"]
-      - etc.
-*/
+var loginResult = await client.LoginAsync();
 ```
diff --git a/snippets/native-platforms/xamarin/dependencies.md b/snippets/native-platforms/xamarin/dependencies.md
index 3bea53d757..10c16887f3 100644
--- a/snippets/native-platforms/xamarin/dependencies.md
+++ b/snippets/native-platforms/xamarin/dependencies.md
@@ -1,5 +1,19 @@
-In order to include `Xamarin.Auth0Client` component, please perform the following steps:
+If you are using Visual Studio, simply open the Package Manager Console (View -> Other Windows -> Package Manager Console), and install the package:
 
-  1. With the project loaded in Xamarin Studio (or Visual Studio), right-click on the `Components` folder in the `Solution Explorer` and select `Get More Components`.
-  2. Search and double-click on `Auth0Client` component.
-  3. From the component page, select the `Add to Project` button to download the component and add it to the current project.
+**For Android:**
+
+```text
+Install-Package Auth0.OidcClient.AndroidX
+```
+
+**For iOS:**
+
+```text
+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.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 203fc2bd06..59c2df8db5 100644
--- a/snippets/native-platforms/xamarin/setup.md
+++ b/snippets/native-platforms/xamarin/setup.md
@@ -1,7 +1,9 @@
 ```cs
-using Auth0.SDK;
+using Auth0.OidcClient;
 
-var auth0 = new Auth0Client(
-  "${account.namespace}",
-  "${account.clientId}");
-```
+var client = new Auth0Client(new Auth0ClientOptions
+{
+    Domain = "${account.namespace}",
+    ClientId = "${account.clientId}"
+}, this);
+```
\ No newline at end of file
diff --git a/snippets/native-platforms/xamarin/use.md b/snippets/native-platforms/xamarin/use.md
deleted file mode 100644
index c5337e3ce4..0000000000
--- a/snippets/native-platforms/xamarin/use.md
+++ /dev/null
@@ -1,9 +0,0 @@
-```cs
-// 'this' could be a Context object (Android) or UIViewController, UIView, UIBarButtonItem (iOS)
-var user = await auth0.LoginAsync(this);
-/*
-- get user email => user.Profile["email"].ToString()
-- get Windows Azure AD groups => user.Profile["groups"]
-- etc.
-*/
-```
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/dependencies.md b/snippets/server-apis/falcor/dependencies.md
index 9da6c915df..5d004fe4a7 100644
--- a/snippets/server-apis/falcor/dependencies.md
+++ b/snippets/server-apis/falcor/dependencies.md
@@ -1,3 +1,3 @@
 ```bash
-npm install express-jwt falcor-express falcor-router --save
+npm install express-jwt express-jwt-authz falcor-express falcor-router falcor-http-datasource --save
 ```
diff --git a/snippets/server-apis/falcor/setup.md b/snippets/server-apis/falcor/setup.md
index 5d89aa651d..fc2c7615a9 100644
--- a/snippets/server-apis/falcor/setup.md
+++ b/snippets/server-apis/falcor/setup.md
@@ -1,12 +1,54 @@
 ```js
-var express       = require('express');
-var app           = express();
-var jwt           = require('express-jwt');
-var falcorExpress = require('falcor-express');
-var Router        = require('falcor-router');
-
-var authenticate = jwt({
-  secret: '<%= account.clientSecret %>',
-  audience: '<%= account.clientId %>'
+// server.js
+
+const express = require('express');
+const app = express();
+const jwt = require('express-jwt');
+const jwksRsa = require('jwks-rsa');
+const falcorExpress = require('falcor-express');
+const Router = require('falcor-router');
+
+// 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']
+});
+```
+
+```js
+// api.js
+
+const express = require('express');
+const app = express();
+const jwt = require('express-jwt');
+const jwksRsa = require('jwks-rsa');
+const falcor = require('falcor');
+const HttpDataSource = require('falcor-http-datasource');
+
+const checkJwt = jwt({
+  secret: jwksRsa.expressJwtSecret({
+    cache: true,
+    rateLimit: true,
+    jwksRequestsPerMinute: 5,
+    jwksUri: `https://${process.env.AUTH0_DOMAIN}/.well-known/jwks.json`
+  }),
+
+  audience: process.env.AUTH0_AUDIENCE,
+  issuer: `https://${process.env.AUTH0_DOMAIN}/`,
+  algorithms: ['RS256']
 });
 ```
diff --git a/snippets/server-apis/falcor/use.md b/snippets/server-apis/falcor/use.md
index 7faea8d23e..9d593612c6 100644
--- a/snippets/server-apis/falcor/use.md
+++ b/snippets/server-apis/falcor/use.md
@@ -1,9 +1,40 @@
 ```js
-app.use('/api/model.json', authenticate, falcorExpress.dataSourceRoute(function(req, res) 
-  {
-    return new Router([
-      {...}
-    ]);
+// server.js
+
+const checkScopes = jwtAuthz([ 'read:messages' ]);
+
+app.use('/api/private-scoped/model.json', checkJwt, checkScopes, falcorExpress.dataSourceRoute(function(req, res) {
+  return new Router([
+    {
+      route: 'private_scoped.message',
+      get: function(pathSet) {
+        return { path:['private_scoped', 'message'], value: 'Hello from a private endpoint! You need to be authenticated and have a scope of read:messages to see this.' };
+      }
+    }
+  ]);
+}));
+```
+
+```js
+// api.js
+
+app.get('/api/private-scoped', 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-scoped/model.json',
+        {
+          headers: { 'Authorization': 'Bearer ' + token }
+        })
+    });
+
+  try {
+    const message = await model.getValue(['private_scoped', 'message']);
+
+    res.json({ message: message });
+  } catch(err) {
+    res.status(403).json(err[0].value);
   }
-));
+});
 ```
\ No newline at end of file
diff --git a/snippets/server-apis/java-spring-security/configure.md b/snippets/server-apis/java-spring-security/configure.md
index 58d5ca62ff..44b5ecab14 100644
--- a/snippets/server-apis/java-spring-security/configure.md
+++ b/snippets/server-apis/java-spring-security/configure.md
@@ -2,19 +2,18 @@
 import org.springframework.boot.SpringApplication;
 import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
 import org.springframework.boot.autoconfigure.SpringBootApplication;
-import org.springframework.context.annotation.AnnotationConfigApplicationContext;
 import org.springframework.context.annotation.ComponentScan;
 import org.springframework.context.annotation.PropertySource;
 import org.springframework.context.annotation.PropertySources;
 
 @SpringBootApplication
-@ComponentScan(basePackages = {"com.auth0.spring.security.api"})
+@ComponentScan(basePackages = "com.auth0")
 @EnableAutoConfiguration
 @PropertySources({
-  @PropertySource("classpath:application.properties"),
-  @PropertySource("classpath:auth0.properties")
+		@PropertySource("classpath:application.properties"),
+		@PropertySource("classpath:auth0.properties")
 })
 /*
  * Your application class
  */
-```
+```
\ 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 7a81ed4316..ca19b93476 100644
--- a/snippets/server-apis/java-spring-security/dependencies-gradle.md
+++ b/snippets/server-apis/java-spring-security/dependencies-gradle.md
@@ -1,8 +1,3 @@
 ```groovy
-dependencies {
-  /*
-   * Existing dependencies
-   */
-  compile 'com.auth0:auth0-spring-security-api:0.3.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 07c240ffd2..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
-  0.3.3
+  1.1.0
 
-```
+```
\ No newline at end of file
diff --git a/snippets/server-apis/java-spring-security/setup.md b/snippets/server-apis/java-spring-security/setup.md
index f05a58ed6c..7fd5b69134 100644
--- a/snippets/server-apis/java-spring-security/setup.md
+++ b/snippets/server-apis/java-spring-security/setup.md
@@ -1,13 +1,4 @@
 ```properties
-auth0.domain:${account.namespace}
 auth0.issuer:https://${account.namespace}/
-auth0.clientId:${account.clientId}
-auth0.clientSecret:${account.clientSecret}
-auth0.securedRoute: NOT_USED
-auth0.base64EncodedSecret: false
-auth0.authorityStrategy: ROLES
-auth0.defaultAuth0ApiSecurityEnabled: false
-auth0.signingAlgorithm: HS256
-#auth0.signingAlgorithm: RS256
-#auth0.publicKeyPath: certificate/cert.pem
-```
+auth0.apiAudience:${apiIdentifier}
+```
\ No newline at end of file
diff --git a/snippets/server-apis/nginx/setup.md b/snippets/server-apis/nginx/setup.md
index 29f6a15299..37255128aa 100644
--- a/snippets/server-apis/nginx/setup.md
+++ b/snippets/server-apis/nginx/setup.md
@@ -2,5 +2,4 @@
 # nginx.conf:
 
 env JWT_SECRET;
-env JWT_SECRET_IS_BASE64_ENCODED;
 ```
diff --git a/snippets/server-apis/php-laravel/dependencies.md b/snippets/server-apis/php-laravel/dependencies.md
deleted file mode 100644
index bbcc9ea6d6..0000000000
--- a/snippets/server-apis/php-laravel/dependencies.md
+++ /dev/null
@@ -1 +0,0 @@
-To install this plugin run `composer require auth0/login:"~4.0"`
\ No newline at end of file
diff --git a/snippets/server-apis/php-laravel/setup.md b/snippets/server-apis/php-laravel/setup.md
deleted file mode 100644
index 23420165d6..0000000000
--- a/snippets/server-apis/php-laravel/setup.md
+++ /dev/null
@@ -1,6 +0,0 @@
-```php
-'providers' => array(
-    // ...
-    'Auth0\Login\LoginServiceProvider',
-);
-```
diff --git a/snippets/server-apis/php-laravel/use.md b/snippets/server-apis/php-laravel/use.md
deleted file mode 100644
index 827b1f2b24..0000000000
--- a/snippets/server-apis/php-laravel/use.md
+++ /dev/null
@@ -1,5 +0,0 @@
-```php
-Route::get('/api/protected', array('middleware' => 'auth0.jwt', function() {
-    return "Hello " . Auth0::jwtuser()->name;
-}));
-```
diff --git a/snippets/server-apis/php-symfony/dependencies.md b/snippets/server-apis/php-symfony/dependencies.md
index 38af52ee7f..69aa7f5f56 100644
--- a/snippets/server-apis/php-symfony/dependencies.md
+++ b/snippets/server-apis/php-symfony/dependencies.md
@@ -1,3 +1,3 @@
 ```
-composer require auth0/jwt-auth-bundle:"~1.2"
+composer require auth0/jwt-auth-bundle:"^3.0"
 ```
diff --git a/snippets/server-apis/php-symfony/setup.md b/snippets/server-apis/php-symfony/setup.md
index f3ca9aa770..afacb9379a 100644
--- a/snippets/server-apis/php-symfony/setup.md
+++ b/snippets/server-apis/php-symfony/setup.md
@@ -1,6 +1,6 @@
 ```yml
 jwt_auth:
-    client_id:     ${account.clientId}
-    client_secret: ${account.clientSecret}
-    secret_base64_encoded: false
+    domain: ${account.namespace}
+    authorized_issuer: https://${account.namespace}/
+    api_identifier: ${apiIdentifier}
 ```
diff --git a/snippets/server-apis/php-symfony/use.md b/snippets/server-apis/php-symfony/use.md
index 60be4cf54b..82a4c6b268 100644
--- a/snippets/server-apis/php-symfony/use.md
+++ b/snippets/server-apis/php-symfony/use.md
@@ -13,6 +13,7 @@ security:
                 authenticator: jwt_auth.jwt_authenticator
 
     access_control:
-        - { path: ^/api/login, roles: IS_AUTHENTICATED_ANONYMOUSLY }
-        - { path: ^/api, roles: ROLE_OAUTH_USER }
-```
+        - { path: ^/api/private-scoped, roles: ROLE_OAUTH_READER }
+        - { path: ^/api/private, roles: ROLE_OAUTH_AUTHENTICATED }
+        - { path: ^/api/public, roles: IS_AUTHENTICATED_ANONYMOUSLY }
+```
\ No newline at end of file
diff --git a/snippets/server-apis/php/setup.md b/snippets/server-apis/php/setup.md
index 8b66a04427..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'];
 
@@ -21,7 +21,7 @@
 
     // validate the token
     $token = str_replace('Bearer ', '', $authorizationHeader);
-    $secret = '${account.clientSecret}';
+    $secret = 'YOUR_CLIENT_SECRET';
     $client_id = '${account.clientId}';
     $decoded_token = null;
     try {
diff --git a/snippets/server-apis/python/setup.md b/snippets/server-apis/python/setup.md
index 8fd42b1231..f9afc8db2c 100644
--- a/snippets/server-apis/python/setup.md
+++ b/snippets/server-apis/python/setup.md
@@ -45,7 +45,7 @@ def requires_auth(f):
                 client_secret,
                 audience=client_id
             )
-        except jwt.ExpiredSignature:
+        except jwt.ExpiredSignatureError:
             return handle_error({'code': 'token_expired',
                                 'description': 'token is expired'}, 401)
         except jwt.InvalidAudienceError:
diff --git a/snippets/server-apis/python/use.md b/snippets/server-apis/python/use.md
index 96b59a9aa4..15a5fe5984 100644
--- a/snippets/server-apis/python/use.md
+++ b/snippets/server-apis/python/use.md
@@ -2,15 +2,30 @@
 # Controllers API
 
 # This doesn't need authentication
-@app.route("/ping")
-@cross_origin(headers=['Content-Type', 'Authorization'])
-def ping():
-    return "All good. You don't need to be authenticated to call this"
+@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("/secured/ping")
-@cross_origin(headers=['Content-Type', 'Authorization'])
+# This needs authentication
+@APP.route("/api/private")
+@cross_origin(headers=["Content-Type", "Authorization"])
 @requires_auth
-def securedPing():
-    return "All good. You only get this message if you're authenticated"
+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/rails/dependencies.md b/snippets/server-apis/rails/dependencies.md
index edf948e438..602cb2ee93 100644
--- a/snippets/server-apis/rails/dependencies.md
+++ b/snippets/server-apis/rails/dependencies.md
@@ -1,3 +1,3 @@
 ```ruby
-gem 'knock', '~> 2.0'
+gem 'knock', '~> 2.1'
 ```
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 59808aad64..0000000000
--- a/snippets/server-apis/relay/frontend.md
+++ /dev/null
@@ -1,11 +0,0 @@
-```js
-var token = localStorage.getItem('id_token');
-
-Relay.injectNetworkLayer(
-  new Relay.DefaultNetworkLayer('http://localhost:3000/graphql', {
-    headers: {
-      Authorization: 'Bearer ' + token
-    }
-  })
-);
-```
\ No newline at end of file
diff --git a/snippets/server-apis/relay/setup.md b/snippets/server-apis/relay/setup.md
deleted file mode 100644
index 3020f9ac47..0000000000
--- a/snippets/server-apis/relay/setup.md
+++ /dev/null
@@ -1,11 +0,0 @@
-```js
-var express       = require('express');
-var graphqlHttp   = require('express-graphql');
-var schema        = require('./schema/schema');
-var jwt           = require('express-jwt');
-
-var authenticate = jwt({
-  secret: '<%= account.clientSecret %>',
-  audience: '<%= account.clientId %>'
-});
-```
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-apis/ruby/use.md b/snippets/server-apis/ruby/use.md
index 7fd5efb055..ebf09542f9 100644
--- a/snippets/server-apis/ruby/use.md
+++ b/snippets/server-apis/ruby/use.md
@@ -4,7 +4,7 @@ def authenticate!
   # Extract  from the 'Bearer ' value of the Authorization header
   supplied_token = String(request.env['HTTP_AUTHORIZATION']).slice(7..-1)
 
-  JWT.decode supplied_token, '${account.clientSecret}',
+  JWT.decode supplied_token, 'YOUR_CLIENT_SECRET',
     true, # Verify the signature of this token
     algorithm: 'HS256',
     iss: 'https://${account.namespace}',
diff --git a/snippets/server-apis/wcf-service/setup.md b/snippets/server-apis/wcf-service/setup.md
index d1c2150ea0..4e86c9e7e4 100644
--- a/snippets/server-apis/wcf-service/setup.md
+++ b/snippets/server-apis/wcf-service/setup.md
@@ -2,7 +2,7 @@ The NuGet package will create three empty settings under the `` sec
 
 ```xml
 
-  
+  
   
   
 
diff --git a/snippets/server-platforms/apache/setup.md b/snippets/server-platforms/apache/setup.md
index c8ab2276ca..b0e71776f9 100644
--- a/snippets/server-platforms/apache/setup.md
+++ b/snippets/server-platforms/apache/setup.md
@@ -1,24 +1,15 @@
 ```
-OIDCProviderIssuer https://${account.namespace}
-OIDCProviderAuthorizationEndpoint https://${account.namespace}/authorize
-OIDCProviderTokenEndpoint https://${account.namespace}/oauth/token
-OIDCProviderTokenEndpointAuth client_secret_post
-OIDCProviderUserInfoEndpoint https://${account.namespace}/userinfo
+# mods-available/auth_openidc.conf
 
+OIDCProviderMetadataURL https://${account.namespace}/.well-known/openid-configuration
 OIDCClientID ${account.clientId}
-OIDCClientSecret ${account.clientSecret}
-OIDCProviderJwksUri https://${account.namespace}/.well-known/jwks.json
+OIDCClientSecret 'YOUR_CLIENT_SECRET'
 
 OIDCScope "openid name email"
 OIDCRedirectURI https://your_apache_server/your_path/redirect_uri/
 OIDCCryptoPassphrase 
-OIDCCookiePath /your_path/
 
-SSLEngine on
-SSLCertificateFile /home/your_cert.crt
-SSLCertificateKeyFile /home/your_key.key
-
-
+
    AuthType openid-connect
    Require valid-user
    LogLevel debug
diff --git a/snippets/server-platforms/apache/use.md b/snippets/server-platforms/apache/use.md
index 3b6b48bbaf..2e638a3a69 100644
--- a/snippets/server-platforms/apache/use.md
+++ b/snippets/server-platforms/apache/use.md
@@ -1,5 +1,7 @@
 ```xml
-
+# mods-available/auth_openidc.conf
+
+
    AuthType openid-connect
    #Require valid-user
    Require claim folder:example
diff --git a/snippets/server-platforms/asp-classic/setup.md b/snippets/server-platforms/asp-classic/setup.md
deleted file mode 100644
index 30fd16b551..0000000000
--- a/snippets/server-platforms/asp-classic/setup.md
+++ /dev/null
@@ -1,26 +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 4e82ad50b4..0000000000
--- a/snippets/server-platforms/asp-classic/use.md
+++ /dev/null
@@ -1,58 +0,0 @@
-```asp
-<%= '\<%@ Language="VBScript" %\>' %>
-
-
-
-<%= '\<%' %>
-CLIENT_ID = "${account.clientId}"
-CLIENT_SECRET = "${account.clientSecret}"
-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 "UserID = " & profile.user_id
-
-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 f99067fe04..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/golang/setup.md b/snippets/server-platforms/golang/setup.md
index 7b1180d496..a2a874e409 100644
--- a/snippets/server-platforms/golang/setup.md
+++ b/snippets/server-platforms/golang/setup.md
@@ -1,4 +1,6 @@
 ```go
+// server.go
+
 r := mux.NewRouter()
 r.HandleFunc("/callback", callback.CallbackHandler)
 ```
diff --git a/snippets/server-platforms/java-spring-security/customLoginJsp.md b/snippets/server-platforms/java-spring-security/customLoginJsp.md
index 34baf64f5e..4204623db7 100644
--- a/snippets/server-platforms/java-spring-security/customLoginJsp.md
+++ b/snippets/server-platforms/java-spring-security/customLoginJsp.md
@@ -13,7 +13,7 @@ ${'<%@ taglib prefix="sec" uri="http://www.springframework.org/security/tags"%>'
     
     
     
-    
+    
 
 
     
      
@@ -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/java-spring-security/setup.md b/snippets/server-platforms/java-spring-security/setup.md
index fb44f102b7..07ccf1badb 100644
--- a/snippets/server-platforms/java-spring-security/setup.md
+++ b/snippets/server-platforms/java-spring-security/setup.md
@@ -2,7 +2,7 @@
 auth0.domain: ${account.namespace}
 auth0.issuer: https://${account.namespace}/
 auth0.clientId: ${account.clientId}
-auth0.clientSecret: ${account.clientSecret}
+auth0.clientSecret: YOUR_CLIENT_SECRET
 auth0.onLogoutRedirectTo: /login
 auth0.securedRoute: /portal/*
 auth0.loginCallback: /callback
diff --git a/snippets/server-platforms/java-spring/setup.md b/snippets/server-platforms/java-spring/setup.md
index 01dac0628f..8ddb23f7ae 100644
--- a/snippets/server-platforms/java-spring/setup.md
+++ b/snippets/server-platforms/java-spring/setup.md
@@ -2,7 +2,7 @@
 auth0.domain: ${account.namespace}
 auth0.issuer: https://${account.namespace}/
 auth0.clientId: ${account.clientId}
-auth0.clientSecret: ${account.clientSecret}
+auth0.clientSecret: YOUR_CLIENT_SECRET
 auth0.onLogoutRedirectTo: /login
 auth0.securedRoute: /portal/*
 auth0.loginCallback: /callback
diff --git a/snippets/server-platforms/java/setup.md b/snippets/server-platforms/java/setup.md
index 98d3acf197..9eb2f389ef 100644
--- a/snippets/server-platforms/java/setup.md
+++ b/snippets/server-platforms/java/setup.md
@@ -22,6 +22,6 @@
 
 
     auth0.client_secret
-    ${account.clientSecret}
+    YOUR_CLIENT_SECRET
 
 ```
diff --git a/snippets/server-platforms/laravel/dependencies.md b/snippets/server-platforms/laravel/dependencies.md
deleted file mode 100644
index ee523d37f0..0000000000
--- a/snippets/server-platforms/laravel/dependencies.md
+++ /dev/null
@@ -1 +0,0 @@
-To install this plugin run `composer require auth0/login:"~4.0"`
diff --git a/snippets/server-platforms/laravel/setup.md b/snippets/server-platforms/laravel/setup.md
deleted file mode 100644
index 4525bf8b07..0000000000
--- a/snippets/server-platforms/laravel/setup.md
+++ /dev/null
@@ -1,6 +0,0 @@
-```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 234cdefc7a..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/nodejs/setup.md b/snippets/server-platforms/nodejs/setup.md
index 554a3c4ecb..8345ebfe75 100644
--- a/snippets/server-platforms/nodejs/setup.md
+++ b/snippets/server-platforms/nodejs/setup.md
@@ -5,7 +5,7 @@ var Auth0Strategy = require('passport-auth0');
 var strategy = new Auth0Strategy({
     domain:       '${account.namespace}',
     clientID:     '${account.clientId}',
-    clientSecret: '${account.clientSecret}',
+    clientSecret: 'YOUR_CLIENT_SECRET',
     callbackURL:  '/callback'
   }, function(accessToken, refreshToken, extraParams, profile, done) {
     // accessToken is the token to call Auth0 API (not needed in the most cases)
diff --git a/snippets/server-platforms/nodejs/use.md b/snippets/server-platforms/nodejs/use.md
index 3211815ab8..9a3a0774d2 100644
--- a/snippets/server-platforms/nodejs/use.md
+++ b/snippets/server-platforms/nodejs/use.md
@@ -1,17 +1,19 @@
 ```html
 
 
 
diff --git a/snippets/server-platforms/php/dependencies.md b/snippets/server-platforms/php/dependencies.md
deleted file mode 100644
index 7487779663..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:"~4.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 8b4360a300..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' => '${account.clientSecret}',
-    '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/python/dependencies.md b/snippets/server-platforms/python/dependencies.md
index c433eeeae8..029cf9b852 100644
--- a/snippets/server-platforms/python/dependencies.md
+++ b/snippets/server-platforms/python/dependencies.md
@@ -3,4 +3,6 @@ Add the following dependencies to your `requirements.txt` and run `pip install -
 ```js
 flask
 requests
+flask-oauthlib
+six
 ```
diff --git a/snippets/server-platforms/python/setup.md b/snippets/server-platforms/python/setup.md
index c42ceff959..ed895fe90e 100644
--- a/snippets/server-platforms/python/setup.md
+++ b/snippets/server-platforms/python/setup.md
@@ -1,38 +1,28 @@
 ```python
+# server.py
+
 import os
 import json
 
-import requests
-from flask import Flask, request, jsonify, session, redirect, render_template, send_from_directory
+from auth0.v3.authentication import GetToken
+from auth0.v3.authentication import Users
+from dotenv import load_dotenv
+from flask import Flask
+from flask import redirect
+from flask import render_template
+from flask import request
+from flask import send_from_directory
+from flask import session
 
 # Here we're using the /callback route.
 @app.route('/callback')
 def callback_handling():
-  code = request.args.get('code')
-
-  json_header = {'content-type': 'application/json'}
-
-  token_url = "https://{domain}/oauth/token".format(domain='${account.namespace}')
-
-  token_payload = {
-    'client_id':     '${account.clientId}',
-    'client_secret': '${account.clientSecret}',
-    'redirect_uri':  '${account.callback}',
-    'code':          code,
-    'grant_type':    'authorization_code'
-  }
-
-  token_info = requests.post(token_url, data=json.dumps(token_payload), headers = json_header).json()
-
-  user_url = "https://{domain}/userinfo?access_token={access_token}" \
-      .format(domain='${account.namespace}', access_token=token_info['access_token'])
-
-  user_info = requests.get(user_url).json()
-
-  # We're saving all user information into the session
-  session['profile'] = user_info
-
-  # Redirect to the User logged in page that you want here
-  # In our case it's /dashboard
-  return redirect('/dashboard')
+    code = request.args.get('code')
+    get_token = GetToken('${account.namespace}')
+    auth0_users = Users('${account.namespace}')
+    token = get_token.authorization_code('${account.clientId}',
+                                         'YOUR_CLIENT_SECRET', code, '${account.callback}')
+    user_info = auth0_users.userinfo(token['access_token'])
+    session['profile'] = json.loads(user_info)
+    return redirect('/dashboard')
 ```
diff --git a/snippets/server-platforms/python/use.md b/snippets/server-platforms/python/use.md
index 3211815ab8..2062a67bd7 100644
--- a/snippets/server-platforms/python/use.md
+++ b/snippets/server-platforms/python/use.md
@@ -1,17 +1,15 @@
 ```html
-
+
 
 
diff --git a/snippets/server-platforms/rails/dependencies.md b/snippets/server-platforms/rails/dependencies.md
deleted file mode 100644
index c3719f42d7..0000000000
--- a/snippets/server-platforms/rails/dependencies.md
+++ /dev/null
@@ -1,4 +0,0 @@
-```js
-gem 'omniauth', '~> 1.3.1'
-gem 'omniauth-auth0', '~> 1.4.2'
-```
diff --git a/snippets/server-platforms/rails/setup.md b/snippets/server-platforms/rails/setup.md
deleted file mode 100644
index 56eac28a45..0000000000
--- a/snippets/server-platforms/rails/setup.md
+++ /dev/null
@@ -1,11 +0,0 @@
-```ruby
-Rails.application.config.middleware.use OmniAuth::Builder do
-  provider(
-    :auth0,
-    '${account.clientId}',
-    '${account.clientSecret}',
-    '${account.namespace}',
-    callback_path: "/auth/oauth2/callback"
-  )
-end
-```
diff --git a/snippets/server-platforms/rails/use.md b/snippets/server-platforms/rails/use.md
deleted file mode 100644
index 3211815ab8..0000000000
--- a/snippets/server-platforms/rails/use.md
+++ /dev/null
@@ -1,19 +0,0 @@
-```html
-
-
-
-
-```
diff --git a/snippets/server-platforms/scala/dependencies.md b/snippets/server-platforms/scala/dependencies.md
index 514f964035..47d927692b 100644
--- a/snippets/server-platforms/scala/dependencies.md
+++ b/snippets/server-platforms/scala/dependencies.md
@@ -1 +1 @@
-Add the client ID, client secret, domain, and callback URL for your application to `application.conf`. You can get your client ID, client secret, and domain from your [application settings](${manage_url}/#/clients/${account.clientId}/settings).
+Add the client ID, client secret, domain, and callback URL for your application to `application.conf`. You can get your client ID, client secret, and domain from your [application settings](${manage_url}/#/applications/${account.clientId}/settings).
diff --git a/snippets/server-platforms/servicestack/use.md b/snippets/server-platforms/servicestack/use.md
index 3211815ab8..56b55ac57c 100644
--- a/snippets/server-platforms/servicestack/use.md
+++ b/snippets/server-platforms/servicestack/use.md
@@ -3,7 +3,6 @@