Single Sign-On Demystified: Security Considerations for Developers and Users

Conference paper
Part of the Advances in Intelligent Systems and Computing book series (AISC, volume 746)

Abstract

A website of an entity (organization or enterprise) usually provides multiple services to its members. Once a user of the entity signs-on for a service, she can access all services available to her. This is known as single sign-on (SSO). For implementation of SSO, user authentication is separated, at least logically, from services. An identity provider (IDP) authenticates a user and a service provider (SP) delivers each service. Thus, a user has an active IDP session, and one active service session for each SP she is accessing. While SSO eases the life of users and system-administrators, if SSO not implemented carefully, a user may sign-out from all services but still may have an active IDP session, and users might not be aware of existence of the active IDP sessions. In this work, we use state-transition diagrams to trace the steps during a SSO activity, and then show the states that a user’s browser may maintain. We show that even after a user signs-out or timed-out from all service sessions or the IDP server session, active sessions may exist that the user maybe unaware of. This situation may happen because implementer never thought of this possibility or the user is unaware of such possibility or both. We propose some possible remedies to mitigate undesirable information-security situations we have exposed.

Keywords

Single sign-on Authentication Authorization Security Identity Provider Service Provider 

References

  1. 1.
    Beltran, V.: Characterization of web single sign-on protocols. IEEE Commun. Mag. 54(7), 24–30 (2016).  https://doi.org/10.1109/MCOM.2016.7514160CrossRefGoogle Scholar
  2. 2.
    Beltran, V., Skarmeta, A.F.: An overview on delegated authorization for CoAP: authentication and authorization for constrained environments (ACE). In: 2016 IEEE 3rd World Forum on Internet of Things (WF-IoT), pp. 706–710 (2016).  https://doi.org/10.1109/WF-IoT.2016.7845482
  3. 3.
    Clercq, J.D.: Single sign-on architectures. In: Proceedings of the International Conference on Infrastructure Security, InfraSec 2002, pp. 40–58. Springer, London (2002). http://dl.acm.org/citation.cfm?id=647333.722879
  4. 4.
    Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Longman Publishing Co., Inc., Reading (1995)MATHGoogle Scholar
  5. 5.
    Hardt, D.: The OAuth 2.0 authorization framework, RFC 6749. Internet Engineering Task Force (2012). https://tools.ietf.org/html/rfc6749
  6. 6.
    Kemp, J., Cantor, S., Mishra, P., Philpott, R., Maler, E.: Assertions and protocols for the OASIS security assertion markup language (SAML) v2.0. OASIS (2015). http://saml.xml.org/saml-specifications
  7. 7.
    OWASP Foundation: Session timeout. OWASP Foundation (2012). https://www.owasp.org/index.php/Session_Timeout
  8. 8.
    Sun, S.T., Pospisil, E., Muslukhov, I., Dindar, N., Hawkey, K., Beznosov, K.: What makes users refuse web single sign-on?: an empirical investigation of openid. In: Proceedings of the Seventh Symposium on Usable Privacy and Security, SOUPS 2011, pp. 4:1–4:20. ACM (2011).  https://doi.org/10.1145/2078827.2078833
  9. 9.
    Wang, H., Zhang, Y., Li, J., Gu, D.: The achilles heel of OAuth: a multi-platform study of OAuth-based authentication. In: Proceedings of the 32nd Annual Conference on Computer Security Applications, ACSAC 2016, pp. 167–176. ACM, New York (2016).  https://doi.org/10.1145/2991079.2991105

Copyright information

© Springer International Publishing AG, part of Springer Nature 2018

Authors and Affiliations

  1. 1.University of MiamiCoral GablesUSA

Personalised recommendations