Hi there,
We’ve (mmh) managed to get SSO working with the Health Store team (nhs-dtx), such that they can mint an asserted_login_identity token, pass it to us and we can use it to carry on the user’s session. However this is only working where the user has already consented to share data with us (RP2) using a previous nhs login to our site. If the user is new to us, then the user gets directed to login, I assume this would then take the user through a consent, however this largely defeats the purpose of SSO in this situation, as it requires the user to log in again.
Is there any mechanism that already exists, such that a) RP1 can detect if the user has already consented to share data with RP2 and b) trigger such a consent request flow if not?
Afternoon Matt,
SSO should work irrespective of the user accepting consent, if we identify that the user has not accepted consent for RP2 then they would be asked to do so.
Apologies if I have misunderstood
Assuming the user accepts consent as part of the flow to RP2 then the user will be passed to RP2 as a logged in user - i.e. not have to login again - i.e. the SSO will ‘work’. This how NHS App to e.g. PKB works. See Single Sign On (SSO)
Perhaps if I explained what we are trying to achieve, and what we’ve seen, it might make it clear where my concerns are…
So one outcome of this NHS Health Store alpha, will be a section under the NHS App to link to various digital therapeutics as and when they are “prescribed” to patients, called Connected Apps. One aim of the project is to allow a level user trust to be provided to the DTx by making initial launch and log in, from within the NHS App, seamless. They will get an SSO link from the Connect Apps section of the NHS App to the DTx (This could be a native app, or a web app) which will allow the user to launch the DTx with the asserted_login_identity parameter, which can then be used to authenticate within the DTx itself.
Currently, with a user who has consented to share with RP2 this is working great. They click the link and the DTx is launched, asserted_login_identity provided to the authorize endpoint, and then the user is redirected back with an OIDC exchange code.
If we try the same scenario with a fresh user who has not used NHS login within the DTx (RP2) the user gets directed to the login page and asked to enter their credentials (I assume this would then progress to a consent screen, which would then enable the SSO process as normal). A key thing to note here is that the DTx (RP2) probably (In our case definitely) has a completely separate session / cookie storage from the NHS App - so any fallback to /login on error, forces an actual login, which is something we’d like to avoid.
The request here is if there’s some way that the Connected Apps page (RP1), that our collaborators at NHSE are writing and which links out to the DTx (RP2), can detect if the consent to share with RP2 has been agreed to, and if not, trigger that consent page themselves somehow, within the current logged in session, so that the consent can be performed without the user having to re-authenticate, and then subsequently mint the asserted_login_identity token before passing it to the DTx as normal.
This is a very rough diagram showing the issue - top half, is where it will work in the web browser, bottom where it doesn’t in two separate native apps
We are starting work with DTx / HealthStore and so we will be able to explore how the product DTx will be applying consent (or not) as an internal product - i.e. where NHS England is the data controller for both HealthStore and the NHS App. Similarly if we have a consent recorded for a 3rd party, we will not ask again. The handoff from NHS App to DTx and from DTx to a 3rd party will be via NHS login.
The scenario you describe above is not what I am expecting - the user would not have to enter their credentials again from App to DTx or DTx to a 3rd party - it sounds like DTx has not implemented an SSO.
