oauth implicit grant vs authorization code grant?

Question

I would like to better understand the difference's between the implicitly grant flow and the authorization code grant flow as i'm not sure that my current understanding is correct.

1. Is the implicitly grant flow primarily used by front-end applications to authenticate the user?
2. Does the implicitly grant flow only require a client_id, username & password to authenticate, in other words the client_secret is never sent?
3. Is a authorization codes only a short lived token?
4. After an authorization code has been exchanged for a access token, how long can the client access the users account for? Specifically, if the client is a long running script, does the user need to authenticate each time the script runs? Or can we assume that after the user has authorized once that the client has permission to access the user when ever it needs to (unless the user revokes access) and as such it just needs to authenticate using the client credentials?
5. What is the advantage of using the authorization code flow over the implicitly flow?
6. Does the resource server it's self need a client id?

Thanks

Answer 1

While jwilleke answers most of the questions you have, I will answer for your specific questions,

1. Implicit flow is designed for clients who does not have the ability to perform the token request. From OAuth 2.0 specification - 4.2 section

The implicit grant type is used to obtain access tokens (it does not support the issuance of refresh tokens) and is optimized for public clients known to operate a particular redirection URI. These clients are typically implemented in a browser using a scripting language such as JavaScript.

2. It is used by public clients. They do not have a client secret. This is because their inability to protect such secret since they run on a browser.

3. Authorization code can have a lifetime of few seconds (30 seconds) to few minutes (2 minutes). Compared to other tokens, they are short lived.

4. This depends on the life time of the access token. If there's a long running task and token expires, you will have to obtain a new access token for authorization. But if your specific backend establish a session, it may have a prolonged lifetime than the access token.

5. One advantage is refresh token. It can be used to refresh the access token without end user interaction (a fresh login). Also depending on implementation of OAuth server, you might get access tokens with different lifetimes. For example, authorization server may issue short lived access tokens for implicit flow due to the fact that it's used by a public client.

6. It depends. If resource server need to consume protected resource from a another resource server, which authorize using access tokens, then your resource server too will need a client id and follow a specific flow to obtain tokens. But if it's not communicating outside, you don't have to get a client id for it.

Answer 2

The OAuth 2.0 Authorization Framework (RFC 6749) implies that:

Implicit Flow is only suitable for OAuth Client applications that are browser based or JavaScript NOT Mobile Devices or other Applications that could use a Authorization Code Grant

The implicit grant type is used to obtain access tokens (it does not support the issuance of refresh tokens) and is optimized for public clients known to operate a particular redirection URI.

See Sections 1.3.2 and 9 for background on using the implicit grant. See Sections 10.3 and 10.16 for important security considerations when using the implicit grant.

When using the implicit grant type, the access token is transmitted in the URI fragment, which can expose it to unauthorized parties.

-jim