0

I have

  • a public API (intended to be used by third-party websites)
  • authentication only via JWT bearer tokens (no cookie authentication). SPAs have to add the Authorization header for every API request. A CSRF request would IMO not be authenticated (unless the attacker could steal the access token from the SPAs storage which is an entirely different problem).

I understand the motivation for blocking the combination of wildcard origin and credentials in browsers (as e.g. basic authentication etc. would be cached by the browser and could be exploited via CSRF), and the motivation of framework developers not to support the reflection of the requested origin as the accepted origin (anymore, example).

However, in the scenario described above, would it be okay to do exactly this (reflecting the requested origin header), or am I missing something?

Background: Third-party websites obviously need to register with the OAuth server (to get a client ID, register redirect URIs etc.), but I would really want to avoid to update the CORS configuration of every protected resource for every change in registered clients (or to somehow retrieve the allowed origins from the identity server).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.