Unified login accross several websites

[Red Squirrel]

I run several websites, most don't get much traffic or arn't maintained, but one thing I've been wanting to do is setup a unified login system for all my site/services. Something like what Google does.

Now doing that on it's own would be fairly easy. Just need to modify the forum software to authenticate to my custom central system instead. But I want to go a step further and make it so if someone logs in on one forum, and goes to another that's on another domain, they'll also be logged in. Obviously for security reasons a site cannot read another domain's cookies. So what is the best way to go about doing this?

 

[douglasb]

I would suggest looking into OAuth and OpenId

 

[DaveSimmons]

Shibboleth and CAS are two popular single-sign-on systems. Shibboleth is the more popular of the two right now since it's more flexible.

OAuth is more for apps that need to authenticate themselves, by having the user manually go through a sign-on (often shib of CAS) to obtain a token to be used later.

 

[Red Squirrel]

Not looking at a whole system, I'll be coding this myself. I just want ideas on how I can know if someone who goes to site B already logged into site A. Cookies are out of the question due to them being restricted by domain for security reasons, as far as I know, unless there's something I can maybe do with javascript? Or is there a way to set a cookie in a way that I can set a list of domains that are allowed to access it?

Basically the way it will work is I'll have a central page somewhere that other sites query with hashed information, and it will return a yes or no. So say I login to site A with credentials, it will hash them, then query the authentication page (which could be on another server) and it will either reject or allow the login. Then the script will set a cookie so the rest of the site works as normal. If the user goes to site B I want the cookie or other stored info to still work and query the authentication page. But since site B will be on another domain I obviously can't access site A's cookies.

The very back end I have not decided yet what it will be, either something as simple as just a user database, or maybe something like LDAP. Probably going to just do something custom.

 

[Leros]

I'd break out your authentication functionality into a service. I'd also break out your account/login stuff (registration, login, account info, etc) into a separate web application (this would be akin to Google's accounts.google.com)

When a user wants to login to one of your sites, you forward them to the authentication webapp. After logging in, the authentication webapp redirects the user back to the originating site. This redirect needs to include data that allows the originating site to set a cookie on it's domain so that the login will be remembered on that site.

All of your webapps can query the authentication service to see if the user is logged in. You'll need to do this on every request (for reasons I'll explain below).

Logging out becomes a bit trickier. If I log out of site A, I need to also be logged out of site B, but the app running on site A can't remove cookies on site B's domain. To get around this problem, you need to keep track of the user's logged in status in a database. After logging out of site A, you record that the user is logged out. On the user's next request to site B, the backend for site B makes a query to the authentication service to see if the user is logged in, it realizes the user has been logged out, and deletes the login cookies from site B.

From what I've heard, this is sort of on the same track as what Google does.

 

[GregGreen]

An idea, not sure it would work:

On login, when the user successfully logs in, have the user ping each individual server via ajax so each server can set their own cookies?

 

[Red Squirrel]

I'd break out your authentication functionality into a service. I'd also break out your account/login stuff (registration, login, account info, etc) into a separate web application (this would be akin to Google's accounts.google.com)

When a user wants to login to one of your sites, you forward them to the authentication webapp. After logging in, the authentication webapp redirects the user back to the originating site. This redirect needs to include data that allows the originating site to set a cookie on it's domain so that the login will be remembered on that site.

All of your webapps can query the authentication service to see if the user is logged in. You'll need to do this on every request (for reasons I'll explain below).

Logging out becomes a bit trickier. If I log out of site A, I need to also be logged out of site B, but the app running on site A can't remove cookies on site B's domain. To get around this problem, you need to keep track of the user's logged in status in a database. After logging out of site A, you record that the user is logged out. On the user's next request to site B, the backend for site B makes a query to the authentication service to see if the user is logged in, it realizes the user has been logged out, and deletes the login cookies from site B.

From what I've heard, this is sort of on the same track as what Google does.

Yeah that's kinda what I was thinking of doing actually. Just not sure how the other sites will know about the successful login. Maybe some kind of temporary token is generated by Auth service (AS), then a query is set to each site using that token, and because it's valid, the site is then instructed to set the cookie? Cookie could then contain another token that is also kept on AS, so when I then go to any of those sites the token is checked through AS before authenticating. In the case of a forum I could also have it set that specific forum's cookies (but to expire at end of session) and it would work as normal from that point on. Would reduce the queries to AS.

Logging out would simply be to delete the token so when the user visits that site and it does the authentication check it will fail.


Idealy though, I rather not need to have a listener on each site/service. But guess it could work.

 

[Leros]

Yeah that's kinda what I was thinking of doing actually. Just not sure how the other sites will know about the successful login. Maybe some kind of temporary token is generated by Auth service (AS), then a query is set to each site using that token, and because it's valid, the site is then instructed to set the cookie? Cookie could then contain another token that is also kept on AS, so when I then go to any of those sites the token is checked through AS before authenticating. In the case of a forum I could also have it set that specific forum's cookies (but to expire at end of session) and it would work as normal from that point on. Would reduce the queries to AS.

Logging out would simply be to delete the token so when the user visits that site and it does the authentication check it will fail.


Idealy though, I rather not need to have a listener on each site/service. But guess it could work.

You need to have a primary domain (e.g. website.com) where you host your authentication webapp (e.g. accounts.website.com).

So, when a user logs in, the authentication webapp sets a cookie on website.com. If you host another application that same domain (like secondary.website.com), that webapp can directly read the website.com cookies and recognize that the user is logged in without any additional steps.

If you have a site on another domain (e.g. anothersite.com), you have to bounce the user through your primary domain so you can pick up the pre-existing login cookies.

Example: User goes to website.com and logs in. The user now has cookies on website.com and no cookies on anothersite.com. The user goes to anothersite.com. The backend for this site recognizes that the user is not logged in and bounces them through a redirect on accounts.website.com. This redirect reads the website.com cookies and recognizes that the user is logged in, so it redirects back to anothersite.com with some sort of shortlived token in the URL. The backend for anothersite.com uses this shortlived token to lookup the user's session via the authentication service. If it can validate that the user is logged in, it will set the login cookie on anothersite.com.

 

[Red Squirrel]

You need to have a primary domain (e.g. website.com) where you host your authentication webapp (e.g. accounts.website.com).

So, when a user logs in, the authentication webapp sets a cookie on website.com. If you host another application that same domain (like secondary.website.com), that webapp can directly read the website.com cookies and recognize that the user is logged in without any additional steps.

If you have a site on another domain (e.g. anothersite.com), you have to bounce the user through your primary domain so you can pick up the pre-existing login cookies.

Example: User goes to website.com and logs in. The user now has cookies on website.com and no cookies on anothersite.com. The user goes to anothersite.com. The backend for this site recognizes that the user is not logged in and bounces them through a redirect on accounts.website.com. This redirect reads the website.com cookies and recognizes that the user is logged in, so it redirects back to anothersite.com with some sort of shortlived token in the URL. The backend for anothersite.com uses this shortlived token to lookup the user's session via the authentication service. If it can validate that the user is logged in, it will set the login cookie on anothersite.com.

Hmm I think I understand now, and I could probably do all that through ajax or "background" process so that it's fairly seamless, too. Going to have to experiment. Thanks I have some ideas to go on now.

 

[beginner99]

Not looking at a whole system, I'll be coding this myself.

if you want it to be insecure go ahead...security is the most stupid area to "roll your own".

 

[Red Squirrel]

if you want it to be insecure go ahead...security is the most stupid area to "roll your own".

Actually it's safer that way, since I'll know EXACTLY what the code does. Just have to think of all the possible scenarios and ensure I'm covered. Really the #1 thing with web security is NEVER trust user inputted data, and that includes data that is passively passed by the user through hidden form fields or query strings. If it comes from the client side, it cannot be trusted for authenticity.

Of course there's other stuff to check like SQL injection and such but that's pretty easy and common sense.

 

[tfinch2]

Actually it's safer that way, since I'll know EXACTLY what the code does. Just have to think of all the possible scenarios and ensure I'm covered.

You can't be serious.

 

[Red Squirrel]

You can't be serious.

So are you suggesting that something I code today will be less secure than it's replacement, which I coded almost 10 years ago? You can't be serious.

 

[Leros]

So are you suggesting that something I code today will be less secure than it's replacement, which I coded almost 10 years ago? You can't be serious.

Wrong comparison. It's:

Something made by you (a single developer who is not a security expert)

VS

An open source solution written by many developers (possibly including security experts), which has been pounded on by bad guys for several years, and with several years worth of patches that were made as problems were discovered.

 

[Markbnj]

So are you suggesting that something I code today will be less secure than it's replacement, which I coded almost 10 years ago? You can't be serious.

I think he's suggesting that it's highly unlikely that you will do a better job than an open source framework that has been in the wild for years, and tested and debugged by thousands of developers.

Which is, of course, true.

 

[Red Squirrel]

Still much easier to code exactly what I need than to try to integrate something 3rd party. What would be the point of programming anything with the attitude of just using something already made? I see that attitude at too many programming forums. Mac already had an OS out which was made by thousands of developers and tested etc. With that attitude, MS should not have bothered making their own OS.

 

[Markbnj]

What would be the point of programming anything with the attitude of just using something already made? I see that attitude at too many programming forums. Mac already had an OS out which was made by thousands of developers and tested etc. With that attitude, MS should not have bothered making their own OS.

You're talking about different things. If your goal is to create a better federated authentication framework, then by all means proceed. But if your goal is to create an application that happens to need federated authentication then you're better off using something tried and tested, and spending more of your time adding value in your core domain.

 

[beginner99]

You're talking about different things. If your goal is to create a better federated authentication framework, then by all means proceed. But if your goal is to create an application that happens to need federated authentication then you're better off using something tried and tested, and spending more of your time adding value in your core domain.

this + the tried and tested will be better anyway to anything "home-brewed"...even if OP is a genius.

 

[TecHNooB]

pay no attention to these naysayers. i say, homebrew that shit and let us know how it goes

 

[DaveSimmons]

I've never had a reason to set up either CAS or shib, I just deal with them on customer sites. But either one is more likely to be secure out of the box than rolling your own scheme then letting customers and hackers beta-test it for you.