Stream: smart
Topic: Ballot reconciliation - OIDC - mandatory to implement
Isaac Vetter (Oct 04 2018 at 17:33):
Per, Scopes for requesting Identity data -> OIDC 15.1:
OPs MUST support the prompt parameter, as defined in Section 3.1.2, including the specified user interface behaviors such as none and login.
Isaac Vetter (Oct 04 2018 at 17:33):
Further, per OIDC 3.1.2.1 :
prompt
OPTIONAL. Space delimited, case sensitive list of ASCII string values that specifies whether the Authorization Server prompts the End-User for reauthentication and consent. The defined values are:
none
The Authorization Server MUST NOT display any authentication or consent user interface pages. An error is returned if an End-User is not already authenticated or the Client does not have pre-configured consent for the requested Claims or does not fulfill other conditions for processing the request. The error code will typically be login_required, interaction_required, or another code defined in Section 3.1.2.6. This can be used as a method to check for existing authentication and/or consent.
login
The Authorization Server SHOULD prompt the End-User for reauthentication. If it cannot reauthenticate the End-User, it MUST return an error, typically login_required.
consent
The Authorization Server SHOULD prompt the End-User for consent before returning information to the Client. If it cannot obtain consent, it MUST return an error, typically consent_required.
select_account
The Authorization Server SHOULD prompt the End-User to select a user account. This enables an End-User who has multiple accounts at the Authorization Server to select amongst the multiple accounts that they might have current sessions for. If it cannot obtain an account selection choice made by the End-User, it MUST return an error, typically account_selection_required.
Isaac Vetter (Oct 04 2018 at 17:34):
Enabling advanced features such as prompt and display in order to claim the SMART sso-openid-connect capability feels like a large jump from what's actually implemented and tested at connectathons.
Pascal Pfiffner (Oct 05 2018 at 03:40):
I want to add that I would love to see more widespread support for the prompt parameter: it helps avoid weird saved-state situations logging in to different resource servers that use the same auth server. But I will defer to you EHR folks on whether it makes sense to make it mandatory or not.
Josh Mandel (Oct 05 2018 at 15:16):
For the group here @Pascal Pfiffner can you describe a bit more: what weird behavior do you see, and how does prompt help?
Pascal Pfiffner (Oct 09 2018 at 00:22):
Imagine you want to login to portal A and then login to portal B in order to receive access tokens to download your data. If these portals share the authorization server you may be logged in with portal A credentials when bringing up the login screen for portal B. You may see the username/password fields telling you that you have been logged out, which is confusing. You may also not even see the username/password fields but proceed to a nonfunctional "Authorize" page (because the user doesn't exist for portal B). To get out of this state you need to manually sign out and then sign back in with your portal B credentials. This process usually loses OAuth2 context so after entering portal B credentials it's unlikely that the redirect is being called correctly or you end up in the portal, rather than the "Authorize" screen. prompt=login can remediate these cases by always forcing a fresh login.
Pascal Pfiffner (Oct 09 2018 at 00:22):
-/-
Grahame Grieve (Oct 09 2018 at 01:27):
why is the client asking for that?
Josh Mandel (Oct 09 2018 at 01:50):
Yeah, this feel like a broken authz service out of the gate.
Pascal Pfiffner (Oct 09 2018 at 17:15):
This may be a client that aggregates data from several portals, so you would login to portalA, the token would be used to grab your data, then you would login to portalB and so on. If it's the same authz service then I can see how it would keep a session as to not have the user log in again. I'm not sure the authz service could necessarily know that the already logged-in user doesn't exist for portalB, though I would presume it could (and therefore would prompt to login).
Last updated: Apr 12 2022 at 19:14 UTC
