Portfolio

OAuth란?OAuth 2.0 용어 Resource Owner Resource Server Authorization Server Client 애플리케이션 등록 Redirect URI Client ID, Client Secret OAuth 2.0 동작 매커니즘 1 - 2. 로그인 요청 3 - 4. 로그인 페이지 제공, 아이디/비밀번호 제공 5 - 6. Authorization Code 발급, Redirect URI로 리다이렉트 7 - 8. Authorization Code와 Access Token 교환 9. 로그인 성공 10 - 13. Access Token으로 리소스 접근 Authorization Code가 왜 필요한 것인가?프론트와 백엔드 그래서 결론은?참고

OAuth란?

구글, 네이버, 카카오 등 다양한 플랫폼의 특정한 사용자 데이터에 접근하기 위해 제 3자 클라이언트(링크오션)가 사용자의 접근 권한을 위임 받을 수 있는 표준 프로토콜

OAuth 2.0 용어

Resource Owner

우리의 서비스(링크오션)를 이용하면서, 구글 네이버 카카오 등의 플랫폼에서 리소스(구글 캘린더 정보, 네이버 블로그 포스트 작성, 카카오 친구 목록 등)를 소유하고 있는 사용자

Resource Server

구글, 네이버, 카카오와 같이 리소스를 가지고 있는 서버

Authorization Server

Resource Owner를 인증하고, Client에게 액세스 토큰을 발급해주는 서버

Client

Resource Server 자원을 이용하고자 하는 서비스(링크오션)

애플리케이션 등록

OAuth 2.0 서비스를 이용하기 전에 선행되어야 하는 작업으로 Client(링크오션)를 Resource Server(구글, 네이버, 카카오 등)에 등록하는 일이다. 이 때 Redirect URI를 등록하는데, Redirect URI는 사용자가 OAuth 2.0 서비스에서 인증을 마치고(구글 로그인 페이지에서 로그인을 마쳤을 때) 사용자를 리다이렉션 시킬 위치이다.

Redirect URI

OAuth 2.0 서비스는 인증이 성공한 사용자를 사전에 등록된(애플리케이션 등록 단계) Redirect URI로만 리다이렉션 시킨다. 등록되지 않은 URI로 리다이렉션될 경우, Authorization Code를 중간에 탈취 당할 위험이 있기 때문에 사전 등록 작업이 필요하다.

일부 OAuth 2.0 서비스(구글)는 여러 Redirect URI를 등록할 수 있으며, Redirect URI는 기본적으로 보안을 위해 https만 허용하지만 루프백(localhost)은 예외적으로 http가 허용된다.

Client ID, Client Secret

Resource Server에 애플리케이션 등록 과정을 마치면, Client ID, Client Secret를 발급해준다. 발급된 Client ID, Client Secret은 액세스 토큰을 획득하는데 사용된다.

Client ID는 공개되어도 상관없지만, Client Secret은 절대 유출되어서는 안 된다.

OAuth 2.0 동작 매커니즘

1 - 2. 로그인 요청

Resource Owner(사용자)가 Client(우리 서비스, 링크오션)의 “구글로 로그인하기” 등의 버튼을 클릭해 로그인을 요청

Client(링크오션)가 OAuth 프로세스를 시작하기 위해 사용자의 브라우저를 Authorization Server로 전송

이때 Client(링크오션)는 Authorization Server가 제공하는 Authorization URL에 response_type, client_id, redirect_uri, scope 등의 매개변수를 쿼리 스트링으로 포함하여 전송

예시) OAuth 2.0 서비스의 Authorization URL = https://authorization-server.com/auth라면, Client(링크오션)는 https://authorization-server.com/auth?response_type=code&client_id=111111111&redirect_uri=https://example-app.com/callback&scope=create+delete의 URL 빌드하여 해당 URL로 사용자의 브라우저를 Authorization Server로 전송

매개변수

reponse_type: 반드시 code로 값을 설정해야 하며, 인증이 성공할 경우 Client는 Authorization Code를 받는다.
client_id: “애플리케이션 등록” 단계를 마치고 발급 받은 Client ID
redirect_uri: “애플리케이션 등록” 단계에서 등록한 Redirect URI
scope: Client가 부여 받은 리소스 접근 권한

3 - 4. 로그인 페이지 제공, 아이디/비밀번호 제공

Client(링크오션)가 빌드한 Authorization URL로 이동된 Resource Owner는 제공된 로그인 페이지에서 아이디와 비밀번호를 입력하여 인증

5 - 6. Authorization Code 발급, Redirect URI로 리다이렉트

Resource Owner가 제공한 아이디와 비밀번호로 인증에 성공했다면, Authorization Server는 매개변수로 제공된 redirect_uri로 Resource Owner를 리다이렉션 시킨다.

이때 Redirect URI에 Authorization Code를 포함하여 Resource Owner를 리다이렉션 시킨다.
Authorization Code란 Client(링크오션)가 Access Token을 획득하기 위해 사용하는 임시 코드로, 수명이 일반적으로 1~10분으로 짧다.

7 - 8. Authorization Code와 Access Token 교환

Client(링크오션)는 Authorization Server에 Authorization Code를 전달하고, Access Token을 응답받는다.

Authorization Code와 Access Token 교환은 token 엔드포인트에서 이루어진다.

예시) Access Token을 발급 받기 위한 HTTP 요청


POST /oauth/token HTTP/1.1
HOST: authorization-server.com
CONTENT_TPYE: application/x-www-form-urlencoded

grant_type=authorization_code
&code=xxxxxxx
&redirect_uri=https://example-app.com/redirect
&client_id=xxxxxx
&client_secret=xxxxxxx

매개변수

grant_type: authorization_code로 설정되어야 한다.
code: 발급 받은 Authorization Code
redirect_uri: Redirect URI
client_id: Client ID
client_secret: Client Secret

Client(링크오션)는 발급 받은 Resource Owner의 Access Token을 저장한다.

저장한 Access Token을 이용해 이후에 Resource Server에서 Resource Owner의 리소스에 접근한다.
Access Token는 유출되어서는 안 되므로 다른 이가 가로채지 못하도록 HTTPS 연결을 통해서만 할 수 있다.

9. 로그인 성공

Client(링크오션)는 Resource Owner에게 로그인이 성공하였음을 알린다.

10 - 13. Access Token으로 리소스 접근

이후 Resource Owner가 Resource Server의 리소스가 필요한 기능을 Client(링크오션)에 요청

Client(링크오션)은 저장한 Resource Owner의 Access Token을 사용하여 Resource Sever의 제한된 리소스에 접근하고 Resource Owner에게 Client(링크오션)의 서비스를 제공

Authorization Code가 왜 필요한 것인가?

7 - 8. Authorization Code와 Access Token 교환 단계를 생략하면, Authorization Server는 Access Token을 Client에게 전달하기 위해 Redirect URI을 통해, 즉 Redirect URL에 Access Token을 실어 전달하는 방법밖에 없다. 이는 브라우저에 Access Token이 노출되는 것이다.

Access Token은 민감한 데이터이므로 노출되어서는 안 되기 때문에 이를 위해 Authorization Code를 사용하는 것이다.

프론트와 백엔드

Redirect URI를 프론트엔드 주소로 설정

Authorization Code를 프론트엔드로 전달

프론트엔드가 백엔드로 Authorization Code를 전달

백엔드는 Authorization Server의 token 엔드포인트로 요청하여 Access Token을 발급 받아 저장

⇒ Access Token이 항상 백엔드와 OAuth 서비스를 통해서 전송되기 때문에 다른 이가 Access Token을 가로챌 수 없게 된다.

그래서 결론은?

Client ID, Scope 등의 정보로 “Authorization Server의 로그인 페이지로 이동하기 위한 인증 URL” 생성 Redirect URI은 프론트엔드로 설정하는 일은 프론트엔드, 백엔드 어디서해도 상관없음

Resource Owner가 로그인에 성공했다면, 프론트엔드 Redirect URI에 담긴 Authorization Code를 백엔드 API를 통해 백엔드한테 전달

백엔드는 프론트엔드가 전달한 Authorization Code와 Client ID, Client Secret을 이용해 Authorization Server로부터 Access Token을 발급받는다.

참고

OAuth 2.0 개념과 동작원리

2022년 07월 13일에 작성한 글을 보충하여 새로 포스팅한 글이다. 우리의 서비스가 사용자를 대신하여 구글의 캘린더에 일정을 추가하거나, 페이스북, 트위터에 글을 남기는 기능을 만들 수 있을 것 이다. 이때, 가장 쉽게 이 기능을 구현하는 방법은 사용자로부터 구글, 페이스북, 트위터의 ID, Password 를 직접 제공받아 우리의 서비스에 저장하고 활용하는 방법이다. 하지만 이런 방법이 안전할까?

https://hudi.blog/oauth-2.0/