If you look at that response carefully, you'll see that the JavaScript actually makes a request of https://xxx.my.salesforce.com/, not your server. You need to follow one step further to see the request to your server. Here's an abbreviated version of what I just saw.
First, the initial OAuth request to a My Domain URL:
$ curl -v 'https://superpat-developer-edition.my.salesforce.com/services/oauth2/authorize?response_type=code&redirect_uri=...&client_id=...'
* ...
< HTTP/1.1 302 Found
< Location: https://superpat-developer-edition.my.salesforce.com/setup/secur/RemoteAccessAuthorizationPage.apexp?source=...
Following the redirect:
$ curl -v https://superpat-developer-edition.my.salesforce.com/setup/secur/RemoteAccessAuthorizationPage.apexp?source=...
* ...
< HTTP/1.1 200 OK
< ...
<
<script>
var escapedHash = '';
var url = '/saml/authn-request.jsp?saml_request_id=...&saml_acs=...&saml_binding_type=HttpPost&Issuer=https%3A%2F%2Fsuperpat-developer-edition.my.salesforce.com&urlSource=1&RelayState=%2Fsetup%2Fsecur%2FRemoteAccessAuthorizationPage.apexp%3Fsource%3D...';
if (window.location.hash) {
escapedHash = '%23' + window.location.hash.slice(1);
}
if (window.location.replace){
window.location.replace(url + escapedHash);
} else {;
window.location.href = url + escapedHash;
}
</script>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
...
</html>
Note - no server on that /saml/authn-request.jsp URL, so the request will go to https://superpat-developer-edition.my.salesforce.com/. Let's simulate it with curl and see what happens:
$ curl -v 'https://superpat-developer-edition.my.salesforce.com/saml/authn-request.jsp?saml_request_id=...&saml_acs=...&saml_binding_type=HttpPost&Issuer=https%3A%2F%2Fsuperpat-developer-edition.my.salesforce.com&urlSource=1&RelayState=%2Fsetup%2Fsecur%2FRemoteAccessAuthorizationPage.apexp%3Fsource%3D...'
* ...
< HTTP/1.1 200 OK
< ...
<
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<body onload="document.forms[0].submit()">
<noscript>
<p>
<strong>Note:</strong> Since your browser does not support JavaScript,
you must press the Continue button once to proceed.
</p>
</noscript>
<form action="https://ADFS.example.com/adfs/ls/" method="post">
<div>
<input type="hidden" name="RelayState" value="/setup/secur/RemoteAccessAuthorizationPage.apexp?source=..."/>
<input type="hidden" name="SAMLRequest" value="..."/>
</div>
<noscript>
<div>
<input type="submit" value="Continue"/>
</div>
</noscript>
</form>
</body>
</html>
And there's the request that's posted to the SAML endpoint you configured (in my case, https://ADFS.example.com/adfs/ls/). So - follow the chain one more link and you should see what's really happening.
You can pass a session ID as an attribute in the SAML Assertion. In the Connected App configuration for your SP, set $Api.Session_ID as a Custom Attribute value. The recipient will be able to use the session ID with the REST API.
Best Answer
I'm happy to say that this feature is now fully accessible to administrators. It has been possible to prevent users from using their Salesforce credentials when they were SSO-enabled but it required contacting Salesforce support.
As of Summer '20 (release notes), you can configure SSO in a way that it prevents users from using their internal credentials.