why was implicit flow conceived?

Question

The OAuth2.0 Implicit Flow allows to obtain an Access Token directly with just one call to the Authorization Server (AS), without the need of a second POST request to the same AS.

According to this article, the OAuth2.0 Implicit Flow was conceived as:

The Implicit flow in OAuth 2.0 was created nearly 10 years ago, when browsers worked very differently than they do today. The primary reason the Implicit flow was created was because of an old limitation in browsers. It used to be the case that JavaScript could only make requests to the same server that the page was loaded from. However, the standard OAuth Authorization Code flow requires that a POST request is made to the OAuth server’s token endpoint, which is often on a different domain than the app. That meant there was previously no way to use this flow from JavaScript. The Implicit flow worked around this limitation by avoiding that POST request, and instead returning the access token immediately in the redirect.

What is not clear to me is: if back in the days browsers didn't allow to make cross-domain requests, once an OAuth2.0 client obtained an Access Token through an Implicit Flow, then what would client do with that Access Token? I mean, if the browser didn't allow a cross-domain request, then how was the Access Token used?

Answer 1

In the Authorization Code Flow the authorization code is obtained directly by the client's user agent, but exchanging it for an access token can be done with a server-to-server request, with the following advantages:

• The access token is not exposed to the user agent.
• The client's server can authenticate to the authorization server with a secret (which a user agent could not keep confidential).

In the Implicit Flow the access token is obtained directly by the client's user agent. This removes the need for a client's server and a client secret, but at the price of exposing the access token to the user agent.

If client authentication is required, clients would choose the Implicit Flow if they do not have a server to carry out the token exchange in the Authorization Code Flow.

However, if an extra security measure called PKCE is added, the token exchange in the Authorization Code Flow can also carried out without client authentication, by the user agent directly, as explained here. This "OAuth 2.0 for Browser-Based Apps" is nowadays preferred over the Implicit Flow. But it requires (in steps D and E) the user agent to make a POST request via Javascript to the OAuth server's token endpoint, and (what the blog calls an "old limitation in browsers") this was prevented by the same-origin policy before the advent of the CORS protocol.