What is the difference between the OAuth Authorization Code and Implicit workflows? When to use each one?

The access_token is what you need to call a protected resource (an API). In the Authorization Code flow there are 2 steps to get it:

  1. User must authenticate and returns a code to the API consumer (called the “Client”).
  2. The “client” of the API (usually your web server) exchanges the code obtained in #1 for an access_token, authenticating itself with a client_id and client_secret
  3. It then can call the API with the access_token.

So, there’s a double check: the user that owns the resources surfaced through an API and the client using the API (e.g. a web app). Both are validated for access to be granted. Notice the “authorization” nature of OAuth here: user grants access to his resource (through the code returned after authentication) to an app, the app get’s an access_token, and calls on the user’s behalf.

In the implicit flow, step 2 is omitted. So after user authentication, an access_token is returned directly, that you can use to access the resource. The API doesn’t know who is calling that API. Anyone with the access_token can, whereas in the previous example only the web app would (it’s internals not normally accessible to anyone).

The implicit flow is usually used in scenarios where storing client id and client secret is not recommended (a device for example, although many do it anyway). That’s what the the disclaimer means. People have access to the client code and therefore could get the credentials and pretend to become resource clients. In the implicit flow all data is volatile and there’s nothing stored in the app.

Leave a Comment