okta · susanharper-okta · Feb 12, 2026 · Feb 6, 2026 · Feb 6, 2026 · Feb 9, 2026
@@ -119,7 +119,7 @@ Client apps may also exchange tokens with a Security Token Service (STS) to prov
 
 You can use direct authentication with your apps in Identity Engine rather than an embedded SDK, the customer-hosted Okta Sign-In Widget, or direct APIs. This allows you to directly authenticate users rather than delegating authentication to Okta identity providers and authorization servers through an HTTP redirect in a web browser. Direct authentication is beneficial in scenarios where there's a high degree of trust between the user and the app. It's also beneficial where browser-based flows aren't feasible, like with mobile apps.
 
-See the `/challenge` [endpoint](https://developer.okta.com/docs/api/openapi/okta-oauth/oauth/tag/OrgAS/#tag/OrgAS/operation/challengeOrgAS), the `/oob-authenticate` [endpoint](https://developer.okta.com/docs/api/openapi/okta-oauth/oauth/tag/OrgAS/#tag/OrgAS/operation/oob-authenticateOrgAS), and the new `grant_types` for the `/token` [endpoint](https://developer.okta.com/docs/api/openapi/okta-oauth/oauth/tag/OrgAS/#tag/OrgAS/operation/token). Also, for information on how to set up each new grant type, see [Configure Direct Authentication](/docs/guides/configure-direct-auth-grants/).
+See the `/challenge` [endpoint](https://developer.okta.com/docs/api/openapi/okta-oauth/oauth/tag/OrgAS/#tag/OrgAS/operation/challengeOrgAS), the `/primary-authenticate` [endpoint](https://developer.okta.com/docs/api/openapi/okta-oauth/oauth/tag/OrgAS/#tag/OrgAS/operation/primary-authenticateOrgAS), and the new `grant_types` for the `/token` [endpoint](https://developer.okta.com/docs/api/openapi/okta-oauth/oauth/tag/OrgAS/#tag/OrgAS/operation/token). Also, for information on how to set up each new grant type, see [Configure Direct Authentication](/docs/guides/configure-direct-auth-grants/).
 
 ### Other embedded authentication solutions
 

@@ -16,7 +16,7 @@ participant "Authorization Server (Okta) " as okta
 autonumber "<b>#."
 client -> user: Prompts user for username
 user -> client: Enters username
-client -> okta: Sends OOB authentication request to `/oob-authenticate`
+client -> okta: Sends OOB authentication request to `/primary-authenticate`
 okta -> client: Sends `oob_code`, `interval`, other parameters required by authenticator
 okta -> user: Sends push notification
 user <-> client: Per configured authenticator options, more interaction may occur
@@ -33,7 +33,7 @@ At a high level, this flow has the following steps:
 
 1. Your client app prompts the user for their username in the app interface.
 1. The user enters their username.
-1. Your app sends the username as a `login_hint` and `channel_hint=push` to the Okta authorization server `/oob-authenticate` endpoint.
+1. Your app sends the username as a `login_hint` and `channel_hint=push` to the Okta authorization server `/primary-authenticate` endpoint.
 
     Register your app so that Okta can accept the authorization request. See [Set up your app](#set-up-your-app) to register and configure your app with Okta. After registration, your app can make an authorization request to Okta. See [Request for tokens](#request-for-tokens).
 

@@ -2,13 +2,13 @@ The following sections outline the requests required to implement the out-of-ban
 
 ### Request for out-of-band authentication
 
-Before you can begin this flow, collect the username from the user in a manner of your choosing. Then, make an API call to the Okta [authorization server](/docs/concepts/auth-servers/) `/oob-authenticate` endpoint. Use this endpoint to initiate an authentication flow with an out-of-band factor as the primary factor. Your request should look something like this:
+Before you can begin this flow, collect the username from the user in a manner of your choosing. Then, make an API call to the Okta [authorization server](/docs/concepts/auth-servers/) `/primary-authenticate` endpoint. Use this endpoint to initiate an authentication flow with an out-of-band factor as the primary factor. Your request should look something like this:
 
-> **Note:** The `/oob-authenticate` endpoint doesn't support multifactor authentication.
+> **Note:** The `/primary-authenticate` endpoint doesn't support multifactor authentication.
 
 ```bash
 curl --request POST \
-  --url https://{yourOktaDomain}/oauth2/v1/oob-authenticate \
+  --url https://{yourOktaDomain}/oauth2/v1/primary-authenticate \
   --header 'accept: application/json' \
   --header 'content-type: application/x-www-form-urlencoded' \
   --data 'client_id={client_id}&login_hint={testuser%40example.com}&channel_hint=push'
@@ -20,7 +20,7 @@ Note the parameters that are passed:
 - `login_hint`: The email username of a registerd Okta user
 - `channel_hint`: The out-of-band channel used by the client. For Okta Verify, use `push`.
 
-For more information on these parameters, see the `/oob-authenticate` [endpoint](https://developer.okta.com/docs/api/openapi/okta-oauth/oauth/tag/OrgAS/#tag/OrgAS/operation/oob-authenticate).
+For more information on these parameters, see the `/primary-authenticate` [endpoint](https://developer.okta.com/docs/api/openapi/okta-oauth/oauth/tag/OrgAS/#tag/OrgAS/operation/primary-authenticate).
 
 ### OOB response example for Okta Verify Push
 

@@ -16,7 +16,7 @@ participant "Authorization Server (Okta) " as okta
 
 autonumber "<b>#."
 client <-> user: Prompts user for username, and user enters username
-client -> okta: Sends `/oob-authenticate` request with `channel_hint`
+client -> okta: Sends `/primary-authenticate` request with `channel_hint`
 okta -> client: Responds with `oob_code`, `channel`, `binding_method`
 okta -> user: Sends out-of-band challenge
 client -> user: Prompts user to enter OTP, and user enters OTP
@@ -29,7 +29,7 @@ At a high level, this flow has the following steps:
 
 1. Your client app prompts the user for their username in the app interface.
 1. The user enters their username.
-1. Your app sends the following parameters to the Okta authorization server `/oob-authenticate` endpoint:
+1. Your app sends the following parameters to the Okta authorization server `/primary-authenticate` endpoint:
     * `login_hint`
     * `channel_hint` with a value of `sms` or `voice`
 

@@ -2,15 +2,15 @@ The following sections outline the requests required to implement the out-of-ban
 
 ### Request for out-of-band authentication
 
-Before you can begin this flow, collect the username from the user in a manner of your choosing. Then, make an API call to the Okta [authorization server](/docs/concepts/auth-servers/) `/oob-authenticate` endpoint. Use this endpoint to initiate an authentication flow with an out-of-band factor (such as SMS or Voice) as the primary factor.
+Before you can begin this flow, collect the username from the user in a manner of your choosing. Then, make an API call to the Okta [authorization server](/docs/concepts/auth-servers/) `/primary-authenticate` endpoint. Use this endpoint to initiate an authentication flow with an out-of-band factor (such as SMS or Voice) as the primary factor.
 
-> **Note:** The `/oob-authenticate` endpoint doesn't support multifactor authentication.
+> **Note:** The `/primary-authenticate` endpoint doesn't support multifactor authentication.
 
 Your request should look something like this:
 
 ```bash
 curl --request POST \
-  --url https://{yourOktaDomain}/oauth2/v1/oob-authenticate \
+  --url https://{yourOktaDomain}/oauth2/v1/primary-authenticate \
   --header 'accept: application/json' \
   --header 'content-type: application/x-www-form-urlencoded' \
   --data 'client_id={client_id}&login_hint={testuser%40example.com}&channel_hint={sms or voice}'
@@ -22,7 +22,7 @@ Note the parameters that are passed:
 - `login_hint`: The email username of a registered Okta user
 - `channel_hint`: The out-of-band channel that the client wants to use. For Phone, use `sms` or `voice`.
 
-For more information on these parameters, see the `/oob-authenticate` [endpoint](https://developer.okta.com/docs/api/openapi/okta-oauth/oauth/tag/OrgAS/#tag/OrgAS/operation/oob-authenticate).
+For more information on these parameters, see the `/primary-authenticate` [endpoint](https://developer.okta.com/docs/api/openapi/okta-oauth/oauth/tag/OrgAS/#tag/OrgAS/operation/primary-authenticate).
 
 ### OOB response example
 

@@ -37,7 +37,7 @@ Okta provides two embedded identity solutions:
 
 This guide shows you how to set up your Okta org to support the embedded SDK or the embedded widget with SDK solutions. Ensure that you [get set up](#get-set-up) with Okta and [set up your Okta org for your use case](#set-up-your-okta-org-for-your-use-case) before you <StackSnippet snippet="downloadguideuri" inline />.
 
-> **Note:** You can use direct authentication with your apps in Identity Engine rather than an embedded SDK. This enables you to directly authenticate users rather than delegating authentication to Okta Identity Providers and authorization servers through an HTTP redirect in a browser. Direct authentication is beneficial in scenarios where there's a high degree of trust between the user and the app. It's also beneficial where browser-based flows aren't feasible, like with mobile apps. See the `/challenge` [endpoint](https://developer.okta.com/docs/api/openapi/okta-oauth/oauth/tag/OrgAS/#tag/OrgAS/operation/challengeOrgAS), the `/oob-authenticate` [endpoint](https://developer.okta.com/docs/api/openapi/okta-oauth/oauth/tag/OrgAS/#tag/OrgAS/operation/oob-authenticateOrgAS), and the new `grant_types` for the `/token` [endpoint](https://developer.okta.com/docs/api/openapi/okta-oauth/oauth/tag/OrgAS/#tag/OrgAS/operation/token) to help tailor authentication to your specific use cases. Also, for information on how to set up each new grant type, see [Implement by grant type](/docs/guides/configure-direct-auth-grants/aotp/main/).
+> **Note:** You can use direct authentication with your apps in Identity Engine rather than an embedded SDK. This enables you to directly authenticate users rather than delegating authentication to Okta Identity Providers and authorization servers through an HTTP redirect in a browser. Direct authentication is beneficial in scenarios where there's a high degree of trust between the user and the app. It's also beneficial where browser-based flows aren't feasible, like with mobile apps. See the `/challenge` [endpoint](https://developer.okta.com/docs/api/openapi/okta-oauth/oauth/tag/OrgAS/#tag/OrgAS/operation/challengeOrgAS), the `/primary-authenticate` [endpoint](https://developer.okta.com/docs/api/openapi/okta-oauth/oauth/tag/OrgAS/#tag/OrgAS/operation/primary-authenticateOrgAS), and the new `grant_types` for the `/token` [endpoint](https://developer.okta.com/docs/api/openapi/okta-oauth/oauth/tag/OrgAS/#tag/OrgAS/operation/token) to help tailor authentication to your specific use cases. Also, for information on how to set up each new grant type, see [Implement by grant type](/docs/guides/configure-direct-auth-grants/aotp/main/).
 
 ## Get set up