GraphQL is a graph based JSON API over HTTP. It exposes a strongly typed schema with query and mutation operations. In User Management, the graph is based on the account, with sub-elements such as linked accounts and devices that belong to that particular account. Moreover, the User Management GraphQL API allows to manage buckets linked to user accounts.
query
mutation
The operations are categorized into two types: query and mutation.
The possible queries for accounts are:
accountByUserName(userName: String!) : Account accountById(accountId: String!) : Account accountByEmail(email: String!) : Account accountByPhoneNumber(phoneNumber: String!) : Account accounts( activeAccountsOnly: Boolean = true first: Int after: String sorting: Sorting = {sortOrder: DESCENDING} filtering : Filtering ) : AccountConnection! credentialPolicy: CredentialPolicyDescriptor
If a Credential Manager is configured with a credential policy, the following queries are also available:
credentialPolicyRulesStateByUserName(userName: String!) : CredentialPolicyRulesState
If a bucket datasource is configured in the User Management profile, the following queries are also available:
bucketsByUserName( userName: String! purposes: [String!]! ) : [Bucket!]!
As can be determined from the names, they operate on singular or plural accounts.
The account type provides information about the account (attributes of an account) as well as devices and dynamic clients associated with that account. The inclusion of dynamic clients is disabled by default and can be enabled by setting include-dynamic-clients-in-graph-QL-account-response to true under /profiles/profile (user-management-service)/settings/user-management-service/include-dynamic-clients-in-graph-QL-account-response.
include-dynamic-clients-in-graph-QL-account-response
/profiles/profile (user-management-service)/settings/user-management-service/include-dynamic-clients-in-graph-QL-account-response
The credentialPolicy query provides information about the optional credential policy configured on the credential manager. Note that this query provides global information that isn’t associated to a specific user. This query is experimental and the associated schema may change in future versions of the Curity Identity Server.
credentialPolicy
The Opt-In MFA information exposed in the account depends on whether the User Management profile has a configured Opt-In MFA action or not:
The possible mutations for account related data available are:
createAccount(input: CreateAccountInput!): CreateAccountPayload updateAccountById(input: UpdateAccountByIdInput!): UpdateAccountByIdPayload validatePasswordAndUpdateAccountById(input: ValidatePasswordAndUpdateAccountByIdInput!): ValidatePasswordAndUpdateAccountByIdPayload deleteAccountById(input: DeleteAccountByIdInput!): DeleteAccountByIdPayload deleteLinkFromAccountByAccountId(input: DeleteLinkFromAccountByAccountIdInput!): DeleteLinkFromAccountByAccountIdPayload deleteDeviceFromAccountByAccountId(input: DeleteDeviceFromAccountByAccountIdInput!): DeleteDeviceFromAccountByAccountIdPayload deleteOptInMfaFactorFromAccountByAccountId(input: DeleteOptInMfaFactorFromAccountByAccountIdInput!): DeleteOptInMfaFactorFromAccountByAccountIdPayload resetOptInMfaStateByAccountId(input: ResetOptInMfaStateByAccountIdInput!): ResetOptInMfaStateByAccountIdPayload addDeviceToAccountByAccountId(input: AddDeviceToAccountByAccountIdInput!): AddDeviceToAccountByAccountIdPayload updateDeviceFromAccountByAccountId(input: UpdateDeviceFromAccountByAccountIdInput!): UpdateDeviceFromAccountByAccountIdPayload! startVerifyEmailAddressByAccountId(input: StartVerifyEmailAddressByAccountIdInput!): StartVerifyEmailAddressByAccountIdPayload completeVerifyEmailAddressByAccountId(input: CompleteVerifyEmailAddressByAccountIdInput!): CompleteVerifyEmailAddressByAccountIdPayload updatePrimaryEmailAddressByAccountId(input: UpdatePrimaryEmailAddressByAccountIdInput!): UpdatePrimaryEmailAddressByAccountIdPayload deleteEmailAddressByAccountId(input: DeleteEmailAddressByAccountIdInput!): DeleteEmailAddressByAccountIdPayload startVerifyPhoneNumberByAccountId(input: StartVerifyPhoneNumberByAccountIdInput!): StartVerifyPhoneNumberByAccountIdPayload completeVerifyPhoneNumberByAccountId(input: CompleteVerifyPhoneNumberByAccountIdInput!): CompleteVerifyPhoneNumberByAccountIdPayload updatePrimaryPhoneNumberByAccountId(input: UpdatePrimaryPhoneNumberByAccountIdInput!): UpdatePrimaryPhoneNumberByAccountIdPayload deletePhoneNumberByAccountId(input: DeletePhoneNumberByAccountIdInput!): DeletePhoneNumberByAccountIdPayload
If a Credential Manager is configured with a credential policy, the following mutations are also available:
setCredentialPolicyRulesStateByUserName(input: CredentialPolicyRulesStateInput!): CredentialPolicyRulesState
Only the state of rules which are configured in the relevant Credential Policy may be modified.
If a bucket datasource is configured in the User Management profile, the following mutations are also available:
deleteBucketByUserName(input: DeleteBucketByUserNameInput!): DeleteBucketByUserNamePayload
The following mutation can be used to start a password reset flow via the sending of an email. This mutation is only available if the User Management profile has an associated HTML Form authenticator.
sendPasswordResetEmail(input: SendPasswordResetInput!): SendPasswordResetPayload
The used Email Sender and templates are the same ones used by the associated HTML Form authenticator.
The following mutation can be used to start an account activation flow via the sending of an email. This mutation is only available if the User Management profile has an associated HTML Form authenticator.
initializeAccountActivation(input: InitializeAccountActivationInput!): InitializeAccountActivationPayload
In addition to management via the updateAccountById generic mutation, account email addresses can also be managed via these specialized mutations.
updateAccountById
startVerifyEmailAddressByAccountId(input: StartVerifyEmailAddressByAccountIdInput!): StartVerifyEmailAddressByAccountIdPayload completeVerifyEmailAddressByAccountId(input: CompleteVerifyEmailAddressByAccountIdInput!): CompleteVerifyEmailAddressByAccountIdPayload updatePrimaryEmailAddressByAccountId(input: UpdatePrimaryEmailAddressByAccountIdInput!): UpdatePrimaryEmailAddressByAccountIdPayload deleteEmailAddressByAccountId(input: DeleteEmailAddressByAccountIdInput!): DeleteEmailAddressByAccountIdPayload
These mutations allow for email address verification via the sending and confirmation of one-time-passwords (OTP). The sent emails:
templates/core/user-management/device/email
These mutations also enforce domain rules, such as requiring an email address to be verified before setting it as primary, which makes them adequate for usage in self-service scenarios.
In addition to management via the updateAccountById generic mutation, account phone numbers can also be managed via these specialized mutations.
startVerifyPhoneNumberByAccountId(input: StartVerifyPhoneNumberByAccountIdInput!): StartVerifyPhoneNumberByAccountIdPayload completeVerifyPhoneNumberByAccountId(input: CompleteVerifyPhoneNumberByAccountIdInput!): CompleteVerifyPhoneNumberByAccountIdPayload updatePrimaryPhoneNumberByAccountId(input: UpdatePrimaryPhoneNumberByAccountIdInput!): UpdatePrimaryPhoneNumberByAccountIdPayload deletePhoneNumberByAccountId(input: DeletePhoneNumberByAccountIdInput!): DeletePhoneNumberByAccountIdPayload
These mutations allow for phone number verification via the sending and confirmation of one-time-passwords (OTP) via SMS messages. The sent messages:
messages/core/en/user-management/device/sms
These mutations also enforce domain rules, such as requiring a phone number to be verified before making it primary, which makes them adequate for usage in self-service scenarios.
The creation of TOTP (Time-based One Time Passwords) devices can be done using the following mutations, which are only available if the User Management profile has a configured TOTP authenticator.
startVerifyTotpDeviceByAccountId(input: StartVerifyTotpDeviceByAccountIdInput!): StartVerifyTotpDeviceByAccountIdPayload completeVerifyTotpDeviceByAccountId(input: CompleteVerifyTotpDeviceByAccountIdInput!): CompleteVerifyTotpDeviceByAccountIdPayload
TOTP device removal is achieved by using the generic deleteDeviceFromAccountByAccountId mutation.
deleteDeviceFromAccountByAccountId
The creation of passkeys devices can be done using the following mutations, which are only available if the User Management profile has a configured Passkeys authenticator.
startVerifyPasskeyByAccountId(input: StartVerifyPasskeyByAccountIdInput!): StartVerifyPasskeyByAccountIdPayload completeVerifyPasskeyByAccountId(input: CompleteVerifyPasskeyByAccountIdInput!): CompleteVerifyPasskeyByAccountIdPayload
Passkeys device removal is achieved by using the generic deleteDeviceFromAccountByAccountId mutation.
The following mutations are always available to manage account information used by Opt-In MFA action
deleteOptInMfaFactorFromAccountByAccountId(input: DeleteOptInMfaFactorFromAccountByAccountIdInput!): DeleteOptInMfaFactorFromAccountByAccountIdPayload resetOptInMfaStateByAccountId(input: ResetOptInMfaStateByAccountIdInput!): ResetOptInMfaStateByAccountIdPayload
These mutations behave differently depending on whether the User Management profile has a configured Opt-In MFA action or not.
If the User Management profile has a configured Opt-In MFA action, then the following additional mutations are also available:
startOptInMfaSetupByAccountId(input: StartOptInMfaSetupByAccountIdInput!): StartOptInMfaSetupByAccountIdPayload completeOptInMfaSetupByAccountId(input: CompleteOptInMfaSetupByAccountIdInput!): CompleteOptInMfaSetupByAccountIdPayload startOptInMfaResetRecoveryCodesByAccountId(input: StartOptInMfaResetRecoveryCodesByAccountIdInput!): StartOptInMfaResetRecoveryCodesByAccountIdPayload completeOptInMfaResetRecoveryCodesByAccountId(input: CompleteOptInMfaResetRecoveryCodesByAccountIdInput!): CompleteOptInMfaResetRecoveryCodesByAccountIdPayload addOptInMfaFactorToAccountByAccountId(input: AddOptInMfaFactorToAccountByAccountIdInput!): AddOptInMfaFactorToAccountByAccountIdPayload optOutFromOptInMfaByAccountId(input: OptOutFromOptInMfaByAccountIdInput): OptOutFromOptInMfaByAccountIdPayload
The Opt-In MFA factors that can used for setup or added after setup are limited to the following:
email
sms
totp
passkeys
Note that the User Management GraphQL API provides mutations to help ensure the previous conditions are met, namely verifying email addresses or adding Passkey devices.
GraphQL comes with a schema that can be introspected directly from the endpoint. Most graphql clients knows how to perform this operation and how to interpret the results. It’s important to note that even the introspection of the schema is oauth protected and requires appropriate permissions to be allowed.
The GraphQL API requires a valid Access Token from the associated OAuth Profile. This token is used to authorize the request. The authorization is handled by the configured authorization manager. If no authorization manager is configured, then no access will be given. It is recommended to use the groups authorization manager and to provide a value for the groups claim in the access token that maps against the rules in the authorization manager. See how GraphQL operations map to CRUD access operations in authorization manager rules.
groups
The User Management profile allows the addition of custom attributes that extend the predefined account type schema. Additional attributes consist of attribute name and attribute type (attribute type represents the data type of an object and must be one of the following: String - text-based attribute, Boolean - true/false, Long - number-based attribute, Object - custom JSON Object). The configured attributes are added to all queries and mutations for an account and are present when introspecting the GraphQL schema. The custom attributes can be configured in the User Management profile settings and are optional in all GraphQL account related queries and mutations.
String
Boolean
Long
Object
The currently supported data sources for GraphQL are the JDBC, MongoDB and SCIM 2.0 data sources. There is limited support for DynamoDB, see the limitations.
The following limits are enforced on inputs
For more details about how to work with the GraphQL APIs see the developer documentation.