Re: [keycloak-dev] Keycloak OIDC Adapter and XMLHttpRequest

----- Original Message ----- That is fine as long as everybody is happy. I'm open to get back on step back and get a agreement about #1 or #2. Integration with third-party OIDC and SAML is something #1 can do using nothing but what the standards define. Regarding DIGEST, it is just one of the different http authentication mechanism supported by WildFly/EAP. Elytron is adding even more to this list. For instance, SCRAM. There are different use cases out there ... Well, it is not really a one-off hack. Actually, I've used something similar to what UMA provides in order to tell clients which AS they should go. There is no adapter on the client side, but only on the RS side. Beside that, the client was designed to rely on a authentication/identity cookie in order to secure requests and get things from the RS. The flow is: 1) Client asks a protected resource to the RS 2) The adapter running on the RS side identifies that the request contains a 'X-Requested-With' header with a value 'XMLHttpRequest' and that there is no authentication info associated with the request 3) Instead of responding with a 302 redirect, the adapter sends back a response with a 403 status code and an Authorization header containing the "as_uri". The "as_uri" is the same URI used in 302 redirect, nothing special here 4) Client extract the Authorization header from the response and redirect the user to an URI as specified in "as_uri" 5) User provides his credentials to the AS and if the authentication is successful, he is redirected back to the RS 6) The adapter running on the RS side now creates an identity cookie or a session based on the response from the AS. Again, nothing new here. 7) The adapter redirect the user back to the client application URI based on some information on the original request (eg.: a redirect_uri parameter sent during step #1), where the URI of the client must be valid and provided via adapter configuration (something like a second valid URI check, but at the RS side). Basically, I'm using 302 instead of 403 and doing a second redirect to get the user back to the client application. Where the client URI must be provided via adapter config and will be always validated.