Single Sign On / Token-Based Authentication process

Question

I have searched the forum for some resources:

I am bouncing around ideas on implementation of single sign-on / token based authentication process. Roughly, requirement would be:

User web app / mobile app / mobile web, etc
System 1: User info and login information, generate token and provide some services (eg. getUserData)
System 2: An external party that has control over user specific data
System 3: Yet another external party like System 2
User need to only sign in once at System 1, and then able to communicate with System 2 and System 3

Think about bank, or something like Mint.com, after initial setup, user can sign in once through Mint which then have access to go to your banks (and possibly multiple banking institutions) - thus gaining access to different systems with a single sign in. However, in my case it will be more than just read-only access that Mint.com is doing.

My initial thought roughly looks like this:

User Sign In ----> System 1, login verification generate token for itself (call it token1)
System 1 ---> generate token and pass it to System 2 (call it token2)
System 1 ---> generate token and pass it to System 3 (call it token3)
System 1 ---> return [token1, token2, token3]

From here, user (ie. the app or site, etc) have 3 tokens that it can use to communicate. If user need to execute action / retrieve data from System 1, it will pass in token1 with the request, etc with System 2 and System 3

Is this approach make sense?

There are of course security concern around this - what if the token is stolen somewhere along the way and now somebody with that token can execute actions on the system the token is for - obviously, this would be bad for things like banking system.

How does the System verify that the request sender that that give the token actually is the legitimate user the token was generated for?

One thought is 2nd authentication level, ie. with every request the user make, it needs to enter a special code (eg. like your bank card PIN) to go along with the token in the request - but doesn't this get annoying? Every request, user has to enter a PIN.

Thoughts and comments would be greatly appreciated.

EDIT: I already looked at OAuth ... As far as my understanding goes, you need to implement an OAuth provider that generates the token and allow you to use it with the OAuth provider itself, in other words, the OAuth provider is System #1 - but how can I make System 2 and 3 accepts that OAuth token as well? Or may be I misunderstood OAuth.

Also, even if using OAuth will work with the way I want it (System 1, System 2, System 3, etc), the question remains: What if an external malicious party gain access to that token? How can I identify to make sure the one using the token is the authorized party?

You might consider looking into oauth, which is a centralized login service. Big systems like the ones you're thinking of probably work using an oauth-like model - one centralized authentication service is used to provide a login token of some sort. Such a token would be small enough to store in a cookie or something, and would contain an embedded expiration, your user id, some random fluff, and a signature from the auth server's private key which could be verified by the public key, which all of the services would have. Token could be renewed at intervals by the client to prevent expiration. — Wug, Jul 30 '12 at 20:33
"What if an external malicious party gain access to that token?" This is called, among other things, session theft, and will always be a problem on every system ever. use HTTPONLY cookies. This is a moot issue, since the same thing happens if I steal the user's password. The idea is to make it difficult or impossible to get this token if you're not the service itself. — Wug, Jul 30 '12 at 20:47
hmm thanks - I might have done overthinking on the issue and overly concern about, as you put it, moot issues. I am just trying to get my bases covered before barrage of questions are asked to me — TS-, Jul 30 '12 at 20:52
As has been pointed out, there are a number of systems out there designed to safely accomplish this and it would be foolish (and dangerous and insecure) to try and roll your own when there are already so many working implementations, and when there are so many things that can go wrong. As a general rule, if you're thinking about rolling your own and have to ask for implementation details or whether it's a good idea, it's not a good idea. — Wug, Jul 30 '12 at 20:55

score 3 · Answer 1 · answered Jul 30 '12 at 20:36

"Does this approach make sense?"

If you are asking how to invent robust authentication schemes on StackOverflow, then you are — by definition — not qualified to invent a robust scheme. Indeed, I don't think that any one expert in the field is currently capable of doing so.

This is one wheel you cannot re-invent. Use OpenID/OAuth or Kerberos or something similar that has had teams of experts analyze them for weaknesses neither you nor I could understand.

Single Sign On / Token-Based Authentication process

1 Answers1