Claims sharing

packages/@okta/vuepress-site/docs/guides/add-an-external-idp/main/oktatookta/appatidp.md

@@ -15,7 +15,3 @@ When you're configuring federation between two Okta orgs, use OpenID Connect as
 
 1. Assign a group or leave the **Everyone** default. Ensure that the users you want to have access are assigned to the group that you select. For instructions on how to assign the app integration to individual users and groups, see [Assign app integrations](https://help.okta.com/okta_help.htm?id=ext_Apps_Apps_Page-assign).
 1. Click **Save**, and then copy the **Client ID** and **Client secret** from the **Client Credentials** section and paste into a text editor. You need these when you configure this IdP in your other Okta org in the next section.
-
-<AMROktatoOkta/>
-
-See [Create an Identity Provider in Okta](#create-an-identity-provider-in-okta) for Okta-to-Okta orgs.

packages/@okta/vuepress-site/docs/guides/configure-amr-claims-mapping/index.md

@@ -1,6 +1,6 @@
 ---
-title: Configure AMR claims mapping
-excerpt: Learn how to configure an OpenID Connect Identity Provider to send AMR claims during SSO to your org
+title: Configure claims sharing
+excerpt: Learn how to configure an identity provider to send claims during SSO
 layout: Guides
 sections:
 - main

packages/@okta/vuepress-site/docs/guides/configure-claims-sharing/index.md

@@ -0,0 +1,7 @@
+---
+title: Configure claims sharing
+excerpt: Learn how to configure an identity provider to send claims during SSO
+layout: Guides
+sections:
+- main
+---

packages/@okta/vuepress-site/docs/guides/configure-claims-sharing/main/index.md

@@ -0,0 +1,158 @@
+---
+title: Configure claims sharing
+excerpt: Learn how to configure an identity provider to send claims during SSO
+layout: Guides
+---
+
+<ApiLifecycle access="ea" />
+
+This guide explains how to configure an <StackSnippet snippet="idptype" inline /> identity provider (IdP) to send authentication claims during Single Sign-On (SSO).
+
+---
+
+#### Learning outcomes
+
+* Know the purpose of claims sharing
+* Configure your <StackSnippet snippet="idptype" inline /> identity provider (IdP) to send authentication claims during SSO
+
+#### What you need
+
+* An Okta SP org and an Okta IdP org configured for an [Okta-to-Okta](/docs/guides/add-an-external-idp/oktatookta/main/) use case. This guide covers how to configure authentication claims sharing for this scenario.
+* The **Okta-to-Okta Claims Sharing** feature enabled for both orgs. Go to **Settings | Features**, locate the feature, and then enable it.
+* If you don't have Okta orgs, you can create [Okta Developer Edition orgs](https://developer.okta.com/signup).
+
+---
+
+## Overview
+
+Claims sharing is the exchange of identity-related information (claims) between different orgs to enable secure access to resources. A claim is a statement made about a user or entity, such as their username, email address, roles, or permissions. This statement is then shared to help determine access rights.
+
+> **Note:** Okta claims sharing currently supports only Okta IdPs and SPs.
+
+### Authentication claims sharing
+
+Authentication claims sharing allows an admin to configure their Okta org to trust claims from IdPs during SSO. Sharing claims also allows Okta to interpret the authentication context from an IdP. This helps eliminate duplicate factor challenges during user authentication and helps improve security posture.
+
+Claims sharing provides assurance context to Okta during policy evaluation. For example, these claims give Okta a better understanding of which factors were used by the IdP to verify the user's identity. Claims do this by conveying information from the IdP that's needed to make policy decisions in the SP. This creates a seamless and secure user experience, which reduces friction and boosts productivity to achieve end-to-end security.
+
+### Accepted authenticators
+
+All authenticators that are natively performed on the Okta IdP are accepted. This includes authenticators such as WebAuthn, password, Okta Verify, Okta FastPass, SMS, email, and so on. Claim sharing doesn't currently support the use of any Custom Authenticators for MFA, such as using another IdP or smart card.
+
+### AMR claims mapping is enabled on your org
+
+When you enable the **Okta-to-Okta Claims Sharing** feature for your orgs and trust claims from an identity provider, Okta ignores the legacy **AMR Claims Mapping** feature.
+
+### <StackSnippet snippet="idptype" inline /> IdP authentication claims sharing
+
+<StackSnippet snippet="idpauthclaimssharing" />
+
+#### Example <StackSnippet snippet="idpresponsetitle" inline />
+
+<StackSnippet snippet="idpresponse" />
+
+## Configure claims sharing for Okta orgs
+
+The **Okta-to-Okta Claims Sharing** feature enables claims sharing between Okta orgs. This section covers how to configure authentication claims sharing for this use case.
+
+### Okta IdP configuration
+
+Okta supports the use of SAML 2.0 and OpenID Connect app integrations, and the Org2Org app in the OIN catalog. This is the app that you use for authenticating and authorizing your users. There are no configuration requirements for claims sharing for the Okta IdP org.
+
+### Okta SP configuration
+
+To use claims sharing, update the IdP settings in your Okta SP org by adding the `trustClaims: true` key and value pair to your IdP PUT request. Alternatively, you can enable the **Trust claims from this identity provider** checkbox in the Admin Console. See <StackSnippet snippet="addanidp" inline />.
+
+> **Note:** When **Okta-to-Okta Claims Sharing** and the legacy **AMR Claims Mapping** feature are both used in your SP org, claims sharing is the only feature considered. The `mapAMRClaims` property (**Trust AMR claims from this identity provider** checkbox in the Admin Console) is associated with the legacy claims mapping feature. If you include this property and the `trustClaims: true` property in your request, only the `trustClaims` property is considered.
+
+#### Example Okta <StackSnippet snippet="idptype" inline /> IdP update request
+
+<StackSnippet snippet="idpupdaterequest" />
+
+#### Response example
+
+> **Note:** This example is truncated for brevity.
+
+<StackSnippet snippet="idpupdateresponse" />
+
+## Policies and claims sharing
+
+You can configure many scenarios for authentication using claims sharing and policies in your Okta SP and Okta IdP orgs.
+
+### Authentication policy example
+
+[Create an authentication policy and rule for your app](https://help.okta.com/okta_help.htm?type=oie&id=ext-create-auth-policy). Select any two factors, don't select a possession constraint, and allow any authenticators.
+
+With trust claims enabled and your IdP org able to verify any two factors, you can satisfy the requirements in the SP org.
+
+#### Other authentication policy scenarios
+
+* **Possession factor constraints:** If you enable any possession factor constraints in the authentication policy of your SP org, the IdP org must satisfy the requirement with appropriate factor verification.
+
+* **Authentication methods:**
+  * **Allow any method that can be used to meet the requirement**: If you enable this setting in your SP org, you can satisfy the policy requirements by using any authenticator that meets those requirements. This includes authenticators that aren't configured locally in the SP org.
+  * **Disallow specific authentication methods**: If you specify authentication methods to disallow, then the SP org disallows those methods.
+  * **Allow specific authentication methods**: If you specify authentication methods to allow, then the SP org only considers those methods.
+
+  After you define these conditions, if you still haven't met the policy requirement, then the SP org redirects you to verify any locally configured authenticator. If there's no local authenticator available, or the enrollment policy for a particular authenticator is disabled, then the SP org displays an error.
+
+### Global session policy example
+
+This same concept applies to the global session policy. Without trust claims enabled, if you have only the password authenticator configured in the SP org, you can't save a global session policy rule that requires MFA.
+
+However, with trust claims enabled, you can specify MFA as required. As long as the claim is coming from the IdP, the session is established because that claim can satisfy the global session policy rule.
+
+### Okta Identity Engine and Classic Engine orgs
+
+If you a combination of Okta Identity Engine and Classic Engine orgs, the rules work in the following ways:
+
+#### Example scenario one
+
+Your SP org is an Identity Engine org. Your IdP is a Classic Engine org. MFA from the Classic Engine org can only satisfy one of the following authentication policy rules on the Identity Engine SP org:
+
+* **Any 1 factor type/IdP**
+* **Any 2 factor types**
+
+For the global session policy, MFA from the Classic Engine org can only satisfy the **Any factor used to meet the Authentication Policy requirements** rule.
+
+#### Example scenario two
+
+Your IdP org is an Identity Engine org. Your SP org is a Classic Engine org. The Classic Engine org only evaluates whether MFA was completed, such as if more than one factor verification was performed on the IdP org.
+
+## Test your integration
+
+To test your integration, first [configure a routing rule](https://help.okta.com/okta_help.htm?id=ext-cfg-routing-rules) for the IdP and then use the IdP to sign in.
+
+### Configure a routing rule for the IdP
+
+Configure a simple routing rule for the IdP in the Okta SP org.
+
+* Click **Add Routing Rule**.
+* Enter a name and leave the default values.
+* In the **THEN Use this identity provider** section, add your IdP in the **IdP(s)** field.
+* Click **Create Rule**.
+
+### Use the IdP to sign in
+
+1. Access your Okta SP org using your browser's privacy or incognito mode to avoid false positive or negative results.
+1. Click **Sign in with {Name of IdP}** on the Okta sign-in page.
+
+   The following are the results if everything is configured properly:
+
+   * The user is redirected to the IdP's sign-in page.
+   * The authenticators configured in the authentication policy prompt the user for more authentication.
+   * After successful authentication, the user is redirected to the <StackSnippet snippet="redirect" inline /> specified in the Okta IdP org app.
+
+   If something is configured incorrectly, the authorization response contains error information to help you resolve the issue. See the [FAQ](#faq) section.
+
+## Trust claims deletion/deactivation
+
+You can only deactivate or delete an IdP with trust claims enabled if there are other active IdPs that have trust claims enabled. Or, you can deactivate or delete the IdP if all policies are configured in a way that doesn't require trusted claims.
+
+> **Note:** This is also true if you try to disable the **Okta-to-Okta Claims Sharing** feature.
+
+## Reauthentication
+
+Okta claims sharing doesn't currently support reauthentication. The user isn’t prompted for reauthentication as long as the session is active.
+
+Also, when you federate from the IdP org to the SP org’s Okta dashboard and then click **Admin**, you aren't prompted for reauthentication. The factors from the IdP are valid until the end of the session on the SP org.

packages/@okta/vuepress-site/docs/guides/configure-claims-sharing/main/oktaoidc/addanidp.md

@@ -0,0 +1 @@
+[Add an OpenID Connect Identity Provider](/docs/guides/add-an-external-idp/openidconnect/main/)

packages/@okta/vuepress-site/docs/guides/configure-claims-sharing/main/oktaoidc/idpauthclaimssharing.md

@@ -0,0 +1 @@
+When you use OpenID Connect with claims sharing, the data that's shared between an Okta IdP and an Okta SP is included in the ID token under a new reserved claim name called `okta_auth`. The `okta_auth` payload within the ID token response contains information about authentication performed at the Okta IdP org.

packages/@okta/vuepress-site/docs/guides/configure-claims-sharing/main/oktaoidc/idpresponse.md

@@ -0,0 +1,17 @@
+> **Note:** The `okta_auth` JSON payload in the ID token is redacted.
+
+```JSON
+{
+  "aud": "ts1hjc8xh3",
+  "auth_time": 1720481750,
+  "email": "[email protected]",
+  "exp": 1720482230,
+  "family_name": "Smith",
+  "given_name": "Jon",
+  "iat": 1720481810,
+  "iss": "https://idp.okta.com",
+  "nonce": "3byzgGdVLxjNUQ3X73rYgQBUc_DO4AJ2",
+  "sub": "[email protected]",
+  "okta_auth": {...JSON payload...}
+}
+```

packages/@okta/vuepress-site/docs/guides/configure-claims-sharing/main/oktaoidc/idpresponsetitle.md

@@ -0,0 +1 @@
+ID token

packages/@okta/vuepress-site/docs/guides/configure-claims-sharing/main/oktaoidc/idptype.md

@@ -0,0 +1 @@
+OpenID Connect

packages/@okta/vuepress-site/docs/guides/configure-claims-sharing/main/oktaoidc/idpupdaterequest.md

@@ -0,0 +1,73 @@
+```JSON
+{
+    "id": "0oa3q52z4b7iDGJfh806",
+    "issuerMode": "DYNAMIC",
+    "name": "Org2Org OIDC IdP",
+    "status": "ACTIVE",
+    "created": "2025-01-14T21:56:04.000Z",
+    "lastUpdated": "2025-01-17T20:01:09.000Z",
+    "protocol": {
+        "type": "OIDC",
+        "endpoints": {
+            "authorization": {
+                "url": "https://{yourOktaIdPDomain}/oauth2/v1/authorize",
+                "binding": "HTTP-REDIRECT"
+            },
+            "token": {
+                "url": "https://{yourOktaIdPDomain}/oauth2/v1/token",
+                "binding": "HTTP-POST"
+            },
+            "jwks": {
+                "url": "https://{yourOktaIdPDomain}/oauth2/v1/keys",
+                "binding": "HTTP-REDIRECT"
+            }
+        },
+        "scopes": [
+            "email",
+            "openid",
+            "profile"
+        ],
+        "issuer": {
+            "url": "https://{yourOktaIdPDomain}"
+        },
+        "credentials": {
+            "client": {
+                "client_id": "0oa3q52oiB4UBbQFT806",
+                "client_secret": "X7i4OV8UXUkrqIhr2vFs0RzeYFy3AUmXe_huqfgMw-eiw1KMUUCEs7X7YXrR_9Sq"
+            }
+        }
+    },
+    "policy": {
+        "provisioning": {
+            "action": "AUTO",
+            "profileMaster": false,
+            "groups": {
+                "action": "NONE"
+            },
+            "conditions": {
+                "deprovisioned": {
+                    "action": "NONE"
+                },
+                "suspended": {
+                    "action": "NONE"
+                }
+            }
+        },
+        "accountLink": {
+            "filter": null,
+            "action": "AUTO"
+        },
+        "subject": {
+            "userNameTemplate": {
+                "template": "idpuser.email"
+            },
+            "filter": "",
+            "matchType": "USERNAME",
+            "matchAttribute": ""
+        },
+        "maxClockSkew": 0,
+        "trustClaims": true
+    },
+    "type": "OIDC"
+}
+```

packages/@okta/vuepress-site/docs/guides/configure-claims-sharing/main/oktaoidc/idpupdateresponse.md

@@ -0,0 +1,74 @@
+```JSON
+{
+    "id": "0oa3q52z4b7iDGJfh806",
+    "issuerMode": "DYNAMIC",
+    "name": "Org2Org OIDC IdP",
+    "status": "ACTIVE",
+    "created": null,
+    "lastUpdated": "2025-01-21T19:52:54.000Z",
+    "protocol": {
+        "type": "OIDC",
+        "endpoints": {
+            "authorization": {
+                "url": "https://{yourOktaIdPDomain}/oauth2/v1/authorize",
+                "binding": "HTTP-REDIRECT"
+            },
+            "token": {
+                "url": "https://{yourOktaIdPDomain}/oauth2/v1/token",
+                "binding": "HTTP-POST"
+            },
+            "jwks": {
+                "url": "https://{yourOktaIdPDomain}/oauth2/v1/keys",
+                "binding": "HTTP-REDIRECT"
+            }
+        },
+        "scopes": [
+            "email",
+            "openid",
+            "profile"
+        ],
+        "issuer": {
+            "url": "https://{yourOktaIdPDomain}"
+        },
+        "credentials": {
+            "client": {
+                "client_id": "0oa3q52oiB4UBbQFT806",
+                "client_secret": "X7i4OV8UXUkrqIhr2vFs0RzeYFy3AUmXe_huqfgMw-eiw1KMUUCEs7X7YXrR_9Sq"
+            }
+        }
+    },
+    "policy": {
+        "provisioning": {
+            "action": "AUTO",
+            "profileMaster": false,
+            "groups": {
+                "action": "NONE"
+            },
+            "conditions": {
+                "deprovisioned": {
+                    "action": "NONE"
+                },
+                "suspended": {
+                    "action": "NONE"
+                }
+            }
+        },
+        "accountLink": {
+            "filter": null,
+            "action": "AUTO"
+        },
+        "subject": {
+            "userNameTemplate": {
+                "template": "idpuser.email"
+            },
+            "filter": "",
+            "matchType": "USERNAME",
+            "matchAttribute": ""
+        },
+        "maxClockSkew": 0,
+        "trustClaims": true
+    },
+    "type": "OIDC",
+    .....
+}
+```

packages/@okta/vuepress-site/docs/guides/configure-claims-sharing/main/oktaoidc/redirect.md

@@ -0,0 +1 @@
+redirect URI

packages/@okta/vuepress-site/docs/guides/configure-claims-sharing/main/oktasaml/addanidp.md

@@ -0,0 +1 @@
+[Add a SAML Identity Provider](https://help.okta.com/okta_help.htm?type=oie&id=csh-idp-add-saml)

packages/@okta/vuepress-site/docs/guides/configure-claims-sharing/main/oktasaml/idpauthclaimssharing.md

@@ -0,0 +1 @@
+When you use SAML 2.0 with claims sharing, the data that's shared between an Okta IdP and an Okta SP is included in the SAML response in a new reserved tag in the `Extension` section called `OktaAuth`. This content is communicated in JSON within the `Assertion` response and contains information about authentication performed at the Okta IdP org. The entire assertion is securely encrypted with a published encryption key from the SP org.

packages/@okta/vuepress-site/docs/guides/configure-claims-sharing/main/oktasaml/idpresponse.md

@@ -0,0 +1,20 @@
+> **Note:** The `OktaAuth` JSON payload is redacted and the response is truncated for brevity.
+
+```JSON
+.....
+<saml2:AuthnStatement AuthnInstant="2024-08-21T21:22:21.250Z" SessionIndex="id29513242525044581346797160">
+    <saml2:AuthnContext>
+        <saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:X509</saml2:AuthnContextClassRef>
+        <saml2:AuthnContextDecl>
+            <AuthenticationContextDeclaration xmlns="urn:okta:saml:2.0:OktaAuth">
+                <Extension>
+                    <OktaAuth xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
+                        ...JSON payload...
+                    </OktaAuth>
+                </Extension>
+            </AuthenticationContextDeclaration>
+        </saml2:AuthnContextDecl>
+    </saml2:AuthnContext>
+</saml2:AuthnStatement>
+.....
+```

packages/@okta/vuepress-site/docs/guides/configure-claims-sharing/main/oktasaml/idpresponsetitle.md

@@ -0,0 +1 @@
+SAML 2.0 IdP response

packages/@okta/vuepress-site/docs/guides/configure-claims-sharing/main/oktasaml/idptype.md

@@ -0,0 +1 @@
+SAML 2.0