Hey Bill, thanks for the clarification, I didn't realize that the cookie was Http-only, neat!
We are building a pure HTML5 client that is also hosted separately from the REST-backends. The thing is that we use a reverse proxy so for the browser it all looks like one app since everything comes from different paths in the same domain.
I'll try to clarify the last part of my last mail: We are currently using org.jboss.resteasy.skeleton.key.as7.OAuthAuthenticationServerValve (skeleton-key-as7) in our REST-backend modules. If I'm not mistaken, some parts of the code base and concepts are the same as in keycloak, right?
So far, in the AngularJS application we've been adding bearer tokens to the HTTP Authorization header. Since the backend uses JAX-RS/ RestEasy, the verification of the bearer tokens was done transparently by OAuthAuthenticationServerValve and RESTEasy automatically added the roles etc. to the HttpServletRequest. Now in the REST backend of the admin app in keycloak you're doing the same thing (validating the tokens and extracting the roles) manually with the AuthenticationManager (authenticateSaasIdentityCookie(...)). So I was just wondering whether you are planning to make that process more transparent in the future?
I think it would be nice to be able to write REST services with @RolesAllowed etc.
Does that make more sense?
Cheers!
Nils