yes, I was correct,. it is expecting the baseUrl
 

Method ValidateAudience() As %Boolean [ Private ]
{
    Set JWTAudience = ..%TokenObject.aud
   
    If JWTAudience'="" {
        Set matched = 0
        Set currentAud = $$formatAud(..%BaseURL)
        If '$IsObject(JWTAudience) {
            // Compare single audience from JWT.
            If $$formatAud(JWTAudience)=currentAud {
                Set matched = 1
            }
        } Else {
            // Compare multiple audience from JWT. In this case it is a %DynamicArray.
            For i = 0:1:JWTAudience.%Size()-1 {
                If $$formatAud(JWTAudience.%Get(i))=currentAud {
                    Set matched = 1
                    Quit
                }
            }
        }

I have identified my issue, and implemented a workaround at least for my proof of concept.  What I found in the FHIR Logs is the audience (aud) is not matching from the FHIR Oauth class.   It appears the OAuthClass is blocking based on the audience as Entra is sending the clientID and the FHIR OAuth Class is expecting something different (my guess is endpoint?).  For now, I have implemented a custom interactionStrategy and a custom OAuth2Token Handler Class to replace the standard one so this audience block does not happen.  I am pending Support on this issue otherwise.  
^FSLOG(24110)="ValidateToken^HS.FHIRServer.Util.OAuth2Token^170903|Msg|ValidateJWT() token aud=<Entra Client ID> |04/29/2026 12:27:34.436871PM"

^FSLOG(24111)="ValidateToken^HS.FHIRServer.Util.OAuth2Token^170903|Msg|Token aud failed validation|04/29/2026 12:27:34.436896PM"

interesting, there is an irisuser defined on install.  if I su to irisuser I get the same error. 

I am have a couple of  instances of VA VistA for development that I support for multiple development teams in VA.  The ssh function is to allow users to log into the VistA "interactive menus" interface. I allow ssh as a non root user and part of the .bash_profile I run iris session iris -U db '^ZU'.  this launches the VistA access/verify code login. This has worked with my cache version of a docker image before I upgraded to iris, another version of docker iris (2020) but for some reason this version (2020) is installing different (same dockerfile and docker-compose).  I am afraid to try and re-build the other container for fear this will start happening on that one as well.  

Thanks, I have this as the last line:
USER ${ISC_PACKAGE_MGRUSER}
that is the same, correct? I will try irisowner.