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, in OAuth 1.0, desktop applications or mobile phone applications had to direct the user to open their browser to the desired service, authenticate with the service, and copy the token from the service back to the application. The main criticism here is against the user experience. With OAuth 2.0, there are now new ways for an application to get authorization for a user.
OAuth 2.0 no longer requires client applications to have cryptography. This hearkens back to the old Twitter Auth API, which didn't require the application to HMAC hash tokens and request strings. With OAuth 2.0, the application can make a request using only the issued token over HTTPS.
OAuth 2.0 signatures are much less complicated. No more special parsing, sorting, or encoding.
OAuth 2.0 Access tokens are "short-lived". Typically, OAuth 1.0 Access tokens could be stored for a year or more (Twitter never let them expire). OAuth 2.0 has the notion of refresh tokens. While I'm not entirely sure what these are, my guess is that your access tokens can be short lived (i.e. session based) while your refresh tokens can be "life time". You'd use a refresh token to acquire a new access token rather than have the user re-authorize your application.
Finally, OAuth 2.0 is meant to have a clean separation of roles between the server responsible for handling OAuth requests and the server handling user authorization. More information about that is detailed in the aforementioned article.
The reason this is out of scope for the specification is the wide range of ways to accomplish this connection between the two entities. The main question is how complex is your deployment.
For example, do you have one server managing authentication and access, and a set of discrete services each with its own servers serving the API calls? Or, do you have just one box with one web server which handles both authentication/authorization and the API calls?
In the case of a single box, not much is needed as the entity issuing tokens is the same as the one validating them. You can implement tokens to use a database table key and lookup the record in the database (or memory cache) on every request, or you can encode the scope, user id and other information directly into the token and encrypt it using a symmetric or asymmetric algorithm.
Things get a bit more complex when dealing with a distributed environment, but not by much. You still issue tokens at the authorization server, but the resource server needs a way to validate those. It can do it by making an internal API available to the resource server to ask the authorization server to "resolve" the token (which can be fast in a local environment), or the two can establish a public/private key pair or symmetric secret and use that to encrypt everything the resource server needs into the token.
Self contained tokens are longer but offer much better performance per-request. However, they come with a price - you can't really revoke them while they are still valid (not expired). For this reason, self contained tokens should be very short lived (whatever is acceptable to you to leave access open after it was revoked - e.g. many sites use one hour), with a refresh token good for a year or more to get new tokens.
Best Answer
token_type
is a parameter in Access Token generate call to Authorization server, which essentially represents how an access_token will be generated and presented for resource access calls. You provide token_type in the access token generation call to an authorization server.If you choose
Bearer
(default on most implementation), anaccess_token
is generated and sent back to you. Bearer can be simply understood as "give access to the bearer of this token." One valid token and no question asked. On the other hand, if you chooseMac
andsign_type
(defaulthmac-sha-1
on most implementation), the access token is generated and kept as secret in Key Manager as an attribute, and an encrypted secret is sent back asaccess_token
.Yes, you can use your own implementation of
token_type
, but that might not make much sense as developers will need to follow your process rather than standard implementations of OAuth.