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. and share their information with enterprise applications. OAuth makes use of 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 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. OAuth uses JSON to transfer messages between applications. OAuth exclusively uses HTTP for requesting and receiving tokens.
OAuth will be used by those who are not looking to maintain identities but are rather trying to leverage the implementation of secure protocol by applications such as Google, Microsoft, Paypal, who ensure that the identities are authentic.
|OAuth 1.0||OAuth 2.0|
|OAuth 1.0 used complicated cryptographic requirements.||OAuth 2.0 is faster and easier to implement.|
|It requires to encrypt the OAuth token on the endpoints.||OAuth tokens no longer need to be encrypted on the endpoints in 2.0 since they are encrypted in transit.|
|OAuth 1.0 only supported three flows, and did not scale.||OAuth 2.0, on the other hand, has six flows for different types of applications and requirements, and enables signed secrets over HTTPS.|
Before OAuth, HTTP Basic Authentication was the 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.
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.
Your registered app can now send 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 user approve the consent, one time token is generated for the user and passed to the client application.
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.
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.
Since SSO requires 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.
OAuth 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 is no complex standards or definitions involved.
|Protocol||OAuth is an authorization protocol.||SAML is an authentication protocol.|
|Usage Scenario||OAuth will be used by those who are not looking to maintain identities but are rather trying to leverage the implementation of secure protocol by applications such as Google, Microsoft, Paypal, who ensure that the identities are authentic.||SAML will be used by those who are looking for federation and identity management. They will use this identity to login the users to different applications.|
|Suitable Application||OAuth is suitable for both browser and mobile applications.||SAML is popular for browser-based applications.|
|Commonly Used By||OAuth is widely used for customer applications and API access.||SAML is widely used for enterprise applications.|
|Data Format||OAuth uses JSON to transfer messages between applications.||SAML uses XML to transfer messages between applications.|