인증 방식

실무에서는 API Key, OAuth 2.0, JWT를 자주 함께 언급하지만, 이 셋은 같은 층위의 개념이 아니다.

• API Key는 주로 클라이언트 또는 애플리케이션 식별 수단이다.
• OAuth 2.0은 권한 위임(authorization) 프레임워크다.
• JWT는 토큰을 표현하는 형식 중 하나다.

API Key

API Key는 서버가 "누가 호출했는가"를 구분하기 위해 발급하는 문자열이다.

• 공개 API나 서버 간 통신에서 많이 사용된다.
• 보통 최종 사용자 인증보다는 애플리케이션 식별에 가깝다.
• 키 하나에 권한이 묶이므로, 유출되면 동일 권한으로 악용될 수 있다.

주의할 점

• 반드시 HTTPS로 전송해야 한다.
• 가능하면 용도별로 키를 분리하고, scope, rate limit, rotation 정책을 둔다.
• 브라우저에 노출되는 프런트엔드 코드에 비밀 키를 직접 넣는 방식은 피해야 한다.

OAuth 2.0

OAuth 2.0은 사용자의 비밀번호를 제3자 애플리케이션에 넘기지 않고도, 제한된 권한을 위임할 수 있게 하는 표준 프레임워크다.

대표 예시는 "구글로 로그인", "깃허브 계정으로 로그인" 같은 소셜 로그인 흐름이다.

핵심 역할

• Resource Owner: 사용자
• Client: 사용자를 대신해 권한을 요청하는 앱
• Authorization Server: 로그인과 동의(consent)를 처리하고 토큰을 발급하는 서버
• Resource Server: 실제 사용자 데이터를 제공하는 서버

현재 권장되는 기본 흐름

브라우저 SPA, 모바일 앱 같은 public client에서는 보통 Authorization Code + PKCE를 사용한다.

1. 클라이언트가 사용자를 인가 서버로 리다이렉트한다.
2. 사용자가 로그인하고, 요청된 권한 범위(scope)에 동의한다.
3. 인가 서버가 클라이언트에게 authorization code를 돌려준다.
4. 클라이언트가 이 코드를 code_verifier와 함께 토큰 엔드포인트로 보내 access token을 받는다.
5. 클라이언트는 access token으로 resource server를 호출한다.
6. 필요하면 refresh token으로 새 access token을 발급받는다.

정리

• Access Token은 보호된 리소스 호출에 사용한다.
• Refresh Token은 새 access token 발급에만 사용하며, 일반적으로 resource server에는 보내지 않는다.
• refresh token 발급은 선택 사항이다.
• OAuth는 인증(authentication) 자체의 표준이 아니라 권한 위임 표준이다.
• 로그인 결과로 사용자 신원 정보까지 표준화해서 받고 싶다면 OpenID Connect (OIDC)를 함께 사용한다.

자세한 내용은 OAuth 문서를 참고하자.

JWT

JWT(JSON Web Token)는 토큰의 문자열 형식을 정의한 규격이지, 로그인 흐름 자체를 정의하는 규격은 아니다.

• access token이 JWT일 수도 있고, opaque token일 수도 있다.
• refresh token도 JWT일 수도 있지만, 반드시 JWT일 필요는 없다.

JWT의 장점은 토큰 자체에 claim을 담을 수 있다는 점이다. 다만 이는 곧 "토큰을 읽을 수 있다"는 뜻이기도 하다.

주의할 점

• 일반적인 JWT(JWS)는 서명되어 있을 뿐 암호화되어 있지 않다.
• 민감한 개인정보를 payload에 그대로 넣는 것은 피해야 한다.
• 서버는 iss, aud, exp, nbf, alg 같은 값을 반드시 검증해야 한다.
• "JWT를 쓰면 인증 서버 확인이 완전히 필요 없다"는 말은 과장이다. 토큰 폐기, 세션 강제 종료, key rotation, refresh token 회전 같은 문제는 별도 설계가 필요하다.

자세한 내용은 JWT 문서를 참고하자.