Talking of OAuth 2.0 and not stackexchange API's specifically, there is an element of risk in the implicit flow, also called the implicit grant flow. This is because the authorization server sends the access token to your user agent/web browser.
To minimize any damage that could result from this, the access tokens were made short lived. Also, an access token, in this scenario, can be used only for the scopes that the user provided authorization for. This type of flow is mainly used for simpler web apps, that do not have a server to support them. The rather irritating apps that you see on Facebook could be an example, every other developer can use this implicit flow without having to worry about arranging for a server.
The explicit flow, called the Authorization code flow is far more secure. This involves the user agent receiving an authorization code from the server. This code can only be used by the app that registered - the server that you would maintain at the back end, with valid credentials.
An example :-
Let's assume there is some Google app that uses Facebook graph APIs. You can open the google app website and authorize
i) Either the browser receives token, the webpage made by the google app ensures that it hits the APIs, fetches the data and returns it to the server.
ii) OR, the browser gets a token and the webpage returns it to the google server. This ensures that only Google can hit the Facebook API (a sense of relief for a big company). Also, there is a central server that manages all requests and can easily generate any sort of metrics for monitoring requests/numbers/patterns.
One more major use of this explicit flow is offline access. In the above scenario, your app server can fetch a Refresh token and can call the REST APIs even when you are not logged in.
If you do have a server side app, I personally would recommend using the authorization code flow /explicit flow.