This is very much implementation specific, but the general idea is to allow providers to issue short term access tokens with long term refresh tokens. Why? Many providers support bearer tokens which are very weak security-wise. By making them short-lived and requiring refresh, they limit the time an attacker can abuse a stolen token. Large … Read more
Bearer Token A security token with the property that any party in possession of the token (a “bearer”) can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of-possession). The Bearer Token is … Read more
Here are my thoughts: The purpose of auth code + token in authorization code flow is that token and client secret will never be exposed to resource owner because they travel server-to-server. On the other side, implicit grant flow is for clients that are implemented entirely using javascript and are running in resource owner’s browser. … Read more
Background: I’ve written client and server stacks for OAuth 1.0a and 2.0. Both OAuth 1.0a & 2.0 support two-legged authentication, where a server is assured of a user’s identity, and three-legged authentication, where a server is assured by a content provider of the user’s identity. Three-legged authentication is where authorization requests and access tokens come … Read more
Eran Hammer-Lahav has done an excellent job in explaining the majority of the differences in his article Introducing OAuth 2.0. To summarize, here are the key differences: More OAuth Flows to allow better support for non-browser based applications. This is a main criticism against OAuth from client applications that were not browser based. For example, … Read more