Authentication

All of our APIs use OAuth 2.0 for authentication. To make API requests you will need a valid access token.
All of our APIs use OAuth 2.0 framework for authentication. OAuth 2 is an authentication framework used worldwide that enables a third-party application to obtain limited and secure access to protected resources without requirement to pass user credentials. It works by delegating user authentication to the service that hosts the user account, and authorizing third-party applications to access the user account. OAuth 2 provides authorization flows for web and desktop applications, and mobile devices.
Requests to the authorization server must use https (the server is only accessible over SSL).
OAuth 2.0 Roles
OAuth defines four roles:

Role description
Resource owner
(the User)
The resource owner is the user who authorizes an application to access some portion of their account.. The application's access to the user's account is limited to the "scope" of the authorization granted (e.g. read or write access).
Resource server
(the API server)
The resource server is the API server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.
Client
(the Third-Party Application)
The client is an application that wants to access protected resources on behalf of the resource owner (user) and with its authorization. The client could hosted on a server, desktop, mobile or other device.
Authorization server
(often the same as the API server)
The server issuing access tokens to the client after successfully authenticating a client and resource owner, and authorizing the request.
OAuth 2.0 Endpoints


Endpoint description
Authorize Endpoint The resource owner is redirected here by the client to authorize the request.
Token Endpoint The client makes a request to this endpoint in order to obtain an access token.
Resource Endpoint(s) The client requests resources, providing an access token for authentication token.
3-Legged vs 2-Legged Authorization
An application that requires authorization from the end user is called three-legged in OAuth terminology because the authorization occurs between three parties: the user (resource owner), the client (third-party application), and the resource server (api service provider).

An application that does not require authorization from the end user is called two-legged in OAuth terminology because the authorization occurs between two parties: the client (third-party application), and the resource server (api service provider). In this case the current user is not known.
OAuth 2.0 Token Types


Token type description
Access Token Access tokens are credentials presented by the client to the resource server to access protected resources. It's normally a string which includes information about scope, lifetime, client, user, app. Access tokens have an expiration time which can last anywhere from a few minutes to several hours. Access tokens are obtained via a number of methods each of which are covered later in the document.
Refresh Token The refresh token enables your application to change expired access tokens for new ones. While access tokens can expire anywhere from few minutes to several hours, a refresh token has a 14 days lifetime. Once an access token is expired, the client can request the authorization server to issue a new access token using the refresh token without redoing authorization. If your application loses the refresh token, the user will need to repeat the OAuth 2.0 flow so that your application can obtain a new refresh token.
OAuth 2.0 Grant Types
Grant types are different ways of granting an access token. The end goal of each of these grants (except the refresh token grant) is for the client application to have an access token which it can use to authenticate a request to a resource endpoint.

The grant types supported by OptimalResume Api's are:

Grant type description
Authorization Code Intended for apps running on a web server (web apps that can securely store persistent information).
Click here to generate an access token using this grant type.
Implicit Intended for Browser-based (eg: javascript applications) or Mobile apps (eg: applications that run on a user’s device).
Click here to generate an access token using this grant type.
Username and password Can be used to exchange a username and password for an access token directly.
Click here to generate an access token using this grant type.
Client credentials Used to authenticate the client (instead of asking for authorization from the user). In this case the current user is not known.
Click here to generate an access token using this grant type.
Refresh token Used to refresh/renew an access token which has expired without redoing authorization.
Click here to generate an access token using this grant type.
SAML Assertion Flow Used to exchange an SAML assertion for an access token. The SAML assertion is POSTed to the OAuth token endpoint, which in turn processes the assertion, and issues an access_token.
Click here to generate an access token using this grant type.