- In an Implicit Grant Type, client requests access token directly, without the need for an Authorization Code which was a step in Authorization Code flow
- Therefore the word “implicit” comes from the implicit authorization which we get from the from the /authorize endpoint, instead of exchanging auth code for token from /token endpoint
- The Implicit grant was previously recommended for native and browser-based applications, because front end applications cannot protect client id and secrets
Comparison of Implicit Flow & Authorization Code Flow
| Implicit Flow | Authorization Code |
|---|---|
| Client requests authorization to access | Client requests authorization to access |
| Client requests access token | Client receives authorization code |
| Client Access resource using access token | Client exchanges authorization code for access token |
| Client requests access token | |
| Client Access resource using access token |
Referring to the example shared in the previous OAuth posts – Post 1 & Post 2 . The flow for client (greet.com) to access the contact list of user from protected resource (contactlist.com) will be as below
- The Implicit flow was a simplified OAuth flow previously recommended for native apps and JavaScript apps where the access token was returned immediately without an extra authorization code exchange step.
- It is not recommended to use the implicit flow (and some servers prohibit this flow entirely) due to the inherent risks of returning access tokens in an HTTP redirect without any confirmation that it has been received by the client.
- Public clients such as native apps and JavaScript apps should now use the authorization code flow with the PKCE extension instead.
Thank you !!!!