Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-31894

Require PKCE for confidential clients

    XMLWordPrintableJSON

    Details

    • Type: Change Request
    • Status: Applied (View Workflow)
    • Priority: Medium
    • Resolution: Persuasive
    • Specification:
      SMART on FHIR (FHIR)
    • Raised in Version:
      2.0.0
    • Work Group:
      FHIR Infrastructure
    • Outstanding Negatives:
      STU
    • Related Page(s):
      Overview
    • Grouping:
    • Resolution Description:
      Hide

      For consistency across implementations and mitigation of authorization code injection attacks, we should update our PKCE guidance to state that in SMARTv2, all clients (confidential or public) SHALL use PKCE, rather than stating "SHOULD" for confidential clients and "SHALL" for public clients.

      Show
      For consistency across implementations and mitigation of authorization code injection attacks, we should update our PKCE guidance to state that in SMARTv2, all clients (confidential or public) SHALL use PKCE, rather than stating "SHOULD" for confidential clients and "SHALL" for public clients.
    • Resolution Vote:
      Gino Canessa/Yunwei Wang: 13-0-0
    • Change Category:
      Enhancement
    • Change Impact:
      Non-compatible

      Description

      We should require PKCE for all clients, not just public clients. Confidential clients are vulnerable to an auth code injection attack should that auth code be intercepted (either over the wire or by a compromised client).

      Steps of the attack against a confidential client:

      • Alice signs into a web app using confidential client interactions and enters a workflow for the app to request data from an EHR
      • The app redirects Alice to the EHR auth server
      • Alice completes authentication with the auth server.
      • The auth server redirects Alice back to the web app along with an auth code
        • Eve intercepts this auth code

       

      • Eve signs into the same web app and enters a workflow for the app to request data from an EHR
      • The app redirects Eve to the EHR auth server
      • Eve completes the authentication with the auth server
      • The auth server redirects Eve back to the web app along with an auth code
        • Eve’s client substitutes Alice’s auth code and completes the redirection call
      • The web app takes the auth code and calls the EHR auth server to get an access token
      • The EHR auth server accepts the auth code and provides a token appropriate for Alice’s scopes
        • With PKCE implemented, this step instead fails because the code_verifier from Eve’s session doesn’t match the code_challenge that was used to produce Alice’s auth code. 
      • The web app now has established a session with Eve and a token that can access Alice’s data from the EHR Resource server

       

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              carl-anderson-msft Carl Anderson
              Reporter:
              cschaut Christopher Schaut
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Vote Date: