Single sign-on or SSO
is an authentication concept that allows
users to authenticate once to be granted
access to a lot of different services and applications.
Since re-authentication for each service isn't needed,
users don't need multiple sets of usernames and
passwords across a mix of applications and services.
SSO is accomplished by authenticating
to a central authentication server,
like an LDAP server.
This then provides a cookie or token that can be used to
get access to applications configured to use SSO.
Kerberos is actually a good example
of an SSO authentication service.
The user would authenticate
against the Kerberos service once,
which would then grant them a ticket-granting ticket.
This can then be presented to
the ticket-granting service in
place of traditional credentials.
The user can enter credentials once and
gain access to a variety of services.
SSO is really convenient.
It allows users to have one set of
credentials that grant access to lots of services,
making it less likely that passwords will
be written down or stored insecurely.
This should also reduce the overhead for
password assistance support and removes
time spent re-authenticating throughout the workday.
So what's the downside?
An attacker that manages to compromise an account
has a lot more access under an SSO scheme.
User credentials will grant
access to all applications and
services that that account is permitted to access.
A big plug here for using
multi-factor authentication in conjunction
with an SSO scheme.
But this opens a new channel of attack,
theft of SSO session cookies or tokens.
Instead of targeting credentials directly,
attackers can try to steal the SSO tokens directly,
which will permit wide access
if even for a short amount of time.
Stealing these tokens also lead to an attacker
dodge multi-factor authentication protections,
since the session token permits access without
requiring full authentication until a token expires.
An example of an SSO system is
the OpenID decentralized authentication system.
This is an open standard that allows
participating sites known as relying parties
to allow authentication of users
utilizing a third-party authentication service.
This allows sites to permit authentication without
requiring the site itself
to have authentication infrastructure,
which can be tricky to implement and maintain.
It also lets users access a site
without requiring them to create a new account,
simplifying access management across
a wide variety of sites.
Instead, a user just needs to
already have an account with an identity provider.
To ask for authentication, first,
the relying party looks up the OpenID provider,
then establishes a shared secret with
the provider if one doesn't already exist.
This shared secret will be used to
validate the OpenID provider messages.
Then the user will be redirected or asked to
authenticate in a new window through
the identities providers login flow.
Once authenticated, the user will be prompted to
confirm if they trust the relying party or not.
Once confirmed,
credentials are relayed to the relying party,
typically in the form of a token,
not actual user credentials,
which indicates the user is
now authenticated to the service.