Identity Provider Overview

Un Fournisseur d'Identité (Identity Provider ou IdP) Persona  est un domaine qui enregistre et certifie directement l'identité de ses utilisateurs. Parce que les identités de Persona sont basées sur les adresses email, tous domaine offrant des emails à leurs utilisateurs peut simplement devenir un IdP.

Si vous avez un nom de domaine, vous pouvez devenir un IdP Persona en implémentant un support pour le protocole BrowserID.

If you have a domain name, you can become a Persona IdP by implementing support for the underlying BrowserID protocol.

Le document support IdP

Domains advertise their ability to act as IdPs by publishing a support document at /.well-known/browserid. This JSON-formatted document contains three values:

• public-key: The public part of the domain's cryptographic key.
• authentication: The domain's page for asking users to log in.
• provisioning: The domain's page for certifying its users' identities.

Websites use the public-key to verify the authenticity of users' identity assertions.

Browsers use the authentication and provisioning values to obtain certification of their user's identity.

For more information, including how domains can delegate to other IdPs, see the /.well-known/browserid documentation.

Comment le navigateur interagit-t-il avec les IdPs ?

Pour montrer l'interaction entre les Navigateurs et les IdPs, nous allons regarder ce qui doit se passer la première fois que [email protected] essaie de se connecter à un site en utilisant Persona.

1. Le navigateur d'alice récupère le document support à l'url https://example.com/.well-known/browserid.
2. Alice's browser invisibly loads the provisioning page for example.com and asks it to sign a public key certifying Alice's identity.
3. Before signing the key, example.com needs proof that the user really is Alice, so it tells the browser that she needs to authenticate.
4. Alice's browser shows Alice the authentication page for example.com and she signs in, establishing a new session at example.com.
5. Alice's browser reloads the provisioning page and again asks it to sign a public key certifying Alice's identity.
6. The provisioning page can verify Alice's identity by inspecting the new session. Satisfied, it signs a certificate containing Alice's public key, her email address, and an expiration date for the certificate.

For the duration of the signed certificate, Alice's browser can create valid identity assertions for [email protected] whenever she wants to log into a web site with Persona.

Steps 3-5 can be skipped if Alice already has a valid session with example.com, for example, from logging into her webmail or an intranet portal.

Comment les Sites Web interagissent avec les IdPs ?

Let's say Alice wants to sign in to 123done.org. Her browser would generate and sign an identity assertion containing the certificate from above and present it as proof of her identity.

By comparing Alice's signature on the identity assertion with the public key inside the signed certificate, 123done can be confident that the certificate was issued to the same person that generated the identity assertion. However, 123done still needs to check that the certificate itself is valid by examining its signature.

Because the certificate was issued for [email protected], 123done fetches the support document from https://example.com/.well-known/browserid. It then extracts the public-key and compares that to the signature on Alice's certificate. If the key matches the signature, 123done knows that the certificate is legitimate and can finish logging Alice in.

Note that 123done never "phoned home" or otherwise revealed Alice's identity when she logged in. Rather, it only needed to request a single, cacheable document from example.com.

Security and trust

The BrowserID protocol, and thus Persona, are built on standard public key crytography techniques.

Feel free to explore our documentation on the cryptographic concepts behind how a Persona IdP works or read more detail on how IdPs are implemented.