The current code requires that each HTTP request contains an x-okapi-token: header line.
This does not work with commonly used external single-sign-on (SSO) services like Shibboleth/OAuth that do not support such an HTTP header. Instead they usually make use of a cookie that contains the session id in a secure way.
The x-okapi-token: header line is prone to cross-site scripting (XSS) and cross-site request forgery (CSRF) attacks.
Investigate what is needed for a secure and SSO compatible solution.
The current code requires that each HTTP request contains an x-okapi-token: header line.
This does not work with commonly used external single-sign-on (SSO) services like Shibboleth/OAuth that do not support such an HTTP header. Instead they usually make use of a cookie that contains the session id in a secure way.
The x-okapi-token: header line is prone to cross-site scripting (XSS) and cross-site request forgery (CSRF) attacks.
Investigate what is needed for a secure and SSO compatible solution.
These references might be a good starting point:
https://stormpath.com/blog/secure-single-page-app-problem
https://stormpath.com/blog/token-auth-for-java
https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage