High level overview - OAuth in SmartRecruiters
SmartRecruiters support three-legged OAuth processing which involves four parties:
-
Resource owner (SmartRecruiters customer)
-
OAuth client (third-party vendor)
-
SmartRecruiters authorization server, and
-
SmartRecruiters resource server (serves data via Customer API)
Three-legged OAuth is a traditional pattern with resource owner interaction. In this case, a resource owner (SR customer) wants to give a client (third-party vendor) access to a server without sharing credentials.
Using the Server-side flow chart:
User = SmartRecruiters Customer
App XYZ = Third-party Vendor
Service ABC = SmartRecruiters Web Services
The typical flow for three-legged OAuth processing involves the following activities:
-
A user, as the resource owner, initiates a request to the OAuth client (third-party vendor).
-
The OAuth client sends the resource owner a redirection to the authorization server (SR).
-
The resource owner authenticates and optionally authorizes with the authorization server (SR customer is asked to login to his SR account and allow the vendor access to his data).
-
The authorization server presents a form to the resource owner to grant access (the pre-defined request scope is listed).
-
The resource owner submits the form to allow or to deny access.
-
Based on the response from the resource owner, the following processing occurs:
-
If the resource owner allows access, the authorization server sends the OAuth client a redirection with the authorization grant code or the access token (in the SR flow, the code is sent, then vendor needs to exchange it for an access_token).
-
If the resource owner denies access, the request is redirected to the OAuth client but no grant is provided.
-
-
The OAuth client sends the following information to the token endpoint (authorization server).
-
Authorization grant code
-
Client ID
-
Client secret or client certificate
-
-
If verified, the authorization server sends the OAuth client an access token and optionally a refresh token (in SR a refresh_token is always sent).
-
The OAuth client sends the access token to the resource server to request protected resources.
-
If the access token is valid for the requested resources, the OAuth client can access the protected resources (SR Customer API).