OKTA-1176445 Refactor SSO OIDC build guide

packages/@okta/vuepress-site/archive/php/simplesamlphp/index.md

@@ -23,7 +23,7 @@ If you're already familiar with Okta, you can skip to the section titled "Config
 
 Before you can configure the example application and SimpleSAMLphp you need to set up an Okta application icon that an Okta user selects to sign in to your to your application using SAML through SimpleSAMLphp.
 
-To set up Okta to connect to your application, follow the guide to [Build a Single Sign-On integration](/docs/guides/build-sso-integration/saml2/main/). As you follow the instructions to [Create your integration](/docs/guides/build-sso-integration/saml2/main/#create-your-integration), there are two steps where you do things differently:
+To set up Okta to connect to your application, follow the guide to [Build a Single Sign-On integration](/docs/guides/create-an-app-integration/saml2/main/). As you follow the instructions to [OIN submission requirements](/docs/guides/submit-app-prereq/main/#oin-wizard-requirements), there are two steps where you do things differently:
 
 * In step \#9: Use **SimpleSAMLphp Example** instead **Example SAML application**.
 * In step \#10: Instead of entering the URL: `http://example.com/saml/sso/example-okta-com`
@@ -171,7 +171,7 @@ Configuring SimpleSAMLphp:
     );
     ```
 
-    Be sure to replace the contents of `${metadataUrl}` with the link that you copied in step \#10 of the [Setting up a SAML application in Okta](/docs/guides/build-sso-integration/saml2/main/#create-your-integration) instructions that you followed above.
+    Be sure to replace the contents of `${metadataUrl}` with the link that you copied in step \#10 that you followed above.
 
     > **Note:** The contents of `${metadataUrl}` should look similar to this:
     > `https://${yourOktaDomain}/app/a0b1c2deFGHIJKLMNOPQ/sso/saml/metadata`

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

@@ -6109,3 +6109,15 @@ redirects:
     to: /docs/guides/create-an-app-integration/openidconnect/main/
   - from: /docs/guides/add-private-app/openidconnect/main
     to: /docs/guides/create-an-app-integration/openidconnect/main/
+  - from: /docs/guides/build-sso-integration/openidconnect/main/
+    to: /docs/guides/create-an-app-integration/openidconnect/main/
+  - from: /docs/guides/build-sso-integration/openidconnect/main/#deployment-models
+    to: /docs/concepts/redirect-vs-embedded/
+  - from: /docs/guides/build-sso-integration/openidconnect/main/#overview
+    to: /docs/concepts/sso-overview/
+  - from: /docs/guides/build-sso-integration/openidconnect/main/#build-your-integration
+    to: /docs/guides/submit-app-prereq/main/#oin-wizard-requirements
+  - from: /docs/guides/build-sso-integration/openidconnect/main/#scopes
+    to: /docs/concepts/oauth-claims/
+  - from: /docs/guides/build-sso-integration/openidconnect/main/#rate-limit-considerations
+    to: /docs/reference/rate-limits/

packages/@okta/vuepress-site/docs/concepts/multi-tenancy/index.md

@@ -56,6 +56,15 @@ SSO app integrations are multi-tenant by design. Each customer (the organization
 
 Because each org manages its own users, policies, and application access independently, a single app integration can serve multiple customers without their data or configurations affecting one another.
 
+### OIDC customer org credentials
+For OpenID Connect (OIDC) integrations, Okta uses a local credential system. When your customer adds your integration in their Okta org, they obtain a unique set of OIDC credentials. Each instance of your app integration inside a customer org has a separate set of OIDC client credentials that are used to access your app.
+
+This local credential approach differs from other IdPs that use a global credential system, where a given app has the same customer credentials across all orgs.
+
+See the [OIN multi-tenancy](/docs/guides/submit-app-prereq/main/#oin-multi-tenancy) requirement.
+
+You must track client credentials for each app integration instance for your app. For example, consider a scenario where your app integration is added to 10 separate customer orgs. Seven of those customers create a single instance of your app integration. However, the other three customers each create two separate instances of your app integration so they can use different configuration options. This scenario creates a total of 13 sets of client credentials for your app that you need to track.
+
 ## Why would you want more than one tenant
 
 An organization can create a tenant for various reasons. For example

packages/@okta/vuepress-site/docs/concepts/oauth-claims/index.md

@@ -1,11 +1,11 @@
 ---
-title: OAuth 2.0 and OpenID Connect claims
+title: OAuth 2.0 claims and scopes
 meta:
   - name: description
-    content: A high-level overview of OAuth 2.0 and OpenID Connect claims.
+    content: A high-level overview of OAuth 2.0 claims and scopes.
 ---
 
-# Learn about OAuth 2.0 and OpenID Connect claims
+# Learn about OAuth 2.0 claims and scopes
 
 [OAuth 2.0 and OpenID Connect (OIDC)](/docs/concepts/oauth-openid) claims are key-value pairs of data that contain information, typically information about a user. Okta uses these claims to provide context about the user and their permissions.
 
@@ -27,6 +27,10 @@ During the authorization flow, an app requests specific scopes. The resulting ac
 
 You can use claims for fine-grained permissions and information to enhance the security of your apps. Scopes include bundles of claims, whereas claims provide more granularity that allows you to control access to specific resources or actions.
 
+> **Note**: The following scopes aren't supported for integrations published in the OIN:
+>   * `offline_access` scope (since refresh tokens aren't supported)
+>   * Custom scopes (such as the `groups` scope). You can only request the [OIDC scopes](https://developer.okta.com/docs/api/openapi/okta-oauth/guides/overview/#scopes). You can't configure custom scopes.
+
 ### Claims in access tokens
 
 Claims in access tokens pass information about the user and their permissions to the resource server. Access tokens can contain scopes and [custom claims](/docs/guides/customize-tokens-returned-from-okta/main/), while ID tokens can contain claims, but not scopes.

packages/@okta/vuepress-site/docs/concepts/oauth-openid/index.md

@@ -57,7 +57,7 @@ The following describes the usual OAuth 2.0 Authorization Code flow.
 
 At the core of both OAuth 2.0 and OIDC is the authorization server. An authorization server is simply an OAuth 2.0 token minting engine. Each authorization server has a unique issuer URI and its own signing key for tokens to keep a proper boundary between security domains. In the context of this guide, Okta is your authorization server.
 
-The authorization server also acts as an OIDC provider. This means you can request [ID tokens](https://developer.okta.com/docs/api/openapi/okta-oauth/guides/overview/#id-token) in addition to [access tokens](https://developer.okta.com/docs/api/openapi/okta-oauth/guides/overview/#access-token) from the authorization server endpoints.
+The authorization server also acts as an OIDC provider. This means that you can request [ID tokens](https://developer.okta.com/docs/api/openapi/okta-oauth/guides/overview/#id-token) in addition to [access tokens](https://developer.okta.com/docs/api/openapi/okta-oauth/guides/overview/#access-token) from the authorization server endpoints.
 
 > **Note:** For information on authorization servers, how they work, and how you can use them, see [Authorization servers](/docs/concepts/auth-servers).
 
@@ -94,6 +94,8 @@ The following table shows you which OAuth 2.0 flow to use for the type of app th
 
 > **Note**: There's also an OAuth 2.0 [SAML 2.0 Assertion flow](#saml-2-0-assertion-flow). This flow is intended for client apps that want to use an existing trust relationship without a direct user approval step at the authorization server. It supports access and ID tokens.
 
+> **Note:** If you're building an integration for the [Okta Integration Network (OIN)](https://www.okta.com/integrations/), additional restrictions apply to your flow choice and authorization server. See [OIDC/OAuth 2.0 integration limitations](/docs/guides/submit-app-prereq/main/#oidc-oauth-2-0-integration-limitations).
+
 ### What kind of client are you building?
 
 The type of OAuth 2.0 flow depends on what kind of client that you're building. This flowchart can quickly help you decide which flow to use.

packages/@okta/vuepress-site/docs/guides/create-an-app-integration/main/openidconnect/see-also.md

@@ -1,2 +1,2 @@
-* See [Build a SSO integration](https://developer.okta.com/docs/guides/build-sso-integration/openidconnect/main/) for information on how to make your SSO app integration publish in the OIN.
+* See [Build a SSO integration](https://developer.okta.com/docs/guides/create-an-app-integration/openidconnect/main/) for information on how to make your SSO app integration publish in the OIN.
 * See [Publish an OIN integration](https://developer.okta.com/docs/guides/submit-app-overview/) for information on submitting your integration for publication in the OIN.

packages/@okta/vuepress-site/docs/guides/submit-app-prereq/main/index.md

@@ -67,6 +67,12 @@ The following multi-tenant example assumes that your Okta app integration suppor
 * Similarly, customer B instantiates your OIDC app integration in their Okta org and obtains their unique client ID and secret. They then sign in to their account on your app platform. They use their client ID, client secret, and Okta domain (for the issuer URL) to enable SSO without any assistance from you.
 * Each customer enables SSO to your app for their users in a separate credential system with their Okta org. Because you've created a self-service portal that allows your customers to enable SSO by themselves, you save resources and provide autonomy to your customers.
 
+#### Rate limit considerations
+
+When you construct your SSO app, be aware of the limits on requests to Okta APIs. Okta provides headers in each response to report on both concurrent and org-wide rate limits. To monitor org-wide rate limits, include code in your app to check the relevant headers in the response.
+
+For information on the rate-limit categories, including which public metadata endpoints aren't subject to rate limits, see the [Rate limits overview](/docs/reference/rate-limits/). For details on response headers, troubleshooting HTTP 429 errors, and requesting a temporary rate limit increase, see [Monitor and troubleshoot rate limits](/docs/reference/rl2-monitor/).
+
 ## OIN Wizard requirements
 
 The OIN Wizard is only available in Integrator Free Plan orgs.
@@ -78,7 +84,9 @@ To access the OIN Wizard and the **Your OIN Integrations** dashboard in your org
 * You must have either the super admin or the app and org admin [roles](https://help.okta.com/okta_help.htm?type=oie&id=ext-administrators-admin-comparison) assigned to you.
 * Use your company domain email as your username for your Okta admin account (submissions from a personal email account aren't reviewed).
 
-> **Note:** The app admin role enables you to view and edit details in the OIN Wizard. For OIN Wizard testing, you must have both the app admin and the org admin roles assigned to you. The super admin role gives you access to all functionality in the OIN Wizard.
+> **Notes:**
+> The app admin role enables you to view and edit details in the OIN Wizard. For OIN Wizard testing, you must have both the app admin and the org admin roles assigned to you. The super admin role gives you access to all functionality in the OIN Wizard.
+> You can't use the Okta SDKs to validate access tokens for apps in the OIN. This is due to the OIN restriction of using an org authorization server and the Authorization Code flow.
 
 ### OIN Wizard test requirements
 
@@ -528,9 +536,21 @@ You can't publish integrations with the following Okta features in the OIN catal
 
 In addition to the general OIN limitations, the following are limitations specific to OIDC or OAuth 2.0 integrations:
 
-* You can't use a [custom authorization server](/docs/concepts/auth-servers/#custom-authorization-server) that includes the `default` server for an OIDC or API service integration. You can only use the [org authorization server](/docs/concepts/auth-servers/#org-authorization-server).
+* When you create your app integration in your Okta org, select **Web Application** as the OIDC app type.
+
+* Native and mobile app integrations aren't accepted as OIDC app integrations in the OIN unless they use server-side authentication patterns. Set up your app to use an authentication flow that allows your client app to talk to your SaaS backend. Your SaaS backend can then securely communicate with Okta through trusted back-channel connections. See [Implement the authorization code flow](/docs/guides/implement-grant-type/authcode/main/).
 
-* You can't use the Okta SDKs to validate access tokens with the [org authorization server](/docs/concepts/auth-servers/#org-authorization-server).
+* The Implicit flow isn't recommended for token exchange in web apps. If your use case requires the use of an Implicit flow for token exchange, contact [Okta Support](https://support.okta.com).
+
+* You can't use a [custom authorization server](/docs/concepts/auth-servers/#custom-authorization-server) that includes the `default` server for an OIDC or API service integration. You can only use the [org authorization server](/docs/concepts/auth-servers/#org-authorization-server). The following are the various `/authorize` request URLs for the different authorization servers:
+
+  * **custom authorization server**: `https://{customerOktaDomain}/oauth2/{authorizationServerId}/v1/authorize?client_id={clientId}&response_type=code&scope=openid&redirect_uri={redirectURI}&state={state}`
+  * **default custom authorization server** (`{authorizationServerId}=default`): `https://{customerOktaDomain}/oauth2/default/v1/authorize?client_id={clientId}&response_type=code&scope=openid&redirect_uri={redirectURI}&state={state}`
+  * **org authorization server**: `https://{customerOktaDomain}/oauth2/v1/authorize?client_id={clientId}&response_type=code&scope=openid&redirect_uri={redirectURI}&state={state}`
+
+  Make sure that you only use the **org authorization server** URL. When you use the org authorization server, the issuer URL is `https://{yourOktaDomain}`.
+
+* You can't use the Okta SDKs to validate access tokens with the [org authorization server](/docs/concepts/auth-servers/#org-authorization-server). This is due to the OIN restriction of using an org authorization server and the Authorization Code flow.
 
 * Refresh tokens aren't supported for SSO OIDC integrations published in the OIN.
 
@@ -556,6 +576,8 @@ In addition to the general OIN limitations, the following are limitations specif
 
 * SP-initiated Single Logout (SLO) isn’t supported.
 
+The OIN Wizard doesn't accept new SSO integrations with more than three app instance variables or advanced SAML features. For these new integrations, add a [private SSO integration](/docs/guides/add-private-app/) with the Application Integration Wizard (AIW) in your Okta org instead.
+
 The OIN team maintains existing SAML integrations with advanced features not supported in the OIN Wizard. If you need to update your existing advanced SAML integration, contact the OIN team at <oin@okta.com>.
 
 ### SCIM integration limitations

packages/@okta/vuepress-site/docs/guides/updating-saml-cert/main/index.md

@@ -300,4 +300,4 @@ Response:
 
 * [SAML overview](https://developer.okta.com/docs/concepts/saml/)
 * [SAML FAQ](https://developer.okta.com/docs/concepts/saml/faqs/)
-* [Building a SAML SSO integration](https://developer.okta.com/docs/guides/build-sso-integration/saml2/before-you-begin/)
+* [Building a SAML SSO integration](https://developer.okta.com/docs/guides/create-an-app-integration/saml2/main/)

packages/@okta/vuepress-site/docs/reference/rate-limits/index.md

@@ -31,6 +31,12 @@ Buckets scoped to authenticated users are independent and not nested under any o
 A bucket’s quota can vary based on several factors, including—but not limited to—the type of service subscription (for example, Workforce versus Customer Identity), the HTTP method used (for example, GET versus POST), the number of licenses purchased, and any applicable add-ons, such as DynamicScale. If the quota is exceeded within the time window, further requests are rejected with an HTTP 429 Too Many Requests response until the quota resets.
 You can monitor rate limit usage through the rate limit dashboard, System Log, or by inspecting the rate limiting headers included in API responses. See [Monitor and troubleshoot rate limits](/docs/reference/rl2-monitor/).
 
+>**Note:** The following public metadata endpoints aren't subject to rate limits:
+>
+>* `/oauth2/v1/keys`
+>* `/.well-known/openid-configuration`
+>* `/.well-known/oauth-authorization-server`
+
 ## How rate limiting works
 
 The logic behind the Okta implementation of rate limits can be summarized in the following steps: