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:
- User must authenticate and returns a
code
to the API consumer (called the “Client”). - The “client” of the API (usually your web server) exchanges the
code
obtained in #1 for anaccess_token
, authenticating itself with aclient_id
andclient_secret
- 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.