Hello, I am attempting to generate an access token using jwt-bearer assertion_type, but I am getting back “client_id is missing” (and later client_secret is missing if I add the client_id). If I supply a valid JWT as client_assertion, my understanding is I should not have to also include my client ID and secret. Is it possible to confirm?
It sounds like you are setting the authentication type for the token endpoint wrong - for the jwt-bearer option the value must be exact as listed in our documentation, otherwise it is ignored and defaults to client secret. If you want to DM the payload you are sending including the JWT I can verify the contents
We attempted to use the authorize flow in the document you referenced
This returns a 400 response, and even the example in the document seems to always generate a 400. Can you verify the correct endpoint addresses for this? Is it as above ? Previously we were using int.api.service.nhs.uk/oauth2/authorize
Hi David, have you requested CIS2 client information from the onboarding team? The value for the client_id you are using looks like the API-M client-id. A CIS2 Auth client ID would be of the form XXXX.supplier.app - I can’t see any valid client configurations on our side. As part of the guidance please reach out to the onboarding team to get set up with CIS2 Auth which is a pre-requisite for authentication
Whilst there are 2 similar token requests as part of the user-restricted separate flow - they are different and use different client IDs and “secrets”.
Hello,
How do I request the CIS2 client information? Can I just email england.digitalonboarding@nhs.net for next steps? We have already completed assurance for CIS2 API auth for use with eRS requests so I am not sure how to expand this to include what’s needed here.
If you have completed assurance for CIS2 Auth, you should have been supplied with credentials for PTL and potentially production. Please read the separate auth guides for using the APIs here: https://digital.nhs.uk/developer/guides-and-documentation/security-and-authorisation/user-restricted-restful-apis-cis2-separate-authentication-and-authorisation
The contact for CIS2 onboarding is : england.nhscareidentityauthentication@nhs.net
We have completed the onboarding steps for CIS2 SSO. We have a new client ID configured as “8109326333.strata_health_pathways_sso.e2f33983-ed0e-45dd-ad23-192ddd88a82c.apps” however our request to https://am.nhsint.auth-ptl.cis2.spineservices.nhs.uk:443/openam/oauth2/realms/root/realms/NHSIdentity/realms/Healthcare/access_token is always returning a “JWT is not valid” error now. We have verified the signature of the JWT using the JWK from our JWKS url. Here is an example token we attempted to use today:
eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiI4MTA5MzI2MzMzLnN0cmF0YV9oZWFsdGhfcGF0aHdheXNfc3NvLmUyZjMzOTgzLWVkMGUtNDVkZC1hZDIzLTE5MmRkZDg4YTgyYy5hcHBzIiwic3ViIjoiODEwOTMyNjMzMy5zdHJhdGFfaGVhbHRoX3BhdGh3YXlzX3Nzby5lMmYzMzk4My1lZDBlLTQ1ZGQtYWQyMy0xOTJkZGQ4OGE4MmMuYXBwcyIsImF1ZCI6Imh0dHBzOi8vYW0ubmhzaW50LmF1dGgtcHRsLmNpczIuc3BpbmVzZXJ2aWNlcy5uaHMudWs6NDQzL29wZW5hbS9vYXV0aDIvcmVhbG1zL3Jvb3QvcmVhbG1zL05IU0lkZW50aXR5L3JlYWxtcy9IZWFsdGhjYXJlL2FjY2Vzc190b2tlbiIsImp0aSI6IjFkYTFjMmM2LTc0YTYtNDFlMS1iMzVlLTVlYTE1NDE2Y2Y5OSIsImlhdCI6MTc4MTA0MjY1NywiZXhwIjoxNzgxMDQzNTU3fQ.kWguZEL1Lm2Ott75O7blV0FCTkFZKYMn89R1zaX2wCyHNHOeFzH9wIjim_l2Q6JatlQE7os280ScYyPIehlNUSfkX_Hnh9cIYk1k1cm3WCMRUqz-_60qyrxItRxOqQp1uANE4k5fi47W1VNkwMd_Q70CjW8CTB_qfllz01eDRQsrxF-QrBeDdf4iZlX3MfpHe5GciPEA7laK3KkW7vdKJNU3Kgg-BLsaNfnDb_PwghBrueyeqlHgVBBX6OC0gP_6P8ZCEFYA4pClNbT9QXVgSaM8kN2PCmq6PpcO9iV3ZuZgOzEITM5avwYnZ_hnQWqgPx3qtiWitIu7a2Q0ZRzbJo8qvwroPkMOsss27Pq8AJV-bXOUcbAVjwRqrFw1g18ochh0z_86lAop06FP_AamThRc2J1WK_EXZiCUSFpTC7Dpkw1hTqYRF5RNegT8cQcAILajab1fINZi0OLPwTLyVx5vepPywTF-eakSlfWbiatuPjV25LJojW5IKn8TO5jFwzU7qRwPWCX5wywjTbQ4RwfMnIiVWrQRlMbEE4hjDdhCzJm5TKtBaaP1nj3um-q9kVgdlSW2aISRyfS1v9vnMHOXO-EBZXnCTNmOU2nGoXB20A4IY7uZX6nwHqJ4db5Cuo6TLJ2gGlsAEjhX6iWyJxrefXWDTA2ZJazaWmE-Eco
Is there anything else we are missing here?
The JWT is invalid and doesn’t contain the correct header. It is missing the kid attribute - which means we cannot identify the public key to use
Hello,
We have updated our JWT to include the kid header and we get the same error. Is there anything else wrong with our request?
Our JWKS URL is https://uk-strataconnect-beta.stratahealth.com/cis/jwks_input and it contains a public key with the associated kid, and manually verifying the JWT signature with this key on jwt.io works fine.
I’ve attached a cURL command of an example token request from today that gives the same error
{
"error_description": "JWT is not valid",
“error”: “invalid_client”
}
authtokencurl.txt (2.3 KB)
The algorithm used in the JWT header is RS256, the public key in the JWKS file is RS512, these have to match
Hello,
We’ve updated our JWKS file to RS256 but we still get the invalid_client. Anything else we’re missing? New JWT from our test today:
eyJraWQiOiI2MzBlY2M3ZC0xMjRkLTQ2OTEtYTk1MC04MzhmM2I2Y2RmM2QiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiI4MTA5MzI2MzMzLnN0cmF0YV9oZWFsdGhfcGF0aHdheXNfc3NvLmUyZjMzOTgzLWVkMGUtNDVkZC1hZDIzLTE5MmRkZDg4YTgyYy5hcHBzIiwic3ViIjoiODEwOTMyNjMzMy5zdHJhdGFfaGVhbHRoX3BhdGh3YXlzX3Nzby5lMmYzMzk4My1lZDBlLTQ1ZGQtYWQyMy0xOTJkZGQ4OGE4MmMuYXBwcyIsImF1ZCI6Imh0dHBzOi8vYW0ubmhzaW50LmF1dGgtcHRsLmNpczIuc3BpbmVzZXJ2aWNlcy5uaHMudWs6NDQzL29wZW5hbS9vYXV0aDIvcmVhbG1zL3Jvb3QvcmVhbG1zL05IU0lkZW50aXR5L3JlYWxtcy9IZWFsdGhjYXJlL2FjY2Vzc190b2tlbiIsImp0aSI6IjRiNjIyYzE2LWZlYTItNDY1Mi05N2MzLWRiZGZmMzljNWJkZSIsImlhdCI6MTc4NDkxNTQxNiwiZXhwIjoxNzg0OTE2MzE2fQ.ddmOa6YHrP0ziYQ5C34T9h5B2DT-veg5uUoOcAHcXs9Zcv3DGCbHfNQhQApgg6uKtsNRJBFxnsdxaynklOxQwLbB6l-FDEzAji5ksgj9hqs-lvXqradKWyvd0KHSozsYVKDZ0hKgBtALAMLojGiqVDKCmgZib2M-A7achigKJjo0Lk1Cy6X7mtbytqGyfgRokgX4gjDnpqpfAL6een1FhCzCAF-RQ2On5We96MMTWX-5HmKszSCZJpFX8HJnd998NOwaqirgeex5gAAVyywbu10pqIGe7aIVigfPNndoLM-3bSGYmMb1ltov38sScpupR8M4A246S9g-jz_6rykAPDtbaqs_doe61_5BUdLfMI51H_3zHtf7vZ0HZpG0rkUUtZTeLBEoTSbDr8KWZJ1dh0pYALvyo6VI4WJy54AuFGm4OlX89AA4LPcRgi5WUaLice6lEXtSezBXbjCWiszkYn1Amd7KgBaNQ__NzcJeaRHnpWBc0qbtrg9Mr_4vmpW1mCfq1UbF06_gXTfqPnX9TZhP9Z-_RauOdQ5XXEW4AXvNL2CBSm-okFNCfnQ31BHLl6jZor2Q7EFJ7YtwK4eRvwTYTW0ICahEVl4TJsAvNRp5LJNr2boFXj6soaKf8axaiPTeEMh_yG3U0UfchYN9BRS3wSectU0ED0_6fpp6jhU
Hi David, two potential reasons.
As far as I can tell the kid (key ID) is the same as before, we cache the JWKS response for the same keys which would mean we still expect a RS512 key, I’d recommend changing the kid or waiting before retrying.
Also you current client config says you are using RS512, but you provide RS256 keys. The key must match your client config