1

One of the really nice articles I came across while trying to understand the various grant types in Oauth2.0 was this. The author really has done a good job at explaining quite clearly what various grant types in an Oauth2.0 flow look like. I also followed a few more articles like this and this. Each one of them explaining well about the flows involved in the different grant types.

However, there is one thing that I am getting confused with & hence this post. Would love to understand what am I missing here.

In the Authorization Code Grant flow, after the Authorization Code is shared with the client (a web app page that the end user is accessing in their browser or a mobile app that the end user is accessing), the front end web page of this web application sends the Authorization Code to it's backend. The web app's backend (server side code) then exchanges this information (along with other info, like the client secret etc.) with the authorization server for an access token. Till here things are clear. (or please correct me if my understanding is not correct here).

Now the confusion is:

Does the web app's backend server send this access token back to it's front end & then the front end makes all subsequent calls, with this access token, to access the resources?

OR

Is it that the access token is never really sent to the web app's front end & instead the front end code simply sends all resource access requests to it's backend which then fetches the resources, using the access token from the backend, & forwards it to the front end?

qre0ct
  • 1,492
  • 3
  • 19
  • 30

2 Answers2

1

This is not something that OAuth specifies. OAuth specifies how you obtain a token and a little bit, how they are used.

Both patterns you describe can be seen in the wild. The first is called the "backend for frontend" pattern. This is generally a good idea, because a user then cannot directly access the ressources, as the access token is never presented to the user.

The second one is mostly seen in Single Page Applications and should be used, when there is no backend present that can handle the tokens for you. You need to make sure that it is not a problem, that a user has access to the access token. (For example by accessing protected resources that only a backend server should access)

Community
  • 1
BenjaminH
  • 492
  • 2
  • 9
1

Both approaches are possible and in both approaches you need to think about security of access token. This is important that access token would not be stolen by any not-legitimate actor (attacker, application, etc.)

By default the first approach (with backend server), can be much safer because you do not need to share token with client's side (browser), which is rather treated as unsafe. You can store it is some session's storage at backend (in-memory, DB, etc.). This is much harder to stole data from backend server than from client's agent. You should also find that such applications are so called "trusted applications", which means that you can store secrets securely for it. Unfortunately this approach requires more work in regards of development as you need to build the server-side of your application.

The second approach is mostly used by client-side applications where there is no backend like in previous scenario. As here you are sending access token to client side, you also need to store it securely, or implement some different scenario to secure tokens from being stolen. From my experience I like approach where access token is very short lived, and retreived from AS when it is needed ("silent refresh" approach - you can read about it here). You can also use here long-lived referesh tokens and use "refresh_token" request to get new access token, but as refresh token also have to be somehow securely stored on client-side, I do not like this solution.

Bartosz Rosa
  • 337
  • 1
  • 6