OAuth2.0 concept and integration
    • PDF

    OAuth2.0 concept and integration

    • PDF

    Article Summary

    Available in Classic and VPC

    Open Authorization 2.0 or OAuth2.0 is an open standard protocol for web and application authentication and authorization. This protocol defines the procedures for third-party applications to access user resources and grants permissions to use service provider's APIs. Representative social media simple logins include NAVER login and Google login. The simple login OAuth2.0 to allow a third-party application to access the user's social media profile information. Because B2B PRISM Live Studio also uses OAuth2.0 to manage permissions, this section contains a description of the basic concept of OAuth2.0 and the authorization methods.

    OAuth 2.0 roles

    The 4 roles of OAuth 2.0 are as follows:

    • Resource Owner: entity who grants access permissions to protected resources using the OAuth 2.0 protocol. Performs the role of authorizing the client. An example of a resource owner is a user who owns a NAVER ID in NAVER login and uses the NAVER ID for social login authentication on a third-party application (client).
    • Client: third-party application or service that uses OAuth 2.0 to access resources.
    • Authorization Server: server that assists the client in obtaining the resource owner's permission. The authorization server manages user authentication, authorization, and token issuance.
    • Resource Server: hosts protected resources and either allows or denies access. This server uses OAuth 2.0 to grant clients permission to access resources and provides actual data.

    OAuth 2.0 glossary

    The terms you need to know to understand OAuth 2.0 are as follows:

    • Access Token: token that grants the permission to allow the client to access resources on the resource server. Access tokens are issued by the authorization server and generally have a limited validity period.
    • Refresh Token: token used to obtain a new access token after the validity period of the access token expires. It allows users to continue using the application by refreshing the token validity without the need to log in again.
    • Scope: string that defines what actions the client can perform on the resource. Scopes are defined by the authorization server, and clients can request access permissions for specific scopes.
    • Authorization Code: code used as an intermediate step for the client to obtain an access token. The code is issued by the authorization server through the Authorization Code Grant method and is used to obtain access tokens and refresh tokens.

    OAuth 2.0 authorization method

    OAuth 2.0 provides various authorization methods to grant and manage permissions that allows client applications to access resource servers. This guide covers the Authorization Code Grant method used in B2B PRISM Live Studio authorization in detail.

    Authorization Code Grant

    It's the method of forwarding a self-generated authorization code for authorization approval, which is the most commonly used method. As the most secure method, it ensures the access token is not directly exposed to the client. This method is used in environments deemed trustworthy, such as web applications or server applications.

    OAuth 2.0 authorization process

    The authorization process is as follows:

    b2bpls-oauth2_authorization-flow_ko

    1. Request an authorization code
      • Request an authorization code by specifying response_type as code, along with the client ID and redirect_uri information previously issued by the authorization server.
    2. Log in
      • The authorization server provides a login page, and the resource owner logs in.
    3. Forward an authorization code
      • When the resource owner is successfully logged in, the authorization server forwards the authorization code to the provided redirect_uri.
    4. Issue an access token
      • The client owner obtains an access token (and refresh token) using the authorization grant code.
      • At this point, the client ID and client secret information issued by the authorization server beforehand are required.

    Call examples

    The following are examples of calls:

    1. Request an authorization code

      curl -X GET https://authorization-server.example.com/oauth/authorize
                    ?response_type=code
                    &client_id=your_client_id
                    &redirect_uri=your_redirect_uri
                    &state=your_state
                    &scope=your_scope
      
      Note

      B2B PRISM Live Studio does not use the scope and state values.

    2. Issue an access token

      curl -X POST "https://authorization-server.example.com/token" \
      -d "grant_type=authorization_code" \
      -d "code=your_authorization_code" \
      -d "client_id=your_client_id" \
      -d "client_secret=your_client_secret" \
      -d "redirect_uri=your_redirect_uri"
      

    Roles of PRISM and customer services used in OAuth 2.0 authentication

    B2B PRISM Live Studio serves as an OAuth2.0 client, while the service you're using serves as both an authorization server and a resource server.

    Customer service development guide

    APIs for OAuth2 authentication must be implemented.

    Pre-registration guide

    To use OAuth 2.0 authentication, register the following items in the NCP dashboard console in advance:

    • OAuth 2.0 authorization code issuance URL
      • If not registered, called as the default value. (Service domain + /oauth/authorize)
    • Client ID for B2B PRISM Live Studio
    • Client Secret for B2B PRISM Live Studio

    Was this article helpful?

    Changing your password will log you out immediately. Use the new password to log back in.
    First name must have atleast 2 characters. Numbers and special characters are not allowed.
    Last name must have atleast 1 characters. Numbers and special characters are not allowed.
    Enter a valid email
    Enter a valid password
    Your profile has been successfully updated.