Oauth란

Oauth

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

즉, OAuth를 바탕으로 제 3자 서비스(나의 서비스)는 외부 서비스(Facebook, Apple, Google)의 특정 자원을 접근 및 사용할 수 있는 권한을 인가받게 된다.

 

Oauth가 제공하는 장점

1. 구글, 페이스북 등의 외부 소셜 계정을 기반으로 간편하게 회원가입 및 로그인
2. 구글, 페이스북 등 외부 서비스가 제공하는 기능을 간편하게 사용 가능

 

Oauth 참여자

• Resource Server : Client가 제어하고자 하는 자원을 보유하고 있는 서버 (Apple, Google)
• Resource Owner : 자원의 소유자 (실제 유저)
• Client : Resoure Server에 접속해서 정보를 가져오고자 하는 클라이언트 (내 서비스)

 

Oauth Flow

Client 등록 → Resource Owner의 승인 → Resource Server의 승인( Access Token 발급) → API 호출 → Refresh Token

1. Client 등록

Client가 Resource Server를 이용하기 위해서는 Resource Server에 자신의 서비스를 등록함으로써 사전 승인을 받아야 합니다.

등록 절차를 통해 3 가지의 정보를 부여받습니다.

1. Client ID :Client을 구별할 수 있는 식별자이며, 노출이 무방하다.
2. Client Secret : Client ID에 대한 비밀키로서, 절대 노출해서는 안 된다.
3. Authorized redirect URL : Authorization Code를 전달받을 리다이렉트 주소다.

Authorization Code: 외부 서비스에 로그인(인증)을 마치면 Query String으로 얻는 Code

2. Resource Owner의 승인

1. Resource Owner는 Client의 어플리케이션을 이용하다가 소셜 로그인 버튼을 클릭한다.
2. Client는 Authorization URL에 response_type , client_id , redirect_uri , scope 등의 매개변수를 쿼리 스트링으로 포함하여 보낸다.
3. Client가 빌드한 Authorization URL로 이동된 Resource Owner는 Resource Server에 접속하여 로그인을 수행한다.
4. 검증이 왼료되면 Resource Server는 Resource Owner에게 명시한 scope에 해당하는 권한을 Client에게 정말로 부여할 것인가?를 질의한다.
5. 로그인이 완료되면 Resource Server는 Query String으로 넘어온 파라미터들을 통해 Client를 검사한다.
6. 허용한다면 최종적으로 Resource Owner가 Resource Server에게 Client의 접근을 승인하게 되며, Redirect URL로 Client를 리다이렉트 시킨다.

3. Resource Server의 승인

1. Resource Owner의 승인이 마무리 되면 명시된 Redirect URL로 클라이언트를 리다이렉트 시킨다. 이 때 Resource Server는 임시 암호인 Authorization Code(Query String으로 들어온 code)를 함께 발급한다.
2. Client는 ID와 비밀키 및 Authorization Code를 Resource Server에 직접 전달한다.
3. Resource Server는 정보를 검사한 다음, 유효한 요청이라면 Access Token을 발급한다.

4. API 호출

1. Client는 해당 토큰을 서버에 저장해두고, Resource Server의 자원을 사용하기 위한 API 호출 시 해당 토큰을 헤더에 담아 보낸다.

5. Refresh Token

Access Token은 만료 기간이 있으며, 만료된 Access Token으로 API를 요청하면 401 에러가 발생한다. Access Token이 만료되어 재발급받을 때마다 서비스 이용자가 재 로그인하는 것은 다소 번거롭습니다.

보통 Resource Server는 Access Token을 발급할 때 Refresh Token을 함께 발급합니다.. Client는 두 Token을 모두 저장해두고, Resource Server의 API를 호출할 때는 Access Token을 사용합니다. Access Token이 만료되어 401 에러가 발생하면, Client는 보관 중이던 Refresh Token을 보내 새로운 Access Token을 발급받게 됩니다.

 

 

Authorization Code가 왜 필요한 것 인가?

Authorization Code를 발급하지 않고, 곧바로 Client에게 Access Token을 발급해줘도 되지 않을까? 왜 굳이 Access Token을 획득하는 과정에 Authorization Code 발급 과정이 필요할까?

Redirect URI를 통해 Authorization Code를 발급하는 과정이 생략된다면, Authorization Server가 Access Token을 Client에 전달하기 위해 Redirect URI를 통해야 한다. 이때, Redirect URI를 통해 데이터를 전달할 방법은 URL 자체에 데이터를 실어 전달하는 방법밖에 존재하지 않는다. 브라우저를 통해 데이터가 곧바로 노출되는 것 이다. 이런 보안 사고를 방지 Authorization Code를 사용하는 것 이다.

Redirect URI를 프론트엔드 주소로 설정하여, Authorization Code를 프론트엔드로 전달한다. 그리고 이 Authorization Code는 프론트엔드에서 백엔드로 전달된다. 코드를 전달받은 백엔드는 비로소 Authorization Server의 token 엔드포인트로 요청하여 Access Token을 발급한다.

 

백엔드와 프론트엔드의 역할

Authorization URL

Authorization Server의 로그인 페이지로 이동하기 위한 인증 URL을 생성하는 것은 프론트엔드, 백엔드 어디서해도 괜찮다고 생각한다. 단, Client ID나 Scope와 같은 정보들의 응집도를 위해 이것도 백엔드에서 생성하고, 프론트엔드는 백엔드로부터 URL을 가져오는것이 좋다고 생각한다. 일단, 백엔드가 URL을 생성한다고 가정한다.

Authorization Code와 Access Token 흐름

프론트엔드는 백엔드가 생성한 인증 URL을 가져오고, 프론트엔드는 사용자를 인증 URL로 리디렉션시킨다. 그리고 사용자는 로그인을 마치고 Redirect URI로 리디렉션 될텐데, 이때 Redirect URI은 프론트엔드로 설정한다.

프론트엔드로 리디렉트 되었다면 함께 전달된 Authorization Code를 백엔드 API를 통해 백엔드로 전달한다. Authorization Code를 전달받은 백엔드는 Authorization Code, Client ID, Client Secret으로 Authorization Server로부터 Access Token을 발급받는다.

 

참고

https://tecoble.techcourse.co.kr/post/2021-07-10-understanding-oauth/

OAuth 개념 및 동작 방식 이해하기

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

OAuth 2.0 개념과 동작원리