The OAuth specification is a protocol for allowing client applications to behave on your site as representatives of the users who have access to resources on your site. If your site is an “OAuth provider,” it means that it will follow this protocol to grant (usually, temporary) access to automated clients to perform certain actions that users usually perform via browsers after going through a login (aka, authentication) process.
There are numerous tutorials on the web that discuss what it means to be an OAuth provider, and how OAuth clients can request access to a website, and use the OAuth credentials made available to them. This tutorial attempts to distil this knowledge further into the basics you need to understand to get going with using a particular implementation of OAuth, to wit, the Ruby and Rails libraries (gems) for OAuth.
Imagine you have a website where users keep a list of bookmarks. You want to write a client that will create and update these bookmarks as if they are representing a specific user.
An important thing to consider is the terminology used in most of the tutorials you’ll find on the web, as well as in this one. We differentiate between users and clients, where the user is the human being who would have logged in via a browser by typing in a password, and the client is the automated code that is acting on behalf of the user.
An OAuth client works by first being included in a list of authorized applications on your bookmark listing site. For a client to gain access, it needs to have its own identity, separate from the identity of the users it is trying to represent. This way, the OAuth client can be provided as a service that users can sign on to, but if the client provider becomes untrustworthy at some point, the OAuth client can be denied access to the site without having to revoke access to the users themselves. 1)A cursory investigation seems to indicate that the Doorkeeper gem requires clients to have IDs, which is the right thing to do, to keep your site secure. Compromised applications can have their client IDs revoked; however, my reading of the OAuth specification indicates that this behavior is not part of the specification itself. In fact, it appears that Google’s implementation allows for ‘anonymous’ clients, which can operate solely by having users authenticate themselves when granting access to the client.
Clients are identified by two keys normally – an ID and a secret. The ID is typically public information – it is simply a bookkeeping measure to keep track of how many clients have registered themselves on your bookmark site. The secret allows you to separately revoke a client’s access without having to delete the client itself – that way, if the client’s developer isn’t the one at fault for having malicious code in the client, they can still regain access by having the consumer key reset in a secure manner.
The Access Token
OAuth clients are given access by being granted a token. The token represents a user’s credentials – that is, their username and password – and also a specific set of actions that the client may execute. This allows clients to have less access than the users they represent – so for example, on your bookmarking site, while users can add, delete, and update bookmarks, you can set up the OAuth client to only update existing bookmarks, say.
The following topics are incomplete.
Token Expiry and Revocation
References [ + ]
|1.||↑||A cursory investigation seems to indicate that the Doorkeeper gem requires clients to have IDs, which is the right thing to do, to keep your site secure. Compromised applications can have their client IDs revoked; however, my reading of the OAuth specification indicates that this behavior is not part of the specification itself. In fact, it appears that Google’s implementation allows for ‘anonymous’ clients, which can operate solely by having users authenticate themselves when granting access to the client.|