[WEB] OAuth

JE·2023년 9월 1일

WEB

목록 보기

2/2

위의 사진과 같이 웹 서핑을 하다 보면 외부 소셜 계정을 기반으로 간편히 회원가입 및 로그인할 수 있는 웹 어플리케이션을 쉽게 찾아볼 수 있다. 별도의 회원가입 없이 로그인을 제공하는 플랫폼의 아이디만 있으면 서비스를 이용 할 수 있다. 외부 서비스에서도 인증을 가능하게 하고 그 서비스를 이용하게 해주는 것을 바로 OAuth 라고 한다.

OAuth의 등장배경
Goolgle Calendar 에 입력되어있는 일정을 관리할 수 있는 통합 Calendar App이 있다.
하지만 이를 사용하려면 User의 Google ID와 PW를 넘겨줘야 Calendar App이 Google로 로그인 한 후에 User의 구글 캘린더 정보를 받고 이를 User에게 서비스로 제공할 수 있다.
여기서 여러 문제점들이 발생한다.

이러한 문제들은 Calendar App이 User의 Id와 Password를 관리하기 때문에 생긴 문제이다.
이런 문제를 해결하기 위해 OAuth 가 등장하였다.

Oauth

인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다.
- wikipedia

OAuth 동작에 관여하는 참여자 .. resource는 '구글 캘린더 정보', '페이스북 친구 목록’ 등이 해당된다.

Resource Owner : 자원의 소유자, 인증을 하는 주체 → User
Client : 권한을 위임받아 정보를 가져오고자 하는 주체 → Calendar App
Resource Server : 인가를 수행하고 Client 에게 자원을 제공하는 주체 → Google
Authorization Server : 인증을 검증하고 Client에게 권한을 부여하는 주체 → Google
참고 Authorization Server 와 Resource Server 는 공식문서상 별개로 구분되어 있지만, 별개의 서버로 구성할지, 하나의 서버로 구성할지는 개발자가 선택하기 나름이라다.

중요 개념

Authentication (인증) : 접근 자격이 있는지 검증하는 단계
Authorization(인가) : 자원에 접근할 권한을 부여하고 리소스 접근 권한이 담긴 Access Token 을 제공
Access Token : Resource Server 에게서 Resource Owner 의 정보를 획득할 때 사용되는 Token
Refresh Token : Access Token 만료시 이를 ****재발급 받기위한 용도로 사용하는 Token

OAuth는 인가를 위해 탄생한 기술이라고 할 수 있다.

Client 등록

우선적으로 OAuth 2.0 서비스를 이용하기전에 Client를 Resource Server 에 등록해야한다.
이 때, Redirect URI를 등록해야한다. Redirect URI는 사용자가 OAuth 서비스에서 인증을 마치고 (예를 들어 구글 로그인 페이지에서 로그인을 마쳤을 때) 사용자를 리디렉션 시킬 위치이다. Redirect URI 를 제공하지 않으면 OAuth를 사용할 수 없다.

등록과정을 마치면, Client ID와 Client Secret를 얻을 수 있다. 발급된 Client ID와 Client Secret은 Access Token 을 획득하는데 사용된다.

Client ID : 어플리케이션(서비스)을 구별할 수 있는 식별자이며, 노출해도 무방하다.
Client Secret : Client ID에 대한 비밀키로서, 절대 노출해서는 안된다.

OAuth 동작 메커니즘

1~2. 로그인 요청

Resource Owner(user) 가 서비스의 '구글로 로그인하기' 등의 버튼을 클릭해 로그인을 요청한다.
Client(App)는 OAuth 프로세스를 시작하기 위해 사용자의 브라우저를 Authorization Server(Google)로 보내야한다.

클라이언트는 이때 Authorization Server가 제공하는 Authorization URL에 response_type , client_id , redirect_uri , scope 등의 매개변수를 쿼리 스트링으로 포함하여 보낸다.

https://authorization-server.com/auth?
response_type=code
&client_id=29352735982374239857
&redirect_uri=https://calendar-app.com/callback
&scope=create+delete

매개변수
- response_type : Authorization code를 나타내는 부분이다. 반드시 code 로 값을 설정해야한다.
- scope : 클라이언트가 부여받은 리소스 접근 권한 범위 (client 등록 때 설정한다.)

3 ~ 4. 로그인 페이지 제공, ID/PW 제공

Resource Owner(user)는 제공된 로그인 페이지에서 ID와 PW 등을 입력하여 인증을 한다.

지금까지의 과정에서 Client 오로지 로그인 페이지로의 이동만 제공해준다는 것이고 로그인 페이지에서의 인증은 Resource Owner 와 Authorization Server 만 참여하고 있다. 이를 통해 인증과 인가의 대상을 분리하는 것이 중요함을 알 수 있다.

5 ~ 6. Authorization Code 발급, Redirect URI로 리디렉트

인증이 성공되었다면, Authorization Server(google)는 제공된 Redirect URI로 사용자를 리디렉션시킬 것 이다. 이때, Redirect URI에 Authorization Code 를 포함하여 사용자를 리디렉션 시킨다. Authorization Code란 Client가 Access Token(권한을 부여받을 수 있는 Token)을 획득하기 위해 사용하는 임시 코드이다.

7 ~ 8. Authorization Code와 Access Token 교환

Client는 Authorization Server에 Authorization Code를 전달하고, Access Token을 응답받는다. Client는 발급받은 Resource Owner의 Access Token을 저장하고, 이후 Resource Server에서 Resource Owner의 리소스에 접근하기 위해 Access Token을 사용한다.

권한을 부여 받는 과정(인가)에서 Client 와 Authorization Server만 참여하는 것을 볼 수 있다. 이는 범위를 줄여 권한을 탈취 당할 수 있는 위험를 줄여주고 둘 사이의 통신은 HTTPS 연결을 통해서만 이루어진다.

9. 로그인 성공

위 과정을 성공적으로 마치면 Client는 Resource Owner에게 로그인이 성공하였음을 알린다.

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

이후 Resource Owner가 Client에게 서비스 요청하면 Client는 위 과정에서 발급받고 저장해둔 Access Token을 사용하여 제한된 리소스에 요청하고, Resource Server는 이 Token을 검증한 후에 리소스를 반환한다. Client는 이 리소스를 가공하여 Resource Owner에게 서비스로 제공한다.

백엔드에서의 역할

인증 URL 생성

Authorization Server의 로그인 페이지로 이동하기 위한 Authorization URL을 생성하는 것은 Client ID나 Scope와 같은 정보들의 응집도를 위해 백엔드에서 생성한다.
Access Token 발급 및 관리

백엔드는 Authorization Code를 통해 Authorization Server로부터 Access Token을 발급받는다. 백엔드에서는 이 Access Token을 안전하게 저장하고 관리하여 무단 접근을 방지해야한다.
Access token으로 자원 요청

Access Token을 사용하여 토큰의 유효성을 검증하여 권한이 있는 요청만이 처리되도록 한다.
Token 갱신 관리

Access Token은 유효 기간이 제한되어 있다. 이 기간이 만료되면 새로운 Access Token을 얻어야 하는데,백엔드에서는 클라이언트가 만료되기 전에 새로운 토큰을 발급받을 수 있도록 하는 갱신 프로세스를 관리한다.

참고
https://hudi.blog/oauth-2.0/
https://www.youtube.com/watch?v=Mh3LaHmA21I

이전 포스트