For the Mgmt. Portal side you can follow through @Yuri Marx's example (though it uses Google and not Keycloak but the principal is similar, you will need a ZAUTHENTICATE, you will find a sample there).

Re your question about accessing the Access Token, you can include in your ZAUTHENTICATE something like this:

 set isAuthorized=##class(%SYS.OAuth2.AccessToken).IsAuthorized(applicationName,sessionId,,.accessToken,,,.error)
 if isAuthorized {
    set sc=##class(%SYS.OAuth2.AccessToken).GetIntrospection(applicationName,accessToken,.jsonObject)
    ...
 }    
 // then you can access the jsonObject for getting info, e.g. (and this is from a KeyCloak example):
 set Username="OAuth2_"_jsonObject.username
 // or:
 set iterator=jsonObject."realm_access".roles.%GetIterator()
 while iterator.%GetNext(.key,.val) { 
    ...
 }

For the FHIR API you can look at @Luis Angel Pérez Ramos's example (though it uses auth0, but again it should be similar).
In this case you don't have to worry about ZAUTHENTICATE because the FHIR Server infrastructure has you covered.

By the way, in v2024.3 which was just released, there's a new OAuth FHIR Client QuickStart you can use to set this up in an easier manner.

For other REST services this would depend on their nature and whether there is user interaction which allows for example the actions described in the two samples mentioned above.

Note, my colleague @Ariel Glikman and myself are in the midst of a project that includes interacting with KeyCloak, and possibly once it's complete we can share some insights, but this will take some time, so I wouldn't hold my breath waiting for this.

Another note, I believe that down the line (perhaps even with v2025.1) we will have more seamless out-of-the-box integration with these kinds of OAuth authentication flows, which will require less background work as you need to implement today with ZUATHENTICATE etc. Stay tuned...