UNDERSTANDING OATH 2.0 PODCAST NOTES AND REFERENCES

By: Saurav

2020-10-18 04:03:00 UTC

Oath vs Oath 2.0
- OAuth 2.0 is a complete rewrite of OAuth 1.0
- It only shares overall goals and general user experience.
- OAuth 2.0 is not backwards compatible with OAuth 1.0 or 1.1
- It is a completely new protocol.

Companies involved
- A lot more companies were involved in the development of Oath 2.0 like Yahoo!, Facebook, Salesforce, Microsoft, Twitter, Deutsche Telekom, Intuit, Mozilla and Google.
While
For Oath , only two major companies - Flickr’s authorization API and Google’s AuthSub.

Server distinctions
- Oath does not explicitly separate the roles of resource server and authorization server. While Oath 2.0 has the distinction
- One of the design decisions that went into OAuth 2.0 was to explicitly separate the roles of the authorization server from the API server. This means you can build out the authorization server as a standalone component which is only responsible for obtaining authorization from users and issuing tokens to clients.

Use issues
- The complexity of OAuth 1.0 signatures was a major pain point for anyone coming from the simplicity of username/password authentication.
- Couldn't use Simple Curl request
- OAuth Sucked on Developer happiness
- Developer were forced to find, install, and configure libraries in order to make requests to the Twitter API since it requires cryptographic signing of each request.
- With the introduction of OAuth 2.0 Bearer tokens, it is again possible to quickly make API calls from a cURL command. The access token is used instead of a username and password.

Oath 2.0
- curl https://api.example.com/profile -H "Authorization: Bearer XXXXXXXXXXX"

Flows
- OAuth 1.0 started out with 3 flows, for web-based applications, desktop clients, and mobile or “limited” devices. However, as the specification evolved, the three flows were merged into one which, in theory, enabled all three client types. In practice, the flow worked fine for web-based applications but provided an inferior experience elsewhere.
- OAuth 2.0 addresses this by defining multiple flows again, called “grant types,”
- There is also a mechanism to develop extensions to handle use cases not previously thought of. Example Device Flow, for authorizing apps on devices that don’t have a web browser.

Scalability
- Oath 2.0 needs the client credentials only when the application obtains authorization from the user.
- Once the credentials are used in the authorization step, only the resulting access token is used when making API calls.
- Oath 1 uses cryptographic signing of each request.
- “Bearer Token”. This is a single string which acts as the authentication of the API request, sent in an HTTP “Authorization” header.
- With OAuth 2.0, the authorization server can issue a short-lived access token and a long-lived refresh token while ion Oath 1.0, these tokens could last indefinitely, or on the order of a year without the ability of server to revoke tokens.

OAuth 2 is a seamless authorization framework that enables 3rd party applications to obtain limited access to user accounts on a different HTTP service, such as Facebook, GitHub, Twitter etc.
It works by using authentication server hosted on the HTTP service and authorizing third-party applications to access the user account in the said service.

Oath2 Roles:

Resource Owner
> user who authorizes an application to access their account. The application’s access to the user’s account is limited to the “scope” of the authorization granted

Client
> The client is the application that wants to access the user’s account. Before it may do so, it must be authorized by the user, and the authorization must be validated by the API.

Resource Server
Authorization Server
> The resource server hosts the protected user accounts, and the authorization server verifies the identity of the user then issues access tokens to the application.

Application Registration
Before using OAuth 2 with your application, you must register your application with the service.
This is done through a registration form in the “developer” or “API” portion of the service’s website, where you provide the following

Application Name
Application Website
Redirect URI or Callback URL

The redirect URI is where the service will redirect the user after they authorize (or deny) your application, This is the part of the application that will handle authorization codes or access tokens.

Client ID and Client Secret
> The Client ID is a publicly exposed string that is used by the service API to identify the application, and is also used to build authorization URLs that are presented to users.
> The Client Secret is used to authenticate the identity of the application to the service API (must be kept secret)

OAuth 2 defines four grant types, each of which is useful in different cases:
> Authorization Code: used with server-side Applications

https://cloud.digitalocean.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read
H

Response types is code

Optimized for server-side applications, where source code is not publicly exposed, and Client Secret confidentiality can be maintained.
https://cloud.digitalocean.com/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL
If a refresh token was issued, it may be used to request new access tokens if the original token has expired, so user agent need not grant authorization again and again.

> Implicit: Similar to the above, works with redirection .It is used with Mobile Apps or Web Applications (applications that run on the user’s device)
The implicit grant type is used for mobile apps and web applications (i.e. applications that run in a web browser), where the client secret confidentiality is not guaranteed. This flow does not authenticate the identity of the application, and relies on the redirect URI (that was registered with the service) to serve this purpose.

The implicit grant type does not support refresh tokens.

https://cloud.digitalocean.com/v1/oauth/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

Response type is Token

> Resource Owner Password Credentials: used with trusted Applications, such as those owned by the service itself
The user provides their service credentials (username and password) directly to the application, which uses the credentials to obtain an access token from the service.

> Client Credentials: used with Applications API access
The client credentials grant type provides an application a way to access its own service account.
- An application wants to update its registered description or redirect URI,
- Access other data stored in its service account via the API.

References :

Digital Ocean Blog by Mitchell Anicas
https://www.oauth.com/oauth2-servers/differences-between-oauth-1-2/>Oath.com

Owned & Maintained by Saurav Prakash

If you like what you see, you can help me cover server costs or buy me a cup of coffee though donation :)