…in the context of token-based security systems.
There are many practical and philosophical ways to discuss the difference between the two terms. But since there is quite some confusion, I want to look at it from the perspective of the “usual suspects” token-based protocols we are commonly using today to build applications. In particular I try to make it very clear where OAuth2 vs OpenID Connect fits in.
But first the “formal” definitions:
Authentication is a process where a person or a computer program proves their identity in order to access information.
Authorization is the act of granting a person or other entity permission to use resources in a secured environment. This is usually tightly linked to authentication.
My rule of thumb is, when an application requests an identity token for its own use to provide personalization or access control to application features, that’s authentication. Or technically, the requested token’s audience is the requester itself and the requesting application can parse and validate the token to use the information contained.
Typical protocols used for authentication: Kerberos, WS-Federation, SAML2p, OpenID (Connect). The resulting token is often called an identity token.
In contrast, when the application requests a token for a different party than itself – e.g. a backend, that falls into the authorization bucket. This token is opaque to the requester and only makes sense in the context of the audience (aka the backend). The backend can parse and validate the token and control access based on the contained information.
Typical protocols used for authorization: Kerberos, WS-Trust, OAuth2. The resulting token is often called an access token.
But – what about authentication with OAuth2?
Some providers advertise OAuth2 sign-in – where does that fit in? Well – OAuth2 on its own cannot provide authentication services and when you look closer, you can see that those providers use some custom extensions to make it happen. Quoting the Google documentation (link):
“The Google endpoints described here align with the OpenID Connect specification, which at the time of this writing, is in early draft stage. For reference, the OpenID Connect specification is very similar to the OAuth 2.0 protocol. These Google endpoints will update as the specification matures.”
To find out what is necessary to teach OAuth2 the authentication trick, I can recommend reading this piece by Tim Bray, the OpenID connect specification and this and this explanation why OAuth2 on its own is not enough.
Pingback: Windows Azure Community News Roundup (Edition #62) - Windows Azure - Site Home - MSDN Blogs
Pingback: Windows Azure Community News Roundup (Edition #62) - Windows Azure Blog