CODEWITHSUNDEEP
iosswiftoauth-2.0authorizationforgerock
Rohan Bhale
Rohan Bhale

Reputation: 1345

Are auth code and access token exclusive to a single resource owner?

In my past jobs as an iOS developer, I used authentication url to redirect the resource owner to the authroization server web page on a browser, which allowed the resource owner to login and then consent to the scopes, and then redirect back to the redirect url along with a auth code. This flow was a black box to me and I assumed that the auth code is exclusive for the resource owner. Later ahead exchanging this auth code for a access token, made me assume that the access token is also exclusive for the resource owner

Fast forward..

I have recently started working on a iOS app codebase which uses OAuth to regulate access to resources. In particular we are using Forgerock AM for identity management. The difference is that we are using authenticate url which is not a webpage, but rather a http url request. The flow I read in the code is

  1. The resource owner enters user id and pass in UITextField.
  2. The resource owner credentials are sent to a authenticate http url request which returns a token id
  3. Then a call to an authorize http url request is made where we pass client id, codechallenge, code method since we use PKCE. This endpoint returned a auth code.
  4. In the end another call to access_token endpoint was made with the authcode and client id and codeverifier, which returns an access token

I was surprised, that no user identity/credential was sent in the third or fourth step above to the auth server requests.

If no user identity was sent to these endpoints, is my earlier assumption that auth code and access token are exclusive to a single resource owner totally wrong?

Are auth code and access token not exclusive to the authenticated resource owner from the second step?

Upvotes: 0

Views: 48

Answers (1)

Paulw11
Paulw11

Reputation: 114773

In both cases you are describing an OAuth Authorisation Code grant.

In the first case it is browser based where your app does not have access to the user credentials. In the second case it is "browserless" and your app obtains the credentials and submits them directly.

In both cases, at the end of the authorisation step, you have an authorisation code that is valid for a limited time and a single use.

The authorisation code is exchanged for an access token (and in some cases also a refresh token that can be used to obtain additional access tokens)

The authorisation code doesn't identify a user per-se, but rather a successful user authentication session (which is associated with a user identity).

In your second flow, the Authorization Grant is combined with PKCE, which is used to provide assurance that the authorisation code is being presented by the party to whom it was provided to protect against MITM attacks.

In the Forgerock implementation, the authorisation code is sent in a cookie, rather than as a request parameter or in a the request body.

The process is described here.

Upvotes: 1

Related Questions