Is there way to remove cookie based feature from laravel sanctum and only use Authorization Bearer token way.
As, by default it sets and check through cookie and this feature don't work when API is deployed with different server then front-end.
Yes, it is possible.
\Laravel\Sanctum\Guard goes through config sanctum.guard, default value is web, so you can set this config in your config/sanctum.php file to whatever suits your need.
Eventually, you can change your web middleware group, if your SPA is the only GUI client.
If any of mentioned options is viable or smart is another question, to which I'd reply: "nope, configure your app properly to send and accept security headers and/or cookies with cors settings fitting your needs."
Related
I'm building a CMS with vue 3 and want to know if using global store store.store.auth = false/true is a secure way of rendering in/out components that are supposed to be seen only by authenticated users. It goes like this:
User enters credentials in login form
Credentials are sent via HTTP request to backend and checked by laravel sanctum
Response arrives in frontend which sets store.store.auth = true
Components and routes that are supposed to be seen only by authenticated users are rendered via v-if
Is this a secure approach or can it be improved?
The security, in this case, depends almost entirely the backend.
Sanctum does not use tokens of any kind. Instead, Sanctum uses Laravel's built-in cookie based session authentication services. Typically, Sanctum utilizes Laravel's web authentication guard to accomplish this. This provides the benefits of CSRF protection, session authentication, as well as protects against leakage of the authentication credentials via XSS.
src
It seems like sanctum handles the authentication, so you should be fine as long as
store.store.auth value is kept up to date, and
the API does it's own authentication and authorization.
Because the entirety of the application is visible through the js source someone could potentially modify state and display options that they shouldn't see. This would be really-really difficult to prevent in SPA, that's why it is paramount that the backend handles this correctly.
You may be able to use code splitting, to prevent loading parts of the application that require authentication, but this is not security measure.
I want to use Nuxt.js for my frontend and laravel sanctum as my backend authentication provider. How should I set the SESSION_DOMAIN key in the .env file in my laravel project.
Also should I edit anything in the server object part in the nuxt.config.js file to make this work?
When you use Sanctum with SPA, such as Nuxt, you've the option to use either API or cookies/sessions. If your application is a first-party application on same top level domain, Laravel recommends to use cookie based approach so you can take advantage of CSRF protection. Axios and Angular Http libraries handles CSRF out of the box, so you don't have to worry too much about handling the requests headers [1].
In your case, I assume your application is first party and is on same top level domain. So your SESSION_DOMAIN value would be for example .domain.com. Also you'll need to set SANCTUM_STATEFUL_DOMAINS=domain.com as well. Usually your SESSION_DOMAIN will have just the main domain your application uses on, while SANCTUM_STATEFUL_DOMAINS will have all the subdomains (if any), that your frontend uses.
To work with Sanctum, we should be familiar with a few things first. We must use our SPA and API backend on the same domain, like frontend on domain.com and API on api.domain.com. We can not set frontend on domain.com and backend (API) on another-domain.com. The client must be able to include cookies with each request being sent to the backend.
session domain is the front-end domain name without protocol and port.
When you are working on local you must set it to localhost and when you are working on server you must set the domain name.
please follow this example of nuxt-laravel-sanctum-auth
I'm trying to get Strapi running behind a Keycloak Gatekeeper. My problem now is that the Admin UI is broken, because it uses the Authorization header to include a custom JWT. Keycloak Gatekeeper also uses the Authorization header with its own JWT. Is there any way to either a) disable authentication in Strapi so that it doesn't send the Authorization header or b) make strapi use another header for its JWT?
Thanks!
Similar example that was never merged take a look here
I 'm trying to create a secure spring rest api using pre-authentication security for siteminder.
I 've tried a solution where I 'm getting SM_USER and when I tested it in postman by adding new header SM_USER with random value it seems to work fine.
If you don't provide header I'm getting an error org.springframework.security.web.authentication.preauth.PreAuthenticatedCredentialsNotFoundException: SM_USER header not found in request which is valid.
But how can I be sure that this is secure? if someone knows the URL of my rest api could call this without problem. Should I check something else in spring or only siteminder offers user authentication?
The front-end SiteMinder web agent is the guaranty that the session is valid - you must make sure via server/network configuration that your application cannot be accessed directly without first passing through the SiteMinder web agent.
Also, SiteMinder asserts multiple headers. SM_USER should not be used alone because it can be asserted by the web agent in some circumstances when the user does not actually have a valid session. Instead, you should first look for the existence (non-blank) of SM_SERVERSESSIONID, which only exists if the session is valid.
Lastly, I generally try to avoid SM_USER at all - because SM_USER is actually not a user attribute at all, but rather is "the login identifier used for authentication". If SiteMinder authenticates users via federation (e.g. SAML) or x509 authentication, SM_USER will be rather different than if a login form was used. Instead, its better in SiteMinder to set a "universal id" that is a user attribute, and appears in the headers as SM_UNIVERSALID. Your SiteMinder administrators will know how to do this (and may already have - look to see if you have a SM_UNIVERSALID header available already).
One other caution, in some SiteMinder configurations, the underscore will not be in the header name (use of the underscore is called "legacy" header mode in SiteMinder), so you might want to make your app configurable with respect to the header names, e.g. SMSERVERSESSIONID, SMUSER, SMUNIVERSALID etc.
If you want to programmatically re-validate a session, you can use the SiteMinder Agent API or REST API, or look at my company's product "SSO/Rest" which provides a comprehensive set of uniform REST interfaces to SiteMinder and also other SSO providers (http://www.idfconnect.com).
HTH!
-Richard
I have written a REST- API in Java and I have secured this API with Spring Security. The procedure is like this:
Frontend invokes /login RestService in Backend
Backend gives back token to frontend
at each REST- API Backend invokation the token has to be placed in header
This works fine, but I have read that it is also possible (with Node.JS/Passport.js/Express.js) that the session object with the cookie inside can be transfered out of the box without any custom code.
My question now would be if there is a better approach so that the frontend/client do not need to set the token into the header all the time for any request.
Usually token based authentication has advantages over cookie based.
You can achieve this using middle-ware layer
Here is a good Post - https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/
Server side, I usually first check in the headers if there is an auth token. If not, I then check in the cookies as a fallback.
If you want to use cookies, then at your step 2, you need to add a Set-Cookie header to the response, so that browsers know they must store a cookie. Once done, no need to add a header client-side, since browsers will send cookies each request. You'll need to add a CSRF protection though (here is a good example).