O(h) Auth
Understanding the most widely used security protocol
What is OAuth?
OAuth (Open Authorisation) is an open standard (basically guidelines) for authorisation (not authentication). To know the difference between the two, read more here.
It is commonly used as a way for access delegation — internet users grant websites or applications access to their information but without giving them the passwords.
What do OAuth guidelines say?
OAuth recommends a safe and secure way to allow access to a certain resource/information without actually sharing it. Think of your resource as a painting in a museum, anyone with a ticket can look at it, they can look at it as many times as they want in a single visit, they can even take a picture of it. But they can’t take the painting home, they can’t enter again without a new ticket, and while anyone can get a ticket it is you who decides to whom you want to sell tickets and which sections of the museum are accessible.
The ticket is just an example of how access can be controlled. The actions that are allowed can vary. Maybe phones aren’t allowed, so no pictures can be taken of the paintings.
OAuth does the same by the means of tokens in the online world.
Auth is one tricky pony and usually SWEs don’t try to play around much with it because 99% of the time it can’t be tested locally and if it breaks ALL traffic to your service is affected. It has a notorious reputation in the tech world. So no team will change their auth policies just for fun. And it is not often you get to work on it unless you are in a dedicated team.
Basic Components in OAuth
An Example
You [Client] are at a hotel reception and trying to check-in to your beautiful room [Resource Server]. The receptionist [Authorization Server] asks for some valid documents for verifying your identity. (Note: This part is Authentication, not Authorisation) Then the receptionist checks the hotel system [ ~ Resource Owner] to see if you have a booking with them [Authorisation!!]. If you do, they give you the room keys [Token that give you access to the resource for a fixed amount of time]. Then you use the keys to access your room. Once your stay is over [token is expired], you need to do the whole dance again to get access to the resource. The access was scoped because you could access only your room. But it could be different for hotel employees, who can access multiple rooms with the master key. Another example could be those all inclusive hotels where the colour code of the band determines what privileges you get. Maybe only the bar and no spa access or something like that.
Tl;dr - The resource owner (hotel) was able to delegate access for a certain resource (room) to the client (you). The access was scoped because there were limits to what you can do based on your token.
Informal definitions
- Client: Wants access to a certain resource.
- Resource Owner: Indirectly/directly owns and controls access to the resource.
- Authorisation Server: Checks if the request has valid scopes to access the resources in the request. So scopes can change based on the type of request. Get request will require only read access while an Update request might require read/write access. Usually(almost always) applications have a separate service that performs these checks and aren’t coupled with the application service that contains the business logic.
- Scope: Constraints what access a user is privileged to have for a certain resource.
- Token: Contains scope and identity information that a client has/wants to use. Obtained through various OAuth grant types.
There are different types of tokens and grants (steps to fetch tokens/how tokens are granted) to support different kinds of authorisation flows. These are the most popular ones in a complex flow:
- Access tokens: Allows access to a resource for a fixed(short) time. A popular sub type is a bearer token that allows access to whoever has the token (with some extra check for security obviously).
- Refresh tokens: If application needs to perform an action in the future, getting an access token is of no use as it will simply expire. You can’t ask for a fresh token from the user right before performing the action, but you can get a refresh token from the user instead during the interaction. Later when you need to perform the action, you can exchange the refresh token for an access one.
The token choice and how it is obtained depends a lot on the kind of flow we have — is it user initiated, after how long does the service need to perform the action etc.
In future posts I will break down some popular auth flows we use frequently such as log in, log in with <some third party email account>, machine to machine calls and more.
