Authorization Code Grant Flow Overview

[@iambhanu7]

I am confused. What is the API here ? Is it part of the Identity/Authorization setup? Or is it the server counterpart of the App.

[@norunners_]

The API is the resource server. No, it uses the authorization services to verify access tokens against scopes protecting their endpoints/resources. No, the app (client) is an untrusted party that the user (resource owner) can grant access to their data via API (resource server).

[@saikrishnapuli6591]

can you confirm, token call is happening at backend or frontend via browser?

[@autumnchills2317]

I am still fairly new to OAuth so I'm still wrapping my head around the concept of oauth clients. In your diagram, would the App be considered the oauth client or would it be the API server? I'm confused because the App would be the one consuming the token and making requests to access protected resources for the user, but the API server here is the one exchanging the auth code for tokens.

[@norunners_]

Yes, the client is sometimes called app. For example, a user (resource owner) can authorize a third party app (client) to access their data via a API server (resource service). The authorization services powers the flow by knowing the relationships (scopes) between clients and resource owners.

[@dennesmagayanes127]

my issue with this now is that for our automation scripts, which obviously uses service accounts they will not work because it's not an actual user/person that has access to a UI/Browser, how to go about this? Seems like it defeats our automation purpose if everything we have to execute them we have to first get the Auth Code via browser.

[@roy_c]

You should use client credentials Flow

[@KawsarAli-s2r]

tuuutft