If you have ever used API’s before then you are probably familiar with OAuth. If not, no worries, read below and expand your authentication knowledge! OAuth has become one of the emerging as a standard for authorization.
Important Terms
Lets get you up to speed with a couple of terms:
OAuth is an authorization protocol that companies/users to grant limited access to their resources on a site or database without having to expose their credentials (sharing usernames or passwords).
Authorization is the process which we can check the permissions a user has. This is usually stored in a table in the system.
Authentication is the process in which we validate that a user is who they claim to be. This can be done by password, certificate/RSA token or a fingerprint.
Federated authentication is the arrangement made among multiple enterprises to let subscribers use the same identification data to access the network so of all enterprises in the group.
Service Composition is an aggregate of services collectively composed to automate a particular task of business process.
Putting The Pieces Together
So in general, OAuth gives one application access to one API on behalf of one user.
In other words, it allows the user (the resource owner) to grant access to their private resources on a site (resource server) to another site (client). In addition, it is actually the authorization server that grants access to the protected resources, with the approval of the resource owner.
Essentially, you can receive access to resources without having to share your identity or passwords. Again, I repeat, you do not need to pass your user’s credentials to the client or the API.
General Steps using Hotel Analogy:
- Request Authorization Grant
- Web app requests that the user authorizes the app. (“Hey, I want to stay in this hotel.”)
- Authorization Grant is given
- The user authorizes the web app and delivers proof of this. (“Sure, let me add you to the list here. Take this receipt to the other desk, they will issue you your room key. “)
- Exchange Authorization Grant for Token
- The web app presents the proof of authorization to the authentication server to receive a token. (“Hi I just booked a room, can you give me a key now?”)
- Token is used to access resource
- The token allows for restricted access to what the user authorized for the app. (“Sure, this key will allow you to use room number 1”)
Understanding the Whole Process
Understanding Access/Refresh Tokens
It is important to note that OAuth makes use of Access Tokens to grant grant users access to limited resources without sharing credentials. Essentially the Access Token is a generated string that represents the permissions given by the intended resource. Formally, it is the unique identifier issued by the authorization server and used by the client to associate the request with the resource owner.
So taking a step back, rather than needing to use multiple passwords to access different resources, OAuth uses tokens instead. This is called token-based authorization. These tokens so have expiration dates and are limited by the scope assigned to them. Essentially, the client can only perform certain operations (read or write) on the resource. The token itself usually can not be understood by anyone besides the Authorization Server.
In terms of refresh tokens, OAuth does outline the ability to refresh your token. This also is helpful when your token has expired (for resources places time limits). This can also be useful when your token is compromised.
The token obtain is sent over in the authorization header to the web app or API. There are two types of tokens that are worth mentioning: Bearer and MAC. However, the bearer token is the most popular choice as it makes OAuth 2.0 the industry standard. MAC token are for those who miss the OAuth 1.0 functionality. You can think of a bearer token as cash, anyone can use it (can be used widely on applications). On the flip side, you can think of a MAC token as a credit card, where a signature is needed to validate that you are the user.
Taking it a Level Up with Open ID Connect
As you can tell, OAuth is extremely useful when building out API functionality for access to a resource. When developing an app, people often use multiple APIs offered by different resources to help streamline a user’s experience, also known as a service composition. Using the OAuth logic above, this would mean that the person using the application would have to authenticate at all of the authentication servers to use the service composition correctly. Open ID connect alleviates this stress. More formally, it is a unified user identification method that essentially acts as a single user identification system that can be used across multiple websites. Ultimately, it is a way to eliminate multiple user accounts across different websites. This layer can simply be added on top of OAuth.
So as a quick recap:
- OpenID is about authentication (ie. proving who you are).
- OAuth is about authorization (ie. to grant access to functionality/data/etc without having to deal with the original authentication).
OAuth could be used in external partner sites to allow access to protected data without them having to re-authenticate a user (every time an API call is made).