Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

CAS and its alternatives all seem to require a flow like this when one service is acting as a proxy for a user when accessing a back-end service:

Service A makes a request to Service B on behalf of a user. The request includes a perishable token (proxy ticket) from the authentication server. Service B forwards the token to the authentication server, asking if it's valid.

It seems like it could be more efficient to have the authentication server sign the ticket, and have Service B know the server's public key so that it can validate the ticket on its own, with no need for the extra request. Obviously any single-sign-out functionality would have to be left to Service A, but otherwise this seems like all-upside: it's more robust in the face of network latency or the auth server going down, and it's even harder to brute-force than a random token.

Are there downsides or risks that I'm missing? Has anybody actually implemented this?

share|improve this question

To some extent, what you suggest exists: it is called X.509 certificates.

The main problems with signed tokens are:

  • Control latency: once a token has been signed, it cannot be promptly canceled; you have to wait for expiration of the token. Or you implement an online revocation check (which is called OCSP in the case of X.509 certificates), which brings you back to the "online authentication server" model.

  • Clock synchronization: to enforce an expiry date, a verifier must have a reasonably accurate clock, which can be a challenge in a security context. Indeed, modern operating systems know NTP out of the box, but NTP is not protected.

  • Signed tokens to authentication, not authorization. The B server wants to be sure that it is talking to the right client, but also wants to know whether that client is allowed to access the service. It is not easy to fit a generic authorization matrix inside a signed token. About everybody who tried to work with X.509 certificates tried to use them for authorization, and regretted it.

With an online authentication server, that both A and B talk to, that authentication server can act as a big kill switch, with immediate cancellation and also possible fine-grained authorization control.

share|improve this answer

If I'm understanding your example correctly, it sounds like you are talking about applying something like Kerberos to SSO. As long as the service provider knows how to trust the ticket granting authentication server, then yes, it should be secure.

As to why it is not done that way, I think it may be to provide greater control of information and keep it up to date. When the service provider actually requests details about the user from the service itself, you can update information in one place and have it reflected throughout multiple systems.

If I said I'm AJ Henderson and had Facebook sign something saying I was AJ Henderson, but then I changed my name to Bilbow Bagins, the signed information wouldn't get the update, but the token linking my account would be able to get updates. It also doesn't have to worry about things like expiration on signatures since every check is done fresh. This means more exchanges are necessary, but also gives tighter control.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.