We’re able to do a combined single sign on against int ( https://int.api.service.nhs.uk ) and use the ../userinfo end point to get the SSO user’s UID,
The application ID in the onboarding portal is c28fcac0-a150-47bf-831a-8ae5955a20ca, access key TAWzmep6ArxavYWT3tfYbevj4RX3IvuU
The userinfo endpoint, post-SSO, is saying my nhsid_useruid is 555384914100
When I try and use the access token against the integration environment’s eRS service, I’m always getting a 401, “invalid access token” error for user-restricted APIs
Seems to happen from both our pre-live Node code and manually with Curl. Rotating the token and using a new one doesn’t seem to change this message.
Is there a way to get some insight as to why it might be failing ? We’re already onboarded for it, as we can access int-ers.nhs.uk directly through it’s own SSO.
Well, we’ve got several now, because combined SSO only allows one redirect URL to be added in the onboarding portal, so we need one for (at least) each of day-to-day development, integration test and client acceptance domains.
I emailed the 3 additional ones to support.digitalservices@ under ref CS1576963 earlier today if you can see that issue and assist ?
But if we can only have a single user restricted application active at any one time in integration, is there a better way to manage this ?
Each of those application ids are tied to different call back URLs, so we we can’t reuse say the development application id in the client testing server because the URLs differ and the callbacks will fail.
Looking ahead to production, we’d then need an application id per-trust as well, as each trust is their own URL, so own callback.
I getting the feeling we’re fighting against some limits inside of the NHS systems here.
Are we meant to have built a generic call back handler, and use the state param to decode that back to the correct backend at our side, rather than adding a call back to each of our applications’ URLs ?
What do other SSO users do ?
I’m not saying you can’t do it, and we’re to help where we can. My point is that if you were to create, say, 20 applications in INT, and every other partner adopted the same approach, it could create some operational and management challenges.
Let me take a look at what you’ve sent above and see if I can understand the issue and whether there’s a way we can address it.
A 401 Unauthorized error during INT testing with SSO usually points to an issue with the Access Token or claims verification. Based on our healthcare integration workflows, I suggest checking if the token contains the exact required scopes for user-restricted APIs, or if the signing certificate/public key in your INT environment has expired or mismatched.
Also, keep an eye on proxy or API gateway configurations; sometimes custom authorization headers get stripped during routing, which leads to missing Bearer tokens at the endpoint level. We frequently address these exact token and data security compliance challenges when building clinical architectures.
We have documented our technical roadmap, security parameters, and system verification protocols on our development overview page here:Custom Healthcare Software Development for Modern Healthcare Organisations. This might serve as a handy benchmarking checklist for your environment mapping. Hope this helps you trace the root cause!
No worries, we have a small back log - i’ll try and pick this up today, but need a seperate team to assist also, so might be a 2-3 days or so before the binding of the correct attributes is complete
@tc1 For speed I can re-purpose the ASID you previously had been allocated - in Live, they would be unique (per site, per app), if not and you want them to be seperate I can request x3 new ones. Both options will work in INT but appreciate you might want it looking’‘live-like’
I think it’s best if we keep it simple and wait for it to be done “right”.
Just to check I understand - all those three applications will get setup so integration SSO through them will return tokens usable against integration testing eRS.
And when we come to move forward to a live environment, we’d set up new applications and callback URLs for live SSO and eRS.
