00. OAuth2 OIDC Social Login 압축 정리

OAuth2 OIDC Social Login

3줄 요약

• OAuth2는 제3자 애플리케이션에 제한된 접근 권한을 위임하는 프레임워크이고, 로그인에서 사용자 인증 결과를 검증하려면 OIDC의 ID Token과 issuer/audience/nonce 검증이 필요하다.
• Authorization Code Flow는 code를 브라우저 front channel로 받고 token은 서버 back channel에서 교환한다. 이때 state, redirect_uri, PKCE code_verifier가 flow 탈취와 혼동을 줄이는 핵심 경계다.
• Social Login은 “같은 이메일”로 자동 연결하면 위험하다. provider, provider subject, email_verified, 기존 세션 재인증, 연결/해제 감사 로그를 함께 봐야 한다.

핵심 정리

• OAuth2의 역할은 Resource Owner, Client, Authorization Server, Resource Server다. 우리 Spring 애플리케이션이 어느 역할인지 먼저 정해야 검증 위치가 보인다.
• Authorization code는 짧게 한 번만 사용되는 임시 값이다. 로그, URL history, referer, analytics에 남지 않게 다뤄야 한다.
• state는 로그인 요청과 callback을 묶어 CSRF와 flow 혼동을 줄인다. PKCE는 code를 훔쳐도 code_verifier 없이는 token 교환을 어렵게 만든다.
• Redirect URI는 prefix match나 wildcard보다 등록된 URI의 정확한 매칭이 안전하다.
• ID Token은 access token이 아니다. ID Token은 인증 결과이고 access token은 Resource Server 접근 권한이다.
• UserInfo 응답과 이메일은 내부 권한이 아니다. 내부 계정과 연결할 때는 provider subject를 안정 식별자로 저장한다.
• Provider access token과 refresh token은 secret이다. 저장, 암호화, scope 축소, 회전, 폐기, 로그 마스킹이 운영 설계에 포함되어야 한다.

하위 문서 연결

• 1. OAuth2 역할과 Authorization Code Flow: OAuth2 역할과 front channel/back channel을 구분하고 code flow의 검증 지점을 잡는다.
• 2. PKCE State Redirect URI 보안: state, PKCE, redirect URI 정확 매칭으로 code injection과 callback 혼동을 막는다.
• 3. OIDC ID Token과 UserInfo: ID Token claim 검증과 UserInfo subject 일치를 통해 인증 결과를 확인한다.
• 4. Social Login 계정 연결 위험: provider subject 기반 연결, 재인증, 알림, 감사 로그로 계정 탈취 위험을 낮춘다.
• 5. Token 교환 저장 갱신 운영: authorization code, provider token, refresh token을 secret으로 저장하고 갱신 실패를 운영 이벤트로 다룬다.

헷갈리는 지점

• OAuth2 로그인을 쓰면 자동으로 OIDC 인증이 된다고 생각하기 쉽다.
  • openid scope, ID Token 검증, issuer/audience/nonce 검증이 실제 로그인 안전성을 만든다.
  • 단순 OAuth2 profile API 호출만으로 내부 사용자 인증을 확정하면 provider별 차이를 놓친다.
• PKCE가 있으면 state가 필요 없다고 생각하기 쉽다.
  • PKCE는 code 탈취 후 token 교환을 막고, state는 요청과 callback을 연결해 CSRF와 flow 혼동을 줄인다.
  • 둘은 서로 대체하지 않는다.
• 같은 이메일이면 같은 사람이라고 생각하기 쉽다.
  • 이메일은 변경되거나 재사용될 수 있고 provider마다 verified 의미가 다를 수 있다.
  • 내부 연결 키는 (provider, subject)를 기본으로 잡고 이메일은 보조 속성으로 둔다.
• token 저장은 Spring Security가 알아서 안전하게 한다고 생각하기 쉽다.
  • 어디에 저장되는지, 암호화되는지, refresh token이 회전되는지, 로그에 남는지 별도 확인해야 한다.

확인 질문

• OAuth2와 OIDC의 차이는 무엇인가?
  • OAuth2는 권한 위임 프레임워크이고 OIDC는 OAuth2 위에서 사용자 인증 결과를 ID Token과 UserInfo로 표준화한 identity layer다.
• Authorization Code Flow에서 반드시 검증해야 하는 값은 무엇인가?
  • state, redirect_uri, code_verifier, provider issuer, client audience, ID Token nonce와 signature다.
• Social Login 계정 연결에서 가장 위험한 단순화는 무엇인가?
  • 같은 이메일이라는 이유만으로 기존 내부 계정과 provider 계정을 자동 연결하는 것이다.