How does authentication Server work on Single Sign on?

Question

I am trying to implement Single Sign On feature(SSO). I have for now three systems that needs this feature. This SSO is relatively new to me, I have done SSO where the domain is same. There browser is no barrier so it works. So with few research i found this good article on auth0.com. https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/

The explaination is quite straight forward. Client domains asks for authorization from auth servers which in turn sends token back to the client domain for storing in the browser.

As per my understanding:

When domain1 request for authentication to auth server, the auth server will validate the request and if successful, send auth token to domain1. Auth server will also store the token in browser? Now when domain2 ask for authorization if a token already exists then auth server will return the existing token to domain2.

If so, what is the amount of time the auth server needs to be holding the token? Doesn't the token stored in auth server be invalid after sometime? How is it refreshed?

Am i missing something?

I am trying to do this on ASP.NET, but any other language should not be a barrier for answer here I think.

Answer 1

Auth server will also store the token in browser?

In short, yes. Browser cookie and local storage is sandboxed by website. So by default domain2 cannot use domain1's token. So during the process of authentication, the browser has to redirect to the auth server's website. The auth server does the authentication or just retrieves the last auth token from browser storage. Once the token is issued, the auth server will redirect back to the requesting domain with the auth token as part of the redirect request.

In other words, domain1 and domain2 can't share a token from browser storage, so the auth server acts as a trusted intermediary and passes the token between the sites.

If so, what is the amount of time the auth server needs to be holding the token?

The auth server itself probably does not hold a copy of the token, if we are talking about JWT. Your browser may keep it in a cookie or local storage, and that is subject to the browser's storage policies. Since auth tokens are cryptographically signed, it is not necessary for the server itself to keep a copy of them. Instead, tokens include a crypto signature that can be validated as genuine without consulting the auth server. Otherwise, the auth server becomes a bottleneck. Once the token is validated, then the contents can be trusted. The token contents include things like:

• when the token expires
• who requested the token
• what operations are allowed

If the token data is changed, the signature will no longer match the token contents, and requests using an invalid token will be rejected.

Doesn't the token stored in auth server be invalid after sometime?

The token has an expiration inside it. The client can examine this expiration as well as the server and if the expiration has passed, the client can redirect back to a login. If the client attempts to use the expired token, then the server will just reject the request.

How is it refreshed?

Partially or fully trusted clients can make use of Refresh Tokens. These are different from the access tokens which were previously described. They do not grant access to resources. Instead, they grant the client the ability to ask the auth server for a new access token without forcing the user to reauthenticate.

The process generally goes:

• Client starts to make an API request, examines access token
• Access token found to be expired
• Client sends Refresh Token to auth server, requesting new access token
• Client is provided a new access token
• Client sends API request with new access token

Refresh tokens can be requested when the user authenticates. Refresh tokens generally have a long expire time, but the access tokens issued from them have a short expire time. This allows the server the opportunity to revoke permissions and have that reflected in the next-issued access token.

Answer 2

As @Harry Ninh said in the comments the token expiration tends to be a matter of your needs, most systems will let you configure this and its duration may be anything between a couple of minutes and forever. Also most systems have a token refresh method: it can be automatically after any use of the token, considering the expiration time of the token from the last time it was used or it can be an explicit token refresh method. If I had to choose I'll go for the first method, but that's just an opinion.

Also, most systems also have a token revocation method that can be invoked to immediately invalidate the token.

Answer 3

If so, what is the amount of time the auth server needs to be holding the token?

This depends entirely on what token implementation you are going for. JWTs for an example are stateless and do not need any information stored on a server in their most basic implementation. With a stateful token I'd recommend holding it for slightly longer than the duration of the token to make sure you always can match a still valid token.

If a token has been revoked, either through a revocation method or due to it having expired, you can safely remove this token from the server storing it as this would mean it cannot be used for authorization anymore.

Doesn't the token stored in auth server be invalid after sometime?

It does, all solutions I've looked at have contained a timestamp saying when the token expires. At this point the token is no longer valid for authorizing the user.

How is it refreshed?

This depends on your implementation; as @Zalomon mentioned a common way is to implement a token refresh method. This typically generates a new token, using an existing one for authorization, and sending the new token back to replace the old.

Another way is obviously to expire a user's session with the token and force them to log in again

Answer 4

Think of the Auth Server as a completely normal website which has some completely standard way of authenticating users, for example:

• Its got a database of usernames and passwords
• It uses NTLM / Kerberos auth
• etc...

Like any other standard website, if someone logs in with a username and password you probably want some sort of cookie to remember that user on future requests, and like any other website the expiration etc... of that cookie will depend on requirements (e.g. 20 minute sliding session, 3 month persistent cookie)

The SSO / auth token stuff only kicks in when domain1 gets involved and wants to be able to piggy back on the Auth Servers authentication mechanism. The purpose of the auth token is to let Auth Server communicate to domain1 who the authenticated user is in a secure way.

Auth Server will also store the token in browser?

It if it wants to, but it doesn't need to - any mechanism (e.g. a cookie) that lets the Auth Server track the authenticated user is fine, e.g. in the case of Windows auth every request is authenticated. As long as the auth server knows who is authenticated, it can create auth tokens whenever it likes so it doesn't need to store the tokens themselves.

Note that domain1 also doesn't have to save the token either - it can do, and its a pretty common thing to do, but it would be just as valid to write a standard ASP.Net cookie with the same expiry time and username as the auth token. Once domain1 knows who the authenticated user is, the auth token has served its purpose.

How is it refreshed?

Typically the Auth Server will issue tokens that expire before its own cookies do, for example suppose your Auth Server keeps users logged in for 7 days, it might want to issue tokens that last for say 12 hours. The scenario might look a bit like this

• On Monday morning User goes to domain1 and logs in via Auth Server. Auth Server writes a cookie that lasts 7 days and sends domain1 a token that expires in 12 hours. domain1 also saves a cookie, but this one lasts 12 hours. This means the user can continue to use domain1 for the rest of the day.
• On Tuesday User goes back to domain1 and the cookie for domain1 is gone so they get directed onto the Auth Server, but the 7 day token from the Auth Server is still there so the user is logged straight in and an auth token sent straight back to domain1 - all the user sees is the page refresh itself a couple of times.

So the "refresh mechanism" for domain1 is just to authenticate against the Auth Server again. If the token duration is short and the "flicker" of the page refreshing is undesirable, you can use tricks like doing this process in a hidden iframe.

Note that Auth Server has a chance to write new cookies whenever the user visits that domain (remember, its just a normal website). This means that the Auth Server can also "refresh" its session e.g. making the 7 day expiry a rolling 7 day expiry.

Answer 5

A bearer token/JWT/SAML assertion/other artifact used in an SSO system represents a verified, verifiable, authoritative claim of right of a specific user, with temporary duration. JWT have an expiry time (e.g. expires_in = 3600 seconds), whereas a SAML assertion has an expiry time stamp (e.g. Not on or after = 2017-06-20 11:38:01).

Aside from that, everything is very general. The claim of right could be anything-- membership in a role, access to a resource, etc.

Two general approaches

There are two ways I have seen this sort of mechanism used in an authentication context:

1. The assertion/token/artifact represents the right to access a system.

In this case, the auth server's token essentially has a long-ish duration (say, 20-40 minutes), and acts as a multi-domain session cookie. When it is close to expiration, you'd have to go back to the auth server to get it "refreshed" or "renewed," and you may end up getting a brand new token as a result.

In some systems, the refresh operation requires a round trip to the auth server in the browser itself. In others, it can be accomplished via web service on the back end. The latter is less "pure" of an implementation (ideally, only the auth server should be able to give out tokens) but in certain circumstances it is necessary to keep things cleaner for the end user-- it can be very disruptive to take the browser somewhere else, even temporarily.

2. The token represents the right to initiate access to a system

In this case, the auth server issues a token of relatively short duration (say, 60 seconds), and the domain server uses this token as sort of a password in its own session management mechanism. The domain server would then issue its own session cookie, and the auth server's token would no longer be needed. The domain server would be responsible for refreshing any session cookies itself, which is usually very trivial because that sort of thing is built into web platforms, e.g. ASP.NET forms authentication.

The down side of this approach is that it is not quite a true SSO... you cannot seamlessly navigate from domain to domain without going back to the auth server to get a new token to initiate a new domain-specific session. But the up side is that it is much simpler to implement.

So... do you need to refresh?

Yes, but depending on the way you have things architected, you might be refreshing the token issued by the auth server, or you may be refreshing a token that the domain server owns, the latter of which is trivial.

Answer 6

There's another way to do this that doesn't require the "middle-man" auth server, as long as domain1 and domain2 trust each other. You can use public key cryptography or a shared secret of your choosing to sign JWT Bearer tokens, and use those tokens to obtain an access token for the other domain.

I daresay that including the middle-man auth server is overkill for a lot of systems. You should, as a general practice, maximize the amount of work not done.