Skip to main content
SmartRecruiters

High level overview - OAuth in SmartRecruiters

  1. Last updated
  2. Save as PDF

 

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:

  1. A user, as the resource owner, initiates a request to the OAuth client (third-party vendor).

  2. The OAuth client sends the resource owner a redirection to the authorization server (SR).

  3. 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).

  4. The authorization server presents a form to the resource owner to grant access (the pre-defined request scope is listed).

  5. The resource owner submits the form to allow or to deny access.

  6. 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.

  7. The OAuth client sends the following information to the token endpoint (authorization server).

    • Authorization grant code

    • Client ID

    • Client secret or client certificate

  8. 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).

  9. The OAuth client sends the access token to the resource server to request protected resources.

  10. If the access token is valid for the requested resources, the OAuth client can access the protected resources (SR Customer API).