Why do you need authorization grant when you can just give the token out directly?

Question

Watching this video, it details in OAuth2 that the client application first has to get the authorization grant from the Authorization server and then use that grant to get a token before being able to access the resource server. What purpose does the grant serve? Why not give the client the token right away after the user signs on with his/her username and password?

Answer 1

Because it is more secure, for some application types.

What you describe is so called authorization-code-flow. It is normally used for "classical" web applications, where only the backend needs to access resource server. The exchange of authorization code to access token happens on the backend and access token never leaves it. Exchange can be done only once and in addition client id and secret (stored on the backend) are necessary.

Single-Page-Applications often use implicit-flow where access token is delivered to the frontend directly in the URL.

See more here: IdentityServer Flows

EDIT: Q: "I still don't see how it is more secure given that you have to have the grant in order to get the token. Why need 2 things instead of just 1 thing to access the resource? If someone steals the token, they can access the resource anyway – stackjlei"

"Stealing" access token will work independent on how your application acquires it. However, stealing access token on the backend is much more difficult than on the frontend.

Authorization code is delivered to the backend also over the frontend but the risk that someone intercepts and uses it is tiny:

1. It can be exchanged only once.
2. You need client-id and client-secret in order to exchange it. Client-secret is only available on the backend.
3. Normally, authorization code will be exchanged by your backend to access-token immediately. So the lifetime of it is just several seconds. It does not matter if someone gets hold of used authorization code afterwards.

Answer 2

In your scenario there could be two servers, an Authorization and a Resource one. It could be only one as well, but let's imagine this scenario.

The purpose of the Authorization Server is to issue short lived access tokens to known clients. The clients identify themselves via their CLientID and CLientSecret.

The Authorization Server ( AS ) holds the list of clients and their secrets and first checks to make sure the passed values match its list. If they do, it issues a short lived token.

Then the client can talk to the Resource Server ( RS ), while the token is valid. Once the token expires, a new one can be requested or the expired one can be refreshed if that is allowed by the Authorization Server.

The whole point here is security, Normally, the access tokens are passed in the Authorization header of the request and that request needs to be over https to make sure that the data can't be stolen. If, somehow, someone gets hold of an access token, they can only use it until it expires, hence why the short life of the tokens is actually very important. That's why you don't issue one token which never expires.

Answer 3

You have different type of OAuth. On type doesn't require to use the 'grant' authorization. It depend who are the user/application, the ressource owner and the server API.

This way, you - as a user - don't send the password to the application. The application will only use the grant token to gain access to your ressources.

I think this tuto is a pretty good thing if you want more details

https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2