I wonder is it possible to get cookies under another domain rather than my current app domain name?
I am building an application which access to another website's api. If the user has already logged in from the other site, my browser will create a cookies under that domain name. For example, user logged in under www.example.com, my browser will store a cookies:
cookies['token'] under www.example.com domain. When user visit my website, www.mywebsite.com, how can I get the cookies under www.example.com in my rails server?
Any help is highly appreciate.
This can be done, but it requires the client, your website, and your other website to all work together. You have a client that knows how to authenticate to site A. It wishes to view site B as the user it knows how to authenticate against site A with. The basic way to accomplish this is to have the client contact site A, authenticate itself, acquire a token from site A that site B can trust, and then hand that token to site B.
Effectively, you want to build a very specific case of OpenID or OAuth. This is certainly possible, but you're going to need to make some changes to www.example.com in order for it to play along. If you're able to do this, great.
Start by reading everything about OAuth. You don't need to use that exactly (although you could), but it will help explain what you need to do: http://hueniverse.com/oauth/
You can share cookies across different subdomains of a domain but you CANNOT share cookies across multiple domain names.
Cookies are stored by the BROWSER and the browser will not allow you to access or store cookies from external domain names. It would be a huge security flaw if browsers did allow you to do this.
You can, however, share session data that is stored on your server between domain names. This may not be completely trivial, but since session information is stored on the SERVER, you can access the information on the server between apps if needed. If your session data is stored in a database, then all that is required is to give database access to both domains. If need be, you could actually open your database to an external domain name and have the external domain directly connect to the database on your server.
Related
I have two sites, one of which is essentially embedded into the other, although they have to be loaded from different URLs. They both access the same backend API. I want the user to log in once and be able to access the API in the embedded site without having to log in again. Essentially, I guess this would be Web-SSO. To complicate things even further, the outer site is a legacy PHP site with a backend server, the inner is a single-page react app.
I'm looking for a way to pass the login from the outer site to the inner site, without actually passing a login token around e.g. as an URL parameter, which would probably not be safe.
Essentially what I'm looking for is something Site A can safely give to site B, that will tell the authrisation server "Site A is authorized, and Site A trusts Site B, so it's OK to give Site B a token too"
Does such a mechanism exist? Some people have suggested OAuth2 and OpenID to me, but in all the documentation I've read, I haven't found any description of this use case. To me, this looks like OAuth2 in reverse. All examples I have seen concern the use case "Site A wants to access Service X, so it needs to authenticate with the Auth server Y, to get a token that will let it access the service". A second site wasn't part of the picture in any of the examples I could find.
Is OAuth2 even the right technology for this, or do I need something else entirely? How does one implement this use case?
If I understand correctly, you just want/need SSO. Since if a user logged in in site A (or any *.domain.com or *.com that is registered as a "safe" application) it will also be logged into site B.
Essentially how this works is when the user is logged in there will be a cookie stored on this website and (not sure) also on the API login website. Then whenever the user tries to enter website B e.g. the application should check for a cookie on site B. If there isn't any cookie it will look for a cookie on the API login website. If there is it will automatically login (without credentials). This is basicly what you say.
Site A can safely give to site B, that will tell the authrisation
server "Site A is authorized, and Site A trusts Site B, so it's OK to
give Site B a token too"
This could be achieved by using a third party like Auth0. Im currently trying to implement this in Symfony. So far not much success but since I searched alot for other SSO providers I think this is the best shot. Also for your needs I belive it will work good enough.
Another option:
Create a API authentication server yourself. This way you have full control over it. But you need to manage it all yourself, also the security. There are probably packages that help you alot but still, you need to figure out alot by yourself.
My advice is to check out Auth0 by just creating a free account. See what it can offer and try some things out.
I work for a company where we give customer (hundreds/thousands of users) access to 2 sites. One owned by a 3rd party SaaS and one owned by us.
Customers spend alot of time registering for both sites and we also spend alot of time removing accounts when customers no longer need access.
I would like users to register for Site A. After successful authentication; a user can click on a link within the site to access Site B but without the user entering credentials.
I want Site A identity to be used to access site B and its resources. I do not need site B resources to be presented on Site A site, but simply allow users to access site B if already authenticated to site A.
Users may have different roles on site B.
What is my best option? Oauth2 sounds like a good option. But will it satisfy my requirement above?
Who will manage the authorisation server? I presume Site B?
Thank you.
Two main options:
OLD TECH WITH COOKIES
Perhaps the cheapest option is to use hosting domains and have 2 apps like this:
mail.google.com
drive.google.com
Use a cookie issued to the parent domain, google.com
Cookie identifies user, to provide a user id
Rights are looked up in each app from the user id
OAUTH2 AND OPENID CONNECT
This is the option for modern apps and they are usually used together, due to being web, mobile and API friendly.
It is a big job though, including user migration, and usually involves giving users a new password. So it needs to be something your company are prepared to invest in.
The Authorization Server (AS) becomes a shared central resource and it is common to use a Cloud Provider to ensure high availability.
RELATED RESOURCES OF MINE
Initial Code Sample with Cloud AS
User Migration Blog Post
I have built a service with user authorization via Google. My project is registered in Google APIs console and it has one Client ID for web applications which is strongly binded to my web domain.
Let imagine that in future I will decide to change my domain name. How would it affect users who are already registered? It seems that they would need to accept my application permissions again? What is the best way to deal with such kind of migration?
I am not sure what you mean by
strongly binded to my web domain.
Authentication is created using the client id and client secret pair in the Client ID for web applications The only thing that is specific to your domain is problem the Redirect URI. All the redirect URI does is tell the authentication server where to return the authentication to.
You could easily add a second redirect URI to another domain or another page on your domain. You could also add a new one and delete the old one it wont mater users will still have access because the client id and client secret haven't changed. So in the event you delete your current domain and create a new one just remember to change the Redirect URI to point to the new domain and the old authentication will still work.
I want to to decouple some parts in my rather large app and delegate them to an external node app, mainly for uploads but authentication remains a problem.
On the Rails side I'm using Devise, clients and forms will point to this new subdomain where the node app resides.
The node app is using express and I can connect to the shared database through the mysql module.
The idea is to use heroku for the main app, and delegate uploads to a node app running on a EC2 instance. In order to access the app I want to pass authentication informations, given that this endpoint will used by both API clients and web forms.
Devise has support for authentication tokens passed via URL, but I'm wondering what are your solutions.
Well if your subdomains are just 1-dot apart like www.myapp.example and uploads.myapp.example, you can share both the session cookie and the session info in the DB. I would just code the node app to validate the session cookie on every request the same way devise does and you're done. Is the upload subdomain user facing, as in does it render HTML to the browser or have to display a login form? If so, than the shared session table in the DB is probably not the best idea, but if the node.js is just for uploads and can redirect to www.myapp.example when the session is not valid, all should be well. Just make sure you set the domain field of the cookie to .myapp.example.
I am putting a plan together for a series of sites that will share user account information among them. The idea is that once a user logs in using their OpenID, they can access any of the sites and it will know who they are.
What are the common patterns/best practices that i could employ to achieve this?
If all the sites share a common hostname in their URL then you can set an auth cookie (FormsAuthentication.SetAuthCookie) specifying the path of the cookie to be "/" so that all sites can see the user is logged in.
If the sites are not sharing a common host name, I think the only way to get a truly "once signed in, signed in everywhere [within your ring of web sites]" would be for all authentication to happen at just one site (perhaps one dedicated to authenticating the user) and for the other sites to redirect the user to that site for authentication and then that site would redirect back. In essence, that auth site becomes an identity provider, and almost exactly fills the role of an OpenID Provider (in fact DotNetOpenAuth could be used here for this exact purpose). Since it sounds like your goal is to let the user log in with their OpenID, your OpenID Provider on that one auth site could itself use OpenID to authenticate the user. Your own pure-delegation OpenID Provider could be written such that it always responds immediately to checkid_immediate requests as long as the Realm in the auth request is one of your trusted ring of sites. Thus you could effect single-sign-on across all your sites.
Please consider the following Patterns & Practices on Web Service Security from Microsoft:
Brokered Authentication - http://msdn.microsoft.com/en-us/library/aa480560.aspx
The main topic is - Web Service Security
Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0
http://msdn.microsoft.com/en-us/library/aa480545.aspx
Ultimately theres lots of ways you could do it. I achieved a simple single sign on by building a url with a token from one website pointing to another domain. The encoded & encrypted token contained details to submit back to the previous domain. Upon receiving an incoming request on the second domain, an underlying web service checks that the incoming request's token is valid with the previous domain using a shared private secret, known to both domains.