Web API Endpoints

Web API Logical Endpoint Name [1] Endpoint /Resource [2] Method Short Description [3]
Token activation_token_endpoint /token/v1/activation/tokens POST, GET, DELETE Management of activation-tokens.
password_reset_token_endpoint /token/v1/passwordreset/tokens POST, GET, DELETE Management of password reset tokens.
username_token_endpoint /token/v1/username/tokens POST, GET, DELETE Management of tokens to change a username
generic_token_endpoint /token/v1/tokens POST, GET, DELETE Management of 'generic' tokens.
SCIM SCIM_users_endpoint /scim/Users
/scim/v1/Users
POST, GET, DELETE, PUT, PATCH Provisioning of end-user identities to iWelcome.

Note: /scim/users is an exception to the rule that a version is always included in the URL. In case of SCIM the standard prescribes that omitting the version must be supported: http://www.simplecloud.info/specs/draft-scim-api-01.html#api-versioning .

SCIM_employees_endpoint https://<domainURI>/employees/scim/Users
https://<domainURI>/employees/scim/v1/Users
POST, GET, DELETE, PUT, PATCH Provisioning of ServiceDesk identities to iWelcome.
OAuth/OIDC authorization_endpoint /auth/oauth2.0/v1/authorize OAuth2.0 authorization endpoint
token_endpoint /auth/oauth2.0/v1/token OAuth2.0 token endpoint https://tools.ietf.org/html/draft-ietf-oauth-discovery-06
introspection_endpoint /auth/oauth2.0/v1/introspect Introspect endpoint as specified by RFC7662
https://tools.ietf.org/html/draft-ietf-oauth-discovery-06
revocation_endpoint /auth/oauth2.0/v1/revoke Revocation endpoint as specified by RFC7009
https://tools.ietf.org/html/draft-ietf-oauth-discovery-06
(well-known endpoint cannot be discovered) /auth/oauth2.0/v1/.well-known/openid-configuration Endpoint discovery endpoint as specified by https://tools.ietf.org/html/draft-ietf-oauth-discovery-10 and OIDC specifications.
token_info_endpoint /auth/oauth2.0/v1/token-info Proprietary OAuth2.0 related endpoint.
⚠️iWelcome will stop support for TokenInfo endpoint by Q4 2020, thus it should not be used for new projects. It will be replaced with TokenIntrospect & UserInfo endpoints.
jwks_uri /auth/oauth2.0/v1/jwk_uri See https://tools.ietf.org/html/draft-ietf-oauth-discovery-06
userinfo_endpoint /auth/oauth2.0/v1/userinfo See https://openid.net/specs/openid-connect-discovery-1_0.html
SAML sso_httpredirect_endpoint /auth/saml2.0/v1/SSORedirect/metaAlias/<Brand>
sso_httppost_endpoint /auth/saml2.0/v1/SSOPOST/metaAlias/<Brand>
slo_httpredirect_endpoint /auth/saml2.0/v1/IDPSloRedirect/metaAlias/<Brand>
slo_httppost_endpoint /auth/saml2.0/v1/IDPSloPOST/metaAlias/<Brand>
Consent processing_purposes_endpoint /consent/v1/processing-purposes GET
attribute_consent_endpoint /consent/v1/attribute-consents
/consent/v1/attribute-consents/users/{userid}
/consent/v1/attribute-consents/{consentId}
POST, DELETE
documents_endpoint /consent/v1/documents GET
document_consent_endpoint /consent/v1/document-consents
/consent/v1/document-consents/{consentId}
/consent/v1/document-consents/users/{userid}
POST, DELETE

About <domainURI> , <Brand> and Multi-Tenancy

The domainURI is customer specific; it is agreed with iWelcome's customer. Typically it is a domain of the customer.

For a company named ONGO that could simply be www.ongo.com.

Sensible default for Brand is "idp1".

In case customers want to have multiple branded login pages within a single tenant, iWelcome configures multiple endpoints and the 'Brand' is shown in 2 locations in the SAML URLs like in the below examples:

  • www.ongo.com/bikes/auth/saml2.0/v1/SSORedirect/metaAlias/bikes

  • www.ongo.com/bicycles/auth/saml2.0/v1/SSORedirect/metaAlias/bicycles

For customers that choose to use iWelcome's multi-branding, the URLs may take various forms within a single tenant. Only one domain can be used per iWelcome tenant, but different subdomains and paths can be used.

The following table shows a few possibilities, using ONGO as an imaginary company having multiple lines of business. The specifics are agreed between iWelcome and the customer.


<ENDPOINT-PREFIX> Value Description/ Purpose
www.ongo.com ONGO doesn't use iWelcome's multi-tenancy.
www.ongo.com/bikes
www.ongo.com/bicycles
ONGO uses 2 brands, each brand has their own segment, so consumer end-users can have an identity in each of these.
bikes.ongo.com
bicycles.ongo.com
Again, ONGO uses 2 brands, each brand has their own segment, so consumer end-users can have an identity in each of these.
In this case the <ENDPOINT-PREFIX>, uses the sub-domain to distinguish between segments.
www.ongo.com/red
www.ongo.com/blue
ONGO uses iWelcome's multi-styling capability. In this example, ONGO's applications make use of 2 different styles (look & feel): a red and a blue style.
www.ongo.com/bikes/red
www.ongo.com/bikes/blue
www.ongo.com/bicycles/red
ONGO uses 2 segments and two styles. The blue style is not used for the 'bicycles' segment.

Note: The domainURI may not be the same for all endpoints in the case of multi-branding, since different styles may not be relevant for all endpoints (see table above).


[1] Logical endpoint name as defined for endpoint discovery.
Convention: "xxx_endpoint" indicates it's a web-api

[2] Base URL is always https://< domainURI >/< Brand > unless stated otherwise

[3] Including reference to spec and spec for endpoint name