CSEC3616Cybersecurity Engineering

    Application layer: OAuth and OpenID

    The difference between authorization and authentication at the application layer, why OAuth's protocol flows are complex, and the four actors every OAuth flow involves.

    • Distinguish what OAuth provides (authorization) from what OpenID provides (authentication).
    • Name the four actors in an OAuth flow and what each one does.
    • State why OAuth results in complex protocol flows despite the underlying idea being simple.

    15 min readJump to the quiz ↓

    OAuth grants access without sharing a password

    Giving a third-party app your Google or Facebook password lets it do anything that password permits. OAuth grants access to part of an account without sharing the password.

    OAuth is a standard for authorization: it lets a user of one internet service grant another service access to part of their account. The lecture draws a direct parallel to Kerberos: an authorization server creates a “ticket” that allows access, in the same spirit as a Kerberos ticket. Because OAuth is designed for use with HTTP, websites implement its standardized flows directly, and this results in genuinely complex protocol flows; several distinct flows have been standardized for different situations. The payoff for that complexity is concrete: a user registers once with a provider and then uses authorization tokens with other services, instead of typing a username and password into every one of them.

    OpenID adds identity to OAuth authorization

    Compare

    OAuth

    OAuth answers “what is this app allowed to access”. An OAuth flow grants access to part of your data.

    OpenID

    OpenID answers “who is this user”, using OAuth’s flows. Signing in to a third-party site with a Google identity lets the site learn who you are through that mechanism. The lecture calls OpenID complementary to OAuth, not a competitor.

    Four actors divide ownership, storage, requests and authorization

    Every OAuth flow involves four actors:

    • Resource Owner. Owns the data held on the resource server, e.g. you are the Resource Owner of your own Facebook profile.
    • The API. The resource server that stores the data the Client wants.
    • Client. The application requesting access to the Resource Owner’s data.
    • Authorization Server. The main engine of OAuth: the component that actually grants (or refuses) access.

    Pitfall

    Do not describe OAuth itself as proving who a user is. OAuth’s job stops at authorization; identity is OpenID’s job, layered on top. An answer that treats “OAuth token” and “proof of identity” as the same thing conflates the two protocols the lecture is careful to keep separate.

    Optional aside

    Despite the complexity, OAuth and OpenID have become the standard for cloud services: Google, Microsoft Azure, Facebook and Twitter, among others, all rely on them. Kerberos itself is covered on the Needham-Schroeder and Kerberos page, if the ticket analogy is unfamiliar.

    Recall

    What do OAuth and OpenID each provide, and which four actors participate?
    • OAuth grants authorization without ever sharing the underlying password, via a ticket-like model similar to Kerberos.
    • OpenID adds authentication on top of OAuth’s own flows; the two are complementary, not competitors.
    • Four actors: Resource Owner (owns the data), the API (stores it), Client (wants it), Authorization Server (the main engine that decides).

    Check yourself

    Source

    Week 8 slides PDF