How has identify management evolved over the years?

Your thoughts?

BuiltOnJavaScript |

Originally, applications handled authentication individually. This means they would have their own database or repository where they managed user credentials themselves. This was super inconvenient when it came to propagating user changes across the different apps. If you updated your password in one application, you also had to update it in every other application...not good.

This led to the use of centralized user repositories or directory services. A good example would be LDAP where a user's credentials are centrally managed in an application. The issue with this is that there is no session management with directory services. A user may have a single username/password but they still need to enter it for each application they access. Not only does this expose the user's password to each application it enters, it also makes it really hard to integrate with cloud services using this directory based approach.

Then came single sign on servers (SSO). These servers manage a users identity by holding the session or state of their authentication. This is great because a user can use a single authentication across different applications without repeatedly logging in to each application and exposing a password everywhere. The downside with SSO is it can be tough to implement and is usually reserved for an enterprise environment. Also, since cookies are domain specific, there are limitations to what a user can access with a SSO server..aka they can't access a bunch of third party SaSS applications with a traditional SSO server...

As the popularity of SaSS apps grew, SSO servers became increasingly limited.This led to the development of the Security Assertion Markup Language (SAML). Originally released in 2005, SAML provided a protocol for web based single sign on. With a single set of creds, enterprise users could securely access different domains with the same auth. SAML worked by interfacing with identity providers which linked corporate logins with other platforms. While SAML solved the cross domain auth problem, it didn't solve the authorization issue...

WS-Fed and OpenId take SAML a step further by providing authorized access across different domains.

Then came along OAuth protocol. This user-centric approach allowed users to authorized sites to use their information from other sites WITHOUT exposing their log in credentials. For example, authorizing Twitter to display your feed on another site uses OAuth protocol.

An improvement on top of OAuth can be found in OpenID Connect (OIDC). OIDC is built on top of OAuth 2.0 and provides a standardized way of communicating user identity to applications.

Enginears |

OAuth 2.0 and OIDC BLEW UP with the advent of social media. Before this, enterprise environments excelled at cross-domain, federated identity management.

This was great, but it didn't exactly bode well for the common user who just wanted to share pics from FaceBook on another site.