OAuth란

OAuth란?

OAuth 2.0는 제3자 애플리케이션이 HTTP 서비스에 대해 제한된 접근 권한을 얻을 수 있게 한다.

(출처 : https://datatracker.ietf.org/doc/html/rfc6749)

유의할 점은, OAuth는 인증이 아니라 권한부여를 토큰으로 표준화한 방식이다

 

LinkedIn OAuth

OAuth를 처음 접하면 "구글로 로그인 = OAuth"처럼 보이지만, 정확히 말하면 비밀번호를 공유하지 않고도, 필요한 권한만 위임해서 API를 안전하게 호출하는 것이다.

 

OAuth가 해결하려는 문제

Linkedin을 구글을 통해 로그인 할때 다음과 같이 할 수 있다

OAuth 이전 사용자 정보 조회

이 방식은 다음 문제가 크다.

- 제3자(Linkedin)가 비밀번호를 보관하게 됨
- 최소권한(조회만 허용 등) 통제 어려움
- 사고 시 피해 범위가 큼

OAuth는 이를 토큰(access token)으로 바꿔 해결합니다

 

OAuth Role

괄호안의 내용은 위 예시와 매핑한것이다

resource owner(User) : 자원(사용자 정보)의 주인

resource server(Google) : 자원을 제공하는 서버

client(Linkedin) : 자원을 가져오려는 애플리케이션

authorization server(Google) : 클라이언트에게 액세스 토큰을 발급하는 서버. authorization server와 resource server가 다를 수도 있고 같을 수도 있다.

 

OAuth 흐름

OAuth 기본흐름

기본적인 흐름은 위와 같다.

"인증"을 어떻게 하는지는 서비스마다 다르게 구현되어있다

여기서 Access Token마다 어떤 resource까지 제공할 수 있는지 제한되어있다.

예를들어, 어떤 Access Token로는 이름까지만 제공가능하고 어떤 Access Token은 이름과 이메일이 제공가능하다

 

 

OAuth + OIDC

OAuth + OIDC 플로우

OIDC : OAuth2.0에서 확장된 ID 인증 프로토콜

1) 사용자가 Linkedin에서 “Google로 로그인”을 누른다

• 이때 Linkedin은 구글 로그인 페이지로 브라우저를 리다이렉트
• 중요한 점: 사용자가 구글 ID/PW를 입력하는 곳은 구글 화면이고, Linkedin은 비밀번호를 절대 받지 않음

2) Linkedin → Google /authorize 요청(브라우저 프론트 채널)

• client_id: "이 요청은 LinkedIn 앱에서 왔다"
• redirect_uri: "로그인 결과를 LinkedIn의 이 주소로 돌려줘"
• scope=openid email profile: "로그인(OIDC) + 기본 프로필/이메일을 원해"

4) Google → LinkedIn으로 code 전달(브라우저 리다이렉트)

구글은 아래정보와 함께 Linkedin의 redirect_uri로 돌려보냄

• code=... (짧은 수명의 1회용 코드)
• state=... (요청 때 보낸 state와 동일해야 함)

Linkedin은 여기서 state가 일치하는지 확인해서 "중간에 누가 끼어든 요청"을 막음

5) LinkedIn → Google /token 교환(서버-서버 백채널)

이제 Linkedin 서버가 구글에 code를 토큰으로 교환

구글은 보통 다음을 반환:

• id_token (JWT): "이 사용자는 누구다"를 서명된 형태로 증명
• access_token: 사용자 정보 같은 구글 리소스 API 호출용

6) LinkedIn이 id_token을 검증하고 사용자 계정을 연결한다

Linkedin은 id_token을 검증

• 서명 검증(구글이 진짜 발급했는지)
• iss(발급자), aud(수신자=Linkedin), exp(만료) 확인

그리고 구글 계정의 고유 식별자를 통한 계정 매핑

8) 최종: LinkedIn이 자체 세션을 만들어 로그인 완료

• LinkedIn은 “구글 토큰”을 그대로 쓰는 게 아니라,
• 최종적으로 LinkedIn 서비스용 세션(쿠키/세션 토큰) 을 발급해서 로그인 상태를 유지해.

3-legged(사용자 대행) vs 2-legged(서비스 대 서비스)

OAuth에 꼭 end user가 껴있지는 않다

3-legged OAuth: 사용자 대행(사용자 동의가 존재)
Access token의 의미: 사용자가 A어플리케이션에게 이 scope로 B어플리케이션의 자원 접근을 허락했다.

 

2-legged OAuth: A 시스템이 "자기 자신 자격"으로 토큰을 발급받아 B API를 호출, 이때 사용자가 관여하지 않는다

Access Token의 의미 : A 서비스는 이 scope로 B API를 호출할 권한이 있다