Single sign-on and login with an external provider

Objectives

By the end of the lesson, you can explain what SSO and login with an external provider mean, how a shared identity provider differs from a shared session, and why neither solves local authorization automatically.

Why don't we want a separate password everywhere?

If a university uses several systems (a course system, a library, a study administration system), and each asks for its own password, the student manages many passwords, which leads to weak and reused passwords. Each of the systems would have to protect the passwords separately and handle forgotten passwords. The solution is a shared identity provider: one central place vouches for the user, and the other systems rely on it. SSO (Single Sign-On) aims at the user experience in which an identity proven once can be used to enter several connected applications.

University portal, library, and course system

The student would first log in to the course system. The system directs them to the university identity provider, where they prove themselves. The identity provider returns a result, and the course system creates its own session (7.2). Later the student goes to the library system. That too turns to the same identity provider; if the user still has a valid login state there, they can continue without typing a password again.

sequenceDiagram
    participant H as Student
    participant K as Course application
    participant I as Identity provider
    participant L as Library application
    H->>K: Login
    K->>I: Redirect for authentication
    I-->>K: Authentication result
    H->>L: Open the library
    L->>I: Request authentication
    I-->>L: Result, without typing a password again

The diagram is a conceptual SSO flow. It does not mean that the two applications read each other's cookies. Both are in contact with the shared identity provider, and each can maintain its own separate session. If the central login has expired or further checking is needed, the student must prove themselves again.

What does SSO provide?

• Fewer password entries, identity checking organized in a central place (password policy, multi-factor authentication in one place).
• The user can manage their access in one place.
• It does not necessarily mean a single session shared by all applications. The course system and the library may also use their own access rules, session durations, and logout behavior. The identity provider helps establish who the user is; the local system decides what they may do.

The price of SSO is dependency: if the central identity provider is unavailable, new logins are blocked. Shared identification is also significant from a security point of view, so special attention must be paid to protecting authentication and the session (8.4).

Login with an external provider

A website can offer that the user log in at the identity provider of another organization. The user reaches the provider by redirection, proves themselves there, and then the application receives verifiable identity information. The standard framework for this is OpenID Connect (7.5): Kurzuspont learns the user's identifier (sub) and the issuer (iss) from the ID token. The local application then attaches its own user record and session to the identity.

It is important that the external identifier of the user (issuer + sub) can be the key of the link, not, for example, the email address: an email address can change, and is not verified at every provider. The local system must therefore keep its own user record, to which the external identifier is linked.

The external provider does not automatically get rights over the application's data, and the application does not learn the user's external password either: in the standard redirect-based flow the password stays with the provider. At the same time, the user needs to know which provider they are being directed to, what data the application receives, and how the external identity is linked to their local account. Data-handling questions need separate consideration (9.6).

Login, logout, access

After a successful login at the identity provider, the course system must still check its own API requests (7.4): a student cannot edit an instructor's course merely because the shared login succeeded. Nor does logout always terminate every central and local session with a single button; the exact experience depends on the agreement of the systems. The interface must therefore clearly show which application we logged out of, and whether we also logged out of the central provider.

flowchart TD
    K[Central identity: who is the user?] --> A1[Course system: own session and authorizations]
    K --> A2[Library: own session and authorizations]
    K --> A3[Study administration: own session and authorizations]

Worked example: logging in to Kurzuspont

Step	What happens?
1.	The student clicks the "Log in with the university identifier" button.
2.	Kurzuspont redirects to the university identity provider (OIDC, authorization code + PKCE).
3.	At the university provider the student logs in (password + second factor).
4.	Kurzuspont receives an ID token and checks the issuer, the audience, the expiry, and the signature.
5.	Based on the (iss, sub) pair, Kurzuspont finds or creates the local user record.
6.	Kurzuspont issues its own session cookie, and from here on decides according to its own authorization rules (7.4).
7.	Later, in the library, the student gets in without a new password, because their login at the university provider is still valid.

Steps 4–6 follow the same pattern as a non-external login: after identification the rules of the local system apply.

Common misconceptions

Statement	Clarification
"With SSO the applications use each other's cookies."	They rely on a shared identity provider, with their own sessions.
"Single sign-on = the same authorization in every application."	Local authorizations are separate decisions.
"With external login the application receives the external password."	In the standard redirect-based flow the password stays with the provider.
"One logout certainly ends every session."	The lifetimes of central and local sessions can differ.
"It is enough to use the email address to identify an external account."	The issuer and the sub are the reliable identifier; an email can change.

In brief

• SSO lets in to several applications with a single proof; in the background there is a shared identity provider, and the applications have their own sessions.
• When logging in with an external provider, OpenID Connect typically supplies the verified identity.
• Local authorization and session remain the responsibility of the local system.
• The advantage of SSO is fewer passwords, its price is dependency on the central provider.

Review questions

1. Why does SSO not mean that two applications share their session?
2. Why is it better to use the external identifier (iss + sub) instead of the email address?
3. What do we gain and what do we risk with SSO?
4. Why is a central logout not enough to terminate the local session?

Learning resources

• OpenID Connect Core 1.0 — the ID token and identification; advanced reading.
• HTTP authentication (MDN) — the basics of HTTP authentication.