Authorization server is "auth.com"
auth.com has a small database on it:
site secret authorize url
------- ---------- ---------------------
b.com secret1 /remoteauth.php
c.com shhh /remoteauth.php
It also contains a user database, with usernames, and passwords
Each member site (b.com, c.com) contains a "userauth" database with fields: UserToken, Username, LoginTime, LastAccessTime
Also, for this example, every page on b.com and c.com requires authorization: you can't even see either site without logging in.
Let's say a user opens their browser and visits http://b.com.
The first thing b.com does is checks for a UserToken cookie. None exists, so it knows this user is not logged in. It then inserts a new entry to the "authusers" database, with only "UserToken" = random string (lets say "foobar"), and LastAccessTime = time(). It then sets a cookie called UserToken to the same value inserted in the database, and sends a 302 Redirect header to "https://auth.com/authorize.php?usertoken=foobar&redirect=http://b.com"
auth.com checks for its own UserToken cookie (remember cookies are not shared across domains). None exists, so it shows them a standard fare login page. Once they login successfully, it sets a UserToken for them, creates its own database entry, and sets a cookie. It then uses the site database (listed above) to see that it has to post the following query:
http://b.com/remoteauth.php?user=UESRNAME&usertoken=foobar&auth=AUTHCODE
where AUTHCODE = sha1(USERNAME."secret1") (the shared secret for b.com)
remoteauth.php on b.com gets this post, and after verifying that $_GET['auth'] == sha1($_GET['user']."secret1"), it updates the authusers database where UserToken = $_GET['usertoken'], and sets the username to $_GET['user'], and LoginTime and LastAccessTime to time(). During this time, the user is still waiting for the page on auth.com to load.
Now authorize.php sends a 302 redirect back to http://b.com. The above process on b.com repeats. b.com looks for a UserToken cookie, but this time finds it.. then it looks in the database, and sees that there is indeed an entry for that UserToken, with Username filled in, so it now considers this user to be logged in.
Next time they hit a page on b.com, it checks for the UserToken, finds the user name in the userauth database, and considers them logged in.
Now, the user decides they're bored of b.com, and visits c.com. c.com repeats the same process as b.com did at first. Doesn't find a UserToken cookie, so it sets a new one, and inserts it into the database and sets the cookie. Now it sends a 302 redirect to "https://auth.com/authorize.php?usertoken=nasdfn2fh2sadf&redirect=http://c.com/somepage".
This time, auth.com finds its own UserToken, and checks its own userauth database. It finds the token, so it immediately posts back to c.com:
http://c.com/remoteauth.php?user=UESRNAME&usertoken=nasdfn2fh2sadf&auth=AUTHCODE
where AUTHCODE = sha1(USERNAME."shhhh")
c.com/remoteauth.php just like b.com gets this post, and updates its userauth database.
Now auth.com sends a 302 to the user back to http://c.com/somepage.
c.com checks the UserToken, and finds the username, and considers them logged in.
For the user, what has happened:
go to b.com, get redirected to https://auth.com/authorize.php?usertoken=foobar&redirect=http://b.com and see a login page.
Enter login information, and get redirected to http://b.com.
Click a link, the page just loads, no redirects involved.
Go to c.com, get redirected to https://auth.com/authorize.php?usertoken=nasdfn2fh2sadf&redirect=http://c.com/somepage, and immediately redirected to http://c.com/somepage.