Skip to main content

identity_providers

Creates, updates, deletes, gets or lists an identity_providers resource.

Overview​

Nameidentity_providers
TypeResource
Idokta.idps.identity_providers

Fields​

The following fields are returned by SELECT queries:

NameDatatypeDescription
idstringUnique key for the IdP (example: 0oaWma58liwx40w6boYD)
namestringUnique name for the IdP (example: Sample IdP)
_linksobjectSpecifies link relations (see Web Linking) available using the JSON Hypertext Application Language specification. This object is used for dynamic discovery of related resources and lifecycle operations.
createdstring (date-time)Timestamp when the object was created (example: 2016-01-03T18:15:47.000Z)
issuerModestringIndicates whether Okta uses the original Okta org domain URL or a custom domain URL in the request to the social IdP (default: DYNAMIC)
lastUpdatedstring (date-time)Timestamp when the object was last updated (example: 2016-01-03T18:15:47.000Z)
policyobjectPolicy settings for the IdP. The following provisioning and account linking actions are supported by each IdP provider: | IdP type | User provisioning actions | Group provisioning actions | Account link actions | Account link filters | | ----------------------------------------------------------------- | ------------------------- | ------------------------------------- | -------------------- | -------------------- | | SAML2 | AUTO or DISABLED | NONE, ASSIGN, APPEND, or SYNC | AUTO, DISABLED | groups, users | | X509, IDV_PERSONA, IDV_INCODE, and IDV_CLEAR | DISABLED | No support for JIT provisioning | | | | All other IdP types | AUTO, DISABLED | NONE or ASSIGN | AUTO, DISABLED | groups, users |
propertiesobjectThe properties in the IdP properties object vary depending on the IdP type
protocolIdP-specific protocol settings for endpoints, bindings, and algorithms used to connect with the IdP and validate messages
statusstring
typestringThe IdP object's type property identifies the social or enterprise IdP used for authentication. Each IdP uses a specific protocol, therefore the protocol object must correspond with the IdP type. If the protocol is OAuth 2.0-based, the protocol object's scopes property must also correspond with the scopes supported by the IdP type. For policy actions supported by each IdP type, see IdP type policy actions. | Type | Description | Corresponding protocol | Corresponding protocol scopes | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------- | -------------------------------------------------------------------- | | AMAZON | Amazon as the IdP | OpenID Connect | profile, profile:user_id | | APPLE | Apple as the IdP | OpenID Connect | names, email, openid | | DISCORD | Discord as the IdP | OAuth 2.0 | identify, email | | FACEBOOK | Facebook as the IdP | OAuth 2.0 | public_profile, email | | GITHUB | GitHub as the IdP | OAuth 2.0 | user | | GITLAB | GitLab as the IdP | OpenID Connect | openid, read_user, profile, email | | GOOGLE | Google as the IdP | OpenID Connect | openid, email, profile | | IDV_PERSONA | Persona as the IDV IdP | ID verification | | | IDV_CLEAR | CLEAR Verified as the IDV IdP | ID verification | openid, profile, identity_assurance | | IDV_INCODE | Incode as the IDV IdP | ID verification | openid, profile, identity_assurance | | LINKEDIN | LinkedIn as the IdP | OAuth 2.0 | r_emailaddress, r_liteprofile | | LOGINGOV | Login.gov as the IdP | OpenID Connect | email, profile, profile:name | | LOGINGOV_SANDBOX | Login.gov's identity sandbox as the IdP | OpenID Connect | email, profile, profile:name | | MICROSOFT | Microsoft Enterprise SSO as the IdP | OpenID Connect | openid, email, profile, https://graph.microsoft.com/User.Read | | OIDC | IdP that supports OpenID Connect | OpenID Connect | openid, email, profile | | PAYPAL | Paypal as the IdP | OpenID Connect | openid, email, profile | | PAYPAL_SANDBOX | Paypal Sandbox as the IdP | OpenID Connect | openid, email, profile | | SALESFORCE | SalesForce as the IdP | OAuth 2.0 | id, email, profile | | SAML2 | Enterprise IdP that supports the SAML 2.0 Web Browser SSO Profile| SAML 2.0 | | | SPOTIFY | Spotify as the IdP | OpenID Connect | user-read-email, user-read-private | | X509 | Smart Card IdP | Mutual TLS | | | XERO | Xero as the IdP | OpenID Connect | openid, profile, email | | YAHOO | Yahoo as the IdP | OpenID Connect | openid, profile, email | | YAHOOJP | Yahoo Japan as the IdP | OpenID Connect | openid, profile, email | | OKTA_INTEGRATION | IdP that supports the OpenID Connect Org2Org IdP | OpenID Connect | openid, email, profile |

Methods​

The following methods are available for this resource:

NameAccessible byRequired ParamsOptional ParamsDescription
list_identity_providersselectsubdomainq, after, limit, typeLists all identity provider (IdP) integrations with pagination. A subset of IdPs can be returned that match a supported filter expression or query.
get_identity_providerselectsubdomainRetrieves an identity provider (IdP) integration by idpId
create_identity_providerinsertsubdomainCreates a new identity provider (IdP) integration.

#### SAML 2.0 IdP

You must first add the IdP's signature certificate to the IdP key store before you can add a SAML 2.0 IdP with a kid credential reference.

Don't use fromURI to automatically redirect a user to a particular app after successfully authenticating with a third-party IdP. Instead, use SAML deep links. Using fromURI isn't tested or supported. For more information about using deep links when signing users in using an SP-initiated flow, see Understanding SP-Initiated Login flow.

Use SAML deep links to automatically redirect the user to an app after successfully authenticating with a third-party IdP. To use deep links, assemble these three parts into a URL:

* SP ACS URL<br>
For example: https://$&#123;yourOktaDomain&#125;/sso/saml2/:idpId
* The app to which the user is automatically redirected after successfully authenticating with the IdP <br>
For example: /app/:app-location/:appId/sso/saml
* Optionally, if the app is an outbound SAML app, you can specify the relayState passed to it.<br>
For example: ?RelayState=:anyUrlEncodedValue

The deep link for the above three parts is:<br>
https://$&#123;yourOktaDomain&#125;/sso/saml2/:idpId/app/:app-location/:appId/sso/saml?RelayState=:anyUrlEncodedValue

#### Smart Card X509 IdP

You must first add the IdP's server certificate to the IdP key store before you can add a Smart Card X509 IdP with a kid credential reference.
You need to upload the whole trust chain as a single key using the Key Store API.
Depending on the information stored in the smart card, select the proper template idpuser.subjectAltNameEmail or idpuser.subjectAltNameUpn.

#### Identity verification vendors as identity providers

Identity verification vendors (IDVs) work like IdPs, with a few key differences. IDVs verify your user's identities by requiring them to submit a proof of identity. There are many ways to verify user identities. For example, a proof of identity can be a selfie to determine liveliness or it can be requiring users to submit a photo of their driver's license and matching that information with a database.

There are three IDVs that you can configure as IdPs in your org by creating an account with the vendor, and then creating an IdP integration. Control how the IDVs verify your users by using Okta account management policy rules.

* Persona

* CLEAR Verified

* Incode
replace_identity_providerreplacesubdomainReplaces an identity provider (IdP) integration by idpId
delete_identity_providerdeletesubdomainDeletes an identity provider (IdP) integration by idpId
* All existing IdP users are unlinked with the highest order profile source taking precedence for each IdP user.
* Unlinked users keep their existing authentication provider such as FEDERATION or SOCIAL.
activate_identity_providerexecsubdomainActivates an inactive identity provider (IdP)
deactivate_identity_providerexecsubdomainDeactivates an active identity provider (IdP)

Parameters​

Parameters can be passed in the WHERE clause of a query. Check the Methods section to see which parameters are required or optional for each operation.

NameDatatypeDescription
subdomainstringThe domain of your organization. This can be a provided subdomain of an official okta domain (okta.com, oktapreview.com, etc) or one of your configured custom domains. (default: my-org)
afterstringThe cursor to use for pagination. It is an opaque string that specifies your current location in the list and is obtained from the Link response header. See Pagination.
limitintegerA limit on the number of objects to return
qstringSearches the name property of IdPs for matching value (example: Example SAML)
typestringFilters IdPs by type

SELECT examples​

Lists all identity provider (IdP) integrations with pagination. A subset of IdPs can be returned that match a supported filter expression or query.

SELECT
id,
name,
_links,
created,
issuerMode,
lastUpdated,
policy,
properties,
protocol,
status,
type
FROM okta.idps.identity_providers
WHERE subdomain = '{{ subdomain }}' -- required
AND q = '{{ q }}'
AND after = '{{ after }}'
AND limit = '{{ limit }}'
AND type = '{{ type }}';

INSERT examples​

Creates a new identity provider (IdP) integration.

#### SAML 2.0 IdP

You must first add the IdP's signature certificate to the IdP key store before you can add a SAML 2.0 IdP with a kid credential reference.

Don't use fromURI to automatically redirect a user to a particular app after successfully authenticating with a third-party IdP. Instead, use SAML deep links. Using fromURI isn't tested or supported. For more information about using deep links when signing users in using an SP-initiated flow, see Understanding SP-Initiated Login flow.

Use SAML deep links to automatically redirect the user to an app after successfully authenticating with a third-party IdP. To use deep links, assemble these three parts into a URL:

* SP ACS URL<br>
For example: https://$&#123;yourOktaDomain&#125;/sso/saml2/:idpId
* The app to which the user is automatically redirected after successfully authenticating with the IdP <br>
For example: /app/:app-location/:appId/sso/saml
* Optionally, if the app is an outbound SAML app, you can specify the relayState passed to it.<br>
For example: ?RelayState=:anyUrlEncodedValue

The deep link for the above three parts is:<br>
https://$&#123;yourOktaDomain&#125;/sso/saml2/:idpId/app/:app-location/:appId/sso/saml?RelayState=:anyUrlEncodedValue

#### Smart Card X509 IdP

You must first add the IdP's server certificate to the IdP key store before you can add a Smart Card X509 IdP with a kid credential reference.
You need to upload the whole trust chain as a single key using the Key Store API.
Depending on the information stored in the smart card, select the proper template idpuser.subjectAltNameEmail or idpuser.subjectAltNameUpn.

#### Identity verification vendors as identity providers

Identity verification vendors (IDVs) work like IdPs, with a few key differences. IDVs verify your user's identities by requiring them to submit a proof of identity. There are many ways to verify user identities. For example, a proof of identity can be a selfie to determine liveliness or it can be requiring users to submit a photo of their driver's license and matching that information with a database.

There are three IDVs that you can configure as IdPs in your org by creating an account with the vendor, and then creating an IdP integration. Control how the IDVs verify your users by using Okta account management policy rules.

* Persona

* CLEAR Verified

* Incode

INSERT INTO okta.idps.identity_providers (
data__issuerMode,
data__name,
data__policy,
data__properties,
data__protocol,
data__status,
data__type,
subdomain
)
SELECT 
'{{ issuerMode }}',
'{{ name }}',
'{{ policy }}',
'{{ properties }}',
'{{ protocol }}',
'{{ status }}',
'{{ type }}',
'{{ subdomain }}'
RETURNING
id,
name,
_links,
created,
issuerMode,
lastUpdated,
policy,
properties,
protocol,
status,
type
;

REPLACE examples​

Replaces an identity provider (IdP) integration by idpId

REPLACE okta.idps.identity_providers
SET 
data__issuerMode = '{{ issuerMode }}',
data__name = '{{ name }}',
data__policy = '{{ policy }}',
data__properties = '{{ properties }}',
data__protocol = '{{ protocol }}',
data__status = '{{ status }}',
data__type = '{{ type }}'
WHERE 
subdomain = '{{ subdomain }}' --required
RETURNING
id,
name,
_links,
created,
issuerMode,
lastUpdated,
policy,
properties,
protocol,
status,
type;

DELETE examples​

Deletes an identity provider (IdP) integration by idpId
* All existing IdP users are unlinked with the highest order profile source taking precedence for each IdP user.
* Unlinked users keep their existing authentication provider such as FEDERATION or SOCIAL.

DELETE FROM okta.idps.identity_providers
WHERE subdomain = '{{ subdomain }}' --required;

Lifecycle Methods​

Activates an inactive identity provider (IdP)

EXEC okta.idps.identity_providers.activate_identity_provider 
@subdomain='{{ subdomain }}' --required;