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 read

    Intuition

    Handing a third-party app your Google or Facebook password so it can read part of your account is obviously a bad idea: the app would then be able to do anything your password allows, forever. OAuth exists to grant that kind of access without ever sharing the password itself.

    Mechanism

    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.

    Compare

    Mechanism

    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.

    EXTRACTION DEFECT: the OAuth architecture diagram (Figure 15 in the notes, and the corresponding slide diagram) did not survive extraction. The four actors above are exactly as the surviving text names and defines them, but the message-by-message flow between them, i.e. which actor sends what to which other actor and in what order, is not reconstructed here, since that sequence is exactly what the missing diagrams showed.

    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.

    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

    • 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).
    • The actual message flow between these actors did not survive extraction and is not reconstructed here.

    Source

    Week 8 slides PDF