Single sign-on · signed XML tokens · ezxmldsig

Log in once.
Watch every hop.

Three sites on three host names: idp, the identity provider, which alone knows the passwords, and two applications, mail and crm, which trust the tokens idp signs with ezxmldsig. The trace on the right shows each hop, each token and each check.

1. Open mail.sso.wbcdr.dev: it has no session, so it sends you to idp.
2. Log in on idp. idp signs a token for mail, and your browser posts it to mail.
3. mail verifies the token and opens its own session.
4. Open crm.sso.wbcdr.dev: idp recognizes you and signs a token for crm, without asking for your password again. That is single sign-on.
5. Rights: log out of idp, then log in as another user. idp signs no token for crm to bjorn, who may only enter mail: idp decides who enters which application. In crm, lagertha, a Shieldmaiden, may read the customers but not delete them: crm decides, from the role idp wrote in the token.

Start with mail.sso.wbcdr.dev

For a single sign-on in production, prefer a standard, OpenID Connect or SAML, with a maintained library: this demo shows the mechanisms, and what a receiver must check. The keys of demo/certs/ and demo-sso/certs/ it uses are public: never trust them outside this demo.