First batch of commits

Author: avanscoy

articles/api-auth/blacklists-vs-grants.md

@@ -30,10 +30,6 @@ We will then compare the two methods and provide our recommendations.
 
 Let's say that you grant access to your API to anyone in possession of the appropriate Access Token. One method of revoking access to a user is to blacklist their token so that it can no longer be used.
 
-::: note
-Please see the Auth0 blog for an in-depth treatment on [Blacklisting JSON Web Token API Keys](https://auth0.com/blog/blacklist-json-web-token-api-keys/).
-:::
-
 Auth0-issued tokens are [JWTs](/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

articles/architecture-scenarios/_includes/_api-signing-algorithms.md

@@ -17,6 +17,3 @@ The most secure practice, and our recommendation, is to use __RS256__. Some of t
 - Under HS256, If the private key is compromised you would have to re-deploy the API with the new secret. With RS256 you can request a token that is valid for multiple audiences.
 - With RS256 you can implement key rotation without having to re-deploy the API with the new secret.
 
-::: note
-For a more detailed overview of the JWT signing algorithms refer to: [JSON Web Token (JWT) Signing Algorithms Overview](https://auth0.com/blog/json-web-token-signing-algorithms-overview/).
-:::

articles/architecture-scenarios/_includes/_architecture/_custom-domains.md

@@ -1,7 +1,7 @@
 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).
-* It's [harder to phish your domain if you have a vanity URL](https://auth0.com/blog/introducing-custom-domains-preview-with-auth0/), 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.
+* 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.

articles/architecture-scenarios/_includes/_authentication/_mfa.md

@@ -7,10 +7,10 @@ It's quite common for customer facing applications to provide users with an _opt
 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](https://auth0.com/blog/from-theory-to-practice-adding-two-factor-to-node-dot-js/)): 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.
+* 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](https://auth0.com/blog/announcing-guardian-whitelabel-sdk/) that you can use to build second factor workflow right in your existing mobile device application(s).
+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).

articles/architecture-scenarios/_includes/_authentication/_social-authentication.md

@@ -10,4 +10,4 @@ With [social](https://auth0.com/learn/social-login/) support, user identities an
 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 <dfn data-key="oauth2">OAuth2</dfn> 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 and by following the guidance described in our [SwissID blog post](https://auth0.com/blog/configuring-swissid-login-into-custom-applications/). 
+Auth0 [Custom Social Connections](/connections/social/oauth2) extend social authentication even further by allowing you to connect with any <dfn data-key="oauth2">OAuth2</dfn> 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. 

articles/architecture-scenarios/_includes/_authorization/_api-integration.md

@@ -34,4 +34,4 @@ When you are considering adding custom claims, we recommend that you store any a
 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](https://auth0.com/blog/on-the-nature-of-oauth2-scopes/). 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.
+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.

articles/architecture-scenarios/_includes/_authorization/_introduction.md

@@ -39,7 +39,7 @@ When deciding what data to include in your ID token and/or access token, conside
 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.  There is a nice [blog post](https://auth0.com/blog/on-the-nature-of-oauth2-scopes/) on that which is easy to read and helps clear up the topic.
+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") { %>

articles/architecture-scenarios/_includes/_launch/_support.md

@@ -46,7 +46,7 @@ One potential cause of issues is using out of date versions of SDKs or libraries
 
 ## 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). The [product feedback blog post](https://auth0.com/blog/improve-auth0-new-feedback-page/) explains the feedback process.
+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 
 

articles/architecture-scenarios/implementation-resources.md

@@ -36,8 +36,6 @@ Resources designed to help you learn the basics of Auth0 include:
 
 * [**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.
 
-* [**How to have a successful IDM Project blog post**](https://auth0.com/blog/how-to-have-a-successful-idm-project/): Learn how to create a realistic project plan that will ensure a satisfying Identity Management project deployment.
-
 ## Learn
 
 Auth0 provides numerous tutorials, guides, white papers, and blog posts that focus on both learning and providing quick reference checks. 

articles/architecture-scenarios/server-api/part-2.md

@@ -52,8 +52,6 @@ The most secure practice, and our recommendation, is to use **RS256**. Some of t
 - Under HS256, if the private key is compromised you would have to re-deploy the API with the new secret. With RS256, you can request a token that is valid for multiple audiences.
 - With RS256, you can implement key rotation without having to re-deploy the API with the new secret.
 
-For a more detailed overview of the JWT signing algorithms, see [JSON Web Token (JWT) Signing Algorithms Overview](https://auth0.com/blog/json-web-token-signing-algorithms-overview/).
-
 ## Configure the Scopes
 
 Once the application has been created, you will need to configure the Scopes that applications can request during authorization.

articles/architecture-scenarios/spa-api/part-1.md

@@ -31,9 +31,7 @@ With this flow, the calling application requests an Access Token over HTTPS with
 
 The original specifications for OAuth2 introduced the Implicit Flow, a way for SPAs without a backend to obtain Access Tokens and call APIs directly from the browser. However, mitigation strategies are necessary to use the Implicit Flow because tokens are returned in the URL directly from the authorization endpoint as opposed to the token endpoint. 
 
-We recommend using the [Authorization Code Flow with PKCE](https://auth0.com/docs/flows/authorization-code-flow) rather than Implicit Flow; however, if you are unable to update to the recommended flow, you should implement necessary mitigations to combat the risks.
-
-To learn more, read our blog post: [OAuth2 Implicit Grant and SPA](https://auth0.com/blog/oauth2-implicit-grant-and-spa/#The-Implicit-Grant). 
+We recommend using the [Authorization Code Flow with PKCE](https://auth0.com/docs/flows/authorization-code-flow) rather than Implicit Flow; however, if you are unable to update to the recommended flow, you should implement necessary mitigations to combat the risks. 
 
 ## Authorization Extension
 

articles/architecture-scenarios/web-saml.md

@@ -33,7 +33,7 @@ In this scenario, an Access Token is also returned, but it is rarely used becaus
 :::
 
 ::: warning
-If you are using Auth0 as a SAML Identity Provider (IdP) and are processing SAML responses in your own code, you will need to verify whether the libraries you use are vulnerable to SAML exploits. To learn more, see [Auth0 Not Affected by SAML Vulnerabilities Identified by Duo Security](https://auth0.com/blog/auth0-not-affected-by-saml-vulnerabilities-identified-by-duo-security/) . Note that the type of attack discussed in this blog can be prevented by Multi-factor Authentication (MFA), even if software used is vulnerable.
+If you are using Auth0 as a SAML Identity Provider (IdP) and are processing SAML responses in your own code, you will need to verify whether the libraries you use are vulnerable to SAML exploits.
 :::
 
 ## Read More

articles/best-practices/application-settings.md

@@ -25,7 +25,7 @@ Here are some best practices for configuring [Application Settings](${manage_url
 | ID token expiration | Set the [ID Token expiration time](/tokens/id-tokens#token-lifetime). By default ID Tokens expire after 10 hours. Once issued, an [ID Token cannot be revoked](/tokens/guides/revoke-tokens), so instead of longer expiration times, use a short expiration time and renew the session if the user remains active. |
 | Wildcards or localhost URLs | Do not use wildcard or localhost URLs in your application <dfn data-key="callback">callbacks</dfn> or allowed origins fields. Using redirect URLs with wildcards [can make your application vulnerable to attacks](https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_Cheat_Sheet). |
 | Logout redirect URLs | To redirect users after [logout](/logout), 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. |
-| **Advanced Settings**: RS256 signature algorithm | Make sure that RS256 is the signature method for signing <dfn data-key="json-web-token">JSON Web Tokens (JWT)</dfn>. The JWT signature method can be found under [Applications > Settings > Advanced Settings > OAuth](${manage_url}/#/applications). See [Auth0 Blog: Navigating RS256 and JWKS](https://auth0.com/blog/navigating-rs256-and-jwks/). |
+| **Advanced Settings**: RS256 signature algorithm | Make sure that RS256 is the signature method for signing <dfn data-key="json-web-token">JSON Web Tokens (JWT)</dfn>. The JWT signature method can be found under [Applications > Settings > Advanced Settings > OAuth](${manage_url}/#/applications).|
 | **Advanced Settings**: OIDC conformant (for tenants created before 2017-12-27) | If your application is not [OIDC conformant](/api-auth/intro), [migrate your applications](/api-auth/tutorials/adoption) to be OIDC conformant. Newer tenants can only use OIDC conformant behavior. Test by turning on the OIDC conformant toggle and testing your application. |
 | **Advanced Settings**: Restrict delegation | <%= include('../_includes/_deprecate-delegation') %> </br> If you are not using delegation, provide your application's Client ID in the **Allowed Apps / APIs** field to restrict delegation requests. |
 | **Advanced Settings**: Grant types | Turn off unneeded grant types for your application to prevent someone from issuing authorization requests for unauthorized grant types. |

articles/best-practices/rules.md

@@ -46,7 +46,7 @@ A rule is essentially an anonymous JavaScript function that is passed three para
 Anonymous functions make it hard to interpret the call-stack generated as a result of any [exceptional error](/best-practices/error-handling#exceptions) condition. For convenience, use compact and unique naming conventions to assist with diagnostic analysis (e.g., `function MyRule1 (user, context, callback) {...}`).
 :::
 
-Rules execute in the pipeline associated with the generation of artifacts for authenticity that forms part of the overall [Auth0 engine](https://cdn.auth0.com/blog/auth0-raises-100m-to-fuel-the-growth/inside-the-auth0-engine-high-res.jpg). When a pipeline is executed, all enabled rules are packaged together in the order in which they are listed and sent as one code blob to be executed as an Auth0 serverless Webtask.
+Rules execute in the pipeline associated with the generation of artifacts for authenticity that forms part of the overall Auth0 engine. When a pipeline is executed, all enabled rules are packaged together in the order in which they are listed and sent as one code blob to be executed as an Auth0 serverless Webtask.
 
 ![Rules Pipeline](/media/articles/rules/rules-best-practice-pipeline.png)
 

articles/connections/database/custom-db/_includes/_panel-bcrypt-hash-encryption.md

@@ -1,5 +1,5 @@
 ::: 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`](https://auth0.com/blog/hashing-in-action-understanding-bcrypt/) algorithm to perform cryptographic 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) {

articles/connections/passwordless/_old/ios-magic-link.md

@@ -37,7 +37,7 @@ iOS needs to know which domains your application handles. To configure this:
 ## Pass callbacks to Lock
 
 ::: note
-If you've already implemented [Lock v1 for iOS](https://auth0.com/blog/how-to-implement-slack-like-login-on-ios-with-auth0/), you have already configured callbacks to the Auth0 Lock Library.
+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:

articles/connections/social/instagram.md

@@ -21,7 +21,7 @@ useCase:
 You can add functionality to your web app that allows your users to log in with Instagram. 
 
 ::: note 
-Instagram hass 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. For more information, see [this blog post](https://developers.facebook.com/blog/post/2019/10/15/launch-instagram-basic-display-api/).
+Instagram hass 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. 
 :::
 
 ## Prerequisites

articles/connector/test-dc.md

@@ -94,7 +94,7 @@ You can run your VM on any cloud platform, but this guide will walk through how
     ::: 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**](http://blog.blksthl.com/2012/11/28/how-to-disable-ie-enhanced-security-in-windows-server-2012/).
+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`