Search code examples
oauth-2.0single-sign-onsingle-page-applicationopenidopenid-connect

Who/What exactly is the Client Application in the Open ID Connect Auth Code Flow?


From an OpenID perspective and all questions/articles I've read, it seems pretty self-explanatory - it is the client application requesting for the ID Token. However, when I try to map it an actual "application" in our architecture, I'm not exactly sure.

Given:

  • ID_Token's audience is intended for the Client_Application
  • Access_Token's audience is intended for the Protected Resource API
  • We have an front-end SPA that has its own back-end web API (which may later be consumed by other clients)

The components involved are:

  1. Front-end SPA (Relying Party)
  2. Back-end Web_API (Protected Resource)
  3. OpenID Provider (OP)

If I wanted to apply the Auth Code flow when a user accesses the Front-end SPA, would the Front-End SPA OR Web_API be considered the Client_Application? In Auth Code flow, the actual exchange of an Auth_Code for ID_Token would happen back-channel, via the Back-end Web_API to the OP. Yet, it's really the Front-end SPA that initially requested for the authentication of the user. What should/would the audience of the ID_Token be - would it be the SPA's or Web_API's App_ID?

Thanks for any help with the clarification.


Solution

  • Current best practice require SPA to use authorization code flow with PKCE (draft best practice rfc). So please consider this when using OAuth with your SPA.

    Regarding your doubt, here are your client and audiences

    • Client - Your SPA
    • Audience of ID Token - Your SPA
    • Audience of Access token - Backend web API

    Justification :

    It is your SPA which completes the OAuth flow and obtain tokens. And as I said, it must follow PKCE as current recomendation (there are enough libraries to support this). So from authorization server perspective, client is your SPA.

    Regarding ID Token, it is intended to be consumed by your SPA. Once validated SPA authenticate the end user. So it intended audience is SPA.

    Access token is intended to be used against your backend by your SPA. Once it receive an API request, it must check access token audience contain identifier targeting itself (ex:- If a JWT, claim containing backend identifeir. Or if token introspection, the resposne containing the identifier). Usually your authorization server allows you to register such audiences and your authorization request can have intended audience parameter (ex:- Azure use this approach). But these are implementation specifics.