OAuth 2.0 이란?

OAuth 2.0 (Open Authorization 2.0)

인증을 위한 개방형 표준 프로토콜이다. 이 프로토콜에서는 Third-Party 프로그램에서 리소스 소유자를 대신해 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 방식을 제공한다.

 

구글, 네이버, 카카오 등 소셜 로그인 기능이 OAuth 2.0 프로토콜 기반의 사용자 인증 기능을 이용한 방식이다.

 

OAuth 의 탄생 배경

OAuth가 등장하기 전에 A 사이트가 B사이트의 리소스를 가져오기 위해서는 다른 사이트의 ID와 PW 등을 직접 입력받아 저장하여 필요할 때 불러와서 사용해야했다. 이러한 방식으로 리소스를 가져오면 문제가 발생하는데

• 사용자 : A사이트에 B사이트의 ID와 PW 등의 정보를 주는 것에 대해 신뢰할 수 없다
• A사이트 : ID와 PW 등을 저장하고 있기 때문에 보안 문제가 생길 경우 책임을 져야한다는 부담감이 생긴다
• B사이트 : A사이트를 신뢰할 수 없다

이와 같은 문제를 해결하기 위해 2006년 트위터 개발자와 Gnolia의 개발자가 안전한 인증방식에 대해 논의를 하며 OAuth가 등장하였고 2010년에 OAuth 1.0이 발표되었다. 현재 OAuth의 세션 고정 공격을 보완한 OAuth 1.0a를 거쳐 OAuth의 구조적인 문제점을 해결하고, 핵심요소만을 차용한 유사 프로토콜 WRAP(Web Resource Access Protocol)을 기반으로 발표한 OAuth 2.0이 많이 사용된다.

 

OAuth 2.0 용어

• Resource Server : OAuth 2.0 서비스를 제공하고 자원을 관리하는 서버 (Google, Naver 등과 같은 다른 사이트)
• Resource Owner(자원 소유자) : Resource Server의 계정을 소유하고 있는 사용자 (서비스를 이용할 사용자)
• Client : Resource Server의 API를 사용하여 데이터를 가져오려고 하는 사이트 (개발 사이트)
• Authorization Server(권한 서버) : Client가 Resource Server의 서비스를 사용할 수 있게 인증하고 토큰을 발생해주는 서버
• Access Token : 리소스 서버에 자원을 요청할 수 있는 토큰
• Refresh Token : 권한 서버에 접근 토큰을 요청할 수 있는 토큰(Access Token의 만료 시)

 

OAuth 2.0 권한 부여 방식

1. Authorization Code Grant - 권한 부여 승인 코드 방식

권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식으로 기본적이고 가장 많이 쓰이는 방식이다. 간편 로그인 기능에서 사용되는 방식으로 클라이언트가 사용자를 대신하여 특정 자원에 접근을 요청할 때 사용하는 방식이다.

Refresh Token의 사용이 가능하다

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

 

2. Implicit Grant - 암묵적 승인 방식

자격 증명을 안전하게 저장하기 힘든 클라이언트(JavaScript 등을 사용한 브라우저)에게 최적화된 승인 방식

권한 부여 승인 코드 없이 바로 Access Token이 발급된다. 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 사용 가능하다.

이 방식은 권한 서버, 리소스 서버, 클라이언트가 모두 같은 시스템에 속해 있을 때 사용해야 하는 방식이다.

 

4. Client Credentials Grant - 클라이언트 자격증명 승인 방식

클라이언트의 자격증명 만으로 Access Token을 획득하는 방식

가장 간단한 방식으로 클라이언트 자신이 관리하는 리소스 혹은 권한 서버에 해당 클라이언트를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우 사용된다.

자격증명을 안전하게 보관할 수 있는 클라이언트에서만 사용되어야 한다.

Refresh Token은 사용 불가

 

[참고]

https://blog.naver.com/mds_datasecurity/222182943542

OAuth 2.0 동작 방식의 이해