Deprecation VuePress Policies API

packages/@okta/vuepress-site/conductor.yml

@@ -108,7 +108,7 @@ redirects:
   - from: /reference/authentication_reference
     to: https://developer.okta.com/docs/api/openapi/okta-oauth/guides/overview/index.html
   - from: /docs/getting_started/policy.html
-    to: /docs/reference/api/policy/index.html
+    to: https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/
   - from: /docs/api/rest/sessions.html
     to: /docs/reference/api/sessions/
   - from: /docs/api/rest/templates.html
@@ -476,7 +476,7 @@ redirects:
   - from: /docs/api/resources/linked-objects/index.html
     to: /docs/reference/api/linked-objects/
   - from: /docs/api/resources/policy/index.html
-    to: /docs/reference/api/policy/
+    to: https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/
   - from: /docs/api/resources/schemas/index.html
     to: https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Schema/
   - from: /docs/api/resources/sessions/index.html
@@ -804,7 +804,7 @@ redirects:
   - from: /docs/api/resources/linked-objects
     to: /docs/reference/api/linked-objects/
   - from: /docs/api/resources/policy
-    to: /docs/reference/api/policy/
+    to: https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/
   - from: /docs/api/resources/schemas
     to: https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Schema/
   - from: /docs/api/resources/sessions
@@ -906,7 +906,7 @@ redirects:
   - from: /docs/api/resources/linked-objects.html
     to: /docs/reference/api/linked-objects/
   - from: /docs/api/resources/policy.html
-    to: /docs/reference/api/policy/
+    to: https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/
   - from: /docs/api/resources/schemas.html
     to: https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Schema/
   - from: /docs/api/resources/system_log.html
@@ -2308,7 +2308,7 @@ redirects:
   - from: /docs/guides/password-import-hook/-/next-steps/index.html
     to: /docs/guides/password-import-inline-hook/nodejs/main/#test-your-hook
   - from: /docs/reference/api/oie-policy-types/index.html
-    to: /docs/reference/api/policy/
+    to: https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/
   - from: /docs/concepts/ie-intro/index.html
     to: https://help.okta.com/oie/en-us/okta_help_CSH.htm#ext-get-started-oie
   - from: /docs/concepts/ie-intro

packages/@okta/vuepress-site/docs/concepts/identity-providers/index.md

@@ -4,39 +4,39 @@ title: External Identity Providers
 
 # External Identity Providers
 
-As a developer building a custom application, you want to give users the freedom to choose which Identity Provider they use to sign in to your application. But first you should understand how Identity Providers connect to Okta.
+As a developer building a custom app, you want to give users the freedom to choose which Identity Provider (IdP) they use to sign in to your app. But first you should understand how IdPs connect to Okta.
 
-What is an Identity Provider? It's a service that creates and maintains identity information and then provides authentication services to your applications. Identity Providers can significantly reduce sign-in and registration friction. This allows your users to easily access applications without needing to create passwords or remember usernames.
+What's an IdP? It's a service that creates and maintains identity information and then provides authentication services to your apps. IdPs can significantly reduce sign-in and registration friction. This allows your users to easily access apps without needing to create passwords or remember usernames.
 
 <a href='/docs/guides/identity-providers/' class='Button--blueDarkOutline card' data-proofer-ignore>
    <span>Add an Identity Provider integration</span>
 </a>
 
 ## The big picture
 
-Okta manages connections to other Identity Providers for your application and sits between your application and the Identity Provider that authenticates your users.
+Okta manages connections to other IdPs for your app and sits between your app and the IdP that authenticates your users.
 
-* You can use Okta as the [user store](/docs/concepts/user-profiles/) for your applications. Then, users can sign in with their email and password by default. See our guides for how to sign in users to your [web](/docs/guides/sign-into-web-app-redirect/), [mobile](/docs/guides/sign-into-mobile-app-redirect/), and [single-page](/docs/guides/sign-into-spa-redirect/) apps.
+* You can use Okta as the [user store](/docs/concepts/user-profiles/) for your apps. Then, users can sign in with their email and password by default. See our guides for how to sign in users to your [web](/docs/guides/sign-into-web-app-redirect/), [mobile](/docs/guides/sign-into-mobile-app-redirect/), and [single-page](/docs/guides/sign-into-spa-redirect/) apps.
 
-* You can add connections to social Identity Providers like Apple or Facebook. This is called social login or social authentication. It allows your users to sign in to your app using credentials from their existing social Identity Providers. After users authenticate, you sync their existing Identity Provider credentials into your Okta Universal Directory while continuing to use that Identity Provider for user authentication. This eliminates the need to store an additional username and password for that user.
+* You can add connections to social IdPs like Apple or Facebook. This is called social login or social login. It allows your users to sign in to your app using credentials from their existing social IdPs. After users authenticate, you sync their existing IdP credentials into your Okta Universal Directory while continuing to use that IdP for user authentication. This eliminates the need to store an additional username and password for that user.
 
-* You can add connections to Identity Providers that you build in-house that support OpenID Connect or SAML protocols. This is also referred to as Inbound Federation or inbound SAML. The SAML flow is initiated with the Service Provider (in this case, Okta) that redirects the user to the Identity Provider for authentication. After authentication, a user is created inside Okta, and the user is redirected back to your application along with an ID token. This allows you to use Okta to proxy between SAML-only Identity Providers and OpenID Connect-only applications that are normally incompatible.
+* You can add connections to IdPs that you build in-house that support OpenID Connect (OIDC) or SAML protocols. This is also referred to as Inbound Federation or inbound SAML. The SAML flow is initiated with the Service Provider (SP) (in this case, Okta) that redirects the user to the IdP for authentication. After authentication, a user is created inside Okta, and the user is redirected back to your app along with an ID token. This allows you to use Okta to proxy between SAML-only IdPs and OIDC-only apps that are normally incompatible.
 
-  > **Note:** Social and OpenID Connect Identity Providers store access tokens that allow subsequent calls to Identity Providers after the user is authorized. For example, the token may contain the permission to add events to a user's Google calendar. After authentication, your app can use the token on more calls to add events to the user's Google calendar on the user's behalf.
+  > **Note:** Social and OIDC IdPs store access tokens that allow subsequent calls to IdPs after the user is authorized. For example, the token may contain the permission to add events to a user's Google calendar. After authentication, your app can use the token on more calls to add events to the user's Google calendar on the user's behalf.
 
-* You can also configure federation [between Okta orgs](/docs/guides/add-an-external-idp/oktatookta/main/) using OpenID Connect or SAML.
+* You can also configure federation [between Okta orgs](/docs/guides/add-an-external-idp/oktatookta/main/) using OIDC or SAML.
 
-Adding any of these Identity Providers allows users to sign in to your application using their credentials from a specific Identity Provider.
+Adding any of these IdPs allows users to sign in to your app using their credentials from a specific IdP.
 
 ## Benefits of using Okta to manage Identity Providers
 
-You could connect your application directly to an Identity Provider (for example, using an SDK to add a button for **Sign in with Google**). However, using Okta as the user store for your application and letting Okta manage the Identity Provider connections has some benefits:
+You could connect your app directly to an IdP (for example, using an SDK to add a button for **Sign in with Google**). However, using Okta as the user store for your app and letting Okta manage the IdP connections has some benefits:
 
-* **No custom code:** Your application only needs to talk to Okta, and Okta does the rest.
+* **No custom code:** Your app only needs to talk to Okta, and Okta does the rest.
 
-* **One protocol:** Your application uses OpenID Connect to talk to Okta. Okta handles whatever protocols the other Identity Providers use, and this is transparent to your application.
+* **One protocol:** Your app uses OIDC to talk to Okta. Okta handles whatever protocols the other IdPs use, and this is transparent to your app.
 
-* **Single user store:** All users are stored in Okta. You can capture the profile attributes from an Identity Provider user and store those attributes in the Okta Universal Directory.
+* **Single user store:** All users are stored in Okta. You can capture the profile attributes from an IdP user and store those attributes in the Okta Universal Directory.
 
 * **Profile sync:** If a user updates their profile at the Identity Provider, those changes appear in Okta the next time they use the provider to sign in.
 
@@ -48,19 +48,19 @@ You could connect your application directly to an Identity Provider (for example
 
 ## How Okta connects to external Identity Providers
 
-Okta sits between your application and the external provider. Your application only needs to talk to Okta, and Okta does the rest.
+Okta sits between your app and the external provider. Your app only needs to talk to Okta, and Okta does the rest.
 
 ### Sign-in process
 
 The sign-in process starts at the `/authorize` endpoint, and then goes out to the provider and back:
 
-1. In your application, the user clicks a button similar to: **Sign in with (Identity Provider)**.
-2. Your application redirects the browser to Okta.
-3. Okta redirects the browser to the Identity Provider.
-4. The user is prompted to sign in at the Identity Provider (if they aren't already) and to accept the permissions required by your app.
+1. In your app, the user clicks a button similar to: **Sign in with (Identity Provider)**.
+2. Your app redirects the browser to Okta.
+3. Okta redirects the browser to the IdP.
+4. The user is prompted to sign in at the IdP (if they aren't already) and to accept the permissions that are required by your app.
 5. The Identity Provider redirects the browser back to Okta.
 6. Okta processes the sign-in request and adds the user to your Okta organization's Universal Directory.
-7. Okta redirects the browser back to your application, just like any other sign-in request.
+7. Okta redirects the browser back to your app, just like any other sign-in request.
 
 <div class="three-quarter">
 
@@ -91,7 +91,7 @@ ok -> ua: 302 to redirect_uri
 
 ## Account Linking and Just-In-Time provisioning
 
-Use account linking to help create a unified view of your users within your org. Also, you can use Just-In-Time (JIT) provisioning to create a seamless experience for users that sign in to your application for the first time using their credentials from another Identity Provider.
+Use account linking to help create a unified view of your users within your org. You can also use Just-In-Time (JIT) provisioning to create a seamless experience for users. User can sign in to your app for the first time using their credentials from another IdP.
 
 ### Account Linking
 
@@ -109,21 +109,21 @@ To enable account linking, select `Automatic` from the **Account Link Policy** d
 
 ### JIT provisioning
 
-If a user signs in to your application for the first time using another Identity Provider, you can implement [JIT provisioning](https://help.okta.com/okta_help.htm?id=ext_Identity_Providers) to create an Okta account automatically for them. JIT account creation and activation only work for end users who aren't already Okta users.
+If a user signs in to your app for the first time using another Identity Provider, you can implement [JIT provisioning](https://help.okta.com/okta_help.htm?id=ext_Identity_Providers) to create an Okta account automatically for them. JIT account creation and activation only work for end users who aren't already Okta users.
 
-Also, you can apply granular control over account linking and JIT by defining a policy and then rules for the policy. You can base a policy on various factors, such as location, group definitions, and authentication type. A specific policy rule can then be created for groups that have been assigned to your application. You can create multiple policies with more or less restrictive rules and apply them to different groups.
+Also, you can apply granular control over account linking and JIT by defining a policy and then rules for the policy. You can base a policy on various factors, such as location, group definitions, and authentication type. A specific policy rule can then be created for groups that have been assigned to your app. You can create multiple policies with more or less restrictive rules and apply them to different groups.
 
 You can also set up group sync to specify the groups that users should be added to and enable profile sourcing so that a user's profile gets updated each time that the user signs in. This allows you to always have the most recent data about your users.
 
 ## IdP Discovery
 
-If you have more than one Identity Provider configured in your org (which can mean just one external Identity Provider, in addition to Okta itself also serving as an Identity Provider), you can define logic to determine which Identity Provider individual end users are routed to when they authenticate. This functionality is called IdP Discovery, or IdP Routing Rules, and is configured by the [IdP Discovery Policy](/docs/reference/api/policy/#idp-discovery-policy).
+If you have more than one Identity Provider configured in your org (which can mean just one external Identity Provider, in addition to Okta itself also serving as an Identity Provider), you can define logic to determine which Identity Provider individual end users are routed to when they authenticate. This functionality is called IdP Discovery, or IdP Routing Rules, and is configured by the [IdP Discovery Policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy/operation/createPolicy).
 
 The Okta Sign-In Widget (version 2.5.0 or above) interacts with the IdP Discovery policy to redirect end users as needed to the IdP determined by the policy.
 
-> **Note:** v1 of the Okta API supports IdP Discovery with the Okta-hosted Widget only.
+> **Note:** v1 of the Okta API supports IdP Discovery with the Okta-hosted Sign-In Widget only.
 
-If you don't use the Okta Sign-In Widget, instead interacting directly with the [Okta Authentication API](/docs/reference/api/authn/) to implement sign-in yourself, you can integrate IdP Discovery into your flow by including a call to the Okta [WebFinger](/docs/reference/api/webfinger/) endpoint. That endpoint returns the name of the IdP that should be used for a given end user, as determined by the org's defined IdP Discovery Policy.
+If you don't use the Okta Sign-In Widget, instead interacting directly with the [Okta Authentication API](/docs/reference/api/authn/) to implement sign-in yourself, you can integrate IdP Discovery into your flow by including a call to the Okta [WebFinger](/docs/reference/api/webfinger/) endpoint. That endpoint returns the name of the IdP that should be used for a given end user, as determined by the org's defined IdP discovery policy.
 
 <a href='/docs/guides/identity-providers/' class='Button--blueDarkOutline card' data-proofer-ignore>
 	<span>Add an Identity Provider integration</span>

packages/@okta/vuepress-site/docs/concepts/okta-data-model/index.md

@@ -26,7 +26,7 @@ An [app](https://developer.okta.com/docs/api/openapi/okta-management/management/
 
 The relationship between an app and a user is stored in Okta as an [AppUser](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/ApplicationUsers/). This allows for mappings between profile values where they're different. For example, app1 may refer to a user's last name as `lastName` and app2 may refer to last name as `surname`. The AppUser stores the value as necessary for the app.
 
-A [Policy](/docs/reference/api/policy/) specifies the rules of how your org behaves for certain actions. Policies have conditions that need to be met to apply actions. Your Okta org contains policies for how to gain access to an app, what the user needs to do to reset their password, and to enroll into multifactor authentication, for example.
+A [Policy](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/Policy/#tag/Policy) specifies the rules of how your org behaves for certain actions. Policies have conditions that need to be met to apply actions. Your Okta org contains policies for how to gain access to an app, what the user needs to do to reset their password, and to enroll into multifactor authentication, for example.
 
 An [authorization server](https://developer.okta.com/docs/api/openapi/okta-management/management/tag/AuthorizationServer/) in your Okta org provides apps tokens that allow those apps to access either your API or Okta resources. This is done with protocols such as OAuth 2.0, OpenID Connect, and SAML.