OAuth 2.0 authorization

Authorized

When a client app wants to access resources hosted by the owner on the resource server, it must first be authorized, and this section describes how the client obtains authorization.

Client identity, client key, and redirect URL

Before a client app can request resources to access the resource server, the client application must first register in the authorized server associated with the resource server.

Register for a one-time task. Once registered, the registration will remain in effect unless the client registration is cancelled.

After registration, the client app will be assigned the client identity and key by the authorization server. O n the authorization server, the client identity and key are uniquely identified by the client app. If a client app registers more than one authorized server (such as Facebook, Twitter, Google, etc.), each authorized server issues a unique identity to the client app.

Whenever a client applies and wants access to resources on the same resource server, it needs to authenticate itself by sending the client identity and key to the authorization server.

During the registration process, the client app also registers a redirect URL that is used when the resource owner authorizes the client app. When the resource owner successfully authorizes the client app through the authorization server, the resource owner is redirected back to the client app and then jumps to the redirect URL.

• Authorize approval

Authorization approval is granted to client applications by the resource server, and the authorization server associated with it.

OAuth 2.0 lists four different types of authorization approvals, each with different security characteristics. These authorization approval types are:

• Authorization code
• Contract
• The resource owner key certificate
• The client certificate
• Each authorization is mentioned below.

Authorization code

The authorization code is used to authorize approval as follows: The resource owner (user) accesses the client app. Client apps tell users to sign in to client apps through authorized servers such as Facebook, Google, and Twitter.

In order to log on through the authorization server, the user is redirected to the authorization server through the client app. W hen a client app sends its client identity to an authorized server, the authorized server knows which application is trying to access the protected resource. W hen redirected back to the client app, the authorization server sends a user-specific redirect URL, which means that the client has registered with the authorization server in advance. With redirection, the authorization server sends an authorization code that represents the authorization.

When the redirect URL of the client app is accessed, the client app connects directly to the authorization server. The client app sends authorization codes, client identities, and keys, and if the client app accepts these values, the authorization server returns an access token.

The client app can now use the access token to request resources from the resource server. The access token can be used as a client to authorize and authorize access to resources.

Here's how to authorize client applications with an authorization code:

Authorization via authorization code

Contract

Contract authorization is similar to authorization code authorization, except that the access token is returned to the client app after the user completes the authorization. When the user agent is redirected to the redirect URL, the access token is returned.

This means, of course, that access tokens can be accessed by user agents, or native apps that participate in the contract authorization process. Access tokens are not stored securely on the web server.

Further, the client app can send only its client identity to the authorization server. If the client also sends its key, the client key will have to be saved in a user agent or native app, which will make it easy to crack.

Contract authorization is mostly used in user agents or native applications. The user agent or native app will receive an access token to authorize the server.

Here's a diagram illustrating contractual authorization:

Contractual authorization

The resource owner key certificate

The resource owner certificate authorization method works by applying the client app to access the resource owner certificate. F or example, a user can enter his Twitter userna name and key (certificate) in the client app. The client app can access users' resources on Twitter with a user name and key.

Using a resource owner key certificate requires the client to apply a lot of trust. You don't want to enter certificates in client apps that you suspect will abuse them.

Resource owner key certificates are typically used in user agents or native apps.

The client certificate

Client certificate authorization is used in situations where clients need to access resources or call functions on the resource server, regardless of a particular resource owner, such as a user. For example, getting a list of venues from Foursquare doesn't have to be done by a Foursquare user.