Connect to applications using SMART on FHIR:: "SMART headers are not supported"

[JosephShook]

Background: 

• I am writing my own FHIR Proxy Server. "udap.proxy.server"
• I have my own Authorization Server based on the UDAP protocol.  It is a reference implementation for the the HL7 FHIR Security IG.
• I do not want to use Apigee.
• I do not want to use SmartProxy.  As I mentioned I am writing a proxy. 
• This is just for testing.  All FHIR data is Synthea synthetic data.

I have read the Connect to applications using SMART on FHIR documenation many times.   The way I understand it and the way I have developed up to this point is the following.

• My udap.proxy.server is running as a service account. Currently generating access-token for a service account.  This is successful.  I can read and write data to the Google Cloud FHIR store.  
• I do all my client authentication to the udap.proxy.server.   Register for scopes that are SMART on FHIR styled scopes.
• I want the Google FHIR server to enforce the SMART scopes.  So I tried to set scopes on the X-Authorization-Scope.  Every variation I have tried end with an OperationOutcome indicating "SMART headers are not supported".  Yet I cannot find this error in the documentation

Here is the output:

{
  "issue": [
    {
      "code": "security",
      "details": {
        "text": "permission_denied"
      },
      "diagnostics": "SMART headers are not supported",
      "severity": "error"
    }
  ],
  "resourceType": "OperationOutcome"
}

 Here are a few access tokens presented to GCP FHIR server.  Maybe they need to be formatted different.  But It just seems from the error that "SMART headers are not supported" and there is some undocumented way to turn the feature on.  If it is my format, the error is not helping me.

If you examine the encoded JWTs you will see the signing alg is RS256 but I have also signed with RS384 as required by SMART.  

Example 1 :access-token

{
  "iss": "https://host.docker.internal:5002",
  "nbf": 1710360459,
  "iat": 1710360459,
  "exp": 1710364059,
  "aud": "https://host.docker.internal:5002/resources",
  "scope": [
    "launch/patient",
    "system/Patient.read"
  ],
  "client_id": "wC9QS1nnaZJ3iOq5WOpVjLCP4-NDVd7P7YpzWBuIk5A",
  "jti": "EFFD282A084B2F6C7739A381C593ECF9"
}

encoded
eyJhbGciOiJSUzI1NiIsImtpZCI6IjZEOTA4MDk2MzExRTZEODVCNEU2QTgwMUE2RUY0MTU5IiwidHlwIjoiYXQrand0In0.eyJpc3MiOiJodHRwczovL2hvc3QuZG9ja2VyLmludGVybmFsOjUwMDIiLCJuYmYiOjE3MTAzNjA0NTksImlhdCI6MTcxMDM2MDQ1OSwiZXhwIjoxNzEwMzY0MDU5LCJhdWQiOiJodHRwczovL2hvc3QuZG9ja2VyLmludGVybmFsOjUwMDIvcmVzb3VyY2VzIiwic2NvcGUiOlsibGF1bmNoL3BhdGllbnQiLCJzeXN0ZW0vUGF0aWVudC5yZWFkIl0sImNsaWVudF9pZCI6IndDOVFTMW5uYVpKM2lPcTVXT3BWakxDUDQtTkRWZDdQN1lweldCdUlrNUEiLCJqdGkiOiJFRkZEMjgyQTA4NEIyRjZDNzczOUEzODFDNTkzRUNGOSJ9.mSplnF2LgWo_Phd3OtFFdTzHKc8uw6PWZZlJTdYzMh9ikHgLfifm9a9gud26WuMus3kQUyCmtsNYDRXlpZ0XpjuWNWRv-pIwHjymI9D8MYqM_mj9DUULKnEAK_JMMVWAZEbMuUC8yGTuNFlspD_rKposPPiAEMIetTkjMN1Zm6VBPaZF8sVv8t5jYtOZq3ekn7j7aFmsO2XyzERtEqWiWAqrsyac03vtMoBgTWICeSiSCB45ZA7Q3K0K1sbK7Kj6tQ3KlckR4DmW182JtCRNmhrFjjirL7GaWQMSEzyyeaec_74C112S9q2HPETU700SPgmwDqPAS4-lVZtrq4f0aA

 Example 1 : access-token

{
  "iss": "https://host.docker.internal:5002",
  "nbf": 1710362714,
  "iat": 1710362714,
  "exp": 1710366314,
  "aud": "https://host.docker.internal:5002/resources",
  "scope": [
    "launch/patient",
    "openid",
    "user/Patient.read"
  ],
  "amr": [
    "pwd"
  ],
  "client_id": "wC9QS1nnaZJ3iOq5WOpVjLCP4-NDVd7P7YpzWBuIk5A",
  "sub": "2",
  "auth_time": 1710362703,
  "idp": "local",
  "sid": "A52AA964B2C245B4FED6A241D6FCB8F9",
  "jti": "FCF7235E5DC395BB30B53293BEC2FCFA"
}

eyJhbGciOiJSUzI1NiIsImtpZCI6IjZEOTA4MDk2MzExRTZEODVCNEU2QTgwMUE2RUY0MTU5IiwidHlwIjoiYXQrand0In0.eyJpc3MiOiJodHRwczovL2hvc3QuZG9ja2VyLmludGVybmFsOjUwMDIiLCJuYmYiOjE3MTAzNjI3MTQsImlhdCI6MTcxMDM2MjcxNCwiZXhwIjoxNzEwMzY2MzE0LCJhdWQiOiJodHRwczovL2hvc3QuZG9ja2VyLmludGVybmFsOjUwMDIvcmVzb3VyY2VzIiwic2NvcGUiOlsibGF1bmNoL3BhdGllbnQiLCJvcGVuaWQiLCJ1c2VyL1BhdGllbnQucmVhZCJdLCJhbXIiOlsicHdkIl0sImNsaWVudF9pZCI6IndDOVFTMW5uYVpKM2lPcTVXT3BWakxDUDQtTkRWZDdQN1lweldCdUlrNUEiLCJzdWIiOiIyIiwiYXV0aF90aW1lIjoxNzEwMzYyNzAzLCJpZHAiOiJsb2NhbCIsInNpZCI6IkE1MkFBOTY0QjJDMjQ1QjRGRUQ2QTI0MUQ2RkNCOEY5IiwianRpIjoiRkNGNzIzNUU1REMzOTVCQjMwQjUzMjkzQkVDMkZDRkEifQ.cLSoo1yhlH-nY5yjOWfuBYKjq6JlJfRHeZhl8tKNKdOTl2HvNfv3acmB5eESM5YEuIHUwYZ_vEBe3HcyYW3Y4oMlWIfj6gFV4FygDjoYhfSKBF7bt8MYfQahPfH5348XS1_99axj53UM_aeUL4QdNi75NGyYokv-1K9Jw-ieMAVO5qXWtFxLO6mIOnW_G6SLuD_3WGuJN7Dlnr7oPdOeCXhNPws9NozDFMfsFcmqeB8xxc80f3ejCN3-vr9uooJdbBwgWLSH7RwYHrk9DIdidejUx6t_x8_IFOcARvp3IOfdwjngYheGPRoV1-Sjh7Uytlck_TUDF9iH4oLLXtXKZw

 I look forward to some guidance.

Also the logs in the Operations are just have two entries. For every FHIR Dataset I have created it is always just two entries.  Why no logs?

[JosephShook · Accepted solution]

Through some help from a Google employee in a different venue the suggestion was to call the v1beta1 endpoint rather than the v1 endpoint.  So for example 

call 

• https://healthcare.googleapis.com/v1beta1/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/fhirStor...

Rather than

• https://healthcare.googleapis.com/v1/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/fhirStores/FH...

Just something I need to be on the look out for as a convention while working with preview releases.