Single-Sign-On is a common way for larger organizations to keep users and logins manageable at scale, while also making logins easier for employees and users. But the standards that enable modern SSO are often mixed up, leading to confusion. This is not a technical guide to implementing either standard, but rather a high-level overview of what each does, and how they interact.
Confusion is inevitable
When using modern Single-Sign-On (SSO) logins, you often have a central identity provider like Authentik or FreeIPA+KeyCloak that handle central user storage and federated logins. Typically, multi factor authentication like one-time passwords are combined for an added layer of security.
When diving into the topic, you may not be aware that this seemingly combined workflow actually consists of three different components, each designed to solve a different problem in the larger picture. It also doesn't help that OATH and OAuth look almost identical, and that the difference between authentication and authorization isn't immediately obvious.
OATH enables 2FA
OATH stands for "Initiative for Open Authentication" and is a standard for one-time passwords, either hardware/hmac based (HOTP) or time-based (TOTP). It works by pre-sharing a secret key with a different device during setup, then using that second device to compute a OTP (one-time password) when logging into an account. This mechanism ensures that a stolen username+password does not lead to compromised accounts, since you need the secondary device to gain access.
TOTP is the most common implementation for one time passwords because it is easier and does not require special hardware. It simply uses the pre-shared secret key to compute a small number sequence that is valid for only a few seconds (typically around 30). Both the 2-factor device and the server you are logging into have the pre-shared key and can compute the same keys for the same time window without talking to each other.
Since generating TOTPs relies on the current time, both devices must be properly synced to a timeserver; if their internal clocks are too far apart (a few seconds are enough), the entire process fails.
HOTP also uses a pre-shared secret key, but relies in an internal counter instead of the current time, making it immune to time drift. Every time an OTP is generated, it increases the internal counter, which is used to generate the OTP. Unfortunately, this will also mean that you cannot easily keep a backup of the secret key since you also need the latest counter value, making this approach only useful in highly-secured environments with break-glass fallback mechanisms that can afford to rely on hardware keys that will fail and lock you out eventually.
The primary advantage of OATH is that, once configured, the secondary authentication device and the real login server never need to talk to one another again, so the OTP mechanism remains working even when offline or in air-gapped environments, and network-based attacks are pointless against it - the only real threats that remain are exposure or loss of the secret key.
OAuth grants access to resources
The OAuth standard refers to "Open Authorization" (NOT authentication!), and is typically implemented as the latest OAuth2.0 specification. It is an access mechanism that provides access to resources using a user's login, no matter what that resource is. It could be an API server, an entire user session on some remote service or just an image file sitting on a protected webserver.
OAuth does not care what it grants access to, as long as the user credentials are correct.
It works by forwarding the authorization request to an authorization server like Keycloak, returning a temporary authorization code on successful login. This code is passed to the OAuth client, which exchanges it for an access token (which remains on the server hosting the OAuth client, often the same as the resource server). The token can then be used to access the protected resource.
The token itself is often a signed JWT, but it could theoretically be any string, like randomly generated bytes encoded as hex.
OpenID Connect (OIDC) enables SSO
The OIDC (OpenID Connect) standard builds on top of OAuth2.0 to provide the full SSO (Single-Sign-On) experience. It defines a standardized "identity" resource and uses OAuth to let users grant applications access to it. The identity resource is practically just an ID token with some added fields called "claims" with identity information (name, email etc), as well as a expiration and refresh mechanism. Modern SSO providers will typically extend this with custom claim fields like "groups" to automatically assign users to the correct groups on external services after they complete SSO, to further automate user permissions.
One login may involve them all
When you see a "sign in with ..." button on a login page, you are almost always using OIDC, which uses OAuth under the hood. If you enabled OTP based 2FA for your account, that will trigger OATH, making it look like one big login workflow - but the different mechanisms are not actually bound to one another like that.
You get one-time passwords from OATH, access delegation from OAuth and identity information from OIDC.