OAuth (Open Authorization) is a standard for authorization of resources. It allows users in an organization to login using OAuth/OpenID connect providers like Microsoft Azure AD, AWS Cognito, Google apps, Facebook, etc & share their information with enterprise applications. It makes use of a token-based authorization mechanism to grant access to users across enterprise applications.
Applications that support login using third party services generally prompt the user to authenticate themselves by giving options like “Login With Facebook” or “Login With Google” etc. thus, allowing the user to use their credentials to login with the third party service. In response, the service sends the access token to the requesting application which proves the authenticity of the user who is requesting access. The token is then used for making requests to resources required by the end-user.
OAuth is suitable for both browser and mobile applications and it is widely used for customer application and API access. Basically, it uses JSON to transfer messages between applications & uses HTTP for requesting and receiving tokens.
OAuth users are those who are trying to leverage the implementation of the secure protocol by applications such as Google, Microsoft, Paypal, who ensure that the identities are authentic.
OAuth 1.0 Vs OAuth 2.0
|OAuth 1.0||OAuth 2.0|
|Used complicated cryptographic requirements.||Faster and easier to implement.|
|It requires encrypting the token on the endpoints.||Tokens no longer need to be encrypted on the endpoints in 2.0 since they are encrypted in transit.|
|Supported three flows, and did not scale.||On the other hand, it has six flows for different types of applications and requirements and enables signed secrets over HTTPS.|
Before OAuth, HTTP was the Basic Authentication standard, where the user is prompted for a username and password for accessing each application. Websites would prompt you to enter your username and password directly into a form and they would log in to your data (e.g. your Gmail account) as you.
Basic Authentication is still used as a primitive form of API authentication for server-side applications wherein instead of sending a username and password to the server with each request, the user sends an API key ID and secret.
Contrary to the above, OAuth allows authentication using access tokens which is more secure as no sharing of passwords is involved.
How does OAuth work ?
OAuth Single Sign On (SSO) Workflow:
- An unknown user tries to access the resources.
- Web application sends an authorization request to OAuth Provider.
- An OAuth Server prompts the user to login and authorizes the application.
- The user is redirected to the login page where the user logs in.
- An OAuth Provider authenticates the user and sends the authorization code to miniOrange web application.
- Web application sends its own client_id, client_secret with the authorization code that has received from OAuth Server.
- Server then authenticates the request and sends the Access token to miniOrange OAuth Client.
- Your web application uses the access token to access resources on the resource server.
- Using access token, id token and user info miniOrange allows the user to access protected features.
- Now, the user authenticated and logged in. Thus, the application gives access to resources.
Let us take an example to show you how to implement OAuth as a Consumer:
1.Register Your App:
Registering your app with the OAuth identity provider like Azure AD, AWS Cognito, Facebook, Google Apps, etc. involves creating an app and entering app-related data. On successful registration of the app, you receive a consumer key and a secret key. These keys are used for identifying your app to the OAuth provider and are required when requesting token.
2.Client application request OAuth provider for Access Token:
Your registered app can now send an Authorization request to the OAuth provider asking for an Access Token. User need to authenticate with OAuth provider and presented with an authorization page consent asking them to give permissions to your application to access specific user data. Once the user approves the consent, one-time token is generated for the user and passed to the client application.
3.Exchange the one time request token with OAuth access token:
After the user grants permissions to your application, your application can exchange the request token with an access token. The access token is used by your application for requesting the specific resources from the OAuth provider which the user granted permission to access.
- End-User/Resource Owner- Resource Owner is the end-user who wants to access the protected resource. The user can perform read/write operations on the resource depending on their authorized permissions.
- Resource Server- The resource which is requested by the end-user is present on the resource server. The resource server handles requests to access/update the resource and also forwards authentication requests to the Authorization Server. It does not allow access to the resource unless the request contains the appropriate access token.
- Authorization Server- It is the authentication server that handles login requests and validates the user identity. It also provides the requested user information along with the access token to the Resource Server.
1.Prevents the need to maintain authentication service:
Since OAuth allows applications to authenticate users by establishing their identity from third-party services, this removes the need for the application to implement its own authentication system.
2.Easy sharing of user data:
Since SSO requires a single set of credentials for authentication and provides access to multiple apps/websites, the user needs to only remember a single password contrary to remembering multiple passwords for each individual app/website.
Usually, the authenticating applications (Google, Facebook), etc. are trusted more by the users than your own application. Hence, they will readily authenticate themselves with those services without worrying about sharing their information directly.
It exclusively makes use of the HTTP protocol for sending and receiving information and access tokens. This makes the implementation of OAuth service as well as the client simpler as there are no complex standards or definitions involved.
- Security Vulnerability: If you use a single service to connect to all your other favorite sites and the single account gets hacked, the consequences are felt across several sites instead of just one. For example, if you are logged in with Facebook for all the applications and later if your Facebook account got hacked, your identity and information are compromised across several sites instead of just one.
- Data Misuse: Even though OAuth limits new websites and applications from obtaining all of your user data and selling it against your will, you still need to trust the authenticating service with your data. This means your data is possessed by the service and you can no longer control whether or not it can be misused without your permission.
OAuth Vs SAML
|Protocol||OAuth is an authorization protocol.||SAML is an authentication protocol.|
|Usage Scenario||Used by those who are not looking to maintain identities but are rather trying to leverage the implementation of the secure protocol by applications such as Google, Microsoft, PayPal, who ensure that the identities are authentic.||Used by those who are looking for federation and identity management. They will use this identity to login to the users to different applications.|
|Suitable Application||Suitable for both browser and mobile applications.||Popular for browser-based applications.|
|Commonly Used By||Widely used for customer applications and API access.||Widely used for enterprise applications.|
|Data Format||Uses JSON to transfer messages between applications.||Uses XML to transfer messages between applications.|
- Authorization Grant: The authorization code grant is used by web and mobile apps to exchange an authorization code for the access token. During the Single Sign-On process, when the user gets redirected to the client app after authorizing themselves on the OAuth server login page, the app gets an authorization code from the URL which can be used to get the access token.
- Implicit Grant: The Implicit grant type is a simplified flow that can be used by public clients, where the access token is returned immediately without an extra authorization code exchange step.
- Password Grant: The resource owner password (or “password”) grant type is mostly used in cases where the app is highly trusted. In this grant, the user provides their resource server credentials (username/password) to the client app, which sends them in an access token request.
- Client Credentials Grant: Client Credentials grant can be used for machine-to-machine authentication. In this grant, a specific user is not authorized but rather the credentials are verified and a generic access_token is returned.
- Refresh Token Grant: A Refresh Token allows the application to issue a new Access Token or ID Token without having to re-authenticate the user. This will work as long as the Refresh Token has not been revoked.
- Authorization Endpoint: The authorization endpoint is an endpoint on the authorization server where the resource owner logs in, and grants authorization to the client application.
- Token Endpoint: The token endpoint is an endpoint on the authorization server where the client application exchanges the authorization code, client ID, and client secret, for an access token.