Vitality · Authentication Profile
Vitality Uk Authentication
Authentication
Vitality secures its APIs with oauth2 and openIdConnect across 2 declared security schemes, as derived from its OpenAPI definitions. OAuth 2.0 is offered via the authorizationCode, clientCredentials, password, deviceCode, refreshToken, jwtBearer, and saml2Bearer flow(s).
InsuranceUnited KingdomHealth InsuranceLife InsuranceEmployee BenefitsCarrierPolicy AdministrationUnderwritingPartner Gated
Methods: oauth2, openIdConnect
Schemes: 2
OAuth flows: authorizationCode, clientCredentials, password, deviceCode, refreshToken, jwtBearer, saml2Bearer
API key in:
Security Schemes
WSO2 API Manager OAuth2 oauth2
Bearer token (gateway) http
scheme: bearer
Source
Authentication Profile
generated: '2026-07-25'
method: searched
source: https://apis.vitality.co.uk/oauth2/token/.well-known/openid-configuration
docs: null
note: >-
Vitality publishes no OpenAPI, so this profile is not derived from a spec — it
is read verbatim from the live OpenID Connect discovery document served by the
WSO2 Identity Server behind the apis.vitality.co.uk gateway, corroborated by
live probes of the token, authorization, userinfo, revocation and JWKS
endpoints and by the OAuth configuration embedded in Vitality's own
first-party Workplace Connect adviser application.
summary:
types:
- oauth2
- openIdConnect
api_key_in: []
oauth2_flows:
- authorizationCode
- clientCredentials
- password
- deviceCode
- refreshToken
- jwtBearer
- saml2Bearer
self_serve_signup: false
audience: commercial partners and first-party applications only
schemes:
- name: WSO2 API Manager OAuth2
type: oauth2
issuer: https://apis.vitality.co.uk/oauth2/token
source: https://apis.vitality.co.uk/oauth2/token/.well-known/openid-configuration
endpoints:
authorization: https://apis.vitality.co.uk/oauth2/authorize
token: https://apis.vitality.co.uk/oauth2/token
userinfo: https://apis.vitality.co.uk/oauth2/userinfo
jwks: https://apis.vitality.co.uk/oauth2/jwks
introspection: https://wso2-prd-idsrv.tvc.vitality.co.uk:9443/oauth2/introspect
revocation: https://wso2-prd-idsrv.tvc.vitality.co.uk:9443/oauth2/revoke
device_authorization: https://wso2-prd-idsrv.tvc.vitality.co.uk:9443/oauth2/device_authorize
registration: https://apis.vitality.co.uk/api/identity/oauth2/dcr/v1.1/register
end_session: https://apis.vitality.co.uk/oidc/logout
check_session_iframe: https://apis.vitality.co.uk/oidc/checksession
grant_types:
- authorization_code
- client_credentials
- refresh_token
- password
- urn:ietf:params:oauth:grant-type:device_code
- urn:ietf:params:oauth:grant-type:jwt-bearer
- urn:ietf:params:oauth:grant-type:saml2-bearer
- iwa:ntlm
- spoofToken
- account_switch
response_types:
- code
- token
- id_token
- code id_token
- code token
- id_token token
- code id_token token
- device
- none
response_modes: [query, fragment, form_post]
token_endpoint_auth_methods: [client_secret_basic, client_secret_post]
pkce:
supported: true
code_challenge_methods: [S256, plain]
id_token_signing_alg: [RS256]
userinfo_signing_alg: [RS256]
request_object_signing_alg: [RS256, RS384, RS512, PS256, none]
subject_types: [public]
session_management:
backchannel_logout_supported: true
backchannel_logout_session_supported: true
check_session_iframe: true
claims:
standard: [sub, name, given_name, family_name, middle_name, nickname,
preferred_username, profile, picture, website, gender, birthdate, zoneinfo,
locale, updated_at, email, email_verified, phone_number,
phone_number_verified, address, formatted, street_address, locality, region,
postal_code, country, acr, iss]
vitality_specific: [memberID, entityID, entityId, entity_id, partyID, partyId,
source, registered, roles, groups, upn, username]
note: memberID / entityID / partyID are Vitality's own identity claims and are
the clearest public signal of how the carrier keys members and parties
across policy administration.
- name: Bearer token (gateway)
type: http
scheme: bearer
bearer_format: JWT
note: Access tokens issued by the token endpoint above are presented to the
apis.vitality.co.uk gateway as HTTP bearer tokens. No published API operation
could be exercised anonymously to confirm the header name beyond the standard
Authorization header.
verified:
- probe: POST https://apis.vitality.co.uk/token (grant_type=client_credentials)
status: 401
body: '{"error_description":"Unsupported Client Authentication Method!","error":"invalid_client"}'
meaning: live token endpoint; rejects anonymous callers, requires partner-issued
client credentials
- probe: GET https://apis.vitality.co.uk/authorize
status: 302
meaning: live authorization endpoint; redirects to the WSO2 authentication
endpoint OAuth error page for an invalid request
- probe: GET https://apis.vitality.co.uk/oauth2/userinfo
status: 400
body: '{"error_description":"Authorization or Content-Type header is missing","error":"invalid_request"}'
- probe: GET https://apis.vitality.co.uk/oauth2/jwks
status: 200
meaning: 1 RSA RS256 signing key published
- probe: GET https://apis.vitality.co.uk/oauth2/introspect
status: 401
body: '{"code":401,"description":"AuthenticationHandler not found.","message":"Unauthorized"}'
- probe: POST https://apis.vitality.co.uk/api/identity/oauth2/dcr/v1.1/register
status: 404
meaning: the dynamic client registration endpoint advertised in discovery is NOT
exposed through the public gateway — client registration is a commercial
onboarding process, not self-serve
onboarding:
self_serve: false
process: Client credentials are issued through Vitality's commercial partner
onboarding process. There is no developer signup form, no API key console and
no public dynamic client registration.
evidence: https://fintech.global/2025/08/20/vitality-accelerates-digital-transformation-with-wso2-api-gateway/