SSO, OAuth 2.0 and OpenID Connect
How 'Sign in with Google' works, and the difference between authentication and authorisation.
On the roadmap:Beginner · step 3: Secure the basics
Lesson 7 of 23 · 9 min read · quiz · exercise
Two questions, two words
- Authentication: who are you?
- Authorisation: what are you allowed to do?
OAuth 2.0: delegated access
OAuth 2.0 lets a user give an app limited access to their data at another service, without sharing their password. Roles:
- Resource owner: the user.
- Client: the app asking for access.
- Authorization server: issues tokens (for example Google, GitHub).
- Resource server: the API holding the data.
The user grants specific scopes (for example "read my calendar"), and the client receives an access token that is limited to those scopes and expires.
The authorization code flow
Figure SDA-CORE-07-1 · Authorization code flow · © forcsguy.com
Important details:
- state: a random value you check on return, which stops attackers forging the callback (CSRF).
- PKCE: a one-time proof that the party exchanging the code is the one that started the flow. Use it for all clients, essential for mobile and single-page apps.
- Register exact redirect URIs and compare them strictly.
OpenID Connect: adding identity
OAuth alone says "this token may call the API", not "this is Jane". OpenID Connect (OIDC) adds an ID token (a signed JWT) with claims about the user: subject id, email, name. To sign someone in, validate the ID token's signature, issuer, audience and expiry.
SSO
With single sign-on, many applications trust one identity provider. The user signs in once; the provider vouches for them to each app. Enterprises use SAML or OIDC for this. Benefits: fewer passwords, central policies like MFA, and one place to revoke access when someone leaves.
Single sign-on means the second application never sees your password. It trusts the sign-in service you already used:
Figure SDA-CORE-07-2 · One sign-in, two applications · © forcsguy.com
Common mistakes
- Using the access token as proof of identity instead of validating an ID token.
- Skipping
stateor accepting any redirect URI. - Storing tokens somewhere scripts can read them.
- Requesting more scopes than the feature needs.
Related reading
- RFC 6749: The OAuth 2.0 Authorization FrameworkIETFDocumentation
- OAuth 2.0 OverviewOAuth Community · oauth.netDocumentation
- Introduction to JSON Web TokensAuth0 · jwt.ioDocumentation
- System Design 101ByteByteGo · ByteByteGoHqGitHub
Show 6 moreShow fewer
- OAuth Audit Toolbox at IndeedIndeed engineers · IndeedCase Studies
- The Architecture of Open Source ApplicationsVarious authors · aosabook.orgBooks
- Secret Detector: Preventing Secrets in Source Code at YelpYelp engineers · YelpCase Studies
- LevelDBGoogle · GitHubGitHub
- Garbage Collection in Go Application at TwitchTwitch engineers · TwitchCase Studies
- DevOps resource center - Azure DevOpsMicrosoft engineers · MicrosoftBlogs
Check your understanding
Question 1 of 3
0 correct so far
What is the difference between OAuth 2.0 and OpenID Connect?
Topics covered in this lesson
Try it: see a system in action
One tap in a real app already crosses a client, a server and a database. Watch it happen, then try scoping a brief a few different ways below.
The app
One tap, no password typed into this app at all
What just happened
Tap the button to send a real request.
One tap in the app sends a real request. Watch where it actually goes.
Go further: the Builder
Once you know what to ask, the Builder is where you turn requirements into an architecture. Come back to this once you've met a few more concepts.
Try it yourself
Your app adds 'Sign in with Google'. Describe the steps from the click to the user being logged in, and say what you should check on the way back.
Click what a strong design here would need:
More in Building blocks
© 2026 forcsguy.com. Original lesson text and diagrams. Books and sites linked above belong to their authors.