{"id":36243,"date":"2024-08-21T13:59:19","date_gmt":"2024-08-21T12:59:19","guid":{"rendered":"https:\/\/developers.ila.cegid.com\/valuekeep\/\/"},"modified":"2024-12-26T15:46:31","modified_gmt":"2024-12-26T14:46:31","slug":"webapi-how-does-the-oauth-2-0-authorization-work","status":"publish","type":"valuekeep","link":"https:\/\/developers.ila.cegid.com\/en\/valuekeep\/api-documentation-en\/web-api-en\/article\/webapi-how-does-the-oauth-2-0-authorization-work","title":{"rendered":"How does the OAUTH 2.0 authorization work?"},"content":{"rendered":"

OAuth 2.0 is a standard authorization protocol that allows applications to access a user’s account in a web service (HTTP) such as the Valuekeep CMMS Web API.<\/span><\/p>\n

The protocol delegates user authentication to the service that holds the user’s account and authorizes external applications to access that user’s account. The protocol makes authorization flows available for Web, desktop and mobile apps.<\/span><\/p>\n

We now describe the basic operation of the protocol from the perspective of an application developer.<\/span><\/p>\n

OAuth Roles<\/h2>\n

The protocol defines 4 roles:<\/span><\/p>\n

    \n
  1. Resource owner<\/span><\/b>: this is the user who authorizes the application’s access to his account. Such access is limited to the scope of the authorization given by the user.<\/span><\/span><\/li>\n
  2. Client<\/b>: is the application that wants to access the user <\/span>account.<\/li>\n
  3. Resource server<\/b>: is the server that hosts the user’s <\/span>accounts.<\/li>\n
  4. Authorization server<\/b>: is the server that verifies the <\/span>identity of the user and assigns authorization tokens to the client (the application).<\/li>\n<\/ol>\n

    From the point of view of an application developer, the Web API you want to consume acts both as resource server and the authorization server. It is, therefore, common for the two roles to be combined in what is called a Service or simply an API.<\/span><\/p>\n

    Generic authorization flow<\/h2>\n

    The normal authorization flow from an external application will follow these steps:<\/span><\/p>\n

      \n
    1. The application requests permission to access user resources.<\/span><\/span><\/li>\n
    2. If the user has already authorized such a request, the application receives an authorization grant.<\/li>\n
    3. The application asks the authorization server for an access token, showing the user’s identity and the authorization grant.<\/li>\n
    4. If the application’s identity is authenticated and the authorization grant is valid, the authorization server assigns an access token to the application and the authorization flow ends.<\/li>\n
    5. The application requests a certain resource from the resource server and displays the access token it obtained before.<\/li>\n
    6. If the access token is valid, the resource server will return the requested resource to the application.<\/li>\n
    7. This is OAuth’s normal conceptual flow, but the actual authentication flow depends on the type of authorization grant <\/span>that is used. We will now discuss the different authorization grants available.<\/li>\n<\/ol>\n

      Authorization Grant: Client credentials grant<\/h2>\n

      The type of grant used depends on the authorization method the app wishes to use and, of course, of the methods supported by the Web API. To work with the Valuekeep CMMS Web API, you must use the Client Credentials authorization method.<\/span><\/p>\n

      Refresh Token<\/h2>\n

      When an access token expires, its use to perform requests to the API will result in the error \u201cInvalid Token Error\u201d. In that moment, if a refresh token has been included when the access token is generated, you can use it for a new server access token.<\/span><\/span><\/p>\n

      Example of a request of that type:<\/span><\/span><\/p>\n

      \n

      1.
      \n<\/span><\/span>https:\/\/myserver.com\/v1\/oauth\/token?grant_type=refresh_token&client_id={ClientId}&client_secret={ClientSecret}&refresh_token={RefreshToken}%E2%80%8B<\/a><\/span><\/span><\/p>\n<\/div>\n

      <\/div>\n<\/div><\/section>\n","protected":false},"excerpt":{"rendered":"","protected":false},"featured_media":0,"menu_order":0,"comment_status":"open","ping_status":"open","template":"","format":"standard","tags":[840],"videos_tax":[],"post-type":[300],"categoria-valuekeep":[998],"class_list":["post-36243","valuekeep","type-valuekeep","status-publish","format-standard","hentry","tag-oauth","post-type-artigo","categoria-valuekeep-web-api-en"],"_links":{"self":[{"href":"https:\/\/developers.ila.cegid.com\/en\/wp-json\/wp\/v2\/valuekeep\/36243","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/developers.ila.cegid.com\/en\/wp-json\/wp\/v2\/valuekeep"}],"about":[{"href":"https:\/\/developers.ila.cegid.com\/en\/wp-json\/wp\/v2\/types\/valuekeep"}],"replies":[{"embeddable":true,"href":"https:\/\/developers.ila.cegid.com\/en\/wp-json\/wp\/v2\/comments?post=36243"}],"version-history":[{"count":0,"href":"https:\/\/developers.ila.cegid.com\/en\/wp-json\/wp\/v2\/valuekeep\/36243\/revisions"}],"wp:attachment":[{"href":"https:\/\/developers.ila.cegid.com\/en\/wp-json\/wp\/v2\/media?parent=36243"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/developers.ila.cegid.com\/en\/wp-json\/wp\/v2\/tags?post=36243"},{"taxonomy":"videos_tax","embeddable":true,"href":"https:\/\/developers.ila.cegid.com\/en\/wp-json\/wp\/v2\/videos_tax?post=36243"},{"taxonomy":"post-type","embeddable":true,"href":"https:\/\/developers.ila.cegid.com\/en\/wp-json\/wp\/v2\/post-type?post=36243"},{"taxonomy":"categoria-valuekeep","embeddable":true,"href":"https:\/\/developers.ila.cegid.com\/en\/wp-json\/wp\/v2\/categoria-valuekeep?post=36243"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}