SMALL

OAuth 2.0

인증 및 인가 프로토콜
third-party application 에 대한 access 권한을 부여할 수 있다.
리소스 소유자를 대신해 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 방식으로 작동된다.
구글, 페이스북, 네이버, 카카오 등 외부 소셜 계정을 기반으로 간편하게 인증할 수 있도록 해준다.

OAuth 2.0 구성요소

Client (클라이언트)
1. OAuth 2.0 서비스에 액세스하는 애플리케이션 또는 서비스
2. Resource Owner가 소유한 리소스에 대한 접근 권한을 얻기 위해 인증 및 인가를 요청한다.
3. 직접 개발한 서비스
Resource Owner (리소스 소유자)
1. OAuth 2.0 서비스에 있는 사용자. 보호된 리소스에 대한 접근 권한을 부여할 수 있는 entity
2. 유저 (소셜 로그인을 사용할 사용자)
Authorization Server (인가 서버)
1. OAuth 2.0 서비스에 인가하는 서버, 권한을 부여해주는 서버
2. Authorization Code를 발급해준다.
Resource Server (리소스 서버)
1. OAuth 2.0 서비스에서 제공하는 데이터 및 기능을 포함하는 서버
2. Access Token을 사용해 보호된 리소스에 대한 요청을 수락하고 응답을 가능하게 하는 보호된 리소스를 호스팅하는 서버
3. 구글, 페이스북, 네이버, 카카오

OAuth 2.0 Authorization Grant 방식

Access Token을 얻기 위해 Client가 사용하는 Resource Owner의 권한을 나타내는 credential(자격 증명)

Authorization Code Grant
- Client는 Resource Owner에게 직접 권한 부여을 요청하는 대신에 Authorization Server로 이동시킨다.
- Authorization Server가 Resource Owner의 동의를 받고 Authorization Code를 발급해준다.
- 발급한 Authorization Code와 함께 Resource Owner를 Client로 이동시킨다.
- 이 Authorization Code로 Authorization Server에게 Access Token을 발급받을 수 있다.
  바로 Client에게 직접 전송하기 때문에 Resource Owner나 다른 사람에게 노출되지 않는 보안 이점이 있다.
Implicit Grant
- Authorization Code와 같이 중간 Credential 없이 바로 Access Token을 Client에게 전달한다.
- Access Token을 발급할 때, Client를 인증하지 않고 바로 발급하기 때문에 노출 위험이 있다. (이를 방지하기 위해 Access Token의 만료기한을 짧게 한다.)
- Access Token을 발급받는데 필요한 왕복 횟수를 줄이기 때문에 일부 경우에 응답성과 효율성을 향상시킨다.
- 권장 X
Resource Owner Password Credentials Grant
- 사용자 이름과 비밀번호를 사용하여 Access Token을 얻는다.
- 권장 X
Client Credentials Grant
- 클라이언트 자격 증명을 사용하여 Access Token을 얻는다.

OAuth 2.0 흐름

(A) Client가 Resource Owner에게 권한 부여를 요청한다.

(B) Client는 Resource Owner의 권한을 나타내는 자격 증명인 Authorization Grant를 수신한다.

(C) Client가 (B)에서 받은 Authorization Grant로 Access Token을 요청한다.

(D) Authorization Server가 Authorization Grant의 유효성을 검사한다. Authorization Grant가 유효한 경우 Access Token을 발급한다.

(E) Client는 Access Token을 사용하여 Resource Server에 보호된 리소스를 요청한다.

(F) Resource Serve는 Access Token을 검증하고 유효한 경우 요청을 처리한다.

Access Token

보호된 자원에 접근하기 위해 사용되는 Credential
Client에 발급된 권한을 나타내는 문자열

Refresh Token

Access Token을 발급받기 위해 사용되는 Credential
Access Token이 만료되었으면 Refresh Token을 이용해 새 Access Token을 얻을 수 있다.

(A) Client는 Authorization Grant를 보내며 Access Token을 요청한다.

(B) Authorization Server는 Authorization Grant를 확인하고, 유효한 경우 Access Token과 Refresh Token을 발급한다.

(C) Client는 Access Token으로 Resource Server에 보호된 리소스를 요청한다.

(D) Resource Server는 Access Token을 검증하고 유효한 경우 요청을 처리한다.

(E) Access Token이 만료될 때까지 (C) 및 (D) 단계를 반복한다.

(F) Access Token이 잘못되었으면(ex. Access Token 만료) Resource Server가 잘못된 토큰 오류를 반환한다.

(G) Client는 Refresh Token으로 새 Access Token을 요청한다.

(H) Authorization Server는 Refresh Token을 확인하고, 유효한 경우 새 Access Token(및 선택적으로 새 Refresh Token)을 발급한다.

카카오 로그인

준비

카카오에서 내 Application 만들기
카카오 로그인 활성화 설정에서 활성화 상태를 ON으로 설정하기
카카오 로그인 활성화 설정에서 Redirect URI 설정하기 (Redirect URI를 통해 Authorization Code를 받을 수 있다.)

카카오 로그인 동의항목 설정하기

appllication.yml 파일 설정하기

spring:
  datasource:
    url: [입력] ex) jdbc:mysql://localhost:3306/DB이름
    driver-class-name: [입력] ex) com.mysql.cj.jdbc.Driver
    username: [입력]
    password: [입력]

  security:
    oauth2:
      client:
        registration:
          kakao:
            client-id: [REST API 키]
            redirect-uri: [Redirect URI, 내 어플리케이션에서 설정한 Redirect URI]
            authorization-grant-type: authorization_code
            client-authentication-method: POST
            client-name: Kakao
            scope: # 설정한 동의항목 명시
              - profile_nickname
              - account_email
        provider:	# 카카오나 네이버는 provider를 직접 설정해줘야 한다.
          kakao:
            authorization-uri: https://kauth.kakao.com/oauth/authorize
            token-uri: https://kauth.kakao.com/oauth/token
            user-info-uri: https://kapi.kakao.com/v2/user/me
            user-name-attribute: id

카카오에서 사용자 정보 가져오는 방법

    private static OAuthAttributes ofKakao(String userNameAttributeName, Map<String, Object> attributes) {
        // kakao_account에 유저정보가 있다. (email)
        Map<String, Object> kakaoAccount = (Map<String, Object>)attributes.get("kakao_account");
        // kakao_account안에 profile이라는 JSON객체 안에 scope에서 설정한 정보가 있다. (nickname)
        Map<String, Object> kakaoProfile = (Map<String, Object>)kakaoAccount.get("profile");

        return OAuthAttributes.builder()
                .name((String) kakaoProfile.get("nickname"))
                .email((String) kakaoAccount.get("email"))
                .attributes(attributes)
                .nameAttributeKey(userNameAttributeName)
                .build();
    }

과정

사용자 클라이언트 = Resource Owner

서비스 서버 = Client

카카오 인증 서버 = Authorization Server

카카오 API 서버 = Resource Server

Step 3 : 서비스 로그인에서 "서비스 세션 발급"에서 JWT 사용

서버 기반 인증 방식

서버측에서 사용자 정보를 저장하는 것.
보통 Spring Security에서는 session을 이용해 처리하는데, MSA를 하거나 서버가 확장되면 모든 서버에게 세션의 정보를 공유해야 한다.
Access Token은 사용자 정보에 직접 접근할 수 있도록 해주는 정보를 담고 있고 Refresh Token에 비해 짧은 만료기간을 가지고 주로 세션에 담아 관리한다.
Refresh Token은 새로운 Access Token을 발급하기 위한 정보를 담고 있다. 이를 통해 Auth Server에 요청해 새로운 Access Token을 발급받을 수 있다. 외부에 노출되지 않도록 DB에 저장한다.
요청마다 Access Token의 유효성을 검증해야 하고 업데이트를 해줘야 한다.
서버의 수가 많은 경우, Access Token의 유효성 및 권한 확인을 위한 요청이 Auth Server에 많이 발생하기 때문에 서버의 부하로 이어질 수 있다.

JWT 기반 인증 방식

JWT는 Claim 기반 방식을 사용하기 때문에 사용자에 대한 의미 있는 정보로 이루어져있다.
Auth Server에 검증 요청을 보내는 과정을 생략하고 각 서버에서 수행할 수 있다.
서버의 수에 상관없이 토큰을 인증하는 방식을 알고 있으면 인증 할 수 있다.
헤더에 JWT 값을 넣어 보내야 하기 때문에 데이터가 증가해 네트워크 부하가 일어날 수 있다.

OAuth란?

등록2-1. 구글 등록 테스트

OAuth 2.0 Flow

1. OAuth란?

OAuth(Open Authorization)

인가 프레임워크는 리소스 소유자와 HTTP 서비스 간의 승인 상호 작용을 조정하거나 타사 응용프로그램이 자체적인 액세스를 획득하도록 허용함으로써 타사 응용 프로그램이 리소스 소유자를 대신하여 HTTP 서비스에 대한 제한된 액세스를 얻을 수 있도록 해준다.

위 그림과 같이 구글, 페이스북, 네이버 로그인 같은 소셜 로그인들은 OAuth2 프로토콜 기반의 인증방식을 지원한다.

연동되는 외부 웹 어플리케이션에서 페이스북과 트위터 등이 제공하는 기능을 간편하게 사용할 수 있다.

즉, OAuth는 다른 서비스의 회원정보를 안전하게 사용하기 위한 방법이라고 생각하자.

사용자가 자신의 소셜 아이디/비밀번호를 우리 서비스에 알려주지 않아도, 고객의 정보를 우리 서비스에서 안전하게 사용하기 위한 방법이다.

2. 등록

서비스마다 등록하는 방법이 모두 다르지만 공통적인 것은 아래 그림과 같다.

Client ID
- 우리가 만든 Application을 식별하는 식별자

Client Secret
- 외부에 절대 노출되서는 안된다

Authorized redirect URIs
- Resource Server만 갖는 정보로, client에 권한을 부여하는 과정에서 나중에 Authorized code를 전달하는 통로다.

2-1. 구글 등록 테스트

https://console.cloud.google.com/

위 사이트를 접속해서 만들어보자.

내프로젝트에 새프로젝트를 만들어준다.

다음과 같이 새프로젝트이름을 지정하고 만들기를 클릭한다.

햄버거 박스를 눌러 API 및 서비스 > 사용자 인증 정보를 클릭한다.

사용자 인증 정보 만들기에 OAuth 클라이언트 ID를 클릭해준다.

애플리케이션 유형과 이름을 정해서 만들기 버튼을 클릭한다.

초반에 나온 그림 처럼 클라이언트 ID와 비밀번호(Secret)가 생성되며 Authorized redirect URIs 것을 볼 수 있다.

3. OAuth 2.0 Flow

사용자(Resource Owner)는 서비스(client)를 이용하기 위해 로그인 페이지에 접근한다.

그럼 서비스(client)는 사용자(Resource Owner)에게 로그인 페이지를 제공하게 된다. 로그인 페이지에서 사용자는 "페이스북/구글 으로 로그인" 버튼을 누른다.

만일 사용자가 Login with Facebook 버튼을 클릭하게 되면, 특정한 url 이 페이스북 서버쪽으로 보내지게 된다.

gitlab 사이트에서 구글 로그인을 할때 url을 복사해서 내용을 확인했을때 아래와 같다

https://accounts.google.com/o/oauth2/auth/identifier?access_type=offline&
client_id=805818759045-aa9a2emskmnmeii44krng550d2fd44ln.apps.googleusercontent.com&
redirect_uri=https://gitlab.com/users/auth/google_oauth2/callback&
response_type=code&
scope=email profile&
state=79d206dc2e07b33197ca9e4c13f15876856ba488a570dde9&
service=lso&
o2v=1&
flowName=GeneralOAuthFlow

향후 redirect_uri 경로를 통해서 Resource Server는 client에게 임시비밀번호인 Authorization code를 제공한다.

클라이언트로부터 보낸 서비스 정보와, 리소스 로그인 서버에 등록된 서비스 정보를 비교한다.

4-1. 확인이 완료되면, Resource Server로 부터 전용 로그인 페이지로 이동하여 사용자에게 보여준다.

ID/PW를 적어서 로그인을 하게되면, client가 사용하려는 기능(scope)에 대해 Resource Owner의 동의(승인)을 요청한다.

5-1. 사용자가 허용 버튼 누르면 사용자는 권한을 위임했다는 승인이 Server 에 전달된다.

허용한 사용자의 user id를 1이라고 칭한다면 서버는 이와 같은 정보를 가지게 된다.

1. Client Id : Resource Owner와 연결된 client가 누군지
2. Client Secret: Resource Owner와 연결된 client의 비밀번호
3. Redirect URL : (진짜)client와 통신할 통로
4. user id : client와 연결된 Resource Owner의 id
5. scope : client가 Resource Owner 대신에 사용할 기능들

하지만, 이미 Owner가 Client에게 권한 승인을 했더라도 아직 Server가 허락하지 않았다. 따라서, Resource Server 도 Client에게 권한 승인을 하기위해 Authorization code(임시 비밀번호)를 Redirect URL을 통해 사용자에게 응답하고

Owner는 서버에게 받은 Location 헤더 값을 통해 url을 이동하고 클라이언트는 Authorization Code를 얻게 된다.

이제 Client가 Resource Server에게 직접 url(클라이언트 아이디, 비번, 인증코드 등)을 보낸다.

그럼 Resource Server는 Client가 전달한 정보들을 비교해서 일치한다면, Access Token을 발급한다. 그리고 이제 필요없어진 Authorization code는 지운다.

그렇게 토큰을 받은 Client는 사용자에게 최종적으로 로그인이 완료되었다고 응답한다.

11 ~ 14. 이제 client는 Resource server의 api를 요청해 Resource Owner의 ID 혹은 프로필 정보를 사용할 수 있다.

15. Access Token이 기간이 만료되어 401에러가 나면, Refresh Token을 통해 Access Token을 재발급 한다.

Refresh Token
- Refresh Token의 발급 여부와 방법 및 갱신 주기 등은 OAuth를 제공하는 Resource Server마다 상이하다
- Access Token은 만료 기간이 있어, 만료된 Access Token으로 API를 요청하면 401 에러가 발생한다. Access Token이 만료되어 재발급받을 때마다 서비스 이용자가 재 로그인하는 것은 다소 번거롭다.
- 보통 Resource Server는 Access Token을 발급할 때 Refresh Token을 함께 발급한다. Client는 두 Token을 모두 저장해두고, Resource Server의 API를 호출할 때는 Access Token을 사용한다. Access Token이 만료되어 401 에러가 발생하면, Client는 보관 중이던 Refresh Token을 보내 새로운 Access Token을 발급받게 된다.

이제는 너무나도 익숙한 소셜 로그인은 유저와 기업 모두에게 매력적인 인증 방법입니다. 유저는 간편하게 로그인할 수 있고 기업은 신규 유저의 가입 장벽을 낮추고 신뢰성 있는 타기업에게 인증의 책임을 미룰 수 있죠. 소셜 로그인 구현을 위해 가장 많이 쓰이고 있는 프로토콜은 OAuth 2.0과 OIDC가 있습니다. 이 두 프로토콜이 어떻게 인증 및 인가를 부여하는지 알아봅시다.

OAuth 2.0과 OIDC(OpenID Connect) 프로토콜

OAuth 2.0

위임 권한부여를 위한 표준 프로토콜인 OAuth는 사용자가 비밀번호를 제공하지 않고 서드파티 어플리케이션에게 접근 권한을 부여할 수 있게 해줍니다. 2010년 IETF에서 OAuth 1.0 공식 표준안이 RFC 5849로 발표되었으며, 현재는 OAuth 2.0 (RFC 6749, RFC 6750)이 많이 쓰이고 있습니다.

용어 정리

OAuth 2.0 의 로직 흐름을 이해하기 위해 몇 가지 용어를 알아야 합니다.

Client: 사용자의 데이터에 접근하고 싶어 하는 어플리케이션.
Resource Owner: 클라이언트 어플리케이션이 접근하길 원하는 데이터의 사용자 또는 소유자.
Resource Server: 클라이언트 어플리케이션이 접근하길 원하는 데이터를 저장하고 있는 서버.
Authorization Server: 사용자로부터 권한을 부여받아 클라이언트가 사용자의 데이터에 접근할 권한을 부여해 주는 권한부여 서버.
Access Token: 리소스 서버의 사용자 데이터에 접근하기 위해 클라이언트가 사용할 수 있는 유일한 키

OAuth 2.0 요청을 위한 파라미터

Client가 Authorization Server에 요청을 보낼 때 주로 다음과 같은 설정값을 Query String을 통해 전달합니다.

response_type : Authorization Server로부터 받길 원하는 응답의 타입 (code, token 등).
scope : Client가 Resource Server에서 접근하고 싶은 리소스 리스트
client_id : OAuth 세팅을 할 때, Authorization Server에 의해 제공. Client가 누구인지 알아내기 위해 사용.
client_secret : Authorization Server에 의해 제공. Code와 client_secret을 가지고 Access Token 받게 됨.
redirect_url : Authorization Server에게 OAuth 플로우가 끝나면 어디로 보내줄지에 대해 알려주는 역할.

인증 방식과 동작 흐름

OAuth 2.0에서는 다음의 4가지 인증 방식으로 동작합니다.

Client는 어플리케이션으로 프론트엔드 + 백엔드 서버를 포괄하는 개념이니 시퀀스 다이어그램을 보실 때 유의해주세요.

1. 권한 부여 코드 승인 방식 (Authorization Code Grant)

자체 생성한 Authorization Code를 전달하는 방식으로 OAuth2.0에서 가장 기본이 되는 방식.
response_type=code, grant_type=authoration_code 등 형식으로 요청.
Authoration Server가 Redirect 시 엑세스 토큰을 전달하면 브라우저에 토큰이 바로 노출되기 때문에 프론트앤드에서 code를 받아서 서버로 전달하면 서버에서 엑세스 토큰을 요청하는 방식
Code를 Access Token으로 변환할 때 client_secret이 필요. 결국, 백엔드 서버에서만 필요.
백엔드 사이에서만 토큰이 이동하여 비교적 안전한 방식

2. 암묵적 승인 방식 (Implicit Grant)

자격 증명을 안전하게 저장하기 힘든 클라이언트 사이드에서 OAuth2.0 인증에 최적화된 방식.
response_type=token 등 형식으로 요청.
Autorization Code 발급 없이 바로 Access Token 발급되기 때문에 만료 기간이 짧아야 함.
절차가 비교적 간단하지만 Access Token이 URI를 통해 전달되어 보안에 취약

3. 자원 소유자 자격 증명 방식 (Resource Owner Password Credentials Grant)

Authorization Server, Resource Server, Client가 모두 같은 시스템에 속해 있을 때만 사용 가능.
ID, Password로만 Access Token을 발급받는 방식.
grant_type=password 형식으로 요청.

4. 클라이언트 자격 증명 방식 (Client Credentials Grant)

클라이언트의 자격 증명만으로 Access Token을 획득하는 방식.
User가 아닌 Client에 대한 인가가 필요할 때 사용.
즉, Client에 대해 리소스 접근 권한이 설정된 경우 사용.
자격 증명을 안전하게 보관할 수 있는 클라이언트에서만 사용.

OpenID Connect

OIDC는 OAuth 2.0을 기반으로 만들어진 유저의 인증(Authentication)을 위한 프로토콜 입니다. OIDC는 OAuth 2.0을 확장하여 인증 방식을 표준화 합니다. OpenID를 관리하는 OpenID Foundation에서 정의한 OpenID의 개념은 다음과 같습니다.

OpenID Connect 1.0은 OAuth 2.0 프로토콜 위에서 동작하는 간단한 ID 레이어입니다. 이를 통해 클라이언트는 인증 서버에서 수행한 인증을 기반으로 최종 사용자의 신원을 확인할 수 있을 뿐만 아니라, 최종 사용자에 대한 기본 프로필 정보를 상호 운용 가능하며 REST와 유사한 방식으로 얻을 수 있습니다. OpenID Connect를 사용하면 웹 기반, 모바일, 자바스크립트 클라이언트 등을 포함한 모든 유형의 클라이언트에서 인증 세션과 최종 사용자에 대한 정보를 요청하고 받을 수 있습니다. 스펙은 확장 가능하므로 필요에 따라 참가자들에게 ID 데이터 암호화, OpenID 제공자 확인, 로그아웃 등을 이용할 수 있습니다.

인증 방식과 동작 흐름

기존 OAuth 2.0의 동작 흐름과 거의 유사하며 ID token을 추가 발급한다는 차이점이 있습니다.
추가로, OpenID 문서를 읽다 보면 IDP, RP라는 용어가 등장하는데 각각 다음과 같습니다.

IDP (IDentity Provider): Google, Apple 같은 간편 로그인 서비스 제공사 (OpenID 제공자)
RP (Relying Party): 사용자를 인증하기 위해 IDP에 의존하는 주체 (어플리케이션)

출처: https://tecoble.techcourse.co.kr/post/2022-10-24-openID-Oauth/

OAuth 2.0 과 OIDC의 차이점

1. 스코프 (Scopes)

OAuth 2.0에서는 제공자가 원하는 대로 요청 범위를 설정 가능하여 유연한 사용이 가능했지만 상호 운용에 취약했습니다. OIDC는 요청범위를 profile, email, address, phone으로 표준화했습니다.

https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims

2. 클레임 (claims)

OIDC에서 ID토큰의 payload는 claims라고 알려진 필드들을 포함합니다. OIDC는 이런 클레임들을 표준화했습니다.

기본적인 클레임은 다음과 같습니다.

iss: 토큰 발행자
sub: 사용자의 유니크한 식별자
email: 사용자 이메일
iat: 토큰 발행 시간 (Unix time)
exp: 토큰 만료 시간(Unix time)

https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims

3. 사용자 정보 요청 엔드포인트 통일

OIDC는 사용자가 요청하는 엔드포인트도 표준화했습니다. 예를 들어 /userinfo를 통해 사용자 메타데이터 정보를 검증합니다.

https://openid.net/specs/openid-connect-core-1_0.html#UserInfo

4. ID token

OIDC의 동작 흐름에서 가장 눈에 띄는 차이가 ID token의 유무입니다. ID token은 JWT로 생성이 되어 Payload 내부에 클레임을 포함합니다. 즉, ID token을 복호화하여 사용자 정보를 얻을 수 있습니다. OAuth 2.0에서 액세스 토큰을 얻고 다시 사용자 정보를 요청하는 것보다 네트워크 통신 비용이 절감됩니다.

OAuth 2.0, OIDC 중 무엇을 사용해야 할까?

정리하자면, 가능하면 OIDC를 쓰되 필요로 하는 IDP에서 제공하는 방식을 사용하자!라고 생각합니다. OAuth 2.0은 인가, OIDC는 인증에 중점을 둔다고는 하지만 큰 차이점은 없었습니다. (ID 토큰과 더 강력한 표준화를 곁들인?) 오히려 OAuth와 OIDC 보다는 자사 서비스의 유저들이 어떤 IDP로 연결했을 때 회원가입 없이 로그인할 수 있을지가 더 중요할 것입니다. 이때 OAuth 2.0 만 제공하는 IDP라면 OAuth 2.0을 쓸 수 밖에 없을 것이고 구글처럼 OpenID가 적용된 OAuth가 기본 사양이라면 OIDC를 쓰지 않을 수 없을 것 입니다.

만약 OAuth 2.0과 OIDC 모두를 지원한다면 OAuth 2.0이 레거시일 확률이 크고, 표준화가 적용된 OIDC가 확장성도 좋고 네트워크 비용도 적게 들 테니 OIDC를 쓰지 않을 이유는 없어 보입니다. 하지만 두 프로토콜의 두드러지는 차이는 없기에 양자택일을 위한 기술적 논의는 유의미하지 않다고 생각합니다.

수업을 보는 다른 방법

WEB2 - OAuth 2.0 youtube 재생목록

수업에 참여조건

이 수업은 최소한 웹과 인터넷에 대한 기본 이해가 필요합니다. 잘 모르신다면 아래 수업을 참고해주세요.

Express-Session & Auth 수업 바로가기

또 OAuth는 애플리케이션 기술(PHP, Python, Ruby, JavaScript, Node.js, Java..)을 이용하기 때문에 이런 기술에 대한 이해가 필요합니다.

전체 재생시간

9개의 동영상으로 이루어진 전체 재생시간 47분 규모의 수업입니다.

수업의 저작권 정책

이 수업은 CCL 라이선스 BY를 따르고 있습니다. 이 수업의 출처를 표시해주신다면 컨텐츠의 수정을 할 수 있고, 상업적인 용도로도 사용할 수 있습니다. 상업적인 용도로 사용하는 경우는 거래 관계가 없다는 것을 인지 가능하도록 표시해주셔야 합니다.

[CS스터디] 프로젝트 관련 면접 질문

👀 mysql을 선택한 이유

mysql은 오픈 소스 기반의 DBMS로 무료로 사용이 가능하다.
무료이지만 빠른 데이터 처리와 확장성을 가지고 있다.
사용이 매우 쉽고 활발한 커뮤니티를 가지고 있어 다양한 문제에 대한 해결책을 찾을 수 있다.

👀 백엔드 언어로 자바를 선택한 이유

자바는 정적 타입 언어로 컴파일 시점에 타입 검사가 이루어져 런타임 시점에서 발생할 수 있는 에러를 방지할 수 있다.
자바는 객체 지향 언어로 코드를 모듈화해 작성해 유지보수성을 높일 수 있다.
메모리 관리를 자동으로 처리해주는 Garbage Collection 기능이 있어 메모리 누수 등의 문제를 방지할 수 있다.
JVM 위에서 동작하기 때문에 운영체제에 종속되지 않아 다양한 운영체제에서 사용할 수 있다.

👀 Java 8, Java 17이 아니라 Java 11을 선택한 이유

Java 8은 지원이 종료된 버전으로 보안 및 안정성에 문제가 있다.
Java 17은 최신 버전으로 상대적으로 안정성이 떨어지고, 사용자가 적어 문제가 발생했을 때 참고할 수 있는 자료가 적다.

✔ Java 11 선택

👀 spring boot 3 버전이 아니라 spring boot 2 버전을 선택한 이유

spring boot 3 버전은 Java 17부터 지원한다.
또한 javax -> jakarta로 변경되었고, 지원하지 않는 라이브러리(springfox swagger)가 존재한다.

✔ spring boot 2 버전 선택

👀 spring이 아니라 spring boot를 선택한 이유

환경설정이 쉽고 빠르다.
내장형 서버가 있어 별도의 웹 서버를 설치하지 않아도 실행이 가능하다.
배포할 때, spring 프레임워크로 개발한 어플리케이션은 WAR 파일과 이를 실행하기 위해 설정한 WAS가 필요하다.
spring boot로 개발한 어플리케이션은 내장형 서버가 있기 때문에 독립적으로 실행 가능한 JAR 파일을 배포하면 된다.

👀 mybatis가 아니라 spring data jpa를 선택한 이유

mybatis는 sql 쿼리를 직접 작성해야 하기 때문에 sql에 의존하는 개발을 해야 한다.
spring data jpa는 개발자가 직접 sql 쿼리를 작성하지 않아도 자동으로 작성된다. (CRUD를 처리하기 위한 공통 인터페이스가 제공된다.)
mybatis는 spring data jpa와 달리 동적 쿼리를 작성하는 것이 어렵다.
mybatis는 sql문의 오류나 오타를 런타임 오류로 발견하지만 spring data jpa은 실행 전 문법 검사를 수행할 때 발견할 수 있다.
spring data jpa는 mybatis를 사용할 때보다 월등한 개발속도와 유지보수성을 갖는다.

👀 response와 entity를 구분해서 사용해야 하는 이유

entity 객체는 데이터베이스 테이블과 매핑되기 때문에 response에 필요없는 필드가 포함될 수 있다.
entity 객체를 response로 사용하는 것은 불필요한 데이터를 전송하기 때문에 네트워크 트래픽을 낭비한다.
또한 frontend 쪽에서 불필요한 데이터를 처리해야 하는 과정을 거쳐야 하기 때문에 성능 저하가 발생할 수 있다.

👀 무한 스크롤을 사용하는 이유

무한 스크롤
- 사용자가 페이지를 로딩하지 않아도 되게 하기 위해 스크롤을 끝까지 내리면 새로운 데이터를 자동으로 불러오는 방식
사용하는 이유
- 사용자 경험을 향상시키기 위해
- 페이지 로딩 시간을 줄이고 사용자가 원하는 정보에 빠르게 접근할 수 있다.

👀 JPA에서 무한 스크롤을 구현하는 방법

Page 객체 사용
- Pageable 인터페이스를 이용해 페이지 번호, 페이지 당 데이터 개수, 정렬 정보 등을 설정한다.
- Page 객체에서 getTotalPages()메소드를 이용해 전체 페이지 수를 구할 수 있다.
- 내부적으로 count 쿼리가 실행되기 때문에 성능이 좋지 않을 수 있다.
Slice 객체 사용
- Page 객체와 달리 count 쿼리를 실행하지 않고 hasNext() 메소드로 다음 페이지가 있는지 여부를 확인할 수 있다.
- count 쿼리를 실행하지 않아 Page 객체를 사용하는 것보다 성능이 좋다.
- 전체 페이지 수를 구할 수 없다.
limit, offset 사용
- 페이지 당 데이터 개수와 페이지 번호를 이용해 limit 절과 offset 절을 계산해 사용한다.
- 페이지 번호가 커질수로 쿼리의 실행 속도가 느려진다. (limit + offset 개수 만큼 데이터를 조회한 후 필요없는 데이터를 버린다.)
no offset 사용
- 마지막 조회 결과의 ID를 사용해 필요없는 데이터 조회를 막는다.
- 해당 ID를 where 절에 걸어서 매번 첫 페이지만 읽도록 한다.

👀 Page vs Slice

둘 다 데이터베이스에서 데이터를 읽어오기 위한 spring data jpa의 객체
Page
- 일정한 개수의 데이터를 한 번에 가져와서 페이지 단위로 처리한다.
- 총 페이지 수, 현재 페이지 번호, 페이지 당 데이터 개수, 이전 페이지, 다음 페이지 등의 정보를 포함하고 있다.
- 총 페이지 수를 계산한 후에 다음 페이지가 있는지 여부를 판단한다.
Slice
- Page 객체와 유사하지만 다음 페이지가 있는지 여부를 판단하는 방법이 다르다.
- 페이지 당 데이터 개수 +1 개의 데이터를 조회하고 데이터가 페이지 당 데이터 개수와 같거나 작으면 다음 페이지가 없고 그렇지 않은 경우 다음 페이지가 있다고 판단한다.

👀 webRTC

웹 기술을 이용해 브라우저 간 오디오, 비디오, 데이터 등을 실시간으로 주고받을 수 있는 기술
플러그인이나 앱을 다운로드하거나 설치하지 않아도 브라우저 내에서 오디오, 비디오, 데이터 등을 공유할 수 있다.
브라우저 간 P2P 통신을 한다.

👀 hadoop

대용량 데이터를 분산 처리하기 위한 자바 기반의 오픈소스 프레임워크
HDFS와 MapReduce로 이루어져 있다.
여러 대의 서버에 데이터를 분산 저장하고 처리하며, 안정성과 확장성이 높다.

👀 spark

대용량 데이터 처리를 위한 프레임워크
인메모리 기반의 빠른 데이터 처리가 가능하다.
대규모 데이터 처리, 머신러닝, 실시간 데이터 처리 등에 사용되며, 하둡과 함께 사용되어 더욱 강력한 기능을 제공
크롤링한 항공권 데이터가 매일 20만 개 이상으로 이 데이터를 정제하고, mysql에 저장해야 하기 때문에 spark를 사용하였다.

👀 pyspark를 선택한 이유

파이썬은 간결하고 읽기 쉬운 문법을 가지고 있어 쉽게 배울 수 있다.
다양한 라이브러리를 가지고 있어 데이터 분석에 유리하다. (ex. pandas)
스칼라, 자바에 비해 다양한 개발자 커뮤니티가 활발하게 운영되어 문제 해결 및 정보 공유가 쉽다.

👀 JIRA를 사용했을 때 장점

프로젝트의 전체적인 상황을 파악할 수 있다.
팀원의 진행상황을 확인할 수 있어, 업무 분담을 쉽게 조정할 수 있다.
맡은 업무에 대한 진행 상황을 실시간으로 공유할 수 있다.
번다운 차트와 같은 보고서를 활용해 프로젝트 진행 상황을 시각적으로 확인할 수 있다.

LIST

저작자표시

OAuth 2.0

OAuth 2.0

OAuth 2.0 구성요소

OAuth 2.0 Authorization Grant 방식

OAuth 2.0 흐름

Access Token

Refresh Token

카카오 로그인

준비

과정

Step 3 : 서비스 로그인에서 "서비스 세션 발급"에서 JWT 사용

서버 기반 인증 방식

JWT 기반 인증 방식

1. OAuth란?

2. 등록

2-1. 구글 등록 테스트

3. OAuth 2.0 Flow

OAuth 2.0과 OIDC(OpenID Connect) 프로토콜

OAuth 2.0

용어 정리

OAuth 2.0 요청을 위한 파라미터

인증 방식과 동작 흐름

OpenID Connect

인증 방식과 동작 흐름

OAuth 2.0 과 OIDC의 차이점

OAuth 2.0, OIDC 중 무엇을 사용해야 할까?

수업을 보는 다른 방법

수업에 참여조건

전체 재생시간

수업의 저작권 정책

[CS스터디] 프로젝트 관련 면접 질문

👀 mysql을 선택한 이유

👀 백엔드 언어로 자바를 선택한 이유

👀 Java 8, Java 17이 아니라 Java 11을 선택한 이유

👀 spring boot 3 버전이 아니라 spring boot 2 버전을 선택한 이유

👀 spring이 아니라 spring boot를 선택한 이유

👀 mybatis가 아니라 spring data jpa를 선택한 이유

👀 response와 entity를 구분해서 사용해야 하는 이유

👀 무한 스크롤을 사용하는 이유

👀 JPA에서 무한 스크롤을 구현하는 방법

👀 Page vs Slice

👀 webRTC

👀 hadoop

👀 spark

👀 pyspark를 선택한 이유

👀 JIRA를 사용했을 때 장점

티스토리툴바