OAuth Audit Toolbox at Indeed

Ideas you will meet

Distributed Systems

Consensus, time, failure and the fundamentals of scale-out.

OAuth

Delegated authorization flows for APIs and apps.

Web Security

OWASP risks, XSS, CSRF, CORS and secure design.

What we already know about this

Our own lessons on these ideas. Read them here before you start, so it makes sense.

• Core Concepts: How Things Actually Work · 9 minSSO, OAuth 2.0 and OpenID ConnectHow 'Sign in with Google' works, and the difference between authentication and authorisation.Read hereClose

  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

  100%

  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:

  100%

  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 state or accepting any redirect URI.
  • Storing tokens somewhere scripts can read them.
  • Requesting more scopes than the feature needs.

  More on this site

  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

  Open this lesson with its quiz and exercise