SSO: signing students in with their school account
SAML or OIDC single sign-on, automatic attachment by email domain, existing accounts recovered: how toGaether's SSO works.
A student already has a school account: the one that opens their mailbox, their course area and the campus Wi-Fi. Asking them to create one more to sign up for a gala or join an association means one more password to forget and one more address to verify. Single sign-on (SSO) removes this step: the student signs in to toGaether with the account the school has already given them.
What the student sees
- On the sign-in page, they type their school address, for example
prenom.nom@eleve.votre-ecole.fr. - toGaether recognises the domain and offers to continue with the school account.
- They are redirected to the institution's sign-in page, authenticate as usual, then come back to toGaether, signed in.
At the first sign-in, their account is attached to the school automatically, with no manual validation by the administration. They immediately see the associations, events and spaces of their campus.
This recognition by domain has a technical name, Home Realm Discovery. It avoids displaying a row of "Sign in with…" buttons: the address is enough to know where to send the person.
SAML or OpenID Connect: two standards, the same result
toGaether accepts the two protocols used by almost all institutions:
| Protocol | Common identity providers |
|---|---|
| SAML 2.0 | Shibboleth, LemonLDAP::NG, ADFS, providers from academic federations |
| OpenID Connect | Microsoft Entra ID, Google Workspace, Okta, Keycloak |
In both cases, the principle is the same: the password is never entered on toGaether. The school authenticates the student, then sends a signed assertion that says "this person really is prenom.nom@…". toGaether checks the signature and opens the session.
The practical consequence for the IT department: its rules apply as they stand. Two-factor authentication, password policy, blocking an account: everything stays in the school's directory.
The attributes sent
toGaether needs only three pieces of information:
- the email address, used to find or create the account;
- the first name and the surname, so that the profile does not start empty.
No other attribute is required: the IT department can limit what it sends to these three.
Students who already had an account
This is the delicate point of any SSO roll-out on a platform already in use. A student who signed up last year with a password has an account, with their associations, their board roles and their tickets. When SSO is switched on, they must on no account end up with a second, empty account.
Yet directories do not always send the address in the form the student used to sign up: some send an identifier (abcd12345@…), others the prenom.nom@… address. toGaether relies on the email address signed by the directory to find the existing account and link the SSO identity to it. The student lands on their usual account, with all their history. The rule is simple: one person, one account.
The address typed by the student on the sign-in page, on the other hand, is never used for this link: anyone could type someone else's address. Only the information signed by the school counts.
On the phone too
The toGaether app for iPhone and Android uses the same sign-in: the student types their school address, goes through the institution's sign-in page, and comes back to the app.
And without SSO?
Not every school has an identity provider ready to be connected. In the meantime, the institution can declare its email domains: any student whose verified address belongs to one of these domains is attached to the school automatically. SSO can be added later, with no migration and no duplicate accounts.
Setting it up, in practice
The configuration is done with the IT department, in a few exchanges:
- the school sends us the metadata of its identity provider (SAML) or its issuer and a client ID (OIDC), along with the list of its email domains;
- we send back what needs to be declared on the directory side: the service identifier and the return URL;
- a test account is used to validate the whole journey before opening it to students.
A point of transparency: toGaether's authentication relies on Google Identity Platform, operated in the United States, whereas the platform's data is hosted in Paris. We set this out in the article on hosting.
To enable SSO at your institution, write to us and tell us which identity provider you use.
