Authentication Libraries & SSO: Optional Background
So far, our notes example has used a password to establish a local account and session. What would change if the user signed in through an identity provider? The source of authentication would change, while our application would still decide which notes the account may access.
Authentication library responsibilities
We have worked with the public interfaces of credential and session services. A maintained authentication library can provide credential storage, sessions, recovery and provider integration. The application still needs correct configuration, updates, account mapping and permission checks.
Before choosing a library, check its runtime and framework compatibility, maintenance, security model, migration behavior and deployment requirements.
OAuth and OpenID Connect
OAuth supports delegated access: a user can authorize an application to access selected resources on another service, such as letting a scheduling application read a calendar. The application presents an access token when requesting those resources.
OpenID Connect (OIDC) adds authentication to OAuth 2.0: its ID token lets the application, called the OIDC client, verify information about the user’s sign-in. An API access token is not automatically an identity proof for another application.
Single sign-on (SSO) lets a person use an existing identity-provider login to sign in to multiple applications, subject to the provider’s policy. Each application still establishes its own session and permissions; logging out of one application does not necessarily end the provider session or the other applications’ sessions.
The callback is the application endpoint where the provider sends the browser after login. In the authorization-code flow, it receives a short-lived authorization code that the application exchanges with the provider for tokens. The issuer identifies the provider; the subject is that provider’s identifier for the user.
Let’s follow a provider login back to the notes application. Figure 1 traces verification, local account mapping and a later permission check. A maintained OIDC library performs the protocol checks defined in the OpenID Connect Core specification.
The library verifies that the login information came from the expected provider, is intended for this application, has not expired and belongs to the login the browser started. It also handles the checks needed to exchange the code safely. The application must wait for these checks before trusting the identity.
Map provider identities to local accounts
Our note ownership rule uses a local account ID. To reach that account after a provider login, store the verified issuer and subject together to identify the provider account.
| Verified issuer | Verified subject | Local account |
|---|---|---|
https://identity.example.test | reader-42 | 7 |
https://partner.example.test | reader-42 | 19 |
Compare the two rows: does the matching subject text identify one account?
Here, reader-42 belongs to two different issuer/subject pairs and maps to two
local accounts. Linking those accounts needs an explicit policy; matching email
text alone is insufficient. The table assumes the OIDC library has already
verified the login response.
Keep provider secrets on the server
A confidential client can keep
its credentials private, for example by storing them on a server. Code and
configuration delivered to a browser can be inspected by the user. Keep provider
client secrets out of VITE_ configuration and browser bundles.
When separate servers handle login and application data
If one server handles login and another owns application data, the data API needs a trusted way to resolve the user’s session. A caller-supplied account ID does not prove a login. The API still checks permission for each operation.
Local and provider-based login
| Responsibility | Local credential implementation | Provider-based login |
|---|---|---|
| Verify the person’s credential | Application’s maintained password/auth library | Identity provider |
| Check the external login response | No external response | Application’s maintained OIDC library |
| Establish the local account and session | Application | Application, after verified identity mapping |
| Decide who may read a private note | Application’s resource policy | Same application policy |
Whether we verify a password locally or use a provider, a later note edit still needs a current application session and the same permission checks. Next, we will return to those shared rules and test allowed and denied operations.
Check Your Understanding
- How do OAuth’s delegated access and OpenID Connect’s authentication differ?
- After a provider response is verified, how does the application identify the local account and decide its permissions?
- Why can a confidential-client secret not be kept in browser-delivered configuration?