Implementation of single authentication point

Question

I am building a series of web apps connected to a single point of authentication. Basically, a user tries to access a site, if not authenticated they are redirected to the central auth system's login page. Once they successfully login, they are redirected to their app. From then on, if they access any other app they would automatically be signed on.

A couple additional details: 1) the apps will all be running under the same domain, so I can use domain cookies, which makes things easier; 2) users can be given access to some apps and not others, so that needs to be taken into account; 3) user needs to be able to retrieve permissions specific to each app.

I have implemented something, but am not 100% happy with it. Right now, this is what I have: 1) web app checks for existence of a session (specific to the app) and a cookie that's a JWT token that was sent from the centralized auth system; 2) if cookie doesn't exist, I redirect to the login page on the auth system; 3) once user logs in, they are redirected to their app passing in a JWT token; 4) the app verifies the token via a REST API call to the auth system (making this REST API calls relies on a separate access token), if it's valid, then the JWT token gets saved as a cookie and a session is initiated with the user logged in; 5) if the app session expires, it checks if the cookie exists and if it does then app does the same as step #4, verifies the token and reinitiates the session; 6) on logout, the system just deletes the cookie, ensuring user is logged out of all apps; 7) if the token expires, the app uses the expired token to request a new one, where the token signature and other claims are validated before issuing a new one, the only thing that doesn't get validated is the expiration claim.

To clarify, the existence of a session specific to the app is used so that you don't have to keep making REST API calls constantly to verify the token. But given that the token was verified once, would it be safe to just use that cookie as the indicator that there's a valid session?

One thing that I'm unsure about is that my token needs to have something that indicates what app it is for because other REST API calls can be made using the token to get some resources that are app specific. But if I obtain a token for app1 and then log into app2, app2 will be relying on the cookie generated by app2. So seems like I'd want to have two tokens, one that can be stored as a domain cookie to indicate the user is authenticated, and another one that would actually be app specific and can be used to make REST API calls for other app-specific resources.

Am I over-complicating this, or does my line of thinking match what others are seeing/doing out there? Or is there a more elegant way of doing this? I've thought of implementing something like Open ID, but seems a bit like overkill for our needs. I want this to be as simple as can be so that I can document the process and other developers teams can develop apps that plug into the auth system without needing too much assistance.

Answer 1

Don't be crazy. No one in their right mind would attempt to write something like this from scratch. Use OAuth. You can use the JWT Bearer token spec for the token and use scopes to determine which app or resource the user has access to. This is not a good area to start reinventing the wheel in!

Answer 2

I recently just followed a guide here that explains the setup process for token based authentication. One way that I can imagine passing some form of app specific identification would be using claims.

So you have website A which redirects you to your login system page. Website A also passed in some other data like where to take the user after login and where Website A is. Your authentication system looks at this data and using a switch of some form you append a claim to the users token that identifies their current app scope.

Also to help combat the user switching apps very fast and still having access to app resources for app1 while on app2 make your access_tokens expire very fast. In my running demo website built using above guide mine expire every minute, as well the implementation of a refresh_token makes everything easier. Another step that could be helpful is while appending claims to users also append a role to that user stating they're on a website.

Then on app1's /api/endpoint/getData set the [Authorize(Roles="App1")], this will ensure that only access_tokens that contain a role = App1 can use that endpoint then inside your javascript or whatever client side scripting your using simply do logical checks for errors such as not accessing a specific endpoint and maybe the user needs to get a new access_token using the refresh token and so on and so on.

Using that same guide I listed above, follow that link and search for this:

var identity = new ClaimsIdentity(context.Options.AuthenticationType);

As you can see the identity is adding claims which are basically just values that are going to be encapsulated inside the access_token.

Now when a user calls into your web api that has an authorized attribute above it you simply do a check on that users claims.

An example of this can be found here.