Starting OAuth 2.0

  • In order for an app developed by the developer to use the cafe24 API, authentication / security procedures must be completed first.
  • Authentication at cafe24 is provided in OAuth 2.0 and adheres to the recommendations of RFC 6749.
  • The developer's app must implement the OAuth client.

OAuth 2.0 overview

  • When using Internet services in general, the contents that contain personal information or need protection require a login using an ID and password to verify the owner‘s identity.
    As Internet services evolve, it becomes necessary to use and share the contents across platforms.
    As a result, there is a problem associated with the conventional way that the owner has to expose ID and password to the platform.
    The owner may only want to share the information he/she desires without providing the ID and password.
    The OAuth 2.0 is a framework that grants a third-party platform the scope to use the contents in order to solve such problems, and is widely employed by most of the global corporations like Google and Facebook.
  • To understand the OAuth, it is crucial to understand the flow.
  • Before explaining the flow, the major roles are first described.
OAuth 2.0 overview
Terms Description
Resource Owner Refers to the owner of the protected contents (e.g. email, calender, memo and address book).
Client It is an application that makes requests for protected contents to the resource server on behalf of the resource owner.
Resource Server Refers to the server that manages the protected contents. The protected contents are accessible using the Access Token, which verifies the scope has been granted by the resource owner.
  • In addition, there are other roles such as "Authorization server" and "Authentication server," and cafe24‘s server replaces these roles.

OAuth 2.0 Flow

  • The major flow of OAuth is code issuance > Access Token issuance > API call.
  • Suppose you have a client that is built in the form of a website.
  • This client attempts to use the data from the resource server.
  • ① First, the resource owner initially executes the client with a web browser.
  • ② The client needs an Access Token to use the data, but it does not have an Access Token in its initial execution, so it enters the scope delegation process.
  • ③ When delegation is completed, a code that can be exchanged with the Access Token is issued.
  • This is the blue box part of the figure above and this procedure must be done through a web browser.
  • Developers can retrieve the code from the Querystring passed through the web browser.
  • ④ Now, if you exchange the issued code with the Access Token, ⑤ You can use the data by calling the API.
  • This process is described in the yellow box, and a request for an issuance of the Access Token must be made to the resource server by using the API at the server where the client is executed.
  • The Access Token has a very short validity period and must be reissued periodically.
  • ⑥ When reissuing, you do not need to execute the authorization delegation process again and use the Refresh Token to have the Access Token reissued.
  • If you understand the flow of the OAuth up to this point, you can implement your own OAuth Client.

Implementation of OAuth Client

  • The role of the OAuth in cafe24 is defined below.
Implementation of OAuth Client
Standard terms Terms used in cafe24
Resource Owner Shopping mall operator
Client App (Application)
Resource Server cafe24 shopping mall
  • The figure below shows data in the basic flow of OAuth.
  • If you implement the OAuth Client by referring to this figure and step-by-step sample requests, you are all ready for your app development.