About OAuth2 grant types

Question

I am reading an article about OAuth2, https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2. What confuses me is the grant types. It says

Authorization Code: used with server-side Applications Implicit: used with Mobile Apps or Web Applications (applications that run on the user's device)

So whats the diff between server side apps and web apps, arent they the same? Can anyone give me an example when to use these two grant types? Thanks.

Answer 1

Grant Type is the type of authorization flow that the client is using to get the access token. The grant type determines the method that the client uses to request the access token. The grant type is specified in the request to the token endpoint.

Types of Grant Types:

1. Authorization Code Grant : This is the most common grant type. It is used in web applications, mobile apps, and desktop apps where the source code is not publicly exposed.

2. Client Credentials Grant : This is used when the client is requesting access to the protected resources under its control, or those of another resource owner that have been previously arranged with the authorization server. The client authenticates with the authorization server and requests an access token.

3. Refresh Token Grant : This is used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner).

4. PKCE (Proof Key for Code Exchange) : This is used in public clients where the client cannot maintain the confidentiality of its credentials. This is used in native or mobile apps where the client and server are in different domains.

5. Device Code Grant : This is used in cases where the client does not have access to the browser of the resource owner, such as in smart TVs, media consoles, and printers. This is also used in cases where the client is unable to receive incoming requests (via redirection from the authorization endpoint).

6. Password Grant (deprecated): This is used in cases where the client has the resource owner's credentials, such as the username and password, and can use those to obtain an access token directly.

7. Implicit Grant (deprecated): This is similar to the authorization code grant, but there is no need to exchange an authorization code for an access token. This is used in single-page applications (SPAs) where the client and server are in the same domain.

Answer 2

You can think of each OAuth grant type as a flow. In OAuth2 there are 4 different grant types.

Each grant type is similar because each has 2 main parts:

1. The App gets an authorization key/access token from the User
2. The App uses key/access token to perform an action (e.g., post on Tweeter at 12pm everyday) on behalf of the User

To understand their differences between all 4 OAuth2 grant types, let us look at an image that compares them side-by-side.

Image credit: https://blog.oauth.io/understand-oauth2-grant-types-by-spotting-the-difference/

Authorization Code (top-right corner):

• There are 5 parties: User, App, Guard, OAuth Server (represented as keychain with multiple keys), Resource Server (represented as store with multiple doors)
• The User obtains a Key/Access Token from the OAuth Server by providing username/password, and it 'hands over' to the Guard (backend), and the App (frontend) can only access the Resource Server through the Guard since it has no access to the Key
• The Guard recognizes the User of the App through conventional means, e.g., through a browser HTTP session.

Implicit (bottom-right corner):

• There are only 4 parties, i.e., no Guard (backend)
• The User obtains a Key from the OAuth Server by providing username/password, and it 'hands over' to the App (frontend) since there is no Guard
• The App accesses Resource Server directly since it has the Key

NOTES:

• In Implicit grant type, the Key is in the frontend (browser) it is exposed to more attack vectors, thus making it less secure compared to Authorization Code grant type, where the Key is in the backend

With these understanding, you can now answer your own question:

What is the diff between server side apps and web apps, arent they the same?

Server-side apps have a backend to mediate between the frontend and the data store, etc. thus they can implement Authorization Code grant type with the backend acting as the Guard, which is more secure. For web apps (single-page apps) that do not have/rely on the backend, they need to use Implicit grant type.

Answer 3

I like to think about the grant as a thing, like perhaps a coin, and the access token another thing, a key the opens doors.

In order to get the key, you are going to have to hand over a coin. What kind of coins are accepted?

Well, you can hand over a coin with your password written on it. This shows that you know your password, and so, the coin is accepted and you get a key. This is the Resource Owner Password Credentials grant.

A web server can put up a login form, and the user types in a password which the web server sees. The web server uses the password to obtain the key.

Along with the key, you may also have been given a refresh token. So later, you can hand over a coin with the refresh token imprinted on it. This coin is accepted and you get a fresh key. This is the Refresh Token grant.

You may not know your password. Your parents keep track of your password for you. You ask your parents to go fetch a "code" for you. They talk to the authorities and give the password, and receive back a code, which they give to you. Now you can put the code on a coin, hand the coin over, and receive a key. You didn't see the password, and your parents did not see the key. This is the Authorization Code grant.

A web server asks you to "signin with Google". Google asks for your password and gives you an authorization code which is passed back to the web server. The web server can get the key from Google without seeing your password.

You might have a special relationship with the authorities, and possess a secret. You don't need a password. In that case you can put this secret on the coin and exchange it for a key. This is the Client Credentials grant.

You may be a back end server and want a key, but don't have a username or password. You just need a secret to get the key.

If you are a VIP, you don't even need a coin! You can just wave your hands, and receive a key. It's an "implicit" coin -- i.e., there is no coin! This is the Implicit grant.

You may be a phone app, and there is really no safe place for you to keep a secret, so you just wave your hands to get your key.

Answer 4

The Authorization Code grant provides additional security and works well for applications that provide server sessions. The addition security is provided through separation of user-agent and client. E.g. web-browser (user-agent) to login with Facebook account on Stackexchange(client). Since the client web application (server) can securely obtain the access token and store it, there is less risk of token being compromised.

The Implicit Code grant is less secure, and only option when there is no web server or no server session (e.g. native mobile application, javascript application). Since the user-agent has to acquire the token, it does not make sense to have intermediate credentials (such as an authorization code) and later obtain an access token.

This might help https://oauth2.thephpleague.com/authorization-server/which-grant/

Answer 5

It's security so it is complicated. Well not too complicated.

First, you need to determine if your OAuth Client (ie your Application) is a "Public or Confidential"

The the best rule is to follow RFC 6749 Section 1.3.2 "Implicit grants improve the responsiveness and efficiency of some clients (such as a client implemented as an in-browser application), since it reduces the number of round trips required to obtain an access token. However, this convenience should be weighed against the security implications of using implicit grants, such as those described in Sections 10.3 and 10.16, especially when the authorization code grant type is available."