OAuth 2.0

📌 OAuth 2.0이란?

OAuth 2.0 은 사용자가 자신의 리소스에 대한 접근 권한을 third-party 웹 또는 애플리케이션에 부여할 수 있도록 설계된 권한 부여 프레임워크이다. 사용자는 OAuth 2.0을 통해 아이디, 비밀번호와 같은 로그인 정보를 공유하지 않으면서 third-party 웹 또는 애플리케이션이 특정 작업을 수행할 수 있도록 허용할 수 있다.

특정 서비스에 로그인 시 카카오, 구글과 같은 계정을 통해 로그인한 경험이 있을 것이다. 이러한 방식이 OAuth 2.0이 사용된 예시이다.

📌 용어 정리

OAuth 2.0의 주요 구성 요소는 다음과 같다.

1. Resource Owner: 리소스에 대한 접근 권한을 가진 사용자, OAuth 2.0이 사용된 애플리케이션을 이용하려는 사용자
2. Client: Resource Owner의 데이터를 요청하는 third party 애플리케이션, Authorization/Resource Server 입장에서 애플리케이션은 Client이다.
3. Authorization Server: 클라이언트를 인증 및 권한을 부여(인가)하고 엑세스 토큰을 발급하는 서버
4. Resource Server: 토큰을 통해 클라이언트의 요청을 검증 및 데이터를 제공하는 서버

OAuth 2.0에서 사용되는 주요 용어는 다음과 같다.

1. Authentication: 사용자가 누구인지 확인하는 과정이다.
2. Authorization: 사용자가 특정 리소스에 접근할 수 있는 권한이 있는지 확인하는 과정이다.
3. Access Token: 사용자의 권한을 나타내는 토큰이다. 만료 기한이 존재한다.
4. Refresh Token: 만료된 Access Token을 갱신하기 위해 사용되는 토큰이다.

📌 동작 방식

OAuth 2.0에서 인증 및 인가를 위한 다양한 방법이 있으나, 그 중 Authorization Code Grant 에 대하여 설명하려고 한다. 단계별로 살펴보자.

1. Resource Owner → Client: 로그인 요청

사용자가 애플리케이션(Client)에 로그인 요청을 보낸다.

2. Client → Authorization Server: 로그인 요청

Client가 Authorization Server에게 인증 및 인가를 요청한다. 요청 시 다음과 같은 정보를 포함한다.

• client _id: Client를 식별하는 고유한 ID
• redirect_uri: 인증 후 사용자를 리디렉션할 URI
• response_type: code 로 설정해야 하며, 인증이 성공하면 Authorization Code를 받는다.
• scope: 클라이언트가 리소스에 어떤 작업을 수행할 수 있는지 정의된 문자열

3. Authorization Server → Resource Owner: 로그인 페이지 제공

제공된 페이지에서 사용자는 자신의 자격 증명(아이디, 비밀번호 등)을 입력한다.

4. Resource Owner → Authorization Server: ID/PW 제공

사용자가 입력한 자격 증명을 통해 인증 과정을 거친다.

5. Authorization Server → Resource Owner: Authorization Code 발급

사용자 인증에 성공하면 Authorization Server는 사용자에게 Authorization Code를 발급한다. 이 코드는 Client가 Access Token을 요청할 때 사용되는 임시 코드이다.

6. Resource Owner → Client: Redirect URI로 리디렉션

Authorization Server는 사용자를 Redirect URI로 리디섹션하며, 이 때 URI에 Authorization Code를 포함시킨다.

7. Client → Authorization Server: Access Token 요청

Client가 Authorization Code를 통해 Access Token을 요청한다. 요청에 포함되어야 하는 정보들은 다음과 같다.

• grant_type: authorization_code 로 설정되어야 한다.
• code: 발급된 Authorization Code로 설정한다.
• redirect_uri
• client_id
• client_secret

8. Authorization Server → Client: Access Token 발급

Authorization Server가 요청을 검증한 후 Client에게 Access Token을 발급한다. 이 시점에 Refresh Token도 같이 발급되는 경우도 있다.

9. Client → Resource Owner: 로그인 성공 알림

Client는 발급된 Access Token을 DB 등에 저장하고 사용자에게 로그인이 성공되었음을 알린다.

10. Resource Owner → Client: 서비스 요청

사용자가 Client를 통해 리소스를 요청한다.

11. Client → Resource Server: Access Token으로 API 호출

Client는 Resource Server에 API 호출 시 Access Token을 함께 전송하여 인증 및 인가를 수행한다.

12. Resource Server → Client: Access Token 검증 및 서비스 제공 승인

Resource Server는 받은 Access Token이 만료되었는지, scope와 권한이 적절한지 확인한다. 유효성 검증이 완료되면 리소스를 제공할 준비를 한다.

13. Resource Server → Client: 리소스 제공

검증이 완료되면 Resource Server는 요청된 리소스를 제공한다.

📌 장점

• 사용자의 자격 증명을 직접 공유하지 않고 토큰을 통해 리소스에 접근할 수 있다. 토큰이 탈취되더라도 유효 기간, scope로 피해를 줄일 수 있다.
• 한 번 인가된 애플리케이션은 추가적인 인증 없이 지속적으로 접근이 가능하다.

📌 단점

• 본질적으로 인가 프로토콜이다. 즉, 인증을 직접 처리하지 않으며, 인증을 위한 추가적인 프로토콜이 필요할 수 있다.
• 데이터 암호화를 기본적으로 제공하지 않는다. 따라서 데이터 암호화를 위해 SSL/TLS를 구현해야 한다.
• Authorization Server에 의존적이며, 따라서 서버에 보안 문제가 발생하면 애플리케이션에도 영향을 미칠 수 있다.
• 권한 위임을 기본적으로 지원하지 않는다.

📌 참고

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

https://guide.ncloud-docs.com/docs/b2bpls-OAuth2