[OAuth2.0] OAuth 2.0이란?

OAuth 2.0이란?

목차

1. OAuth 등장 배경

2. OAuth 2.0이란?

3. OAuth2.0 의 프로토콜 흐름(Protocol Flow)

4. OAuth2.0 의 프로토콜 권한 부여 방식 4가지

---

 

 

1. OAuth 등장 배경

요즘은 사용자가 서비스를 이용할 때 소셜 로그인으로 로그인을 하는 경우가 많습니다. 혹은 구글 캘린더에 일정을 추가하거나 소셜에 컨텐츠를 공유하는 등의 기능들도 할 수 있습니다. 이 기능을 구현하려면 사용자의 정보를 구글이나 카카오 등으로부터 제공받아 우리 서비스에 저장하고 활용할 수 있어야 합니다. 하지만 상대의 입장에서는 우리 서비스가 안전하게 사용자의 정보를 저장하고 관리할 거라는 확신이 없을 수 있습니다. 혹시 사용자의 정보가 유출될 경우 피해의 범위가 정보를 제공해준 곳으로까지 커지게됩니다. 또한 서비스에 부여된 권한을 회수하는 일도 번거롭습니다. 이러한 문제를 해결하기 위해  구글은 AuthSub, 야후는 BBAuth 등 각각의 회사들이 독자적으로 개발을 진행했습니다. 하지만 이러한 방식은 표준화 되어있지 않아 서비스를 이용하기 위해 연동해야하는 과정이 복잡해졌습니다. 각각의 회사에 맞춰서 개발하고 유지보수를 해야했으니까요. 그래서 등장한 것이 바로 OAuth입니다. 최조 1.0 버전을 시작으로1.0a 버전이 출시되었으나 모바일 어플리케이션 등에서 안전하게 사용할 수 없는 사례가 존재했습니다. 이러한 문제들을 보완하여 기존의 버전보다  좀 더 단순화한 OAuth2.0 버전이 2012년 등장했습니다.

 

OAuth의 필요성 10가지

1. 사용자 정보 공유의 필요성: 웹 서비스들이 서로 협업하거나 상호작용할 필요성이 증가함에 따라, 사용자의 정보를 다른 서비스에 공유하는 방법이 필요해졌습니다.
2. 보안과 편의의 균형: 사용자는 여러 서비스에서 편리한 로그인 경험을 원하면서도, 개인 정보 보호와 보안도 중요하게 생각했습니다.
3. 비밀번호 공유 문제: 기존 방식으로는 각 서비스마다 사용자 비밀번호를 공유해야 하는데, 이는 보안과 관리상의 문제를 야기했습니다.
4. 중재자의 필요성: 서비스 간 인증을 위해 중립적인 중재자가 필요한 상황이었습니다.
5. 인증 표준화 요구: 서로 다른 웹 서비스 간에 통합되고 표준화된 인증 방식의 필요성이 대두되었습니다.
6. 권한 관리의 어려움: 사용자는 특정 서비스에 대한 권한을 효율적으로 관리하고 철회할 필요가 있었습니다.
7. API 사용의 증가: 서비스는 다른 서비스의 데이터나 기능을 사용하려는 API 호출이 증가하면서, 이를 위한 효율적이고 안전한 방법이 필요했습니다.
8. 소셜 미디어의 등장: 소셜 미디어 플랫폼이 부상하면서 서로 다른 플랫폼 간의 연결이 중요해졌습니다.
9. 사용자 경험 개선: 사용자는 여러 서비스를 사용할 때마다 반복적으로 로그인해야 하는 번거로움을 해소할 필요가 있었습니다.
10. 보안과 개인정보 보호 강화: 사용자의 민감한 정보를 제3자에게 직접 공유하지 않으면서, 안전하게 서비스 간 인증과 권한 부여를 가능하게 하는 방법이 필요했습니다.

 

2. OAuth 2.0이란?

OAuth 2.0(Open Authorization 2.0, OAuth2)은 인증을 위한 개방형 표준 프로토콜입니다.

구글, 페이스북, 트위터와 같은 다양한 플랫폼의 특정한 사용자 데이터에 접근하기 위해 제3자 클라이언트(우리의 서비스)가 사용자의 접근 권한을 위임(Delegated Authorization)받을 수 있는 표준 프로토콜입니다.

 

2-1 역할에 따른 명칭

명칭	설명
Resource Owner	리소스 소유자로 본인의 정보에 접근할 수 있는 자격을 승인하는 주체를 말합니다. Resource Owner는 클라이언트를 인증(Authorize)하는 역할을 수행하고, 인증이 완료되면 동의를 통해 권한 획득 자격(Authorization Grant)을 클라이언트에게 부여합니다. (ex 카카오로그인 계정을 가진 사용자)
Client	Resource Owner의 리소스를 사용하고자 접근 요청을 하는 어플리케이션 입니다. Resource Server의 자원을 이용하고자 하는 서비스. 보통 우리가 개발하려는 서비스를 지칭합니다.
Resource Server	Resource Owner의 정보가 저장되어 있는 서버입니다. 해당 서버에 token과 함께 데이터 요청을 보냅니다.
Authorization Server	권한 서버입니다. 인증/인가를 수행하는 서버로 클라이언트의 접근 자격을 확인하고 Access Token(필요하다면 refresh token도)을 발급하여 권한을 부여하는 역할을 수행합니다.

 

2-2 주요 용어

이름	설명
Authentication (인증)	인증, 접근 자격이 있는지 검증하는 단계입니다.
Authorization (인가)	자원에 접글할 권한을 부여하고 리소스 접근 권한이 담긴 Access Token을 제공합니다.
Access Token	리소스 서버에게서 리소스 소유자의 정보를 획득할 때 사용하는 Token입니다.
Refresh Token	Access Token 만료시 이를 재발급 받기위한 용도로 사용하는 Token입니다.

 

2-3 Access Token와 Refresh Token 

 

OAuth2.0이 지원하는 여러가지 권한 부여 방식들의 공통점은 토큰을 사용한다는 점입니다. 토큰의 종류는 Access Token과 Refresh Token이 있습니다. 하지만 OAuth2.0에서는 접근 토큰 및 재생 토큰이 가져야 할 특정한 형식을 지정하고 있지 않습니다. 다시 말해, 개발자가 임의로 토큰을 구현할 수 있도록 설계되어있습니다. 실제로 현업에서의 경우 토큰을 JWT 형식으로 구현하고 있습니다.

 

• Access Token
  Access Token은 사용자의 데이터에 접근하기 위해 필요한 자격증명으로서 사용자가 특정 앱에게 부여한 권한에 대한 정보가 담긴 문자열입니다. Access Token에는 접근할 수 있는 특정 scope들과 접근 가능한 기간 등 사용자가 동의한 사항들에 대한 정보가 담겨 있습니다. 이 정보에 기반하여 권한 제공기관 및 데이터 제공기관은 앱의 요청에 응하게 됩니다. 카카오 소셜 로그인을 예로들면, 성별, 이메일, 닉네임 등의 정보를 제공할 것인지 선택할 수 있는 계정을 입력하면 동의하기 단계가 있습니다. 사용자가 직접 접근 권한에 동의한 정보들만 클라이언트가 카카오로부터 제공받을 수 있습니다.

 

• Refresh Token
  누구든지 유효한 Access Token을 보유하면 통제된 데이터에 접근할 수 있게 됩니다. 이때 Access Token이 노출될 경우, 그 피해를 최소화하기 위해 일반적으로 Access Token의 유효기간을 짧게 설정합니다. 공격자가 불법적으로 접근할 수 있는 시간을 줄여 그 피해를 줄이는 방식입니다. Access Token의 유효기간이 만료되었을 경우 Access Token을 재발급 받아야하는데 이때 사용자는 이용하던 서비스로부터 로그아웃되는 경험을 하게 됩니다. 유효기간이 짧을수록 더 자주 이러하 불편을 겪게됩니다. 이러한 문제에 대비하기 위해 Refresh Token을 사용할 수 있습니다. Refresh Token을 활용하면 사용자에게 인증을 반복하게 하지 않고도 Access Token을 새로 발급 받을 수 있게 됩니다. 만약 사용자가 글을 작성하던 도중 Access Token이 만료될 경우 작성하던 페이지를 벗어나 로그아웃되는 경험을 하게 됩니다. 이러한 경우 사용자의 사용 경험에 악영향을 줄수 있습니다. 이때 Refresh Token으로 Access Token을 재발급 하게 되면 사용자는 로그아웃되지 않고 계속 글을 작성할 수 있습니다.

 

 

3. OAuth2.0 의 프로토콜 흐름(Protocol Flow)

[그림1] OAuth 2.0 프로토콜 절차적 흐름도

 

① Client - Resource Owner(사용자)

1-1 Client -> Resource Owner

• 클라이언트측에서 리소스 소유자(사용자)에게 사용자 데이터에 접근하기 위한 권한을 요청합니다. 개념상 클라이어트측에서 사용자에게 요청하지만, 실제로는 클라이언트측과 사용자 사이에서 권한 제공 기관이 중개 역할을 하는 경우가 일반적입니다. 

1-2 Resource Owner -> Client

• 접근에 동의함을 증명하는 권한 부여 동의서(Authorization Grant)를 발급합니다. RFC 6749에서는 4가지 유형의 권한 부여 동의서를 정의하고 있습니다. 서비스의 유형 및 권한 제공 기관의 지원 여부에 따라 사용할 권한 부여 동의서의 유형이 결정됩니다.

 

② Client -  Authorization Server(권한 제공 기관)

2-1 Client -> Authorization server

•  권한 부여 동의서를 제출하여 Access Token을 요청합니다. 

2-2 Authorization server -> Client

• 권한 부여 동의서를 확인하여 사용자가 동의한 데이터 항목, 범위 및 기간 등에 대한 정보가 담긴  Access Token을 제공합니다.

 

③ Client - Resource Server

3-1 Client -> Resource Server

• Access Token을 제출하여 사용자 데이터를 요청합니다. 

3-2 Resource Server -> Client

• 사용자 데이터를 제공합니다. 이때 앱이 제출한 Access Token이 유효함을 확인하고, Access Token의 정보를 확인하여 제공할 데이터 항목, 범위 및 유효기간이 정해집니다.

 

 

4. 권한 부여 방식

OAuth 2.0 프로토콜에서는 다양한 클라이언트 환경에 적합하도록 권한 부여 방식에 따른 프로토콜을 4가지 종류로 구분하여 제공하고 있습니다.

 

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

권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식으로 많이 쓰이고 기본이 되는 방식입니다. 간편 로그인 기능에서 사용되는 방식으로 클라이언트가 사용자를 대신하여 특정 자원에 접근을 요청할 때 사용되는 방식입니다. 보통 타사의 클라이언트에게 보호된 자원을 제공하기 위한 인증에 사용됩니다. Refresh Token의 사용이 가능한 방식입니다. 승인 코드 유형은 신뢰성 높은 앱이 사용하기에 최적화 되어 있습니다. 승인 코드를 사용할 경우 Access Token 뿐만아니라 Refresh Token도 요청할 수 있습니다. 승인 코드는 리디렉션 기반 절차를 활용하기 때문에 앱은 사용자의 에이전트(user-agent)를 통해 사용자와 상호작용할 수 있어야 하며, 또한 권한 제공기관으로부터 Redirection URI에서 요청을 수신할 수 있어야 합니다.

 

[그림 2] 승인 코드 유형 권한 부여의 절차적 흐름도

 

① Client -> UserAgent -> Authorization Server(Authorization endpoint)

클라이언트는 user-agent 상으로 사용자를 Authorization Server(권한 제공 기관)의 Authorization endpoint로 안내합니다. 클라이언트는 Client identifier(클라이언트의 식별자, 요청하는 scope, 로컬 상태) 및 Redirection URI에 대한 정보도 함께 전송합니다. 사용자가 접근 권한 부여에 동의하면 Authorization Server(권한 제공 기관)은 사용자를 Redirection URI로 이동시키게 됩니다.

 

② Authorization Server -> UserAgent -> Resource Owner

Authorization Server(권한 제공 기관)은 사용자에 대한 인증을 수행하고 클라이언트의 접근 요청에 대한 사용자의 동의 여부를 확인합니다.

 

③ Authorization Server -> UserAgent -> Client

사용자가 클라이언트의 접근에 동의하면 Authorization Server(권한 제공 기관)은 Authorization Code(승인 코드)를 발급하고 클라이언트가 요청한 Redirection URI로 user-agent를 안내합니다. 이때 사용되는 Redirection URI에 Authorization Code(승인 코드)와 클라이언트가 요청 시 제출한 로컬 상태에 대한 정보가 포함됩니다.

 

④ Client -> Authorization Server 

클라이언트는 발급받은 Authorization Code(승인 코드)를 Authorization Server(권한 제공 기관)의 Token endpoint에 제출하고 Access Token을 요청합니다. 이 때 클라이언트에 대한 인증 정보와 함께 클라이언트가 Authorization Code(승인 코드)를 제공받은 Redirection URI를 제출함으로써 Authorization Server(권한 제공 기관)은 클라이언트의 요청이 유효함을 검증할 수 있도록 합니다.

 

⑤ Authorization Server -> Client 

 권한 제공기관은 앱을 인증하고 승인 코드가 유효함을 확인하며, Access Token 요청에 제출된 Redirection URI가 승인 코드를 발급한 Redirection URI와 일치함을 확인합니다. 모든 사항에 문제 없음이 확인되면, Authorization Server(권한 제공 기관)은 Access Token을 발급합다. 이때 요청되었을 경우 Refresh Token도 함께 제공합니다.

 

 

 

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

자격증명을 안전하게 저장하기 힘든 클라이언트(ex: JavaScript등의 스크립트 언어를 사용한 브라우저)에게 최적화된 방식입니다.

암시적 승인 방식에서는 권한 부여 승인 코드 없이 바로 Access Token이 발급 됩니다. Access Token이 바로 전달되므로 누출의 위험을 방지하기 위해 만료기간을 짧게 설정하여 전달됩니다.  보안을 유지하기 위해 Refresh Token 사용이 불가능한 방식이며, 이 방식에서 권한 서버는 client_secret를 사용해 클라이언트를 인증하지 않습니다. 암묵적 유형의 권한 부여 방식은 단일 페이지(Single Page) JavaScript 앱을 위해 만들어진 방식입니다. Access Token을 획득하기 위한 절차가 간소화되기에 응답성과 효율성은 높아지지만 Access Token이 URL로 전달된다는 단점이 있습니다.

 

[그림 3] 암묵적 승인 유형 권한 부여의 절차적 흐름도

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

 

① Client -> UserAgent -> Authorization Server(Authorization endpoint)

클라이언트는 user-agent 상으로 사용자를 Authorization Server(권한 제공 기관)의 Authorization endpoint로 안내합니다. 클라이언트는 Client identifier(클라이언트의 식별자, 요청하는 scope, 로컬 상태) 및 Redirection URI에 대한 정보도 함께 전송합니다. 사용자가 접근 권한 부여에 동의하면 Authorization Server(권한 제공 기관)은 사용자를 Redirection URI로 이동시키게 됩니다.

 

② Authorization Server -> UserAgent -> Resource Owner

Authorization Server(권한 제공 기관)은 사용자에 대한 인증을 수행하고 클라이언트의 접근 요청에 대한 사용자의 동의 여부를 확인합니다.

 

③ Authorization Server -> UserAgent -> Client

사용자가 클라이언트의 접근에 동의하면 Authorization Server(권한 제공 기관)은 Access Token를 발급하고 앱이 요청한 Redirection URI로 user-agent를 안내합니다. 

 

 

4-3. Resource Owner Password Credentials Grant │ 자원 소유자 자격증명 승인 방식

간단하게 username, password로 Access Token을 받는 방식으로 사용자 비밀번호 인증 유형이라고도 합니다.

클라이언트가 타사의 외부 프로그램일 경우에는 이 방식을 적용하면 안됩니다. 자신의 서비스에서 제공하는 어플리케이션일 경우에만 사용되는 인증 방식입니다. Refresh Token의 사용도 가능합니다. 사용자가 클라이언트에 직접 ID/비밀번호로 로그인하여 인증하고 권한 부여에 동의하면 접근 토큰을 발급하는 유형입니다. 사용자 비밀번호 인증 유형의 권한 부여 방식은 클라이언트가 운영체제일 경우와 같이 사용자와 클라이언트 사이에 높은 신뢰가 형성된 경우에 적합합니다. 따라서 권한 제공기관은 다른 유형의 권한 부여 방식이 불가한 특수한 경우에만 사용자 비밀번호 인증 방식이 사용되도록 해야합니다.

[그림 4] 자원 소유자 자격증명 유형 권한 부여의 절차적 흐름도

제공하는 API를 통해 username, password을 전달하여 Access Token을 받는 방식입니다. 중요한 점은 이 방식은 권한 서버, 리소스 서버, 클라이언트가 모두 같은 시스템에 속해 있을 때 사용되어야 하는 방식이라는 점입니다.

 

 

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

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

OAuth2의 권한 부여 방식 중 가장 간단한 방식으로 클라이언트 자신이 관리하는 리소스 혹은 권한 서버에 해당 클라이언트를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우 사용됩니다. 이 방식은 자격증명을 안전하게 보관할 수 있는 클라이언트에서만 사용되어야 하며, Refresh Token은 사용할 수 없습니다. 권한 소유자가 클라이언트인 경우로,  클라이언트가 발급 받은 Client ID와 Client Secret을 확인하여 클라이언트에 대한 인증을 수행하고 권한을 부여 받습니다. 클라이언트 인증(Client Credentials) 유형을 사용하는 방법은 사용자 비밀번호 인증 유형을 사용하는 방법과 유사합니다. 

[그림 5] 클라이언트 자격증명 유형 권한 부여의 절차적 흐름도

 

---

참고 문서

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-OAuth-20-%EA%B0%9C%EB%85%90-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC

https://charming-kyu.tistory.com/36

https://www.2e.co.kr/news/articleView.html?idxno=208594 

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-OAuth-20-%EA%B0%9C%EB%85%90-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC#oauth%EB%9E%80? 

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