Open Authorization (OAuth)

Open authorization as a standard was created by a Twitter engineer in 2006. It’s typically used where you see the sign saying “sign in with Google”, “sign in with your Facebook credentials”. So you have a third party service like a blog or an app, and you’re allowed to sign in using existing credentials that you have in use already. So this makes for a much faster enrollment process. Initially, this was standardized under version 1 as RFC 58 49. Subsequently, it was updated to version 2 in 2012 as RFC 67 49. One of the common misconceptions with OAuth is that it is an authentication standard - it is not. OAuth is open authorization, stands for open authorization, and it is an authorization standard.

Here, the authentication is dealt with by the third party provider portal. The service provider does not see the credentials. If we’re logging in with Google credentials, the authentication piece is managed by Google. For this reason, we need to be sure that the third party provider is appropriately structured, has the appropriate protections in place. And OAuth users access tokens that are issued by an authorization server with the approval of the resource owner. So OAuth is a framework approach. We need to be cautious, we need to make sure that any implementations are appropriately structured and well implemented. If we’re implementing our own, we need to make sure that we’re following the framework closely.

Version 2 provided for better support for non-browser based applications, and this is important because typically, the growth area for OAuth is in mobile applications. So we have better support for those non-browser smartphone app type services. Version 2 also does not require, does not mandate, encryption within OAuth itself, and also simplified the use of digital signatures. They were combined as a change. For this reason, we do need to make sure that if we’re using OAuth, that the wider environment provides for the encryption and for the security. So typically, we are looking at HTTPS. So OAuth, again, as with SAML, uses HTTP as a protocol. OAuth is also an open standard as well, just as with SAML, as with Open ID Connect.

Version 2 also introduced token expiration as a requirement. So those delegated authorization tokens did not, in version 1, have an expiration, which is a potential security risk. Version 2 required us to implement, or suggested that we implement, an expiration. Within OAuth, we have a number of roles that are similar, but slightly different to SAML, so please do be careful with SAML, OAuth, OpenID Connect, we’ve got lots of roles that look similar, but are discrete. They work in very subtly different ways. So let’s talk through those now. We have the third party application, or the client. This is the app, or the website, that the user wants to log into. This is not the identity provider.

This does not contain, this is not the IDP. So this could be a bulletin board, this could be some kind of chat app, and we’re trying to log into this third party application using existing credentials. We have a resource server, we have the authorization server, and then we have the user, and the user in OAuth is classed as the resource owner. So they are the owner of their credentials. So the process works whereby the user, or the resource owner, opens an app - and we said that this is the application or the client - and the authorization request now is passed to the authorization server via a user direct.

This is usually a URL that redirects the user back to the authorization server. So here, we would be redirected back to Facebook or Twitter or Google. The authorization server then grants authorization code if the login, if the authentication, is successful to the user, and this is then passed back via the user to the application. So the application then passes the authorization directly then to the authorization server, and the authorization server grants a token to the application. And the access is then permitted. So slightly different process to SAML. The organization, the group behind open authorization, realised the limitation around authentication and built upon open authorization, and created Open ID, Open ID Connect.