Hi Guys,

Today I’m will write this article about what ring central is made to access their APIs. Ringcentral is come up with OAuth authentication rule to get access ringcentral apis.

So, first of all let me explain the OAuth authentication.

OAuth

OAuth combines Authentication and Authorization to allow more sophisticated scope and validity control.

OAuth is a bit of a strange beast. OAuth is not technically an authentication method, but a method of both authentication and authorization. When OAuth is used solely for authentication, it is what is referred to as “pseudo-authentication.”

In this approach, the user logs into a system. That system will then request authentication, usually in the form of a token. The user will then forward this request to an authentication server, which will either reject or allow this authentication. From here, the token is provided to the user, and then to the requester. Such a token can then be checked at any time independently of the user by the requester for validation, and can be used over time with strictly limited scope and age of validity.

This is fundamentally a much more secure and powerful system than the other approaches, largely because it allows for the soft establishment of scope (that is, what systems the key allows the user to authenticate to) and validity (meaning the key doesn’t have to be purposely revoked by the system, it will automatically become deprecated in time).

In Ringcentral, they have provided three api calls to for the authentication process.

1. Authorization
2. Get Token
3. Revoke Token

Authorization Code Flow

First step as you need to create a application using ring central developer account. We need to authorize your application with ring central so that it will gain the client id to get authorization token. To do so while you click on the authorize button and at the background ringcentral will make a api call to get client id and client secret which will be useful to call token service.

GET /restapi/oauth/authorize

Get Token

OAuth 1.0 and 1.0a, were much more complicated than OAuth 2.0. The biggest change in the latest version is that it’s no longer required to sign each call with a keyed hash. The most common implementations of OAuth use one or both of these tokens instead:

• access token: sent like an API key, it allows the application to access a user’s data; optionally, access tokens can expire.
• refresh token: optionally part of an OAuth flow, refresh tokens retrieve a new access token if they have expired. OAuth2 combines Authentication and Authorization to allow more sophisticated scope and validity control.

OAuth 2.0 is the best choice for identifying personal user accounts and granting proper permissions. In this method, the user logs into a system. That system will then request authentication, usually in the form of a token. The user will then forward this request to an authentication server, which will either reject or allow this authentication. From here, the token is provided to the user, and then to the requester. Such a token can then be checked at any time independently of the user by the requester for validation and can be used over time with strictly limited scope and age of validity.

Revoke Token

Revokes access/refresh token. Requests to this endpoint must be authenticated with HTTP Basic scheme using client ID and client secret as login and password, correspondingly.

The server will respond wih a 200 status code on successful revocation. You can use curl to make a revoke request on your server. If you have access to a local installation of your authorization server, you can test revoking a token with a request like that shown below, for a Confidential client.
Request:

POST /restapi/oauth/revoke HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: Basic M2ZmYjNlMThkZDU4ZDE1YTk2NTIwYmFmNzUzZjBiNzk6MzI5OWQ0NTg5NGU1Njg5ODllOTY1ZTFiMTk5MGU2OTI

token=U0pDMDFQMDFKV1MwMXwJ_W7L1fG4eGXBW9Pp-otywzriCw

Response:

HTTP/1.1 200 OK

Thank you for reading!