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.