I am having a bit of a problem here.
I have Keycloak where I have enabled CORS (value '*') and I can call endpoint:
/auth/realms/master/protocol/openid-connect/token
from Postman, where I get response with access token and other stuff, but when I try to call that endpoint from my React application, I get CORS error:
I don't get why, since I have set '*' value for Web Origins in that client.
Is this a Keycloak bug, or am I missing something trivial?
Do you have the address 'http://localhost:3000/*' added on the Valid Redirect URIs keycloak config?
I have fixed this issue by creating Web API project in .NET Core (this could be done in any other technology). I have setted CORS policy in my project to allow any domains and then I make direct calls to Keycloak endpoints from .NET Core project. Besides fixing this issue (since .NET Core Web API project is not a browser application, this is working like a charm), this adds another security layer to the Keycloak by hidding client information that is only accessible from .NET Core application. Information like client_id and client_secret are not visible from browser application and no one can do any damage to my clients in Keycloak.
Related
We have a React App which is hosted inside an ASP.NET Core site hosted on an IIS Server.
Originally we had the React App hosted on its own in IIS and protected by HTTP Basic Auth on our Staging server. This worked fine.
We then moved to hosting the React App inside the ASP.NET Core site. This has now caused problems with Basic Auth. If the user enters the site through just the domain they can authenticate with Basic Auth and everything works. However is the user refresh a page in their browser, the Basic Auth header is no longer sent and causes the server to challenge the user again for their username and password. For our testers this makes their lives very hard.
We have reproduced this in both Firefox and Chrome.
Using Fiddler we are able to request the pages/documents directly with the Basic Auth header, so we know that direct access is possible. We just don't understand why the browser is removing the header on a refresh.
IIS basic authentication is not cookie-based authentication. client just send user credential to client side with authorization header. It looks like the fresh page action will clean the cache or override that header. Please check this on other web browser like edge or IE.
I'm implementing login functionality on my site and I'm running into some problems when sending jwt tokens as cookies.
When the user logs in on the frontend, a POST request is sent with "credentials: 'include'" (I'm using fetch) to my backend API, which returns a jwt token if the login was successful. This all works fine, and I can see the cookie in chrome dev tools, and performing actions that require authentication work fine.
However, when I refresh the site, the jwt cookies disappear. I have ruled out errors with expiration. Through experimentation I've figured out that the domain is the problem. The cookie's domain is "127.0.0.1" from the locally hosted instance of the API, which is different than the domain of the locally hosted website. If I manually change the domain of the cookie to the same as the website, the cookie doesn't disappear.
But that does not solve my problem permanently, as the backend API is hosted on a different domain than the frontend. I've been reading up on cross-domain requests but I'm not sure how to proceed from here. I control both the frontend and the backend, but I'm starting to wonder if I might be going about this the wrong way? Would the simplest solution be to host my api on, say 'api.mydomain.com' instead?
I am currently developing a web application that has separate API and Front end.
For production purpose, I wish to develop the web app locally while hosting the API on the remote server.
The issue is the API is behind a SAML authentication along with Mod Auth in second stage.
Using postman and wget I am able to access the API endpoint by adding a auth_tkt cookie in the request.However I am unable to access the same using AJAX.
I need help in executing the same.
Just to help anyone else facing similar problem. The solution to this problem is using chromium with disabled security. It sends your session cookies along with the request. Also there is no problem of CORS that was coming in picture before.
I developed a windows mobile application which connects back to my web services hosted on internet to sync with the server data.
I didnt put any control for CSRF on mobile application, Is it required to have a CSRF protection on native applications? If yes why?
** My application is native application not on web browser.
Is it required to have a CSRF protection on native applications?
No, if your mobile application is the only type of consumer (e.g. no web browsers) and your mobile application does not make web requests to other domains then by definition CSRF is not possible as there is no cross site request to counterfeit.
CSRF protection would be on the web server side, not the app, although you can help yourself by setting a cookie from the server on login and adding that cookie to the header of your requests from the native app.
You application will most likely need to be CSRF aware (if you've implemented protections on the backend).
For instance, a general best practice is to supply a token on each request that will be used on the next request to ensure no duplicate requests can be made. Your mobile app will need to be able to get and use this token (again, assuming you've implemented this on the server side).
It really depends upon if your site can be accessed by a human AND/OR the authentication method that you are using for the web site.
If a user can login in any way to this web site that is hosting your web services via a browser then while the user is logged into the site, the answer is yes because CSRF takes advantage of the fact that the browser will send along session and other cookies when the web site is communicated with due to the fact that cookies are automatically added by the browser for all request targeting the same origin regardless of which web site is sending them.
If your web services can be accessed directly via NT Authentication then as long as you are logged into the network, the answer is yes. The reason is because the attacking web site that is using malicious JavaScript is still accessing the web services as YOU regardless of which site is sending the request.
Finally, if there is absolutely no way to login to the site via a browser and you are not using NT Authentication, SilverlightFox's answer is correct. The reason is because there would never be a Session cookie for the site so there is nothing to send when the CSRF attack occurred.
The Fix:
For web, this is fixed via an anti-forgery token, which is sent back with put and post verbs (although you can do it with all verbs). A malicious web site could try to send a request and would certainly pickup your session cookie, but the absence of the anti-forgery token in the put/post causes it to fail.
For mobile, patwhite above suggests a fix, but it would require different web service end points for mobile vs web due to the fact that it is a different strategy for handling the problem.
We are the process of developing a android phone app using IONIC framework and Web Api as the backend.
My question is ,is it sufficient to use Forms Authentication along with SSL to keep the phone app secure.
Our background is in Asp.Net web development and we could not see any examples that uses Hybrid mobile app development along with forms authentication,that makes me wonder if we are in the wrong track.
We implemented CORS along with WithCredentials both on Angular and Web API side, and the authentication piece seems to work fine for all subsequent calls in debug mode.
Do we need to take additional steps for security ,since its a phone app ?
Edit: I was reading about bearer token authentication with Web Api, is this a recommended way to go with phone apps ?
Thanks !
Yes my recommendation is to go with bearer tokens not with forms authentication.
You need to use OAuth 2.0 Resource Owner Credentials Flow which means that end-user provides the username/password only once for a specific endpoint i.e(/token) and then if the username/password valid you obtain something called Bearer Access Token.
This token is valid for specified period and you can configure this in your Web API. Once you obtain the access token, you need to store it securely in your android/hybrid app, then you keep sending it with each request to your web api protected end points using the Authorization header (Bearer scheme). I've written very detailed post which covers your scenario 100%. Please check the post Token Based Authentication and another one for authentication with AngularJS authentication which should work with your case. Let me know if you need further help.