Demo instance — all content is sample, fictional data.
Help topics

How-to

Configuring Institutional Sign-In

Turning on OpenID Connect sign-in with the institution's identity provider and setting the allowed e-mail domains and the opening of new accounts.

Permission needed
Manage site settings and feature flags, Create, disable and verify user accounts
Changed in
1.9.7

Institutional sign-in works with Microsoft Entra ID, Google Workspace, Keycloak or any other identity provider that supports OpenID Connect. It is off by default. While it is on, the Sign in with your institution account button appears on the sign-in screen, and the person signs in to the account that has the same e-mail address. Upper and lower case in the addresses do not matter.

Registering the application at the provider

  1. On the Administration → Site settings screen, open the Integrations tab.
  2. On the Institutional sign-in (OIDC) card, copy the Redirect URI address.
  3. Register a web application at the identity provider and add this address to the application's redirect URIs.

The openid, email and profile scopes are enough. In Microsoft Entra ID, add the optional email claim to the ID token. If the provider does not send the e-mail address, nobody can sign in.

Settings on the card

  1. In the Issuer URL field, enter the provider's https address.
  2. Fill in the Client ID and Client secret fields.
  3. If you want only institutional addresses to sign in, enter the domains in the Allowed e-mail domains field, for example universite.edu.tr.
  4. If you want accounts to be opened for institution staff who have no account, turn on the Create accounts for the allowed domains switch.
  5. If you want to change the name of the button on the sign-in screen, fill in the Turkish and English Button label fields.
  6. Press the card's Save button.
  7. Press Test the connection.
  8. If the test succeeds, turn on the Allow sign-in with the institution account switch.
  9. Press Save again.

As the issuer URL, enter the https address at which the provider publishes its /.well-known/openid-configuration document. The table gives examples for common providers.

Provider Example issuer URL
Microsoft Entra ID https://login.microsoftonline.com/<tenant ID>/v2.0
Google Workspace https://accounts.google.com
Keycloak https://sso.kurum.edu.tr/realms/<realm>

Test the connection reads the provider's document and signing keys. The client secret is tested only by a real sign-in. The test uses the saved settings, and the button is off while there are unsaved changes. If the test fails, the reason appears next to the button, for example that the provider names another address or that the document could not be fetched. The client secret is stored encrypted and is never shown again. If you leave the field empty and save, the stored secret is kept. The Remove the saved secret option deletes the secret. When you turn the switch off and save, the button disappears and institutional sign-in stops at once.

The line at the top of the card shows whether institutional sign-in is on and how many accounts are linked to an institution account.

Allowed domains

  • If the list is filled in, only addresses in these domains sign in with an institution account.
  • If the provider never reports whether the e-mail address is verified, addresses in these domains count as verified. Microsoft Entra ID does not send this information.
  • If the provider explicitly reports that the address is not verified, sign-in is always refused.
  • If the list is empty, any address that the provider calls verified can sign in.

Opening new accounts

Create accounts for the allowed domains is off by default. While it is off, only people who have an account in the system sign in. While it is on, a new person from an allowed domain gets a Registered researcher account with a verified e-mail address and no password. The account is opened even if the New account registration flag is off, and the person is asked to accept the privacy notice under KVKK (Türkiye's Personal Data Protection Law). You must enter at least one domain to turn this switch on.

Rules applied at sign-in

  • Disabled and locked accounts cannot sign in.
  • Accounts with two-factor authentication turned on are still asked for the code.
  • An account whose e-mail address was never verified is activated by institutional sign-in. A password set before the address was proved is deleted, and the account's other sessions are closed. If the person wants a password, they set a new one with the Forgot your password? link on the sign-in screen.
  • The first institutional sign-in of an account is reported to the person by e-mail.
  • Every sign-in, opened account, refusal and error is written to the audit log with only a reason code.

At the first sign-in, the ID that the provider gives the person is stored in the account. The Institutional sign-in row on the Profile details card of the user page shows the date of the link.

A sign-in with the same address from another account at the provider is refused, because the institution may have given the address to someone else. If the person's account at the institution was re-created and you are sure it is the same person, press Remove the link on this row. The next institutional sign-in links the account again.

How the person signs in with their institution account is described in Signing in with Your Institution Account.

Was this page helpful?