Q. Inquiry on Authentication Technologies to Consider in a Distributed Environment Such as an MSA

Client Q&A, Identification and Authentication / By

Specific Inquiry

I am responsible for information security at my company. I have been assigned information security responsibilities for an information system development project that the company is pursuing.
I am requesting assistance because I want to know which authentication technologies can be considered in a distributed environment such as an MSA, and how they are used.

Types of Authentication Technologies Used in Distributed Environments Such as an MSA

When developing services in a distributed environment such as a microservice architecture, representative technologies related to user authentication and authorization include OAuth 2.0, JWT, OpenID Connect, SAML, API Key, CI/DI, and biometric authentication. Authentication and authorization technologies can be broadly divided into centralized authentication and distributed authentication. Which technology to choose should be decided by considering the characteristics of the technology together with the service operating environment, fault tolerance, ease of management, scalability, and security. In addition, from the perspective of the end-to-end flow that handles a single service (from the front end to the back end), these technologies are generally used in combination, taking the characteristics of each technology into account.

The characteristics, authentication processing flow, and main security requirements of each authentication technology are summarized below.

1. OAuth 2.0

Characteristics
  • It is a centralized delegated-authentication technology implemented by using authentication information the user already holds with another company (Google, Facebook, Kakao, and others).
  • When a user logs in, authentication information from the other company is received and an access token is issued. That access token includes access-permission information and provides the user with authentication and authorization.
  • For security, an expiration period is set on the access token, and a refresh token can be used after it expires to make authentication more convenient.
  • Ways to implement OAuth 2.0 are divided into the most common Authorization Code Grant (another company’s authentication information → authorization code → access token issuance), the Implicit Grant, which has weaker security and is used mainly for internal services (authentication information and the access token are provided at once), the Client Credentials Grant, in which the client obtains an access token directly from the authorization server, and the Resource Owner Password Credentials Grant, which has weaker security and is used mainly internally (authentication is performed with the user’s password).
  • The processing flow can be summarized as follows: a) OAuth 2.0 provider registration → b) authorization request by the resource owner → c) user authentication and consent → d) access token issuance → e) resource access.
  • This technology is the most widely used because authentication can be managed centrally, one authentication can be applied to multiple services, and an access token is used instead of the user’s authentication information, which reduces the risk of exposing authentication information and can improve security.
Security Requirements

Refer to a separate post (https://wiki.wikisecurity.net/faq:oauth_security)

2. OpenID Connect(OIDC)

Characteristics
  • OAuth 2.0 is a standard framework for authorization and does not itself provide user authentication. A separate mechanism for user authentication must therefore be implemented, or an independent authentication service must be built and integrated with OAuth 2.0.
  • OpenID Connect (OIDC) is a standard framework that provides authentication and authorization management on top of OAuth 2.0, and it is a centralized authentication technology.
  • Unlike OAuth 2.0, OIDC issues and provides an ID token in addition to an access token. User information (such as the user’s name, email address, and profile picture) can be included and used for authentication and authorization management services.
  • The processing flow can be summarized as follows: a) OIDC registration → b) user authentication request → c) user authentication and consent → d) issuance of an authorization code or ID token → e) token exchange and access token request → f) resource access.
  • Because OAuth 2.0 is a technical standard for obtaining authentication information from other companies (Google, Facebook, Kakao, and others), OIDC is used in ordinary services together with the OAuth 2.0 framework to authenticate users and manage user profile information.
Security Requirements

When implementing OIDC, there are various security considerations, including use of SSL/TLS, granting the necessary minimum privileges and scopes, verification and protection of ID tokens and access tokens, defenses against malicious redirects and CSRF, session management, and limits on login attempts. These will be covered in a separate post.

3. SAML(Security Assertion Markup Language)

Characteristics
  • A typical SSO (Single Sign-On) implementation uses cookies so that one login handles authentication and access for multiple services. When SSO is required for MSA-based services or across multiple domains, SSO is commonly implemented with SAML.
  • SAML is an XML-based standard protocol for implementing SSO. Its basic participants, the user (Subject), the identity provider (IdP), and the service provider (SP), provide a highly secure SSO function by creating, exchanging, and verifying SAML tokens.
  • The processing flow can be summarized as follows: a) SP registration (connection setup with the IdP and metadata exchange to support SAML) → b) the user requests authentication from the SP → c) the authentication request is redirected to the IdP → d) credentials are presented to the IdP and the user logs in → e) the IdP creates a SAML token → f) the IdP sends the SAML assertion it created to the SP → g) the SP verifies the SAML token and checks its integrity → h) the SP authenticates the user and allows access.
  • SAML is also integrated with LDAP or Active Directory to consolidate existing authentication systems, manage user IDs and passwords, and provide an SSO service. It is used to implement SSO between affiliates or between business partners.
Security Requirements

When implementing SAML, there are various security considerations, including metadata exchange, signing and encryption, user session management, and connection security between the IdP and the SP. These will be covered in a separate post.

4 JWT(JSON Web Token)

Characteristics
  • A JWT (JSON Web Token) is a JSON-formatted token that carries authentication information. It is a distributed approach in which an authentication server issues the token and shares it with each service and the client.
  • A JWT issued by the authentication server is stored on the client and is not kept on the server, which provides fast authentication processing in a distributed environment such as an MSA.
  • Information needed for a given purpose can be added to a JWT so that it can be used in various ways. The authentication server can protect authentication information by verifying the integrity of a JWT signed with its private key.
  • The processing flow can be summarized as follows: a) user authentication (ID, password, and so on) → b) the authentication server issues a JWT → c) the client stores and sends the JWT → d) the client requests access to a resource → e) the resource server or microservice validates the JWT → f) the resource server or microservice checks authentication and authorization → g) the resource is provided.
Security Requirements

Refer to a separate post (https://wiki.wikisecurity.net/faq:jwt-1)

5. API Key

Characteristics
  • An API Key is assigned to the client itself rather than used for user authentication, so a separate authentication function must be implemented in order to authenticate users.
  • An API Key is represented as an encrypted simple string or as a token. Implementation is relatively simple, but security is lower than with other authentication methods, so it is useful for authentication between services that already have a trust relationship.
  • An API Key is a unique identifier issued by the service provider. The client calls the API with the API Key included in an HTTP header or a query parameter, and the service provider authenticates the client by checking the API Key.
  • The processing flow can be summarized as follows: a) API Key generation → b) provide the API Key to the client → c) the client adds the API Key to the request header and requests the service → d) the service or API gateway verifies the API Key (validity, expiration, restricted permissions, and so on) → e) authentication and authorization checks → f) request processing and resource delivery → g) logging and retention of an audit trail.
Security Requirements
  • As MyData services expand in the financial sector, Open API services among financial institutions are becoming widespread. Among large groups, more companies develop and operate their own Open API services in order to link services between affiliates.
  • To secure Open API services in the financial sector, the Financial Supervisory Service provides a security inspection guide for organizations that operate API services and a security inspection guide for user institutions, and these guides help ensure security.

6. CI(Connecting Information)

Characteristics
  • CI was developed as a substitute for the resident registration number, which causes various social problems. It is a unique personal identifier used only in Korea, so it has the limitation that it cannot be applied to foreigners who do not have a resident registration number or an alien registration number.
  • With the launch of MyData services, CI is a unique personal number that most financial companies use to identify a person without using a resident registration number. Because one-way encryption is applied, it cannot be restored to the original value.
  • A CI value is an 88-byte string generated by hash encryption of the resident registration number and a shared secret. (For the same purpose, DI (Duplication Information) is a 66-byte string generated by hash encryption of the resident registration number, a provider-specific unique number, and a shared secret.)
  • Online service providers that are prohibited from collecting resident registration numbers, or are restricted in doing so, can receive a CI through mobile-phone authentication, accredited-certificate authentication, credit-card authentication, Naver authentication, and similar methods, and can use the CI instead of a resident registration number to identify an individual.
  • Because a CI is only information that identifies an individual, it is generally used in back-end service processing after user authentication is complete, for example when linking other services or affiliate services by using the authenticated user identifier.
Security Requirements

A CI is personal information because, when combined with other information, it can identify a specific individual. Most financial companies define it as personal information and apply the corresponding safeguards. A CI is therefore handled in accordance with personal-information protection policies and management standards.


(*) At Financial Company A, all of the authentication technologies mentioned so far are used in combination.
Traditional authentication technologies such as sessions, OAuth 2.0 and OpenID Connect authentication for user convenience, the CI value produced by identity verification, SAML for using authentication information between affiliates, API Key authentication for linking services between affiliates, and JWT authentication between microservices are applied in combination according to the characteristics and requirements of each service segment.