[OAuth2.0] OAuth2.0 개념과 동작 원리

OAuth2란?

OAuth 2.0은 인증을 위한 개방형 표준 프로토콜로, '제 3자 애플리케이션'이 사용자를 대신해 HTTP 서비스를 이용할 수 있는 권한을 부여하는 메커니즘을 제공합니다.

 

이 프로토콜에서는 Third-Party 프로그램에게 리소스 소유자를 대신하여 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 방식을 제공한다. 구글, 페이스북, 카카오, 네이버 등에서 제공하는 간편 로그인 기능도 OAuth2 프로토콜 기반의 사용자 인증 기능을 제공하고 있는데, 이번 글에서는 자체적인 인증 서버를 만드는 방법을 정리하려고 합니다.

 

먼저 본론으로 들어가기 전에 정확한 용어 설명을 먼저 정리해보겠습니다~!

 

역할

• Resource Owner: 직역하면 리소스 소유자로, 정보에 접근 할 수 있는 자격 승인을 요청하는 주체 입니다.
• Client: Resource Owner의 리소스를 요청하고, 사용하려는 매개체 즉, 어플리케이션 입니다.
• Resource Server: Resource Owner의 리소스 정보가 저장되어 있는 서버 입니다.
• Authorization Server: 인증/인가를 수행하는 서버로 Client의 접근 자격을 확인하고 Access token을 발급하여 권한을 부여하는 서버 입니다.

 

주요 용어

• 인증(Authentication): 접근 자격이 있는지 확인.
• 인가(Authorization): 리소스에 접근 권한을 부여하고, 권한이 담긴 Access Token을 발급.
• Access Token: 리소스 서버로 부터 리소스 오너의 정보를 요청할 때 사용하는 토큰으로 만료 시간이 있음.
• Refresh Token: Access Token 만료 시 재발급 받기 위한 토큰.

 

권한부여 유형

1. Authorization Code Grant

• 권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식으로 가장 많이 쓰이고 기본이 되는 방식입니다.
• 간편 로그인 기능에서 사용되는 방식으로 클라이언트가 사용자를 대신하여 특정 자원에 접근을 요청할 때 사용되는 방식입니다.
• 보통 타사의 클라이언트에게 보호된 자원을 제공하기 위한 인증에 사용됩니다.
• Refresh Token 사용이 가능한 방식입니다.

 

• 권한 부여 승인 요청 시 response_type을 code로 지정하여 요청합니다. 이후 클라이언트는 권한 서버에서 제공하는 로그인 페이지를 브라우저를 띄워 출력합니다.
• 로그인 페이지를 통해 사용자가 로그인을 하면 권한 서버는 권한 부여 승인 코드 요청 시 전달받은 redirect_url로 Authorization Code를 전달합니다.
• Authorization Code는 권한 서버에서 제공하는 API를 통해 Access Token으로 교환됩니다.

2. Implicit Grant

• 자격증명을 안전하게 저장하기 힘든 클라이언트(ex: JavaScript등의 스크립트 언어를 사용한 브라우저, 특별히 안전한 저장공간이 없는 Javascript SPA[Single Page Application])에게 최적화된 방식입니다.
• 암시적 승인 방식에서는 권한 부여 승인 코드 없이 바로 Access Token이 발급 됩니다.
• Refresh Token 사용이 불가능한 방식이며, 권한 서버는 client_secret를 사용해 클라이언트를 인증하지 않습니다.
• Access Token을 획득하기 위한 절차가 간소화되기에 응답성과 효율성은 높아지지만 Access Token이 URL로 전달되어 토큰 노출 위험이 있습니다.

• 권한 부여 승인 요청 시 response_type을 token으로 설정하여 요청합니다. 이후 클라이언트는 권한 서버에서 제공하는 로그인 페이지를 브라우저를 띄워 출력합니다.
• 로그인이 완료되면 권한 서버는 Authorization Code가 아닌 Access Token를 redirect_url로 바로 전달합니다.

3. Resource Owner Password Credentials Grant

• 간단하게 username, password로 Access Token을 받는 방식입니다.
• 클라이언트가 타사의 외부 프로그램일 경우에는 이 방식을 적용하면 안됩니다. 자신의 서비스에서 제공하는 어플리케이션일 경우에만 사용되는 인증 방식입니다.
•  Refresh Token의 사용도 가능합니다.

• API를 통해 username, password을 전달하여 Access Token을 받는다.

 

4. Client Credential

• 클라이언트의 자격증명만으로 Access Token을 획득하는 방식입니다. 즉 클라이언트 자체가 사용자의 대신으로 Access Token을 획득합니다.
• OAuth2의 권한 부여 방식 중 가장 간단한 방식으로 클라이언트 자신이 관리하는 리소스 혹은 권한 서버에 해당 클라이언트를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우 사용됩니다.
• 이 방식은 자격증명을 안전하게 보관할 수 있는 클라이언트에서만 사용되어야 하며, Refresh Token은 사용할 수 없습니다.

• 백엔드 서비스 간 통신에 사용: 두 서비스가 사용자의 개입 없이 서로 통신할 필요가 있을 때. (ex. 마이크로서비스 간의 상호 작용)
• 제한된 리소스에 대한 액세스에 사용: 사용자와 관련이 없는 리소스에 대한 액세스가 필요할 때. (ex: 공통 코드 또는 설정 정보 조회)
• 애플리케이션 수준의 권한에 사용: 특정 애플리케이션 또는 서비스에 권한을 부여할 때 사용자 개입이 필요 없는 경우.

다음 글에서는 Spring Security OAuth2를 사용한 OAuth2 인증서버 구축 방법을 알아보겠습니다~!